ATG Dynamo Messaging System

e-Com

ATG Dynamo Messaging System

ATG Dynamo Messaging System Pawan Modi [email protected]

DYNAMO MESSAGING SYSTEM Oracle ATG Web Commerce includes a number of JMS-related tools, which are known collectively as the Dynamo Messaging System (DMS). ATG

Page 1


Table of Contents ATG INTRODUCTION

4

JMS INTRODUCTION

5

JMS Message Producers and Consumers

6

JMS Destinations Message Persistence

7 7

JMS Message Formats Message header Message body

9 9 9

ATG DMS

10

Local JMS Creating Local JMS Destinations

11 11

SQL JMS Creating SQL JMS Destinations SQL JMS Polling Interval

13 13 14

Patch Bay Patch Bay Manager Messaging Components Patch Bay Initialization

15 15 15 16

Creating Message Sources

17

Creating Message Sinks

18

Creating Message Filters

19

Configuring Patch Bay Declaring JMS Providers Declaring Message Sources, Sinks, and Filters Connecting to Destinations Using Messaging Ports Using the Message Registry Using Patch Bay with Other JMS Providers

20 20 21 21 24 27 27

REFERENCES ATG

31 Page 2


Abbreviation DAS

Dynamo Application Server

DAF

Dynamo Application Framework

DSS

Dynamo Scenario Server

DPS

Dynamo Personalization Server

DRP

Dynamo Request Protocol Server

GSS

Global Scenario Server

LM

Load Manager

CM

Connection Module

RMI

Remote Method Invocation

DCC

Dynamo Control Center

SBS

Session Backup Server

UDP

User Datagram Protocol alternative protocol to TCP/IP, (usually used for broadcasting)

SNMP Simple Network Management Protocol, MIB packet services

ATG

Page 3


ATG Introduction ATG is the worldwide leader in the E-commerce solutions. ATG product suite has enabled the vendors to enable their e-commerce commercial capabilities.

ATG

Page 4


JMS Introduction Java Message Service (JMS) defines a standard way for different elements of a J2EE application to communicate with each other. With JMS, components do not access each other directly. Instead, a component posts a message to a message broker, which then distributes the message to other components. In general, the posting and delivery actions occur in separate transactions, and might even occur in different processes, machines, or sites. This mechanism decouples the actions of the sending and receiving components to so that the sender can continue with its work without having to wait for the receiver to process the message. This decoupling is often called asynchronous processing. The JMS API defines the interfaces for sending and receiving messages. It also defines the semantics for message delivery and acknowledgement, and how message delivery should behave in a transactional environment. JMS message producer sends a message to a destination, where it is retrieved by one or more message consumers. JMS defines two types of destinations, corresponding to two basic forms of messaging.

ATG



Topic - A destination used in publish/subscribe messaging. If a topic has several subscribed listeners, each message published to that topic is delivered to all listeners.



Queue

- A destination used for point-to-point messaging. If a queue has several subscribed receivers, each message is delivered to only one of the receivers. A different receiver might be chosen for each message, possibly depending on some load balancing mechanism.

Page 5


JMS Message Producers and Consumers The JMS API defines a set of interfaces for creating message producers and consumers. There are separate interfaces for producers and consumers, and for objects that communicate with topics and queues. These interfaces are all part of the javax.jms package. 

QueueSender



QueueReceiver



TopicPublisher



TopicSubscriber

In addition to implementing one of these interfaces, the producer or consumer must also obtain a ConnectionFactory, find destinations, obtain a JMS Connection, and create JMS Session etc.

ATG

Page 6


JMS Destinations JMS defines two types of destinations, topics and queues. The use of destinations provides much of the flexibility in JMS. If a new application needs to send messages to or receive messages from an existing application, it can publish or subscribe to the destinations used by that application. The new application does not need to be aware of the message producers and consumers in the original application, just the destinations. This means that message producers and consumers can be added to or removed from one application without affecting other applications, as long as the destinations remain the same. Each destination is maintained by a single JMS provider, which typically maintains many destinations. The creation and management of destinations within a JMS provider is usually an administrative or configuration operation. If a message is sent to a destination, that destination’s JMS provider is responsible for receiving the message and passing it on to subscribers waiting for messages from that destination. Different providers might use different mechanisms to accomplish this. For example, Oracle ATG Web Commerce’s SQL JMS uses an SQL database to store and deliver messages, for applications that require the messaging system to be highly reliable. Other JMS providers might use file or memory-based storage.

Message Persistence Queue destinations typically are persistent. If a message is sent to a queue but no receiver is online, the message is kept in the queue, waiting for a receiver to connect and start reading from the queue. After a message is delivered to a single receiver, it is removed from the queue. Topics, however, are non-persistent by default. If a message is sent to a topic, it is delivered to all subscribers to that topic that are currently online, and then removed. Any subscriber that is offline does not receive the message. If no subscribers are currently online, the message is simply removed from the topic without being delivered anywhere. But some applications require the flexibility of a topic, but also the persistence offered by a queue. For example, suppose an application requires a message to be delivered to several subscribers, but it is not acceptable for a subscriber to miss any of the messages if it goes offline. JMS addresses this need through the use of durable subscriptions. A message consumer that has a durable subscription to a topic can go offline, then reconnect later and pick up any messages that were sent to the topic in its absence. Durable versus non-durable is a property of each individual subscriber but not the characteristic of the topic as a whole. A topic can have a mix of subscribers, some durable and some non-durable.

Durable and non-durable subscribers are created through the JMS API. Creating a durable subscriber requires specifying a name that the topic uses to identify the subscriber. Each durable subscriber to a topic must have a name that is unique for that topic. If a subscriber disconnects, the JMS provider holds ATG

Page 7

ATG Dynamo Messaging System any subsequent messages under that name. If the subscriber then reconnects using the same durable subscription name, the messages held under that name are delivered to the subscriber.

ATG

Page 8


JMS Message Formats The JMS API defines the standard form of a JMS message, which should be portable across all JMS providers. Because the JMS API was designed to accommodate many existing providers, the resulting message form encompasses a wide variety of features. A JMS message consists of two parts. 

Message header



Message body

Message header The header contains system-level information common to all messages, such as the destination and the time it was sent, while the body contains only application-specific data. The header can also contain some application-specific information, stored as keyword/value properties. The most important header value is the JMSType. This is a String that is used to identify what kind of message is being sent. Handlers often examine the JMSType to see how they should handle an incoming message. The header is useful for specifying message selectors. When a receiver subscribes to a destination, it can specify a message selector, which acts as a filter for weeding out messages the receiver does not want to see. The message selector must be specified in terms of the message’s header. For example, a receiver can specify a message selector saying that it wants to see only messages whose JMSType is atg.das.Startup.

Message body To accommodate the various data formats of existing providers, JMS defines five distinct message body types. In the JMS API, these translate into five Java interfaces, each subclassing the javax.jms.Message.

ATG

Page 9


ATG DMS Oracle ATG Web Commerce includes a number of JMS-related tools, which are known collectively as the Dynamo Messaging System (DMS). The main parts of DMS are Two JMS providers i.e. Local JMS and SQL JMS. 

Local JMS is built for high-speed low-latency synchronous messaging within a single process.



SQL JMS is more robust, and uses an SQL database to handle communication between components within the same Oracle ATG Web Commerce application, or components running in different processes.

Patch Bay is an API and configuration system layered on top of JMS. Patch Bay is designed to ease the development of messaging applications in Oracle ATG Web Commerce. The Patch Bay API allows Nucleus components to send and receive messages. The configuration system uses an XML file to specify how these components should be connected. Patch Bay also maintains a Message Registry that the Oracle ATG Web Commerce user interfaces use to present lists of possible notifications to users. Oracle ATG Web Commerce registers the messages that it sends with the Message Registry. Applications can also register their own messages, which then appear in the Oracle ATG Web Commerce user interfaces. The different DMS pieces can be used independently. For example, you can use Local JMS, SQL JMS, or both, with or without Patch Bay. You can use a third-party JMS provider, or use the JMS implementation provided with your application server, also with or without Patch Bay.

ATG

Page 10


Local JMS Local JMS is a JMS provider supplied with Oracle ATG Web Commerce. Messages sent through Local JMS can travel only between components in the same Oracle ATG Web Commerce process. Local JMS delivers messages synchronously. This means that when a component sends a message, the sending component blocks until the receiving components receive and process the message. The entire message sending and receiving process occurs within a single thread. As a result, both the sending and receiving of the message occurs in the same transaction. Local JMS does no queuing. When a message is sent, Local JMS immediately finds out who the receivers are and calls the appropriate methods on the receivers to deliver the message, waiting for each receiver to process the message before delivering the message to the next receiver. Only when the message has been delivered to all receivers does control return to the sender. In this way, Local JMS works more like Java Bean events than like typical JMS implementations; when a Java Bean fires an event, it actually calls a method on several registered listeners. Local JMS is also non-durable; all messages are non-persistent. If a message is sent to a queue destination that has no listeners, the message disappears. Also, durable subscriptions to topic destinations act exactly like non-durable subscriptions—if a subscriber is not listening to a topic, it misses any messages sent to that topic whether it is subscribed durably or not. Local JMS implements synchronous, extremely high-performance messaging. Local JMS is most often used to pass data around to various components within a single request.

Creating Local JMS Destinations In Local JMS there are 2 ways to create JMS destinations. 1. Create destinations by setting the localJMSQueueNames and localJMSTopicNames properties of the /atg/dynamo/messaging/MessagingManager component For Example: localJMSQueueNames+=/Orders localJMSTopicNames+=/RegistrationEvents,/FinancialEvents When a Nucleus-based application starts up, it creates these destinations. To access a Local JMS destination in your code, you use JNDI references like shown here. For Example: localdms:/local{queue-or-topic-name} localdms:/local/Orders.

ATG

Page 11

ATG Dynamo Messaging System 2. Create Local JMS destinations using DMS configuration file. These destinations are specified by name, separated into topics and queues.

When a Nucleus-based application starts up, it create these destinations with the JNDI names localdms:/local/MyApp/RegistrationEvents, localdms:/local/MyApp/FinancialEvents, and localdms:/local/MyApp/Orders.

ATG

Page 12


SQL JMS Local JMS discussed above is synchronous but many messaging applications require messaging to be asynchronous. When a sender sends a message asynchronously, the message is handed off to the JMS provider, and the sender continues on with its work. Asynchronous messaging is useful for processes that can be broken down into separate stages, where each stage might take an unknown amount of time. For example, ATG Commerce uses asynchronous messaging to process an order. Another key difference between Local JMS and SQL JMS is message persistence. Local JMS stores no state, so if the system fails, all messages are lost. SQL JMS uses an SQL database for persistence of messages. This ensures that messages are not lost in the event of system failure, and enables support for persistent queues and durable subscriptions. To deliver messages, SQL JMS polls the database periodically, checking the appropriate tables to see if any new messages were written. If so, those messages are delivered to the appropriate message receivers and then removed from the database. This all occurs in transaction, so if a failure occurs or the transaction rolls back, the messages are all returned to the database, again guaranteeing that messages do not get lost. Note: In SQL JMS, the sending of a message and the receiving of a message occur in separate transactions. A sender might send a message in a transaction that later commits successfully. This does not mean that the receiver has successfully received the message. It just means that SQL JMS has successfully delivered the message to its destination. At some point in the future, receipt of the message is placed in another transaction. The message is then removed from the database when that second transaction successfully commits. SQL JMS uses standard JDBC drivers to communicate with the database. This allows SQL JMS to operate in a distributed environment, where an Oracle ATG Web Commerce server and the database are located on different machines. SQL JMS can also run on multiple Oracle ATG Web Commerce servers at once, all utilizing the same database. This enables multiple Oracle ATG Web Commerce servers to use SQL JMS to communicate with each other. Connection factory for all SQL JMS topic and queue connections (including XA connections) is the Nucleus component /atg/dynamo/messaging/SqlJmsProvider.

Creating SQL JMS Destinations In SQL JMS, create destinations using the requiredQueueNames and requiredTopicNames properties of the /atg/dynamo/messaging/SqlJmsProvider component. For example requiredQueueNames+=MyApp/Orders requiredTopicNames+=MyApp/RegistrationEvents,MyApp/FinancialEvents

ATG

Page 13

ATG Dynamo Messaging System When SQL JMS starts, it looks at these lists of queue and topic names. It then looks into the dms_queue and dms_topic tables and adds any topic or queue names that are not already in those tables. To access an SQL JMS destination in your code, you use JNDI references. For Example sqldms:/{queue-or-topic-name} sqldms:/MyApp/RegistrationEvents

SQL JMS Polling Interval SQL JMS works through polling. At periodic intervals it performs a query on the database to see if there are any messages waiting to be delivered to its local clients. By default, this polling occurs at 20 second intervals. This means that messages have an average latency of 10 second. Decreasing the polling interval decreases the average latency. However, decreasing the polling interval also increases the frequency of queries from each client, thereby increasing the database load. This can add up to a significant load on the database. So if the database load is too high, the administrator should increase the polling interval on the Oracle ATG Web Commerce servers to decrease the number of queries each server is making. This increases latency, making some messages take longer to get from sender to receiver, but decreases the load on the database. The polling interval is set in the /atg/dynamo/messaging/SqlJmsProvider component.

messagePollSchedule

property

of

the

messagePollSchedule=every 20 sec in 10 sec Note: While latency is affected by the polling interval, overall system throughput should remain unchanged. Each time a query performs a poll, it reads in all messages waiting for that client. For example, if a message is being sent every second, and the polling interval is set to 20 seconds, every poll reads 20 messages, yielding an effective throughput of 1 message/second, with an average latency of 10 seconds. But if the polling interval is set to 30 seconds, the average latency increases to 15 seconds, but every poll reads 30 messages, again yielding a throughput of 1 message/second.

ATG

Page 14


Patch Bay Patch Bay is designed to simplify the process of creating JMS applications. Patch Bay includes a simplified API for creating Nucleus components that send and receive messages, and a configuration file where you declare these components and your JMS destinations. When a Nucleus-based application starts up, it examines this file and automatically creates the destinations and initializes the messaging components. This means your code does not need to handle most of the JMS initialization tasks, such as obtaining a ConnectionFactory, obtaining a JMS Connection, and creating a JMS Session.

Patch Bay Manager Patch Bay is represented in Nucleus as the component /atg/dynamo/messaging/MessagingManager, which is of class atg.dms.patchbay.PatchBayManager. Patch Bay is configured with a properties file like all other nucleus components. The properties file controls the general behavior of the Patch Bay system; it configures such things as the transaction manager used by Patch Bay and logging behavior. In addition to the properties file, the MessagingManager uses an XML file called the DMS configuration file to configure the individual parts of the Patch Bay system, such as JMS providers, message sources and sinks, and destinations. The definitionFile property of the MessagingManager component names the DMS configuration file.

Messaging Components Patch Bay API includes Java interfaces that messaging components must implement in order to send and receive messages. 

Message source - A component that can send messages. A message source must implement the atg.dms.patchbay.MessageSource interface.



Message sink - A component that can receive messages. A message sink must implement the atg.dms.patchbay.MessageSink interface.



Message filter - A component that implements both interfaces, and can send and receive messages.

All message sources, sinks, and filters must have global scope. Note: Unlike standard JMS, Patch Bay does not have separate interfaces for objects that communicate with topics and those that communicate with queues. A message source can send messages to both topics and queues, and a message sink can receive messages from topics and queues. In addition to your sources and sinks, you must also define standard JMS destinations. Patch Bay cannot connect a message source directly to a message sink. Instead, the two must be connected through a JMS destination. ATG

Page 15


Patch Bay Initialization Patch Bay defines a simple life cycle for message sources, sinks, and filters. When Patch Bay is started, it resolves each of the Nucleus names. If the referenced components are not yet created, they are created at this time according to the standard Nucleus name resolution procedure.

Message Sink Initialization As soon as message sinks are resolved by nucleus, message sinks should be prepared to receive messages, which can start receiving at any time.

Message Source Initialization Message sources follow a slightly more complicated protocol. After a message source is resolved in Nucleus, Patch Bay calls MessageSource.setMessageSourceContext() on the component. This provides the component with a context object that it can use to create and send messages. At this point, Patch Bay initializes the various JMS providers and makes sure that the messaging infrastructure is up and running. It then walks through each of the message sources and calls MessageSource.startMessageSource() on each one. After this call, the message sources can start sending messages.

Message Filter Initialization Message filters are combinations of message sources and message sinks. They implement both interfaces, and must follow the protocols for both. This means that a message filter must be able to receive messages as soon as it has been initialized, but should not initiate the sending of messages before setMessageSourceContext() and startMessageSource() are called.

Note: There is one situation where message filters behave differently. A typical operation for a message filter is to receive a message, then to send another message in response. In this case, it is acceptable for the message to send a message in response to a received message, even if startMessageSource() has not yet been called (although setMessageSourceContext() must be called first in all cases). It is still not acceptable for a message filter to initiate a message before startMessageSource() has been called, but it is fine for the message filter to send a message in response to a received message.

ATG

Page 16


Creating Message Sources A message source must implement the atg.dms.patchbay.MessageSource interface. Through this interface, the message source is assigned a MessageSourceContext that it can use to create and send messages. The following example demonstrates how to do this.

ATG

Page 17


Creating Message Sinks A message sink must implement the atg.dms.patchbay.MessageSink interface. This interface defines a single method, receiveMessage, which is called to notify the message sink that a message is being delivered. This method might be called simultaneously by many threads, so the message sink should be coded accordingly. The following is a simple example of how a message sink might handle a message.

ATG

Page 18


Creating Message Filters Message filters must implement both the MessageSource and the MessageSink interface. A message filter typically implements receiveMessage by manipulating the message in some way, then sending a new message, like this.

This filter takes in TextMessages, and then sends them out again with period (.) replaced by forward slash (/) in the text. Notice that the mStarted flag is not consulted as shown for the message source, because a message filter is allowed to send out messages in response to incoming messages regardless of whether it has been started or stopped.

ATG

Page 19


Configuring Patch Bay Patch Bay is represented in Nucleus as the component /atg/dynamo/messaging/MessagingManager. The definitionFile property of the component MessagingManager names the XML file that configures Patch Bay. The value of this property is /atg/dynamo/messaging/dynamoMessagingSystem.xml

Declaring JMS Providers By default, Patch Bay is configured to use Local JMS and SQL JMS. These providers and the connection factories they use are specified through Nucleus components of classatg.dms.patchbay.JMSProviderConfiguration. For example, to configure SQL JMS, Oracle ATG Web Commerce includes a component of this class named/atg/dynamo/messaging/DynamoSQLJMSProvider. The properties file for this component includes these lines.

You generally should not need to modify any of these settings for Local JMS or SQL JMS. You can declare JMS providers at the top of the Patch Bay configuration file, using tags that correspond to the properties of JMSProviderConfiguration.

ATG

Page 20

ATG Dynamo Messaging System You can also designate a JMS provider as the default provider in Patch Bay by setting the defaultJMSProvider property of the /atg/dynamo/messaging/MessagingManager component to point to the component that configures the provider. By default, this property points to the DynamoSQLJMSProvider component, which configures SQL JMS.

Declaring Message Sources, Sinks, and Filters One of the functions of the DMS configuration file is to name all message sources, sinks, and filters existing in the system. As described earlier, these elements are globally scoped Nucleus services that implement the appropriate interfaces. Each element should be declared with its Nucleus name. For example

Any number of sources, sinks, and filters can be specified, in any order

Connecting to Destinations After a message source, sink, or filter has been declared in the configuration file, it must be hooked up to JMS in order for its messages to go anywhere, or for it to receive messages. As discussed earlier, a messaging component is never connected directly to another component. Instead, a messaging component is hooked up to a JMS destination, maintained by one of the JMS providers registered with Patch Bay. Messaging components communicate with each other by hooking up to the same destination. if message source A sends messages to destination D, and message sink B receives messages from destination D, messages flow from A to B.

ATG

Page 21

ATG Dynamo Messaging System Whenever a destination is specified in the DMS configuration file, it must specify which provider owns that destination. The destination must also be named by its JNDI name, using the prefix appropriate to that destination’s provider. Oracle ATG Web Commerce includes two providers: Local JMS and SQL JMS. The following table specifies the required information for each provider.

The following illustrates how a message source is connected to a destination in the DMS configuration file. In this case, the destination is managed by Local JMS, and is called localdms:/local/TestMessages.

The important part of this example is the output-destination definition. This definition says that messages coming out of this Nucleus component should be directed to the topic called localdms:/local/TestMessages, managed by JMS provider local.

ATG

Page 22

ATG Dynamo Messaging System This says that each message coming out of the component is sent to a destination in Local JMS, and a destination in SQL JMS. The messages are sent in the order specified.

Message sinks shown below are configured in much the same way. This configuration says that messages sent to either topic in either provider are passed to the TestMessageSink1 component, using the MessageSink.receiveMessage() call. Notice that the sqldms input-destination specifies a durable-subscriber-name. This means that the connection to the topic should be made using a durable subscription, with the given durable subscriber name. If messages are sent to this topic while the subscriber is off-line, those messages are held under this name. When the subscriber starts up, the messages held under that name are passed to the message sink.

ATG

Page 23

ATG Dynamo Messaging System The durable-subscriber-name is optional. If it is not supplied, the subscription is non-durable, meaning that the message sink misses any messages sent to the topic while the message sink server is off-line. Durable subscriptions are probably used whenever SQL JMS is used, as most applications that require the robust persistence of SQL JMS also probably want the functionality of durable subscriptions.

Using Messaging Ports In the Patch Bay configuration, a component can be configured to send its messages to a destination (or group of destinations), or to receive its messages from a destination (or group of destinations). Sometimes, however, you might want a component to have more control over where its messages are going. For example, a message filter might read in a message and then resend that message to one of several outputs based on some aspect of the message, such as its JMSType.

ATG

Page 24

ATG Dynamo Messaging System Each of those outputs is then configured in Patch Bay to go to a separate set of destinations. In Patch Bay, those outputs are called ports. The author of a messaging component chooses the names of the ports that are used by that component. Whenever a message source (or filter) sends a message, it must specify the name of the port through which the message is sent. This means that the port names used by the component are hard-coded into the component. In Patch Bay, each of a component’s output ports can be attached to a different set of destinations. For example:

In this example, it is assumed that TestMessageSource1 is sending messages through at least two ports i.e. Normal and Emergency. Patch Bay then directs messages coming out of those two ports to different destinations. Normal messages go to localdms:/local/NormalMessages. Emergency messages go to localdms:/local/EmergencyMessages.

ATG

Page 25

ATG Dynamo Messaging System If TestMessageSource1 sends a message through some other port name, that message goes nowhere. A MessageSource must be coded to specify which port it wants a message to use. The port is specified in both the createMessage and sendMessage methods. For example, following sample sends a TextMessage through the Normal port.

Notice that the message source does not need to declare what ports it uses. It just sends a message out using a name, and if Patch Bay has destinations hooked up to that name, the message is sent to those destinations. It is the responsibility of the message source developer to provide documentation as to what output ports it uses and in what situations. Message sinks can also make use of ports. Whenever a message is received, the receiveMessage method passes in the name of the port through which the message arrived. For example, the DMS configuration might look something like this.

ATG

Page 26

ATG Dynamo Messaging System If a message arrives from localdms:/local/TestMessages, the receiveMessage method is passed LowPriority as the name of the port. But if a message arrives from sqldms:/PersistentTopic1, the receiveMessage methods are passed HighPriority. An input port can have many input destinations. If a message arrives from any of those destinations, it is passed in with the name of its associated input port. Again, the message sink need not declare what ports it uses. However, the message sink developer should document what port names the message sink expects to see. Ports provide another level of flexibility available through Patch Bay, but they should be used with care because they push some of the hookup responsibility into the messaging component code.

Using the Message Registry Patch Bay provides a Message Registry, which is a facility that maps message types to the data carried by those message types. The data in the Message Registry can then be accessed at runtime through a set of APIs. Application construction tools, such as the ATG Control Center, make use of this data to present lists of available message types or types of data associated with each message type. The Message Registry works only for Oracle ATG Web Commerce messages. The important points to note here is. 

The messages are identified by JMSType.



They are ObjectMessages.



The object in the message is a bean whose class is always the same for a given JMSType.

The Message Registry maps the JMSType string to the class of bean held by messages of that type. For example, messages with JMSType atg.dcs.Purchase are ObjectMessages containing objects of type atg.dcs.messages.PurchaseMessage.

Using Patch Bay with Other JMS Providers Patch Bay comes preconfigured to use Local JMS and SQL JMS. This ensures that Oracle ATG Web Commerce products and demos work without any further configuration. If desired, you can configure Patch Bay to use your application server’s JMS provider or a third-party JMS provider, through standard Patch Bay tags. Consult the provider’s documentation to determine the values to use. In addition, you must add the client libraries for the JMS provider to Oracle ATG Web Commerce’s CLASSPATH. The DMS configuration file must declare all providers before it declares message sources and sinks. For Example

ATG

Page 27


If you specify multiple providers, each must have a unique provider-name. Each tag can supply the following fields. provider-name This field identifies the provider. The field can have any value that is unique among other providers in the system. When message sources and sinks define input and output destinations, those destinations are associated with a provider name. This provider name must match the provider name declared for the provider that is handling a particular destination. Connection Factory JMS provider is accessed through ConnectionFactories that are identified by JNDI names as specified by the JMS provider documentation. There are four connection factories available. They are as follow.  ATG

topic-connection-factory-name Page 28

ATG Dynamo Messaging System 

queue-connection-factory-name



xa-topic-connection-factory-name



xa-queue-connection-factory-name

supports-transactions Set to true or false, to specify whether the JMS provider supports commit() and rollback(). supports-xa-transactions Set to true or false, to specify whether the JMS provider supports XA transactions. Note: If this field is set to true, you must also set xa-topic-connection-factory-name and xa-queueconnection-factory-name. Username password Many JMS providers require that clients log in to the JMS system using a username and password. If these fields are defined, their values are used to log in when creating JMS connections. client-id Many JMS providers have a notion of a client identifier, which allows the provider to remember who a client is even if that client is disconnected and later reconnects. This allows the JMS provider to queue up messages for the client while the client is disconnected. When the client reconnects, it uses the same client identifier it had previously, and the JMS provider knows to deliver the messages queued up for that client. This field is optional, but it should be filled in if there are multiple clients running against the same JMS provider. In this case, each client should be assigned a unique client-id. initial-context-factory JNDI names are used to identify the connection factories and the topics and queues managed by a provider. These JNDI names are resolved against an InitialContext. Each provider obtains the InitialContext in its own way. Typically, a Dictionary is created with several properties, and is passed to the InitialContext’s constructor. For example, a JMS provider might say that the InitialContext must be created using this code.

ATG

Page 29

ATG Dynamo Messaging System The Nucleus component must implement the interface atg.dms.patchbay.JMSInitialContextFactory, which defines a single method createInitialContext(). Patch Bay calls this method to get the Context that it uses to resolve a JNDI name. The code for that Nucleus component might look like this.

ATG

Page 30


References http://docs.oracle.com/cd/E24152_01/Platform.101/ATGPlatformProgGuide/html/s1201atgmessagesystem01.html

ATG

Page 31

ATG Dynamo Messaging System

Recommend Documents