|
Comments
Did you read today's front page stories & breaking news?
SYS-CON.TV
|
Product Review SpiritWave from SpiritSoftA Flexible, Reliable Messaging System Tool
SpiritWave from SpiritSoftA Flexible, Reliable Messaging System Tool
By: Brian Barbash
Jan. 11, 2002 12:00 AM
Editor's Note: SpiritWave 4.4 from SpiritSoft is a vendor-independent, JMS-compliant messaging system that provides a common interface to heterogeneous messaging systems. It supports the publish/subscribe and point-to-point messaging paradigms. To leverage existing investments in messaging systems, SpiritWave provides transport drivers for IBM's MQ Series, Tibco's Rendezvous, Microsoft's MSMQ, OpenTrade's Orbita, and Active Software's ActiveWorks products. It also provides a pure Java JMS implementation for both queue-based and publish/subscribe messaging. Figure 1, from SpiritSoft's Web site, illustrates the overall architecture in which the SpiritWave messaging system interacts with third party transports.
Working with SpiritWave SpiritSoft provides a common administration architecture for all of its products, called SpiritAdmin. Configuration information is housed in XML data files that may be stored in various formats, including a JDBC-compliant database. SpiritWave's provided messaging transport comes in two flavors: Standard and Enterprise. The two drivers provide the same services with regards to message transportation, but the Enterprise component adds the capability to validate users and control access to destinations. It's optimized for a distributed enterprise messaging, whether queueing or publish/subscribe. Each messaging transport is fully configurable from the SpiritAdmin console provided. As mentioned earlier, SpiritWave contains several modules to allow message transport systems to become accessible via the JMS API. For the modules that provide access to the provided message queue, three options or modes exist: Unadministered, Administered, and Enterprise. Under the Unadministered configuration, the messaging system and its communicating clients aren't controlled from a centralized configuration mechanism. Configuration details are set up by the individual application and may be stored independently, often within a JNDI tree. In the Administered mode, the configuration details for the transport module are stored within the repository established for the SpiritAdmin framework. This repository may be, for example, XML files or a JDBC database. In the third option, Enterprise, the modules incorporate the user management and destination access services components of the SpiritAdmin architecture.
Development The first task in working with SpiritWave is to establish and bind the queue connection factory and a default queue into the JNDI tree. To accomplish this, a simple registration servlet executed at server startup will create the necessary objects and perform the binding. Once in the JNDI tree, the objects are available to clients and message-driven EJBs for processing. If the developer is working with WebLogic, the registration process is straightforward and easy to configure. SpiritSoft provides a startup class that takes no parameters and reads its configuration information from an XML file. The configuration file specifies all communication properties for SpiritWave and the JNDI binding information. Connections to the SpiritWave messaging system may be obtained in two ways. The first uses the standard JMS connection factories, queue or topic, appropriate for the task at hand. The second incorporates SpiritWave's WaveProfile object that defines the implementation details of the underlying transport. If a developer chooses the WaveProfile approach, it's incorporated in the creation of the connection factory. WaveProfiles separate the message transportation and storage mechanisms to provide flexibility to the developer and the application environment. For storage, the developer may choose between the object-oriented databases from ODI and Versant, and a standard relational database accessed via JDBC. For this review, I've chosen to use a JDBC connection to Oracle 8i. After retrieving a JMS connection, a session is created through the standard procedure. The developer must specify the acknowledgement option and whether or not the session is transacted. When using transacted connections, no messages are delivered until specific commits are issued from the publishing object. Subsequently, messages aren't acknowledged until specific commits are issued from the message consumers. JMS destinations may be obtained using either the standard JMS approach or the proprietary option available through SpiritWave. If a developer is using JNDI, as in this review, the standard method must be used to obtain a topic or queue. If, however, an alternative repository contains the destination object, the developer has the choice to use lookup methods on the SpiritWave class appropriate for the object desired. All objects are identified by a logical name. Future releases of SpiritWave will support JNDI. For the remaining process of transferring messages through the system, creating the message, sending, receiving, and managing the connections, SpiritWave relies on the standard JMS API calls. SpiritWave provides several enhancements to the messaging system that provides further control and management of items. They include:
Summary Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
|
SYS-CON Featured Whitepapers
Most Read This Week |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||