Chapter 1   iPlanet Trustbase Transaction Manager Architecture


The iPlanet Trustbase Transaction Manager is designed to fulfil the need for Identrus enabled message oriented middleware for Financial Institutions. The platform provides a means of offering Financial Services Applications over the Internet that are consistent and re-useable.

Overview

---

Within a multi-tiered architecture, the iPlanet Trustbase Transaction Manager component is the middle tier infrastructure that provides the ability to offer new function, but shields first tier clients from the complexity of the existing enterprise infrastructure (see Figure 1-1).

Figure 1-1    Three Tier Architecture

In order to achieve this, the iPlanet Trustbase Transaction Manager is designed to be:

• Highly available

• Secure

• Reliable and scalable

It achieves this by using server side standards such as Servlets and EJB and leverages the existing reliability and scalability functions of the iPlanet Application Server.

The iPlanet Trustbase Transaction Manager Platform extends the iPlanet Application Server function by providing a message-handling pipeline that may be extended to process specific message types and formats. This message-handling pipeline contains four major components:

• Transport listeners

• Presentation and formatting handlers

• Routing and authorisation management

• Business logic plug ins

The message pipeline is populated with a set of components that provide all of the necessary pre-processing to support applications using the Identrus messaging protocol and HTML based communication.

The operational side of the iPlanet Trustbase Transaction Manager platform is augmented by a toolkit that allows the developer to generate message classes and deploy the completed application. This is designed to reduce the development effort required to produce applications that conform to the Identrus requirements to an absolute minimum.

External interfaces

---

The iPlanet Trustbase Transaction Manager is a middleware component that provides a means of accessing and using existing legacy data sources over the Internet. In order to provide this function the platform must be capable of:

• Listening and processing web protocols - HTTP, HTTPS, SMIME

• Accessing existing legacy systems via JDBC, CORBA, RMI

• Using resources provided by other servers on the Web

Figure 1-2 shows how these external interfaces relate to the iPlanet Trustbase Transaction Manager component.

Figure 1-2    iPlanet Trustbase Transaction Manager Interfaces

Transport protocols

The iPlanet Trustbase Transaction Manager supports three basic transport protocols:

• SMTP - Asynchronous mailed based communication

• HTTP - Synchronous insecure communication

• SSL - Secure synchronous communication

iPlanet Trustbase Transaction Manager listeners proxy the SMTP and SSL transport protocols to provide both a means of processing, and a means of logging transport specific data. Any HTTP data is listened for directly by the Web Server.

These three transport protocols provide a means of carrying a variety of application level messaging. The iPlanet Trustbase Transaction Manager contains presentation components that deal directly with:

• SMIME wrapped XML or HTML

• HTML

• Identrus compliant XML application messages

The iPlanet Trustbase Transaction Manager platform may be extended to support other application messaging protocols as required.

Enterprise connectivity

The iPlanet Trustbase Transaction Manager business logic is designed so that the business logic implemented by the developer may use all of the standard connectivity components available within the J2EE platform. Standard J2EE connectivity components include:

• JDBC - Access to relational databases

• RMI and CORBA - Access to remote objects and EJB's

• JNDI - Access to directory and naming services

• JMS - Message oriented interfaces for use with message queues e.g. MQ Series

The iPlanet Trustbase Transaction Manager business logic is also capable of utilising the underlying connectivity components provided by the iPlanet Application Server for access to internal systems. These enterprise connectors include interfaces for:

• R/3 - Enterprise Resource Planning

• CICS - IBM Mainframe integration

• BEA Tuxedo - Transactional data systems

• Peoplesoft - Enterprise Resource Planning

Server to server connectivity

The iPlanet Trustbase Transaction Manager platform provides a means of abstracting the transport and presentation formats used by the incoming message within the presentation component. The same mechanism (through a different API) is used to allow a business service to make requests of other servers.

The Identrus Certificate Status Check (CSC) service uses this connector functionality to provide a means of determining the validity of a certificate at a particular point in time. (See Chapter 2 Presentation logic.)

Routing

The router provides a mechanism for imposing structure and ordering on the execution of services in a secure way. It acts as a gatekeeper to ensure that services are only executed by authorised individuals and in an appropriate context. A user of the system will connect to the server and then exchange messages. At the highest level, the user will be trying to accomplish a task. Some tasks will require authorisation (and therefore authentication) prior to being performed; services may also perform tasks in a slightly different fashion depending on the identity of the user making the request.

The Router has been designed with the following in mind:

• Authentication and authorisation is kept separate from business logic.

• Configuration and management of the routing table is easily implementable and not error prone.

• Complex solutions can be built where required

• Implementing a simple solution is not difficult

• Services can implement atomic business level functions and are independent of one another.

The function of the router is central to the iPlanet Trustbase Transaction Manager platform. All messages are passed through a router, and, based on the current context of the message and its contents, the router will accept or reject the message for processing.

In order to define a flexible mechanism for routing, capable of working within a variety of complex environments, iPlanet Trustbase Transaction Manager provides rule based routing. This allows a means of modifying, and extending, the behaviour of the iPlanet Trustbase Transaction Manager installation over a period of time without the need to modify existing modules or services. See also Chapter 3 Routing for more details on this.

Authorisation

The basic requirement of being able to gate service access is met by the ability to route a message based not only on the message type, but also on its current level of authorisation. Within iPlanet Trustbase Transaction Manager, authorisation is considered an extension of authentication i.e. in understanding who a person is, we can determine what they are allowed to do.

The authentication mechanisms of iPlanet Trustbase Transaction Manager are not a separate component. Authentication data is gathered by the default iPlanet Trustbase Transaction Manager framework. This can then be added toby domain specific services. The platform provides a default authorisation service that is capable of mapping both a username and password, or a digital certificate onto a user group or role. The router then ensures that when a service is accessed, the role has been authorised for access to that service.

Developers are at liberty to replace the default authorisation service with a mechanism that maps user information onto existing repositories such as an enterprise directory service. See also Chapter 3 Routing for more information on this.

Services

Business services are at the heart of an e-commerce application, and the iPlanet Trustbase Transaction Manager provides a means of registering services written by the developer into the platform. These services need not be concerned with processing transport specific information, presentation specific information, authentication of the user, or authorisation of a users request. This allows the developer to concentrate on the function of the application, and integration of existing systems into a web enabled infrastructure. See also Chapter 5 Standard Services for more information on this.