Section 14.3. Technology

14.3. Technology

The service concept of Deutsche Post's SBB is similar to the Web service concept. Web technologies such as SOAP and HTTP are combined with reliable messaging through an underlying MOM-based on JMS (Java Messaging Service). Furthermore, the SBB supports important features such as version management, safety, and dynamic binding and thus offers enriched functionality compared to standard Web services. For the future, Deutsche Post plans to publish SBB services as Web services based on WS-I Basic Profile 1.0.^[8]

^[8] WS-I Basic Profile 1.0 is a profile developed by WS-I (Web Services Interoperability) to ensure interoperability between Web services platforms from different vendors (see http://www.wsi.org).

14.3.1. ARCHITECTURE

The SBB is built of three key components, which we will describe in detail (see [HS03]):

• Local SBB interface

• Central infrastructure components

• Technical service participants

Local SBB interfaces enabling the connection are implemented in each service participant. There are two kinds of local SBB interfaces: Service providers use a Service Programming Interface (SPI), whereas service consumers are connected by an Application Programming Interface (API). When a consumer calls a service, it uses the API, sending a message that contains the input parameters. This message (XML) is sent to the provider's SPI by SBB, and the requested operation is started.

For the processing of a service call, two central infrastructure components are involvedthe Service Registry (currently based on LDAP, UDDI in development) and the message queue (based on JMS). To ensure high availability, Deutsche Post replicates and clusters these infrastructure components. Figure 14-4 shows a service call using SBB functionality.

This call information mainly consists of an XML document containing attributes of the business objects that are to be created, manipulated, or modified. Additional parameters can be used to control synchronous or asynchronous behavior or other aspects, such as the number of results to be returned when calling a search service.

The Service Registry is the central source for all information needed for the communication between service participants. It should be noted that all interfaces always access the Service Backbone, regardless of their interaction style, which can be synchronous, asynchronous, publish/subscribe, or request/reply. Which interaction type is used depends on the business requirements. When calling the interface, the interaction type is passed through a parameter.

The call to the Service Backbone is realized as a Java call, where the main argument containing the business object information is represented as an XML document. The structure of the XML documents is described through service-specific XML Schemas. Internally, SOAP is used on top of Java, and there are also wrappers and adapters for C++ and non-XML arguments.^[9] Actually, before the Service Backbone initiative started, the IT Strategy of Deutsche Post was based on C++. The need to easily integrate the associated software assets using the aforementioned wrappers and adapters is a major requirement of the new SOA.

^[9] For the Java wrappers of C++-Code the product Junc++ion from codemesh is used, which supports various C++ dialects, including GNU and .NET.

The Service Backbone itself is built in a loosely coupled fashion, relies on standards, and avoids proprietary features. Although for example MQ Series is used for message handling, no proprietary features are used. Instead, connection to MQ Series is realized by using the JMS interface. A similar approach is used with other components in order to ensure that products can be easily interchanged and no vendor-dependency is created by using non-standard features.

Deutsche Post currently uses various technical service participantsincluding Transformation, Service Registry Administration, Data Integration, and Single Sign On. Privilege Management and Service Registry are candidates planned for further releases.

14.3.2. REPOSITORY, SERVICE INTERFACES, AND CONTRACTS

In order to maximize reusability, Deutsche Post designed their service operations in a rather coarse-grained fashion. When retrieving customer data, for example, almost 100 attributes are returned by the service, which then can be filtered on the client side. The alternative would have been to perform filtering within the service, which would have restricted reusability.

Exceptions to this general approach are only made in the context of critical performance requirements. Although it is important to insist on generic and reusable interfaces, it is also necessary to remain flexible and sometimes acknowledge the need for a custom-built interface. However, these exceptions have been minimized as far as possible and were only authorized if there were very convincing arguments for them.

The registry contains information about all services currently available at Deutsche Post's Division Mail. For each service, an XML Schema describing the XML document it expects as an argument is specified in the registry. In addition, information regarding binding and IP addresses is specified, as well as some meta information, concerning service-level agreements for example.

Currently, the registry implementation is based on LDAP. Deutsche Post is planning to use UDDI as the basis for its registry in the future. This is mainly motivated by the desire to keep up with development in Web services.

14.3.3. CHOREOGRAPHY, SECURITY, AND MANAGEMENT

There is currently no support for distributed transactions or workflow management within Deutsche Post's Service Backbone. These topics are seen as important challenges both from the business and technical perspectives. However, currently the process logic is implicitly contained in the service implementation and is not explicitly modeled in a declarative process format. The Service Backbone is thus only responsible for the transport of data between the service consumer and the service provider.

Although the Service Backbone is logically a centralized component, its physical realization is highly distributed. This is to ensure loose coupling and to avoid bottlenecks and single points of failure created by centralized solutions. Approximately 90% of its functionality runs locally based on libraries, which are installed throughout the network. As we have already mentioned previously, there are only two centralized components, the directory and the queue.

As a consequence, there is no central control of all the interaction between service consumers and providers on all machines in the network. Monitoring is thus currently restricted to local monitoring. In the future, this will have to be enhanced in order to provide unified information about the overall system behavior. However, it is not yet clear how to achieve this without violating the principle of loose coupling.

Finally, security is realized through modeling access rights based on users, groups, and roles. Access rights are checked on the general service and operation level. Because use is so far restricted to intra-corporate applications within the demilitarized zone, no encryption is performed. This would be necessary for supporting external usage.