HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

Beyond the JMS Specification, by David Chappell and Bill Cullen

The Java Message Service (JMS) is a specification put forth by Sun to define a common set of APIs and common semantics for messaging-oriented middleware providers. An increasing number of MOM vendors have embraced this specification, and new vendors are building messaging products suitable for doing business-to-business communication across the Internet.

The result is a landscape where developers can feel comfortable about writing an application using a standard set of APIs while still having an ample selection of JMS-compliant vendors to choose from. However, the JMS specification is intentionally agnostic when it comes to deployment architectures. Today's B2B environment requires much more than is commonly dictated by the specification, and all JMS vendors have been racing to the finish line to build the additional infrastructure to keep pace with the demands of large-scale e-business messaging deployment over the Internet.

In this article we'll discuss some of the real-world issues beyond the JMS specification. In particular we'll focus on large-scale B2B deployments, and explain how the "beyond JMS" capabilities are a key component of the Commerce One e-marketplace solution.

About Commerce One. . .
Commerce One, through its software, services, and Global Trading Web of interconnected business communities, enables worldwide commerce on the Internet. They are the leading force behind the Global Trading Web, the world's largest business-to-business global trading community, connecting thousands of e-marketplaces around the globe. Through Commerce One.net, Commerce One provides the technology and business services that allow these global trading partners to work together sucessfully.

Commerce One's solutions include:

  • Enterprise Buyer: An e-procurement application
  • MarketSite: Assists Internet market makers in building open marketplaces and linking them to the Global Trading Web
  • MarketSet: Based on the MarketSite platform; provides a specific set of infrastructure and applications for the direct goods and supply chain management market segments
The JMS Specification

The JMS spec prescribes a clear set of rules of engagement between an application and an enterprise messaging middleware. They include:

  • Standard APIs for establishing connections, and the sending and receiving of messages
  • Loosely coupled asynchronous communication between applications or between components of applications
  • A publish-and-subscribe model for a one-to-many broadcast of information, and a point-to-point queuing model for establishing many-to-one or a one-to-one conversational pipe between distinct endpoints
  • Quality of service options for message delivery, including once-and-only-once guaranteed delivery, at-most-once delivery, all-or-nothing transactional grouping of messages, and guaranteed ordering; determined by a strict set of rules governing message persistence and store-and-forward capabilities, which are held together by a well-defined set of message acknowledgement semantics
  • Failure conditions, error handling, crash recovery, message redelivery
  • A broad range of message types capable of transporting any kind of application data in a convenient fashion, and a rich set of methods for constructing and deconstructing messages on either side of a conversation
Beyond JMS: Requirements of E-Business Messaging
Traditional MOM vendors built products intended to carry data between a relatively small set of applications within the four walls of an enterprise. However, if you consider the kind of messaging infrastructure that is capable of supporting the likes of the Commerce One e-marketplace solution, a whole new set of requirements is necessary. Consider these requirements in the context of the diagram shown in Figure 1:

figure 1
Figure 1: Trading partners participating in a supply chain through an e-marketplace

  • Massive scalability: Concurrently connecting tens of thousands of trading partners in a single trading exchange, and connecting multiple trading exchanges together
  • Fault tolerance and high availability
  • Geographically dispersed applications: Using the Internet as a means of communicating in a secure and reliable fashion; being secure and firewall-friendly via the use of Secure Sockets Layer (SSL) and HTTP protocols
  • End-to-end security: Through the use of PKI, digital certificates, mutual authentication, Access Control Lists (ACL)
  • Segregation of application domains: Protecting data that is private to an application domain while still being able to selectively expose message queues to the other participants across the domains; this is key, whether communicating between geographically dispersed locations within a single company or between trading partners participating in a trading exchange
  • Simple and flexible deployment configurations: Separation of physical deployment topology from the client applications that use the messaging system
  • Server-to-server-based architecture: Minimum number of "moving parts" or processes reduces number of failure points and network hops; preferable over an IP multicast architecture when conducting business across corporate boundaries. Considering the number of gateways or bridges that need to be installed/maintained in order to move across firewalls and network router boundaries, the perceived benefits of IP multicasting diminish quickly
Commerce One chose SonicMQ as the way to connect these pieces. The basic benefits of JMS, combined with the e-business messaging capabilities of the SonicMQ, allowed them to delegate the responsibility of scalable, secure, guaranteed delivery of data to a best-of-breed JMS provider suitable for the task.

The key enabling technology that fulfills the e-business messaging requirements of this equation is referred to as dynamic routing architecture (DRA)

Massive Scalability via DRA
DRA is a messaging server technology that allows increased message volumes to be handled as needed without reconfiguring application programs or requiring significant administrative overhead. The DRA approach eliminates the need to accommodate topology changes and connectivity issues by dynamically adjusting as needed to support changes in messaging configuration. Additional message servers may be added transparently to support additional external connections or to scale up internal systems to handle increased message traffic.

As illustrated in Figure 2, groups of servers, called clusters, may connect to other groups of servers as needed, creating highly distributed deployments across loosely coupled locations. The high throughput performance of each JMS server minimizes the number of servers needed in these configurations to handle large messaging volumes.

figure 2
Figure 2: A distributed topology based on DRA

DRA provides robust, on-demand connection management to eliminate excessive resource use on single servers and the corresponding communication infrastructure. Message senders and receivers may be distributed dynamically across groups of servers to fully utilize resources. DRA connections between clusters enable distributed groups of servers to communicate seamlessly when needed. A connection may be established only when there are messages to send, or may be connected continuously. DRA determines the best path for a message destination dynamically and creates a connection if necessary. As connections are made, messaging destinations dynamically become available throughout the DRA system.

Hardware and communication failures are also handled by DRA, with failover for connections and transparent store-and-forward capabilities for destinations that are temporarily unavailable. The features listed above allow messaging servers to be deployed with maximum efficiency while maintaining high availability.

Parallel Cluster Technology
Parallel clustering allows clusters of one or more servers to be created as needed within the messaging infrastructure. Clusters allow multiple servers to support as many JMS connections as necessary, while providing transparent cluster-wide access to messaging destinations (see Figure 3).

figure 3
Figure 3: JMS Server cluster

The clustering architecture of DRA minimizes overhead through a loosely coupled design. Topology and destination changes are broadcast in parallel with participating clusters and servers, minimizing overhead as routing paths change dynamically.

Minimal administrative overhead within and between DRA clusters results in the full utilization of server capacity for messaging tasks. Communication between servers is predominantly used to deliver messages, providing predictable, linear scalability as servers are added to the cluster.

Active Route Optimization
DRA features active route optimization, which allows named destinations to be reached within the system by message senders regardless of connection and topology changes. The ability to actively locate destinations by name eliminates the need to reconfigure application code as messaging servers are changed or scaled to higher volumes.

Active route optimization allows clients to be distributed across multiple servers and reach message destinations dynamically from the server they're connected to, without configuration. To handle additional connections for an application, a server may be added at any location in a distributed system, which is immediately used to handle additional client traffic (see Figure 4).

figure 4
Figure 4: Multiple connections handled by a DRA cluster

Message routing is a key element of the DRA server cluster technology. Through routing, when a message destination is added, it's immediately accessible by all messaging clients regardless of the machine within the cluster they're currently connected to. For example, a new incoming connection from a trading partner can immediately be used throughout the system to reach message destinations at that trading partner. Destinations within a firewall or across the Internet are immediately available throughout the cluster once they're connected with DRA.

As illustrated in Figure 5, active route optimization is used to route a request for a quote to an e-marketplace pricing application, which then creates a message destined for a supplier's quote application. The messages are delivered through the optimal path to their destination.

figure 5
Figure 5: Messages routed using active route optimization

Active route optimization enables applications to be run and replicated as needed. Replication allows application services to be added to support increased application traffic. Within a cluster, duplicate destination names on different servers may be created to replicate application services on multiple machines and achieve high scalability. Messages will be routed to the nearest application service when received at a server (see Figure 6).

figure 6
Figure 6: Replicated application services

Application services may be configured to receive messages from multiple messaging servers, allowing additional load on one message server to be handled on demand by multiple application services. On-demand load balancing ensures that no application waits for work while any JMS server has messages available. On-demand load balancing also enhances system resiliency; application services continue operation in the event of a message server machine failure, and message servers can continue to handle clients if an application machine fails.

DRA allows messaging servers and application services to be deployed in the topology most suitable to achieve the performance and resiliency necessary for high-volume applications.

Multiple Cluster Configuration and Naming
Connections between servers allow all destinations within a cluster to be reached from other clusters. Each cluster is given a routing node name that uniquely identifies it within the rest of a DRA-based system. Destinations are named in a manner similar to e-mail addresses.

Configurations with tens of thousands of clusters can be supported within a single naming system using DRA. Unique destinations across a routing connection may be found by specifying a routing node name and a destination name, allowing for unique names to be created and reached on a global scale. Destinations specified without a node name are resolved within the cluster to allow for simple local operation, while node names are required to reach destinations across cluster-to-cluster connections. Duplicate destination names in different clusters don't conflict, and may be reached individually by specifying the appropriate node name.

Internet Connection Management
To maximize server use, DRA supports load balancing for incoming client as well as server connections. Load balancing spreads incoming connections across the servers in a cluster after an initial connection is made. For resiliency in the case of a server failure, load-balanced connections may have multiple initial points of connection and support a failover reconnect to other servers should a connection be lost.

Connections in DRA are made on demand for messaging between servers, and can be made from either side of a routing connection when needed to deliver messages. An inactivity timeout can be specified for a connection to either maintain or avoid a long-duration connection when no messages are being sent.

When a connection can't be made to a destination, messages are stored in the sending server until forwarded for delivery. The store-and-forward capability allows guaranteed messaging to continue despite short- or long-term interruptions in connectivity. Messages saved for forwarding may be persisted to disk when large volumes must be retained. When a cluster is able to establish a connection to a destination, all messages will be delivered to the newly accessible location, regardless of which server connected to the destination last, which side initiated the connection, or where messages were stored.

End-to-End Security
Server and cluster-level security allows full access control between groups of users and destinations in the DRA architecture. A company may provide a trading partner with access to any selected part of its messaging system and be assured that other aspects of the system are fully protected. DRA ensures the isolation of security domains from each other by preventing information about DRA clusters from reaching unwanted destinations.

Mutual authentication of clients and other DRA clusters is handled by a choice of authentication technologies to guarantee the identity of incoming connections; full privacy is supported through the use of SSL and payload encryption features. DRA provides a system-wide PKI digital certificate capability that fully secures trading partner relationships. Through secure DRA, JMS servers may be employed both inside and outside firewalls with HTTP tunneling capability and forward and reverse proxy support.

Administration
A cluster of servers may be managed as a single entity, allowing user information, routing connections, and security settings to be administered with a single operation. Multiple clusters may be managed using a single-configuration database, and from a single administrative console screen. Notifications of system events are available to assist in the management of distributed operation. All administrative functions, including notifications, are also available from a programmatic interface.

Servers maintain full configuration information locally, eliminating the need for server interaction when handling messages. Local configuration allows each server to function even if centralized configuration information is temporarily unreachable.

Exception Handling Beyond the JMS Spec:
Dead Message Queue

For each server, a dead message queue (DMQ) is used as the ultimate destination for any message not delivered in the DRA system. A message that can't be routed due to changing configuration will end up in this queue. Messages that exceed their time to live can also be placed in the DMQ. Destinations that aren't reachable within predetermined time limits may have pending messages added to the DMQ. The DMQ is accessible to applications as a normal queue and provides notifications as messages are added to it. A message in the DMQ will remain intact, including its intended destination and a code explaining why it arrived in the DMQ. A custom application can be written to read messages from the DMQ and decide what to do based on business rules.

Conclusion
JMS, combined with the proper deployment architecture, such as dynamic routing architecture, solves today's e-business messaging needs of connecting enterprises in a secure, reliable, and highly scalable fashion.

DRA provides the simplicity and flexibility needed to deploy e-business applications within an infrastructure that can grow and scale. Application functionality may be added as and where needed, with the appropriate level of messaging performance to support it. Dynamic routing ensures that applications are insulated from infrastructure changes, and that new messaging connections may be added at any time.

Resources

  1. SonicMQ:www.SonicMQ.com
  2. MiddlewareSpectra's article on Commerce One's middleware selection criteria: www.sonicmq.com/whitepapers/mws.pdf
Author Bios
Dave Chappell is chief technology evangelist for Sonic Software's SonicMQ, and coauthor of O'Reilly's Java Message Service. Mr Chappell can be contacted at [email protected]

Bill Cullen has been developing and managing software projects for over 18 years. As director of software engineering for Sonic Software, he plays a key role in engineering the architecture and performance for SonicMQ, one of the first products to implement the Java Message Service specification. Mr. Cullen can be contacted at [email protected]

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.