Because businesses, institutions, and technologies change continually, the software systems that serve them must be able to accommodate such changes. Following a merger, the addition of a service, or the expansion of available services, a business can ill afford to recreate its information systems. It is at this most critical point that it needs to integrate new components or to scale existing ones as efficiently as possible. The easiest way to integrate heterogeneous components is not to recreate them as homogeneous elements but to provide a layer that allows them to communicate despite their differences. This layer, called middleware, allows software components (applications, enterprise java beans, servlets, and other components) that have been developed independently and that run on different networked platforms to interact with one another. It is when this interaction is possible that the network can become the computer.
conceptually, middleware resides between the application layer and the platform layer (the operating system and underlying network services).
Middleware can be grouped into the following categories:
■ Remote Procedure Call or RPC-based middleware, which allows procedures in one application to call procedures in remote applications as if they were local calls. The
middleware implements a linking mechanism that locates remote procedures and makes these transparently available to a caller. Traditionally, this type of middleware handled procedure-based programs; it now also includes object-based components.
■ Object Request Broker orORB-based middleware, which enables an application’s objects to be distributed and shared across heterogeneous networks.
■ Message OrientedMiddleware or MOM-based middleware, which allows distributed applications to communicate and exchange data by sending and receiving messages.
All these models make it possible for one software component to affect the behavior of another component over a network. They are different in that RPC- andORB-based middleware create systems of tightly-coupled components, whereasMOM-based systems allow for a looser coupling of components. In an RPC- orORB-based system, when one procedure calls another, it must wait for the called procedure to return before it can do anything else. As mentioned before, in these models, the middleware functions partly as a super-linker, locating the called procedure on a network and using network services to pass function or method parameters to the procedure and then to return results.
Advantages of connecting distributed components using message-oriented middleware
Message OrientedMiddleware makes use of messaging provider to mediate messaging operations. The basic elements of aMOMsystem are clients, messages, and the MOMprovider,which includes an API and administrative tools. TheMOMprovider uses different architectures to route and deliver messages: it can use a centralized message server or it can distribute routing and delivery functions to each client machine. SomeMOMproducts combine these two approaches.
Using aMOMsystem, a client makes an API call to send a message to a destination managed by the provider. The call invokes provider services to route and deliver the message. Once it has sent the message, the client can continue to do other work, confident that the provider retains the message until a receiving client retrieves it. The message-based model, coupled with the mediation of the provider, makes it possible to create a system of loosely-coupled components. Such a system can continue to function reliably, without downtime, even when individual components or connections fail.
JMS as a MOMStandard
To have created a standard that included all features of existing systems would have resulted in system that was hard to learn and difficult to implement. Instead, JMS defined a least common denominator of messaging concepts and features. This resulted in a standard that is easy to learn and that maximizes the portability of JMS applications across JMS providers. It’s important to note that JMS is an API standard, not a protocol standard. It is easy to move a JMS client from one vendor to another. But different JMS vendors typically cannot communicate directly with one another.
In order to send or receive messages, a JMS client must first connect to a JMS provider which is often implemented as a message broker: the connection opens a channel of communication between the client and the broker.Next, the client must set up a session for creating, producing,and consuming messages. You can think of the session as a stream of messages defining a particular conversation between the client and the broker. The client itself is a message producer and/or a message consumer. The message producer sends a message to a destination that the broker manages. The message consumer accesses that destination to consume the message. The message includes a header, optional properties, and a body. The body holds the data; the header contains information the broker needs to route and manage the message; and the properties can be defined by client applications or by a provider to serve their own needs in processing messages. Connections, sessions, destinations, messages, producers, and consumers are the basic objects that make up a JMS application.
Using these basic objects, a client application can use two messaging patterns (or domains) to bsend and receive messages. These are shown in below.
Clients A and B are message producers, sending messages to clients C,D, and E by way of two different kinds of destinations.
■ Messaging between clients A, C, andDillustrates the point-to-point pattern. Using this pattern, a client sends a message to a queue destination from which only one receiver may get it.No other receiver accessing that destination can get that message.
■ Messaging between clients B, E, and F illustrates the publish/subscribe pattern. Using this broadcast pattern, a client sends a message to a topic destination from which any number of consuming subscribers can retrieve it. Each subscriber gets its own copy of the message.
Message consumers in either domain can choose to get messages synchronously or asynchronously. Synchronous consumers make an explicit call to retrieve a message;asynchronous consumers specify a callback method that is invoked to pass a pending message.Consumers can also filter out messages by specifying selection criteria for incoming messages.
Administered Objects
Two messaging elements that JMS does not completely define are connection factories and destinations. Although these are fundamental elements in the JMS programming model, there were so many existing and anticipated differences in the ways providers define and manage these objects, that it was neither possible nor desirable to create a common definition.
Therefore, these two objects, rather than being created programmatically, are normally created and configured using administration tools. They are then stored in an object store, and accessed by a JMS client through standard JNDI lookups.
■ Connection factory administered objects are used to generate a client’s connections to the broker. They encapsulate provider-specific information that governs certain aspects of messaging behavior: connection handling, client identification, message header overrides,reliability, and flow control, and so on. Every connection derived from a given connection factory exhibits the behavior configured for that factory.
■ Destination administered objects are used to reference physical destinations on the broker. They encapsulate provider-specific naming (address-syntax) conventions and they specify the messaging domain within which the destination is used: queue or topic.JMS clients are not required to look up administered objects; they can create these objects
programmatically (which are then stored in the broker’s memory). For quick prototyping,creating these objects programmatically might be easiest. But for deployment in a production environment, looking up administered objects in a central repository makes it much easier to control and manage messaging behavior:
■ By using administered objects for connection factory objects, administrators can tune messaging performance by reconfiguring these objects. Performance can be improved without having to recode.
■ By using administered objects for physical destinations, administrators can control the proliferation of these destinations on the broker by requiring clients to access these preconfigured objects.
■ Administered objects shield developers from provider-specific implementation details andallow the code they develop for one provider to be portable to other providers with little or no change.
To Use Administered Objects as Destinations
1.The administrator creates a physical destination on the broker.
2.The administrator creates a destination administered object and configures it by specifying the name of the physical destination to which it corresponds and its type: queue or topic.
3.The message producer looks up the destination administered object using a JNDI lookup call.
4.The message producer sends a message to the destination.
5.The message consumer looks up the destination administered object where it expects to get messages.
6.The message consumer gets the message fromthe destination.
The process of using connection factory administered objects is similar.
1.The administrator creates and configures a connection factory administered object using administration tools.
2.The client looks up the connection factory object and uses it to create a connection.
Although the use of administered objects adds a couple of steps to the messaging process, it also adds robustness and portability to messaging applications.
The MessageQueue Service
both application clients and administration clients can connect to the broker. The JMS specification does not dictate that providers implement any specific wire
protocols.Message Queue services, used by application clients and administration clients to connect to the broker, are currently layered on top of TCP, TLS, HTTP, or HTTPS protocols.(Services layered on top of HTTP allow messages to pass through firewalls.)
■ Services that provide JMS support and allow clients to connect to the broker (jms, ssljms, http, or https) have a service type of NORMAL and are layered on top of TCP, TLS, HTTP, or HTTPS protocols.
■ Services that allow administrators to connect to the broker ( admin, ssladmin) have a service type of ADMIN and are layered on top of TCP or TLS protocols.
By default, when you start the broker, jms and admin services are up and running. Additionally, you can configure a broker to run any or all of these connection services. Each service supports specific authentication and authorization (access control) features and each service is multi-threaded, supporting multiple connections.
Should a connection fail, theMessage Queue service can automatically retry connecting the client to the same broker or to a different broker if this feature is enabled. For more information, see the description of the automatic reconnect feature in Appendix B, “Message Queue Features”
Clients can configure connection runtime support when they create the connection factory from which they obtain their connections. Options allow you to specify which brokers to connect to, how to handle reconnection, message flow control, and so on. For additional information about how connections can be configured, see “Connection Factories and Connections” on page 38.
The Broker
At the heart of the message service is the broker, which routes and delivers messages reliably, authenticates users, and gathers data for monitoring performance.
■ To route and deliver messages, the broker places incoming messages in their respective destinations and manages message flow into and out of these destinations.
■ To provide reliable delivery, the broker uses a persistent store to save state information and persistent messages until they are received. Should the broker or the connection fail, the saved information allows the broker to restore the broker’s state and to retry operations.
■ To provide security for the data being exchanged the broker uses authenticated connections.Optionally data may be encrypted by running over a secure protocol like SSL. The broker also uses and manages a repository that holds information about users and the data or operations they can access. The broker authenticates users requesting services and authorizes the operations they want to carry out by looking up information in this repository.
■ To monitor the system, the broker generates metrics and diagnostic information that an administrator can access to measure performance and to tune the broker.Metrics information is also available programmatically to allow applications to adjust message flow and patterns to improve performance.
TheMessage Queue service provides a variety of administrative tools that the administrator can use to configure broker support. For more information, see “Administration” on page 28.
Java and C Client Support
The Java client runtime supplies Java clients with the objects needed to interact with the
broker. These objects include connections, sessions, messages, message producers, and
message consumers.
SOAP Support for Java Clients
Message Queue Java clients are also able to send and receive SOAP messages, wrapped as JMS
messages. SOAP (Simple Object Access Protocol) allows the exchange of structured data
between two peers in a distributed environment. The data exchanged is specified by an XML
scheme.
Administration
TheMessage Queue service offers command line tools that you can use to do the following:
■ Start and configure the broker.
■ Create and manage destinations, manage broker connections, and manage broker
resources.
■ Add, list, update, and deleted administered objects in a JNDI object store.
■ Populate and manage a file-based user repository.
■ Create and manage a JDBC compliant database for persistent storage.
You can also use a GUI-based administration console to perform the following command-line
functions:
■ Connect to a broker and manage it.
■ Create and manage physical destinations.
■ Connect to an object store, add objects to the store, and manage them.
Scaling the MessageQueue Service
As the number of clients or the number of connections grows, you may need to scale the message service to eliminate bottlenecks or to improve performance. TheMessage Queue message service offers a number of scaling options, depending on your needs. These may be conveniently sorted into the following categories:
■ Vertical scaling is achieved by adding more processing power and by expanding available resources. You can do this by adding more processors or memory, by switching to a shared thread model, or by running the JavaVM in 64 bit mode. If you are using the point-to-point domain, you can scale the consumer side by allowing
multiple consumers to access a queue. Using this approach, you can specify the maximum number of active and backup consumers. The load-balancing mechanism also takes into account a consumer’s current capacity and message processing rate. This is a Message Queue feature. (The JMS specification defines messaging behavior if only one consumer is accessing a queue; behavior for queues allowing more than one consumer is provider-specific. TheMessage Queue developer guides provide more information about this scaling option.)
■ Stateless horizontal scaling is achieved by using additional brokers and redistributing existing clients to these brokers. This approach is easy to implement, but it is appropriate only if your messaging operations can be divided into independent work groups.
■ Stateful horizontal scaling is achieved by connecting brokers into a cluster. In a broker cluster, each broker is connected to every other broker in the cluster as well as to its local application clients. Brokers can be on the same host or distributed across a network.Information about destinations and consumers is replicated on all the brokers in the cluster. Updates to destinations or subscribers is also propagated Each broker can therefore route messages from producers to which it is directly connected to consumers that are connected to other brokers in the cluster. In situations where backup consumers are used, if one broker or connection fails, messages sent to inaccessible consumers can be forwarded to a backup consumers on another broker. In the event of broker or connection failure, state information about persistent entities (destinations and durable subscriptions) can get out of sync. For example, if a clustered broker goes down and a destination is created on another broker in the cluster, when the first broker restarts, it will not know about the new destination.Message Queue uses two different models to resolve this problem:
conventional clustering and high availability clustering.
■ Using conventional clustering, you set broker properties to designate one broker in the cluster to be the master broker. This broker is responsible for tracking all changes to destinations and durable subscriptions in a master configuration file and for updating brokers in the cluster that are temporarily offline.
When using a master broker,Message Queue only provides service availability, not data availability in the case of broker or connection failure. For example, if a clustered broker becomes unavailable, any persistent messages held by that broker become unavailable until that broker recovers. To get data availability you can use a SunClusterMessage Queue agent or you can use high availability clustering, described next. (In the SunCluster case, a persistent store is kept on a shared file system. If a broker fails the Message Queue agent on a second node starts a broker that takes over the shared store. Clients are reconnected to that broker, thereby getting both continuous service and access to persistent data.)
■ Using high availability clustering, you set broker properties to specify a highly available database that is shared by all brokers in the cluster. The shared store holds updated information about the state of each broker in the cluster. If one broker fails, another broker assumes ownership of the failed broker's persistent state (in the shared store) and provides uninterrupted service to the failed broker's clients.For additional information, see Chapter 4, “Broker Clusters,”
the next blogs will be following with more things about this topic.