Messaging helps move Java into the
enterprise - JavaWorld January 1999
Tutorial Details:
Messaging helps move Java into the enterprise
Messaging helps move Java into the enterprise
By: By Todd Sundsted
Find out how the Java Message Service API helps developers create more robust enterprise applications
essaging is playing an increasingly important role in enterprise computing. Its advantages are a natural result of several factors: the trend toward peer-to-peer computing, greater platform heterogeneity, and greater modularity, coupled with the trend away from synchronous communication between processes.
In its effort to stay on top of important industry trends, Sun announced last April (at the 1998 JavaOne Developer Conference) its plans to publish the Java Message Service (JMS) API, an interface for using existing enterprise messaging systems in a uniform manner. The version 1.0 specification, which was released in July, provides a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product.
Since its release, almost twenty vendors have stepped up to endorse the specification (including companies like IBM, Oracle, and BEA) and four companies have produced implementations: Etsee Soft, Fiorano Software, Modulus Technologies, and Push Technologies.
Messaging services
Rather than communicate directly with each other, the components in an application based around a message service send messages to a message server. The message server, in turn, delivers the messages to the specified recipients. This might seem like an extra, unnecessary layer of software, but the advantages a message service provide often outweigh this single disadvantage. The message service model is much like the model behind the postal service. We could directly deliver our own mail, but letting someone else do it greatly simplifies our life.
The common building block of a messaging service is the message. Messages are events, requests, and replies that are created by and delivered to enterprise applications. Messages contain formatted data with specific business meanings.
Beyond the message, however, messaging services display a surprising degree of diversity. For example, a messaging service may:
Allow messages to be prioritized
Deliver messages either synchronously or asynchronously
Guarantee messages are delivered once and only once
Support message delivery notification
Support message time-to-live
Support transactions
In addition, every messaging service packages these capabilities slightly differently.
How does the JMS API fit in?
A key goal of the JMS API is to unify the packaging of these capabilities and to minimize the set of concepts a Java programmer must learn in order to use messaging products. As its secondary goal, it strives to maximize the portability of messaging applications.
Specific goals of the JMS API specification are to:
Provide a single, unified message API
Provide an API suitable for the creation of messages that match the format used by existing, non-JMS applications
Support the development of heterogeneous applications that span operating systems, platforms, architectures, and computer languages
Support messages that contain serialized Java objects
Support messages that contain XML pages
The JMS API is divided into two nearly identical pieces. One implements the point-to-point model of messaging, and the other implements the publish/subscribe model of messaging. Each of these models is called a domain. The APIs are almost identical between domains. This greatly improves the feeling of cohesiveness throughout the API.
The point-to-point and publish/subscribe models were selected because they represent the two largest paradigms behind existing messaging services. While sharing many characteristics, they differ in enough ways that they can be thought of as two separate services. They're not necessarily incompatible -- both can be used in an application. However, most applications tend to use one or the other. The separation of the API into two domains relieves vendors that support only one messaging model from providing facilities their product doesn't natively support.
The advantages of messaging
Messaging provides three clear advantages when used in an enterprise application.
First, it decouples resources. Messaging allows business components to be combined into a reliable, flexible system with extremely loose coupling between components. This characteristic is desirable for two reasons: it makes the application more modular (and therefore more open to reuse) and it makes the application more reliable (a failure in one part of the application is less likely to affect an unrelated part of the application).
Second, messaging provides scalability. An application built around a messaging architecture scales well as both clients and servers are added to the system. It will also scale well as the volume of messages increases.
Third, messaging masks both heterogeneity and change. Remember, the common element in a messaging application is the message. As long as components can read and understand the message, the platform on which they reside and the languages in which they're written is unimportant.
Putting theory into practice
The following two examples should help clarify the role and the function of messaging services in applications.
This first figure illustrates one typical messaging-based application. This application is a modification of the traditional client/server architecture. The major difference is the presence of a messaging product between client and server layers. Thus, rather than communicating directly, clients and servers communicate via the messaging service.
The addition of the messaging service adds another layer to the application, but it greatly simplifies the design of both the clients and the servers (they are no longer responsible for handling communications issues), and it greatly enhances scalability (more about this later).
This second figure illustrates another messaging-based application -- this one based on a point-to-point architecture.
This type of application almost demands a centralized messaging service. Without one, each component would be responsible for creating and maintaining connections with the other components. A possible alternative approach would be to architect the system around a communication bus, but this would still leave each component in charge of message delivery issues.
These two examples illuminate the advantages of messaging services mentioned earlier:
The application scales well. In the first example above, all that is required to increase server capacity is to add servers to the pool. The application itself doesn't have to be rearchitected. Likewise, when components fail the application degrades gracefully.
Communication is asynchronous. Components can perform other tasks while not busy handling requests. They can either poll the message server when ready or receive notification via a callback when a message is waiting. It is unnecessary to wait in a loop. This is an important consideration in applications like those in the second example.
The application is modular. The messaging service
is responsible for quality of service issues such as reliable delivery. This frees the components (which may be custom built) of the application from having to deal with these fairly generic issues.
The application is flexible. Because the application API is defined by the format of the messages exchanged, components of the system can run on almost any platform and can be written in almost any programming language. They can also be replaced with minimal system impact.
Note that the introduction of a messaging component admits a potential bottleneck and a single-point-of-failure into the system. Both of these issues can be address by replicating the messaging server and its content.
Conclusion
Based on vendor comments at this year's Java Business Expo, it appears likely that we'll see additional implementations of the JMS API over the next two quarters or so, so stay tuned for more on this simple, versatile enterprise technology.
This page formated for crawlers and browsers that don't support scripts and tables.
Home
EZone
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Messaging helps move Java into the
enterprise - JavaWorld January 1999
View Tutorial: Messaging helps move Java into the
enterprise - JavaWorld January 1999
Related
Tutorials:
 XML messaging, Part
3
XML messaging, Part
3
|
Connect the
enterprise with the JCA, Part 1
Connect the
enterprise with the JCA, Part 1
|
Implement a J2EE-aware application console in Swing
Implement a J2EE-aware application console in Swing
|
Cache SOAP services on
the client side
Cache SOAP services on
the client side
|
Step into
the J2EE architecture and process
Step into
the J2EE architecture and process
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Jabber away with instant
messaging
Jabber away with instant
messaging
|
J2SE 1.4
breathes new life into the CORBA community, Part
1
J2SE 1.4
breathes new life into the CORBA community, Part
1
|
Should you go
with JMS?
Should you go
with JMS?
|
Add concurrent processing with message-driven beans
Add concurrent processing with message-driven beans
|
Finally, getting hands in !
Finally, getting hands in !
|
Java Testing and Design
Java Testing and Java Test and Design is the companion to any book on Java software development practices, techniques, and testing. Software developers, QA analysts and IT managers working in large corporate IT groups, software development companies, and
|
Capture the benefits of asynchronous logging
Capture the benefits of asynchronous logging
Develop an asynchronous log service using JMS and Hibernate
This article will help you develop a simple log service. The service creates some log messages, sends them across the network to a JMS provider,
|
JMS Messaging Online Resource
JMS Messaging Online Resource
JMS Tutorials
JMS provides a way for Java programs to access an enterprise messaging system, also known as message oriented middleware (MOM). Check out the below tutorials.
|
Distributed Enterprise Messaging with MantaRay
A very important communication standard in Java is Java Messaging Service (JMS). JMS is a set of Java interfaces and associated semantics that define a way for a Java-based client to access a messaging system. JMS provides a rich, yet simple, set of messa
|
JSP (JavaServer Pages) is a standard for combining Java and HTML to provide dynamic content in web pages.
With JSP, you embed Java code in HTML using special JSP tags similar to HTML tags. You install the JSP page, which has a .jsp extension, into the WebLogic Server document root, just as you would a static HTML page. When WebLogic Server serves a JSP page..
|
Power Messaging, Maps and more...
BuddySpace is an instant messenger with four novel twists: (1) it allows optional maps for geographical & office-plan visualizations in addition to standard 'buddy lists'; (2) it is built on open source Jabber, which makes it interoperable with ICQ, MSN,
|
Getting Started with Java Message Service (JMS)
The Java Message Service (JMS) is designed to allow Java applications to use enterprise messaging systems. It makes it easy to develop enterprise applications that asynchronously send and receive business data and events. Learn how to implement it for you
|
J2ME Technology Turns 5!
In 2004 the Java 2 Platform, Micro Edition (J2ME) celebrated its fifth anniversary. This article presents where J2ME is today.
|
NetBeans IDE 4.1
Out-of-the-box support for J2EE 1.4 and Web Services. Check out what early access release 2 can do for you!
|
|
|
|
