JMS descriptor files used by Weblogic and how they might be supported in Glassfish SUMMARY There is limited scope to support a Weblogic JMS descriptor file (*-jms.xml) in Glassfish. There is an obvious correspondence between these and the sun-resources.xml file supported by Glassfish, since both are XML documents that define resources that are created in the corresponding administration console. If support for the Weblogic JMS descriptor file were added to Glassfish then the processing of such a file might be similar to the way that a sun-resources.xml is currently handled and much of the analysis below is performed on that basis. Weblogic JMS descriptors may be deployed as globally "system modules", or as a named "package module" either standalone or packaged in an application, In contrast the sun-resources.xml file is rather like an asadmin script that simply creates global resources. If support for the Weblogic JMS descriptor file were added to Glassfish then these completely new concepts would need to be added to Glassfish (and supported directly via the admin console as well as via deployment descriptors). Note that although Jagadish Ramu has been looking at adding the ability for sun-resources.xml to define "application scoped resources" to Glassfish 3.1, this is not the same thing. There is a related concept in Weblogic called a "JDBC module". Supporting JDBC modules may impose similar requirements on Glassfish to those imposed by JMS modules. It should be possible to map a queue or topic in the Weblogic JMS descriptor to a queue or topic resource in Glassfish. However the only attributes that can be supported are JNDI name and physical destination names. All other attributes are weblogic-specific. The Weblogic JMS descriptor file includes definitions of a connection factories. However these are raw JMS connection factories; these have no equivalence in Glassfish, which only handles resource-adapter-managed connection factories. These are defined in weblogic as part of the resource adapter deployment descriptor weblogic-ra.xml. It might be appropriate to map these to Glassfish managed connection factories, as defined in sun-resources.xml. Jagadish Ramu is looking at what elements of weblogic-ra.xml might be supported. The remaining elements defined in the Weblogic JMS descriptor file are specific to Weblogic JMS (even if they configure functionality that is also supported by MQ), and it is not appropriate to try to support these directly. DETAIL The WebLogic JMS descriptor is an XML file used to define entities called "JMS Modules" in Weblogic's JNDI store. (You can also create JMS modules using the admin console). JMS descriptor files typically have a name ending with "-jms.xml". JMS descriptor files are used to define and configure JMS resources used by Weblogic applications. They can either be deployed in three ways:
- globally as "system modules" (this is the older technology),
- as named groups of resources called "application modules", which can be deployed either
- "standalone" or
- "packaged" as part of an application.
Note that JMS descriptors are not intended for JMS server configuration. JMS servers are defined separately, in the Weblogic domain configuration file, and are not considered further here. Here's the schema of a JMS descriptor file:
http://www.oracle.com/technology/weblogic/10.3/weblogic-jms/1.0/weblogic-jms.xsd Here's a good place to start in the user guide:
http://download.oracle.com/docs/cd/E12839_01/web.1111/e13738/overview.htm#i1081492 What can you define in a JMS module? Here are the main elements in the scheme:
- version
- notes
- quota
- template
- destination-key
- connection-factory
- foreign-server
- queue
- topic
- distributed-queue
- distributed-topic
- uniform-distributed-queue
- uniform-distributed-topic
- saf-imported-destinations
- saf-remote-context
- saf-error-handling
How does this relate to Glassfish? What we have here is a way of configuring admin resources in an XML file that can either be deployed directly into the app server (either globally or as named modules) or bundled in an application. The obvious equivalent in Glassfish is the sun-resources.xml file: http://docs.sun.com/app/docs/doc/820-7693/giyhh?a=view which can be used to define resources needed in an application. You can deploy it using asadmin or Netbeans, but you can't include it in an EAR file, and there is no concept in Glassfish of a JMS module, a named group of related JMS resources. Review of elements The configuration elements with the most obvious correspondence with Glassfish are
in that they map a JNDI name to a defined physical queue or topic. However the correspondence ends here: in Glassfish (in sun-resources.xml) you can associate a JNDI name with the "physical destination name" used by MQ. However you can't use Glassfish to define any other properties of the destination. These need to be defined using MQ tools, notably imqadmin. Conversely, although Glassfish allows you to associate a destination with a resource adapter (jmsra by default) this doesn't seem possible in the Weblogic descriptor Note that even if Glassfish could be used to configure destination properties there isn't a one-to-one correspondence between MQ destination properties and Weblogic destination properties, making a direct mapping inappropriate. It is suggested that Glassfish does support the queue and topic elements in the Weblogic JMS descriptor, but only to map a JNDI name to a physical name. (That said, I haven't identified where the physical destination name is configured, but it must be defined somewhere). Another configuration element with a possible correspondence with Glassfish is
ConnectionFactory is a well-defined concept in JMS, and this descriptor defines numerous weblogic-specific connection-related properties such as flow control. However you can't define any properties related to connection pools. This is because Weblogic doesn't use a resource adapter by default, and if you do, any connection pools need to be configured in weblogic-ra.xml, not here. By contrast, when you define the corresponding resource in Glassfish (in sun-resources.xml) you are actually defining a JCA connection pool of connection factories created by a defined resource adapter. You can fully-define the connection pool, and you can specify connection factory properties exposed by the resource adapter. However you can't define properties of the underlying MQ connection factory (though the new options property does provide a way to do this). So we can't map a connection-factory element in the JMS descriptor *-jms.xml to anything. We might, however, map a connection factory (and connection pool) in weblogic-ra.xml to a connection factory in sun-resources.xml. Jagadish Ramu is looking at what support might be provided for elements in weblogic-ra.xml.
- version
- notes
- quota
- template
- destination-key
- foreign-server
- distributed-queue
- distributed-topic
- uniform-distributed-queue
- uniform-distributed-topic
- saf-imported-destinations
- saf-remote-context
- saf-error-handling
The other configuration elements are used to configure specific features of Weblogic JMS. These cannot be supported by Glassfish for one or more of the following reasons:
- There is no equivalent in MQ (e.g. foreign server, distributed queues), not because of a limitation of MQ but because they are different products
- MQ has a similar concept but it is implemented differently so there is no correspondence of attributes (e.g. flow control)
- Any similar feature in MQ needs to be configured as a broker configuration option, and Glassfish does not currently provide general access to broker configuration options (e.g. destination quota)
High-level roadmap The limited support for Weblogic JMS descriptor files suggested above might be implemented in stages as follows:
1. Add generic support to allow Weblogic JMS descriptor files ending with "-jms.xml" to be parsed and used to create Glassfish admin resources, just like is currently possible with sun-resources.xml.
2. Add code to handle those elements that can be supported and map them to appropriate Glassfish resources
This would give a certain amount of support for "system" JMS modules, the simplest kind of JMS module.
3. Extend Glassfish to support named groups of JMS resources, corresponding to "standard" JMS modules in Weblogic. This would introduce a new type of entity to Glassfish; it would need to be possible to configure an application to specify which JMS modules it used so would affect multiple components including the admin console. Part of this work would involve parsing Weblogic JMS descriptor files to create standard JMS modules.
4. Extend Glassfish to allow a group of JMS resources to be defined in an application archive, corresponding to "packaged" JMS modules in Weblogic. Again this would require changes to multiple Glassfish components.
Note that even when all four steps were completed only a small subset of a Weblogic JMS descriptor would be supported.
|
