 |
 |
 |
 |
|
|
 |
Administered objects are connection factories and destinations bound in the Java Naming and Directory Interface (JNDI) namespace of the Server. Clients access these objects through portable interfaces, so a client application can run with little or no change on more than one implementation of the JMS API. Clients lookup administered objects using the JNDI API on the message service, after an administrator places the objects in a namespace.
Selecting Configure > Message Server on the Console displays a statistical summary of all the Messages, Queues, and Topics, along with all the destination objects and connection factories configured in the Message Server.
A destination is the object a client uses to specify the target of messages it produces and the source of messages it consumes. In the PTP messaging domain, destinations are called Queues and in publish or subscribe messaging domain, destinations are called Topics.
You can add a Queue using either the Console or the Command Shell.
On the Console, click Queue on the left side panel. This invokes the Queue page. Here, enter the Name of the Queue to be created. For example, myQueue.
On the Server command line or shell, to add Queue to server, use add queue command. The add command takes a single argument <queue name>. This must be unique.
The following command adds the myQueue queue to the the Message Server: jmsadmin@default:>add queue myQueue
When a Queue is added, it will have the default destination properties that are configured in the jms-config.xml file. You can change the properties of the queues using either the Console or the Command Shell.
Click the Settings icon of the Queue for which you want to change the properties. Change the values of the Queue properties and click Save.
Command Shell provides set command with which you can edit only some of the properties of the Queue like maxcachesize, maxmemorysize, redeliverylimit, redeliverylimitpolicy, and redeliverydelay.
For example, to set a Queue size using the command shell, use the command maxcachesize. This command takes two arguments, <queue _moz-userdefined="" name=""> and size.
jmsadmin@default> set maxcachesize myQueue 100
If the command is successful, the server displays the following message: Max cache size for destination: myQueue set to 100
On the Web-based Console, select a queue using the check-box and click Purge. This purges the specified queue.
Use the following command to purge a Queue using the command shell: jmsadmin@default:>purge queue [queue name]
This deletes all the messages in the queue specified. The output on execution of this command shows the number of messages that are deleted by executing this command.
Executing the purge command for JMSQueue displays the following output:
Purged queue: JMSQueue Persistent Messages: 0
On the Console, select Message Server > Topic on the left side panel to add a topic. This invokes the Topic List. Enter the Name of the topic to be created. For example, myTopic. Click Add.
On the Server command line or shell, to add a Topic to Server, use add topic command. The add command takes a single argument topic name, which should be unique.
jmsadmin@default:>add topic myTopic
status command. The status command provides detailed status about the Server. You can use the options provided by the status command to know the status of particular entity.
The status command provides the following options: clients/destinations/queues/topics/queue/topic/factories/ds/state/thpool/timemsgs/all
For example, status all displays detailed status of the Server, like queues, topics, clients, and durable subscribers; status queues displays status only for queues, and status queue displays the status of a specific Queue.
The sample status for a Queue named JMSQueue, is given below:
jmsadmin@default> status queue JMSQueue
Destination Details:
-------------------------------------------------
QUEUE_JMSQueue
-------------------------------------------------
Total Messages Pending : 0
Total Memory In Use : 0
Messages Pending in MessageList : 0
Messages Pending in Orphaned List : 0
Messages in Persistent Store : 0
Messages Delivered : 0
Messages Discarded : 0
Messages Delivered To DMQ : 0
Asynchronous Receiver Connections : 0
Synchronous Receives Waiting : 0
Configuration Properties
Max Messages in cache : 1000
Max Memory Size : 5 MB
Cache overflow policy : block-sender
Max message size(kb) : 50
Message size overflow policy : override-message-delivery-mode
Enable multiple receivers : true
Redelivery delay (millis) : 0
Redelivery limit : 20
Redelivery limit overflow policy : add-to-dead-message-queue
Override message priority : no-override
Override time to live : no-override
Override messages delivery mode : no-override
To see the total free memory and total memory allocated to JVM instance on which the Message Server is running, type: jmsadmin@default:>show memory
The output may look like:
jmsadmin@default> show memory Free Memory : 11418 KBytes Total Memory : 25112 KBytes
A client uses a connection factory to create a connection with a provider. This encapsulates a set of connection configuration parameters that have been defined by an administrator. The following connection factories are pre-configured with the Message Server:
A connection factory can be an instance of one of the following interfaces:
On the Console, choose Configure > Message Server > Connection Factory. This shows the list of the existing connection factories, if any.
Table 1: Details of a Connection Factory
| Fields | Description |
|---|---|
| Name | Name of the connection factory. |
| Bulk Send Enabled | Displays whether or not the Bulk Send options is enabled on this connection factory. |
| Compression Enabled | Displays whether or not the Message Compression is enabled on this connection factory. |
| SSL | Displays whether or not the communication between the client and server requires SSL authentication. |
| Auto-Acknowledge Messages | Displays whether or not the acknowledgement required for the non-persistent messages. |
Click Add to add a new connection factory. Provide the name for the new connection factory, select the type for it, and click Save. This creates a new connection factory with the default connection factory properties that are configured in the jms-config.xml.
To change the settings of the connection factory, click the Setting icon, change the values of the connection factory properties, and click Save.
To add a QueueConnectionFactory to the Message Server, execute the command add qcf if you are using server command line or remote shell. This command takes a single argument
To create and add myqueueconnectionfactory that implements javax.jms.QueueConnectionFactory on the Pramati Message Server, type jmsadmin@default:>add qcf myqueueconnectionfactory
To add a TopicConnectionFactory to the Message Server, execute the command add tcf if you are using Message Server command line or remote shell. This command takes a single argument
To create and add mytopicconnectionfactory that implements javax.jms.TopicConnectionFactory on the Pramati Message Server, type the following on the command line:
jmsadmin@default:>add tcf mytopicconnectionfactory
To add an XAQueueConnectionFactory to the Message Server, execute the command add xaqcf if you are using server command line or remote shell. This command takes a single argument
To create and add myqueueconnectionfactory that implements javax.jms.XAQueueConnectionFactory on the Pramati Message Server, type the following on the command line:
jmsadmin@default:> add xaqcf myqueueconnectionfactory
To add an XATopicConnectionFactory to the Message Server, execute the command add xatcf if you are using Message Server command line or remote shell. This command takes a single argument
To create and add myTopicconnectionfactory that implements javax.jms.XATopicConnectionFactory on the Pramati Message Server, type the following on the command line:
jmsadmin@default:> add xatcf myTopicconnectionfactory
A common connection factory supports both Queue and Topic operations, introduced in JMS 1.1 specification. To add a common ConnectionFactory to the Message Server, execute the command add cf if you are using Message Server command line or remote shell. This command takes a single argument
To create and add myConnectionfactory that implements javax.jms.ConnectionFactory on the Pramati Message Server, type the following on the command line:
jmsadmin@default> add cf myConnectionfactory
XA Common Connection factory supports both Queue and Topic operations with XA Enabled, introduced in JMS 1.1 specification. To add a common XAConnectionFactory to the Message Server, execute the command add xacf if you are using Message Server command line or remote shell. This command takes a single argument
To create and add myXAConnectionfactory that implements javax.jms.xAConnectionFactory on the Pramati Message Server, type the following on the command line:
jmsadmin@default> add xacf myXAConnectionfactory
To maintain the persistent messages, Message Server requires a persistence store to be configured. By default, it uses the local filestore for persisting its messages. You can, however, configure it to use database as its persistence store.
To configure a persistent store using the Console:
This section guides you in accessing the Message Server from components running in application Servers (Pramati and other servers). The access may be made from JSP pages, Servlets, or EJBs.
To access Pramati Message Server from Pramati Application Server you need to create a JMS Adapter in the Resource Service. Please see the Resource Service section on how to configure the JMS Adapters.
An Adapter can be created by adding the following tags to the resource-config.xml file under the <install_dir>\server\nodes\<node_name>\config\.
<jms-adapter description="nodesc" interface-class="com.pramati.jms.client.JMSProviderImpl" name="default">
<properties>
<property name="java.naming.factory.initial" value="com.pramati.naming.PramatiLocalContextFactory"/>
<property name="java.naming.provider.url" value="rmi://127.0.0.1:9191"/>
<properties>
</jms-adapter>
The above tags add a JMS Adapter with the name default in the resource service.
Here, com.pramati.jms.client.JMSProviderImpl is the class that implements interface JMSProvider which is specified by Pramati Server. Its purpose is to furnish JMS related details from the Message Server to Pramati Server.
The integration of JMS and EJB allows enterprise beans to participate fully in loosely connected systems. Through this integration, message driven beans can receive and act upon JMS messages, without the involvement (or existence) of an application client user interface. This new capability makes EJB an excellent choice for the developers of shared business services. Additionally, any EJB can send asynchronous messages via the JMS API. This paper explains the seamless integration of the other JMSs with Pramati J2EE server.
Pramati J2EE Server provides the JMS Server in an easy-to-use and standard way in creating a Java-based implementation using the JMS adapter. This reduces the cost of purchasing an existing messaging product and the Java interface. The steps involved in the JMS Server integration are as follows.
Pramati interacts with a JMS server using the implementation of com.pramati.services.resource.spi.JMSProvider. This has to be implemented by the JMS vendor. It enables the application server to fetch any administered objects from the JMS Server.
The JMS provider:
javax.jms.message in and out of the ServerThe JMS Adapter provides an interface to other JMS Servers that implement javax.jms to access the JMS resources, making it JMS-compliant. This enables seamless plug-in of an external JMS. This involves:
The Console provides a standard User Interface to add a JMS adapter. After connecting to the Console, select Resources > JMS. Enter the following details to create a JMS adapter:
adapterName: The resource name in the Console. This can be any name that is used to refer to the resource. It should be clear enough to identify the resource.
adapterImplementationClassName: The class name. If the interface extended is com.pramati.services.resource.spi.JMSProvider, the default class name is com.pramati.jms.client.JMSProvider.
Click Next.
adapterName: The JMS resource name entered is the JNDI name defined in the Step-1 of the JMS adapter creation.
Class: The InitialContextFactory name or the naming service name has to be entered here.
Name: The InitialContextFactory name or the naming service name has to be entered here. This should be clear enough for easy identification.
Value: The value of the InitialContextFactory name or the URL of the naming service has to be entered here.
Description: The description of the naming service or InitialContextFactory can be provided here.
Click Next to specify local JNDI names for the existing queues, topics and connection factories.
Name: The JMS resource name entered in the Step-1 of the JMS adapter creation.
Class: The class name entered in Step-1 is displayed here.
Name: The names of the ConnectionFactories added in the JMS server are listed here. This includes both QueueConnectionFactory and the TopicConnectionFactory.
JNDI Name: The local JNDI names to be specified to the ConnectionFactories added in the JMS server are to be provided here. This helps the beans of an J2EE application to look-up the Queue and TopicConnectionFactories.
Name: The names of the XAConnectionFactories added in the JMS server are listed here. This includes both XAQueueConnectionFactory and the XATopicConnectionFactory.
JNDI Name: The local JNDI names to be specified to the XAConnectionFactories added in the JMS server are to be provided here. This helps the beans of a J2EE application to look-up the XAQueue and TopicConnectionFactories.
Name: The names of the queues added in the JMS server are listed here.
JNDI Name: The local JNDI names to be specified to the queues added in the JMS server are to be provided here. This helps the beans of a J2EE application to look-up the queues.
Name: The names of the topics added in the JMS server are listed here.
JNDI Name: The local JNDI names to be specified to the topics added in the JMS server are to be provided here. This helps the beans of a J2EE application to look-up the topics.
When the above steps are completed the deploytool brings up the administered objects that can be mapped during the deployment process. These objects are bound during the start of the deployed application.
/* * Copyright (c) 2006 Pramati Technologies Private Ltd. All Rights Reserved. * This software is the confidential and proprietary information of Pramati Technologies. * You shall not disclose such Confidential Information and shall use it only in accordance * with the terms of the source code license agreement you entered into with * Pramati Technologies. */ package com.pramati.services.resource.spi; import java.util.List; import java.util.Properties; import javax.jms.TopicConnection; import javax.jms.XATopicConnection; import javax.jms.TopicConnectionFactory; import javax.jms.XATopicConnectionFactory; import javax.jms.JMSException; import com.pramati.services.resource.ConfigPropertyMetaData; /** *This interface is implemented by JMS providers to provide integration with Pramati *J2ee Server. *
*a) Getting AdministeredObects (destinations and connection factories) for the use *in the deployment tool of the server:– *This functionality is used to obtain the list of bound jms (queues, topics, *TopicConnectionFactories, QueueConnectionFactories, XATopicConnectionFactories, *XAQueueConnectionFactories) resources all/of particular type. *
*b) Getting the jms XATopicConnection/TopicConnection for the Pramati J2EE cluster:- *Here we provide the JMS server with cluster name and node name of the J2EE Cluster *and user name and password for security authentication in connection creation. *An MDB is deployed homogenously on the Pramati J2EE Cluster. Hence the MDB will be *deployed on all the J2EE nodes and hence all J2EE nodes will create the connection *to the JMS server/cluster for receiving the messages. Ideally in this case MDB on *only one of the J2EE nodes should actually receive the message. Hence the delivery of *the messages should be performed in a round robin fashion from the JMS Server. *This method provides the JMS server provider of the same information. The JMS server *should internally takes care of distribution of messages among all the J2EE cluster nodes. *This is not a good assumption and hence being worked upon. *In the future releases we will come with a distribution mechanism outside the scope of JMS *provider server. This method pitches in only in case of J2EE cluster being used. * * @version 1.0 created 4:39 PM Thursday, September 27, 2001 * @author Priyank Rastogi */ public interface JMSProvider { public static final String TOPIC_CONN_FACTORY = "javax.jms.TopicConnectionFactory"; public static final String QUEUE_CONN_FACTORY = "javax.jms.QueueConnectionFactory"; public static final String CONN_FACTORY = "javax.jms.ConnectionFactory"; public static final String XA_TOPIC_CONN_FACTORY = "javax.jms.XATopicConnectionFactory"; public static final String XA_QUEUE_CONN_FACTORY = "javax.jms.XAQueueConnectionFactory"; public static final String XA_CONN_FACTORY = "javax.jms.XAConnectionFactory"; public static final String QUEUE = "javax.jms.Queue"; public static final String TOPIC = "javax.jms.Topic"; public static final String LOOKUP_FROM_MDB = "lookup_from_mdb"; /** *This method is called with the properties specified in the resource-config.xml for the *adapter. The provider can perform JNDI setup and initialization of global onjects like *MBeans required in this method. * @param props * @throws JMSException */ public void initialize(Properties props) throws JMSException; /** *This refreshes the internally maintained data structures if any. User should also *perform a re-initialization before updating the datastructures. */ public void refresh() throws JMSException; /** *This is a generic method which will be called when the JMS provider is unable to provide *an implementation of getXAFactories methods. This must return all TopicConnectionFactories *defined in the server. These will be used for the mapping in the deployment tool as well *as for the runtime validation of archives getting deployed. * *@return list of names of ConnectionFactories (XA and non-XA) available in the server. */ public List getTopicConnectionFactories() throws JMSException; /** *This is a generic method which will be called when the JMS provider is unable to provide an *implementation of getXAFactories methods. This must return all QueueConnectionFactories *defined in the server. These will be used for the mapping in the deployment tool as well as *for the runtime validation of archives getting deployed. * *@return list of names of ConnectionFactories (XA and non-XA) available in the server. */ public List getQueueConnectionFactories() throws JMSException; /** *This is a generic method which will be called when the JMS provider is unable to provide an *implementation of getXAFactories methods. This must return all ConnectionFactories defined *in the server. These will be used for the mapping in the deployment tool as well as for the *runtime validation of archives getting deployed. * *@return list of names of ConnectionFactories (XA and non-XA) available in the server. */ public List getConnectionFactories() throws JMSException; /** *This method returns all the XAQueueConnectionFactories available in the JMS server. *These will be used for mapping in the deployment tool as well as for the runtime *validation of archives getting deployed. * *@return list of names of XAQueueConnectionFactories available in the server. */ public List getXAQueueConnectionFactories() throws JMSException; /** *This method returns all the XATopicConnectionFactories available in the JMS server. *These will be used for mapping in the deployment tool as well as for the runtime *validation of archives getting deployed. * *@return list of names of XATopicConnectionFactories available in the server. */ public List getXATopicConnectionFactories() throws JMSException; /** *This method returns all the XAConnectionFactories available in the JMS server. These *will be used for mapping in the deployment tool as well as for the runtime validation *of archives getting deployed. * *@return list of names of XAConnectionFactories available in the server. */ public List getXAConnectionFactories() throws JMSException; /** *This method returns all the Topics available in the jms server. These will be used for *mapping in the deployment tool as well as for the runtime validation of archives getting *deployed. * * @return list of names of Topics available in the server. */ public List getTopics() throws JMSException; /** *This method returns all the Queues available in the JMS server. These will be used for *mapping in the deployment tool as well as for the runtime validation of archives getting *deployed. * * @return list of names of Queues available in the server. */ public List getQueues() throws JMSException; /** *This method returns the Administered object bound in the JMS server with the name specified. * *@param resourceName the actual name of the administered object in the jms server. *@return administered object representing the resourceName in the jms server */ public Object getAdministeredObject(String resourceName) throws JMSException; /** *This method returns the Administered object bound in the JMS server with the name and *type specified. * *@param resourceName: the actual name of the administered object in the JMS server. *@param type: the type the administered object. *@return administered object representing the resourceName in the jms server */ public Object getAdministeredObject(String resourceName, String type) throws JMSException; /* *This method provides the information of what all properties are required for the *initialization of the adapter. These properties will be used to prompt the user to give *the values for. *@return metadata containing name & description of properties that this jms adapter accepts. */ public ConfigPropertyMetaData[] getPropertiesInfo(); /** *This method will return a TopicConnection for the specified cluster and node name *@param factory: TopicConnectionFactory to be used for creating the connection *@param clusterName: Name of the cluster for the which the connection is being created *@param nodeName: Name of the node of the cluster for which the connection is being created. * @param userName: Name of the user * @param password: Password * * @return TopicConnection for the cluster */ public TopicConnection getTopicConnectionForCluster(TopicConnectionFactory factory, String clusterName, String nodeName, String userName, String password) throws JMSException; /** *This method returns a TopicConnection for the specified cluster and node name *@param factory: TopicConnectionFactory to be used for creating the connection *@param clusterName: Name of the cluster for the which the connection is being created *@param nodeName: Name of the node of the cluster for which the connection is being created. *@param userName: Name of the user *@param password: Password * * @return XATopicConnection for the cluster */ public XATopicConnection getXATopicConnectionForCluster(XATopicConnectionFactory factory, String clusterName, String nodeName, String userName, String password) throws JMSException; }
 |
|
| © Pramati Technologies 2007 | Runs on Pramati Server | Feedback | Legal |