System Architecture

The overall view of the MTS, as currently implemented, is shown in Fig-ure 3.1. The message service component on the upper left binds the

com-Service API

Figure 3.1: The Message Transfer Service architecture

ponents together and is the main interface for applications. We describe this main component in this chapter and leave the internals of other com-ponents to later chapters. In the figure,EM is an encodable message that will be serialized by the protocol layer, andBMis a sequence of bytes that will be parsed by the message service component.

The MTS is divided into three separate components, themessage service, themessage protocol, and theXML serialization. All of these provide generic interfaces and have at least two implementations each. The message proto-col and XML serialization components are the topics of later chapters.

In Figure 3.1 the message service component provides two interfaces to the outside world: theservice API and theprotocol framework. The for-mer is for use by messaging applications, and the latter is for pluggable protocols. We have, in fact, implemented several different protocols using the message service’s protocol framework, but Abstract Mobile Message Exchange (AMME) is the most featureful of these.

The service API provides a class for messages, instances of which are constructed by applications and passed to the message service for delivery.

The data in messages can be specified either as XML or as a collection of name-value pairs. The names in the latter are hierarchical, and also seri-alized as hierarchical XML. SOAP headers may also be specified for mes-sages, but for them only XML is available.

Various properties required by the MTS to direct and correlate messages are specified in SOAP headers. This is similar to Web Services Address-ing [126], except that we use simple strAddress-ings and numbers instead of URIs.

For example, each message gets a unique identifier so that responses to messages can be dispatched to the proper target.

Messages are always directed atdestinations. In essence, a destination is a Uniform Resource Locator (URL) separated into component parts. Its

components are protocol, server address, server port, and target. The pro-tocol names a Message Transfer Propro-tocol (MTP), and may in addition in-cludefeaturesthat specify additional information on the type of connection required. The server address and port are the same as in normal HTTP URLs. The target is the local name of the target on the server side and is used to dispatch the message.

The two basic message sending operations aresendfor one-way mes-sages and sendCallback for asynchronous two-way messages. The basic two-way messaging operation needs a callback object provided by the ap-plication that is then invoked when the response arrives. The callback style of two-way messaging is simple, yet powerful, permitting different Mes-sage Exchange Patterns (MEPs) to be easily implemented.

The invocation method of the callback interface permits a message to be returned by the application. If the received message was one for which a response was expected, indicated by a specific SOAP header, the service will send the returned message back. As the application can also mark this message as one to which a response is expected, the callback style can easily be used to implement the conversation MEP, which consists of a sequence of messages sent back and forth between the parties.

The service supports two different kinds of callback objects. Persistent ones are explicitly registered by the application and they remain known until the application deregisters them. Transientones, on the other hand, are generated by the service for a single MEP and are deregistered after the MEP has completed. Each non-one-way message carries a SOAP header to identify its sender. If this sender is a persistent one, the receiver can store it and use it at any later time as a message target. This can be used to provide the subscribe/notify MEP.

We also provide other semantics for two-way messaging, all imple-mented generically on top of the callback interface. The other major asyn-chronous two-way style, polling, is implemented as afutureobject [33] that is registered as the callback. By forcing a synchronization of the future object immediately, it is possible to provide a synchronous two-way invo-cation. For reasons detailed above, we do not, however, recommend using the synchronous request-response pattern. These other semantics only sup-port request-response interaction, as specifying more flexible semantics for these styles is not feasible.

As with the rest of the system, the service API is a generic one, permit-ting multiple implementations. We provide two of these, which we call the Axis serviceand theLye service. The Axis service is built around theApache Axis² SOAP implementation, and only alters the protocol processing and serialization performed by Axis. AsFigure 3.1shows, we also provide the standard Axis API to applications to permit some compatibility with

stan-2http://ws.apache.org/axis/

dard Web services. As Axis is not usable on mobile devices, we imple-mented from scratch the Lye service for the Java MIDP platform. The Lye service is intended as a very simple one that should be suitable for mobile devices.

Chapter 4