|WHITE MESA SOFTWARE|
|Home Download Links Documentation|
An Email/HTTP Gateway Service for SOAP
The White Mesa Email/HTTP Gateway Service implementation consists of:
This application allows a loosely coupled mode of accessing a SOAP service node, without the need for directly connecting to the service via HTTP as usual. SOAP request messages are pulled down from a POP3 mailbox periodically and then forwarded to the associated SOAP service node for processing. In this way:
What's new in Version 1.0?
This is the initial release.
The White Mesa Email/HTTP Gateway for SOAP server functions as a POP3 client which periodically polls a list of one or more POP3 mailboxes (on one or more hosts) for messages. It expects these to be MIME messages wrapping SOAP Request message envelopes per the proposed SMTP Transport Binding for SOAP. The MIME messages are expected to be of Content-Type "text/xml" with character encodings "utf-8", "utf-16", and "us-ascii" accepted. These messages are also expected to be encoded for email transport with Content-Transfer-Encoding mechanisms "base64" or "quoted-printable" (only). After each mailbox is polled, a worker thread is created to process the messages that have been retrieved from it, while the POP3 client moves on to the next mailbox in the list. The worker thread proceeds to process the messages retrieved from the mailbox in the background.
The SOAP request message envelope is extracted from the MIME wrapper, and the Content-Transfer-Encoding of the message (e.g. "base64") is reversed to obtain the original message content. Other relevant information is stored, e.g. the message ID and the return address to which the response message needs to be sent.
If the mailbox is configured to submit received messages to a "filter" component for processing, the message is converted to a BSTR (UTF-16) and passed along to the filter. The filter component serves to apply any transformations that may be needed, e.g. applying an XSLT transformation to the XML document contained in the SOAP request. The output of the filter is received as a BSTR (UTF-16) and is then converted to UTF-8 encoding. If no filter is configured for input message processing, the message retains its original character encoding.
An HTTP connection is then opened and the SOAP request message sent to the service node associated with the mailbox (the URL of the node is a configuration item).
The SOAP response message from the service node is received, and if the mailbox is configured to submit the message to a "filter" component for processing, the message is converted to a BSTR (UTF-16) and passed along to the filter. The filter component serves to apply any transformations that may be needed, e.g. parsing the SOAP response message envelope and generating a non-XML prose message expressing the information received in the SOAP response (for human readers). The output of the filter is received as A BSTR (UTF-16) and is then converted to UTF-8 encoding. If no filter is configured for output message processing, the message retains its original character encoding (as indicated by the "Content-Type" HTTP header found in the HTTP response).
The response message is packaged in a MIME message, and the Content-Transfer-Encoding used in the request message is applied to it. The proper "Content-Type" and "Content-Transfer-Encoding" headers are inserted. A "Message-Id" header is generated for the response message, and the "Message-Id" value of the request message is referenced in the "In-Reply-To" header. Also, the value of the "Subject" header received in the request message is echoed back as the value of the "Subject" header in the response message.
An SMTP session is then initiated with the SMTP host associated with the mailbox (the host name and port nbr are configuration items). The response message is then sent to the return address contained in the request message.
Finally, an entry recording information about the message is written to the log file if
logging has been enabled. Enabling the "verbose" mode causes the contents of the request
and response messages to be written to the log as well. Here is an example of a non-verbose log
The Gateway Server supports the use of COM Automation Servers as message "filters" to allow user defined processing to be applied to:
A VB implementation (in an ActiveX Dll project) might look like this:
The "Message" parameter contains the SOAP message envelope, and the "IsInputMsg" parameter is used to distinguish between a call to process an input message and a call to process an output message. This is useful if a single Automation Server is specified as both the input and output filter. It is the duty of the filter component to return a BSTR value containing the transformed SOAP message. In the case of the input filter, this message is immediately forwarded to the SOAP service node over HTTP, and must represent a proper SOAP request message envelope. In the case of the output filter, this message is sent back to the client as a MIME message over SMTP. It may be desirable in some cases for the output filter to transform the SOAP response message into a non-XML message suitable for human readers.
Configuration of the Gateway Server is accomplished with a GUI tool, "wmsmscp.exe". This is a standalone application which is used to:
Service Descriptions may be added, edited, or deleted, and the general settings maintained.
Here is a view of the Service Description Editor:
A Service Description consists of the following information:
The Gateway Server at one time or another acts as a POP3 client, an HTTP client, and an SMTP client. This functionality is implemented by classes WMPOPSocket, WMHTTPRequestSock, and WMSMTPSocket respectively. These inherit from class WMWinSocket2, a Winsock2 client socket implementation. Additional details may be learned by looking at the source.
Platform and Compiler
Win32, using Winsock2. Developed using Visual C++ 6.0 and tested on Win2000. The standalone GUI configuration tool for the service is an MFC app.
Send questions, comments, etc. to:
|Home Download Links Documentation|
Copyright ರ00, 2001 by Robert Cunnings. firstname.lastname@example.org Last modified: Dec 31, 2001