A Distributed System in the PTP Domain

The Point-to-Point example is a business-to-business e-commerce system for delivering flowers worldwide via a network of local flower shops. The example is purely imaginary and would certainly require extensive additional features in order to be acceptable for real business use. Let's walk through the system first, and then enumerate the features that make it interesting from the architectural point of view.

The global flower deliver system allows a customer to order flowers from a fixed list of bouquet types and have them delivered to any address in any country that has affiliated local delivery agents. Customers can order via the World Wide Web, telephone, or in person at a local flower shop. The customer will receive one notification confirming the order, and another one confirming delivery. Notifications may be delivered by e-mail, fax, or ordinary snail mail. The system is centered on a JMS message server, and involves several other generic servers: database, e-mail, and fax.

The application-specific part of the system comprises several functional modules, each of which is either a complete Java application, or a library embedded in a larger Java application. All modules are JMS clients, and in addition, some of the modules are also JDBC clients. These clients execute distributed transactions that include both the JMS connection and the JDBC connection. It is assumed, then, that both of these services provide optional XAResource support so that they can act as resources in a JTA distributed transaction. This also implies that these modules are run within an application server that provides a JTA transaction manager. For simplicity, the application server and transaction manager are not shown explicitly in the diagram:

Note 

Each type of module is depicted by a different shape in the diagram. Arrows indicating the flow of information are only drawn for selected module instances, in order to keep the diagram comprehensible. In general, each instance of a module of the same type would have the same arrows to and from the JMS server and JDBC server. Note that the arrows only indicate logical message flow and not connections. There need not be more that one connection from a module to the message server.

We will walk through the steps in a normal (exception-free) flower delivery scenario, and explain each module in turn:

• Order Entry Module

  This is the point of contact with individual customers, so variations of this module are embedded in the web system (possibly as an EJB) and the call center application, as well as being available at local flower shops in the form of an application or an applet. Customers interact indirectly with this module to order flowers. The order details (address, bouquet type, delivery date, billing info, etc.) are packed into a JMS message and sent to the incoming queue of the JMS server. This module can also access the order tracking database to allow customers to check the status of their order. Orders can be submitted, though, even when the database is not available.

• Order Processing Module

  This module is a Java application that should run continuously on the systems of the flower network. It receives order messages from the incoming queue and inserts a record in the order tracking database. It then forwards the order message to the order queue. It also sends a message to the notification queue that contains the text of an order confirmation. In step 2a, the notification module receives the message from the notification queue and, depending on the indicated delivery preference, reformats and sends it to the printer, fax server, or e-mail server.

  All four interactions — consumption from the incoming queue, producing to the order queue and notification queue, and the insertion of a record into the database — are executed within one distributed transaction so that a failure of this module will not leave these steps partially completed. If an instance of this module fails partway though the processing of an order, the whole transaction will be rolled back, and the order will be effectively "pushed back" onto the incoming queue, as though the failed attempt never happened. It can then be consumed and processed by another instance of the order processing module.

• Fulfilment Module

  This module is a Java application or applet that runs at the various local shops that can fulfill the orders. In the case of an enterprise scale flower delivery service (let's pretend for the sake of the example that such a thing exists) this module could be embedded in the service's own order management system. Each instance of module will subscribe to the order queue using a message selector that selects only messages that lie within the delivery area of the local shop. In more sophisticated shops, this module might be tied into an inventory control system and the messages selector may further restrict the message delivery according to the flowers currently in stock. Another option for the more sophisticated shops is to receive the order and enter it into the local order processing system within a single distributed transaction. When the delivery is complete, a message is sent the status queue confirming this fact.

• Status Tracking Module

  This module has a function similar to that of the order processing module, and it is also a Java application that runs continuously on the systems of the flower network. It consumes messages from the status queue, updates the order tracking database, and sends a deliver confirmation to the notification queue. For each flower delivery, these steps are executed within one distributed transaction. In step 4a, the notification module formats the text from the notification queue and routes it to the appropriate delivery server.

Now that we know how the system works, let's take a look at some of the features that this message-based architecture provides:

• Distributed transactions (see Chapter 4 for details) are contained within one organization and never extend beyond the message server. Each distributed transaction is centered on one of the modules. It only involves local databases and the message server. It is never necessary for systems from organizations that otherwise never have direct contact to vote in the same two-phase commit. Thus your transaction will never fail due to a resource that is outside your control.

• There is no application-specific code in the message server. None of the system components that contain application code are in the message server, which means that this critical central hub executes exactly the same software that is in use in many other production systems and that was tested by the JMS vendor before shipping. Application-specific code, in contrast, is always new when the system first goes live, and often produced under time pressure. The likelihood of bugs is higher here, so it is advantageous when the system is not crippled by the failure of an application-specific component.

• Critical servers, such as the message server, are completely generic and can be maintained by an Application Service Provider (ASP). Thus the maintenance of the message server can be outsourced to an organization that can properly guarantee high availability and back up this guarantee with staff on site 24 hours a day and 7 days a week. Since the server is generic, the ASP does not need to learn how to care for your custom application, but can provide the same service that it may be providing to dozens of other customers. In the case that your application is not big enough to justify its own message server, your queues can coexist on the same server with those of other applications. With proper security configurations, this poses no problem.

• There can be any number of instances of each module. Multiple instances of the same module will process orders in parallel. This provides concurrency and load balancing of the application-specific component, without requiring application developers to explicitly program these features. If a module fails, the message that it is currently processing gets rolled back and will be dispatched to another instance automatically by the message server. If no instances of a module are running, the processing gracefully halts and resumes as soon as one or more instances come online. As each new instance comes online and connects to the message server, it begins sharing load automatically, with no additional administrative action required. Thus, the application gets fault tolerance, high availability, load balancing, and concurrency for free.

• As an extension of the previous point, new flower shops can be integrated into the system at any time. The only administrative action required is the configuration of access control on the server. Access control is, of course, required to ensure that unauthorized parties do not interfere with the system.

• A flower shop can alter the service it provides at any time. If it extends its delivery area, then it need only change the message selector used by its fulfillment module and it will start to receive orders to be delivered in this new area. Perhaps it will only deliver an order outside of its own area if it exceeds a certain amount. This can also be specified with message selectors.

• The diagram also shows a case in which a flower delivery truck is tied directly into the system via a wireless gateway. Remember that with JMS, it is not an exception when the recipient of a message is not available when the message is sent. This makes it ideal for a mobile client that could be in a tunnel at any given time (refer to Chapter 11 for disconnected devices).