Introduction
NetKernel is transport independent. It can process messages received by any application protocol.
Here we demonstrate how to configure NetKernel with the MailTransport
to process email messages.
Service Specification
We will describe a service which auto replies to every email arriving in a mailbox. We will provide a web interface to
manage the autoreply service - this will allow the service to be initially configured, started, stopped and for the autoreply message to
be customized. We shall generate the auto-reply message by making a further service request which may be written to serve either static or dynamic
content thus demonstrating service-oriented mail processing.
The completed module "trailmap email autoreply" is available for installation through the install wizard
.
The module should be installed into the front-end fulcrum so that the web-interface is exposed.
The module JAR file will be placed in your [install]/modules directory. You should unzip the JAR to view and modify the source.
After you've installed the module the service can be initialised and managed here
.
Fulcrum Module MailTransport Configuration
The MailTransport is dynamically configurable but it must be registered in a host module. If you inspect the module.xml configuration
you will find that the mail transport is registered with the following entry...
<transports>
<transport>org.ten60.mail.traccessor.MailTransport</transport>
</transports>
The MailTransport requires a minimal configuration to be provided at ffcpl:/etc/MailTransportConfig.xml.
You will see that the module has an /etc directory containing the MailTransportConfig.xml which is...
<mailTransportConfig>
<id>urn:org:ten60:netkernel:mail:service:autoreply:transport</id>
</mailTransportConfig>
In addition the /etc directory provides an SMTPConfig.xml file which provides the configuration for the SMTPServer
accessor, which is used to send emails via SMTP.
Finally the module imports the mod:smtp module, this is the library module containing the MailTransport classes, it's configuration services and the SMTPServer.
<import>
<uri>urn:org:ten60:netkernel:mod:smtp</uri>
</import>
Service Structure
The module is partitioned into 4 distinct parts. The /resources/ directory holds the primary DPML idocs which provide the web-interface
of the service. The /services/ directory holds the main services for servicing an autoreply message from the transport, generating a message
and processing updated transport configuration. Lastly /content/ and /transforms/ hold static content and stylesheets used by the web-interface.
Initialisation
The init.idoc serves a dynamically generated form containing the current configuration for the mail processor and the SMTP server. This form is submitted
to the services/process-config.idoc which uses mailproc-register
to register the new MailProcessor
with the MailTransport, mailproc-start
to start the newly registered processor. Finally it also stores
the SMTPServer config. After initialisation the browser is redirected to the main status.idoc.
Initialisation can be performed repeatedly - if new config is provided the old mailprocessor will be stopped and removed before the configuring the MailTransport
with the new MailProcessor.
Status
The status.idoc uses the mailproc-status
accessor to request the current status of the
autoreply mailprocessor from the MailTransport which it styles to produce the main management view.
Stop
The stop.idoc uses mailproc-stop
accessor to stop the
autoreply mailprocessor in the MailTransport.
Start
The start.idoc uses mailproc-start
accessor to start the
autoreply mailprocessor in the MailTransport.
Target Service
A MailProcessor registered with the MailTransport periodically polls a pop or imap mailbox for new mail messages. For each new message
received it invokes the service URI specified in the MailProcessor config. In this demo the default service is
active:dpml+operand@ffcpl:/resources/services/autoreply.idoc
which is the active URI to execute the DPML autoreply.idoc.
The MailTransport appends to the active target URI the message header and body part arguments.
In the autoreply.idoc the header argument is transformed to create a reply header (it simply swaps the contents of the "from" and "to" tags).
The autoreply.idoc next requests the reply message from the message.idoc service. By default this is a static greeting (the comments explain how
this could be modified to a dynamically generated greeting or to serve useful information, such as the current new headlines). Finally
the autoreply.idoc issues the message as an email reply using the SMTPServer.
You will note that the MailTransport and SMTPServer are asymetric - that is, MailTransport only ever receives messsages, SMTPServer only sends messages.
This is because email is intrinsically asnychronous and asymetric - email can be received by a number of different means (pop3, imap, maildir, mbox)
but is generally always sent via an SMTP server.