In addition to supporting RMI-based distributed business objects, Enterprise JavaBeans supports asynchronous messaging. An asynchronous messaging system allows two or more applications to exchange information in the form of messages. A message, in this case, is a self-contained package of business data and network routing headers. The business data contained in a message can be anything—depending on the business scenario—and usually contains information about some business transaction. In enterprise systems, messages inform an application of some event or occurrence in another system.
Asynchronous messages may be transmitted from one application to another on a network using message-oriented middleware (MOM). MOM products ensure that messages are properly distributed among applications. In addition, MOM usually provides fault-tolerance, load-balancing, scalability, and transactional support for enterprises that need to reliably exchange large quantities of messages. MOM vendors use different message formats and network protocols for exchanging messages, but the basic semantics are the same. An API is used to create a message, give it a payload (application data), assign it routing information, and then send the message. The same API is used to receive messages produced by other applications.
In modern enterprise-messaging systems, applications exchange messages through virtual channels called destinations . When you send a message, it’s addressed to a destination, not to a specific application. Any application that subscribes or registers an interest in that destination may receive that message. In this way, the applications that receive messages and those that send messages are decoupled. Senders and receivers are not bound to each other in any way and may send and receive messages as they see fit.
Enterprise JavaBeans integrates the functionality of MOM into its component model. This integration extends the EJB platform so that it supports both RMI and asynchronous messaging. EJB 2.0 and 2.1 support asynchronous messaging through the Java Message Service (JMS) and a new component called the message-driven bean. In addition to JMS, message-driven beans in EJB 2.1 can support other synchronous and asynchronous messaging systems.
Each MOM vendor implements its own networking protocols, routing, and administration facilities, but the basic semantics of the developer API provided by different MOMs are the same. It’s this similarity in APIs that makes the Java Message Service (JMS) possible.
JMS is a vendor-agnostic Java API that can be used with many different MOM vendors. JMS is very similar to JDBC in that an application developer can reuse the same API to access many different systems. If a vendor provides a compliant service provider for JMS, the JMS API can be used to send messages to and receive messages from that vendor. For example, you can use the same JMS API to send messages with Progress’s SonicMQ as with IBM’s MQSeries.
Enterprise JavaBeans 2.0 introduced a new kind of component, called a message-driven bean, which is a kind of standard JMS bean. It can receive and send asynchronous JMS messages, and can easily interact with other EJBs.
EJB 2.1 extends the programming model of the message-driven bean beyond JMS to any messaging system. While vendors must continue to support JMS-based message-driven beans (JMS-MDBs), other types of messaging systems are also allowed. It’s likely that vendors will develop new message-driven bean types to support all kinds of protocols, including SMTP for email, SNMP for device control, peer-to-peer protocols (e.g., BEEP and Jabber) and many other open and proprietary messaging systems. In addition, the message-driven bean has become an elegant option for serving connections to legacy transaction processing systems like CICS, IMS, openUTM, and others.
The expansion of message-driven beans in EJB 2.1 to other protocols is made possible by the new J2EE Connector Architecture (J2eeCA 1.5), which defines a portable programming model for interfacing with enterprise information systems. The use of J2eeCA in J2EE is analogous to the use of USB in computer hardware. A computer that supports USB can interface with just about any USB-compliant device. Similarly, an EJB 2.1 container that supports J2eeCA 1.5 can interface with any J2eeCA 1.5-compliant resource. For example, if XYZ Vendor creates a new message-driven bean component for their proprietary messaging system based on J2eeCA 1.5, that component will be portable across all EJB 2.1-compliant servers. Figure 1-3 illustrates how a J2eeCA for a messaging system integrates with EJB 2.1.
Message-driven beans in EJB 2.1 and 2.0 allow other applications to send messages that can be captured and processed by the EJB application. This feature allows EJB applications to better integrate with legacy and other proprietary systems.
Web services represent the latest wave in distributed computing, and perhaps the most important innovation since the introduction of Java in 1995 and XML in 1998. Although the term "web services” is bandied about quite a bit, arriving at a concrete definition is difficult because web services is, at the highest level, not specific to any particular technology or platform. It’s often defined in fairly abstract terms like “a substrate for building distributed applications using software running on different operating systems and devices”[5] or “self-contained, self-describing, modular applications that can be published, located, and invoked across the Web.”[6] Of course, these quotes are taken out of context, but that’s the essential point: you need some kind of context to define web services. Here’s my definition of web services that has meaning in the context of J2EE, EJB, .NET, and most other web services platforms:
Web services are network applications that use SOAP and WSDL to exchange information in the form of XML documents.
To understand this definition, you need to understand SOAP and WSDL. Here are brief definitions of these terms.
- SOAP 1.1
SOAP (Simple Object Access Protocol) is an XML grammar developed by Microsoft, IBM, and others, that is currently under the auspices of the W3C. It’s an application protocol used in both RPC and asynchronous messaging. SOAP is very flexible and extensible and, unlike its predecessors (DCE RPC, CORBA IIOP, Java RMI-JRMP, and DCOM), it’s been endorsed and adopted by just about every major vendor. (If you’re not familiar with XML, see Java and XML by Brett McLaughlin (O’Reilly) or XML in a Nutshell by Elliotte Rusty Harold (O’Reilly).
- WSDL 1.1
The Web Service Description Language (WSDL) is another XML grammar, developed by Microsoft and IBM under the auspices of the W3C. It is an XML-based IDL (Interface Definition Language) that can be used to describe web services, including the kind of message format expected, the Internet protocol used, and the Internet address of the web service.
Web services are truly platform-independent. Although Java RMI and CORBA IIOP also claim to be platform-independent, in fact these older technologies require their own platforms. To use Java RMI, you need a Java virtual machine and the Java programming language; a program written in Visual Basic or C++ can’t interact with a Java program using RMI. CORBA IIOP is also restrictive, because the IIOP protocol usually requires an elaborate infrastructure like a CORBA ORB, which limits developers to those few vendors that support CORBA, or to the Java environment (which includes built-in support for CORBA IIOP).
Web services, on the other hand, are not tied to a specific platform like the JVM or to a technology infrastructure like CORBA because they focus on the protocols used to exchange messages—SOAP and WSDL—not the implementation that supports those protocols. In other words, you can build web services on any platform, using any programming language any way you please.
EJB 2.1 allows enterprise beans to be exposed as web services, so that their methods can be invoked by other J2EE applications as well as applications written in other programming languages on a variety of platforms. Web services in EJB 2.1 supports both RPC-style and document-style messaging. Support for web services is based on a new web service API: JAX-RPC. Web services and the use of JAX-RPC is covered in detail in Chapter 14.
[5] Tim Ewald, “The Web Services Idea,” July 12, 2002, Microsoft.com (http://msdn.microsoft.com/webservices/understanding/readme/default.asp).
[6] Doug Tidwell, “Web services—the Web’s next revolution,” November 29, 2000, IBM.com (http://www-105.ibm.com/developerworks/education.nsf/webservices-onlinecourse-bytitle/BA84142372686CFB862569A400601C18?OpenDocument).