Hi experts
In this email, I would like to discuss one of the important areas that
this MR seeks to address, namely enhanced JMS/MDB integration.
Sorry for the long email. Please let this group know any questions,
inputs, and comments you may have.
The Message Inflow Contract (Chapter 13) in the Connectors spec have
served as the standard message provider pluggability contract allowing
different JMS products to be plugged into any Java EE application server
through a resource adapter provided by the product.
However the need to provide a resource adapter was left to the JMS
vendor. There were recommended suggestions while building this resource
adapter (Appendix B of the Connectors 1.6 specification), but no
standard way to work with such a JMS resource adapter.
The JMS 2.0 expert group has been working for the last year [1],
studying how this integration can be enhanced and made portable.
JMS 2.0 now requires a JMS Provider to provide a Resource Adapter thus
further solidifying the role of Connectors in Message Provider
Pluggability, and also has made steps in standardizing JMS
ActivationSpec configuration properties to enable more portable JMS MDBs.
The JMS EG's work is in discussed in Chapter 12 of the JMS 2.0
specification [2].
1. With the JMS specification defining the standard configuration
elements for all JMS RAs, the non-normative Appendix B is not relevant
in our specification.
*Spec impact*:
We could remove Appendix B, and instead provide a pointer to the JMS
spec (Chapter 12) for more information on JMS RA configuration.
I have raised a JIRA issue CONNECTOR_SPEC-5 to track this.
QUESTION: Is the group ok with this removal of Appendix B from the spec?
JMS 2.0 adds 2 new features (that are discussed below in 2(a) and 2(b))
and they are discussed in detail in:
* the JMS spec chapter 12 (which defines the behaviour of a JMS RA) [2]
* the EJB 3.2 spec [3] 5.4.16.7 and 5.4.16.9 (which define the behaviour
of a JMS MDB which doesn't use Connectors).
2.(a) Allowing Topic subscription names to be left unset by the
bean deployer: This is an ease of use feature, as most users simply set
the subscription name to the name of the MDB manually, and this could
be automated through a contract between the container and the RA.
[As a refresher, the definitions of Topic Subscriptions,
Durable/Non-Durable, Shared/Non-Shared subscriptions are in Section 6.3
and 6.11 of [2]].
To support 2.(a), there is a proposal from Nigel Deakins in
CONNECTOR_SPEC-1 to enhance the MessageEndpointInterface to add a new
method to provide the MessageEndpoint's name to the RA, and suggests
the requirements on the MDB container's implementation of this method.
Though some of the requirements appear to be JMS-specific, this method
and the proposed javadoc requirements are written in a generic way so
that it could be used by all RAs.
A JMS RA would then be able to use this during endpointActivation to
determine the unique MDB name that is being activated while generating
the JMS topic subscription name. The current proposed name
is MessageEndpointFactory.getEndpointUniqueName(), but I would like it
to be modified to getActivationUniqueName() as we are talking about the
unique name for the Activation in the application server.
QUESTION: What do you think? Any other choice for the method name?
Is the group fine with the proposed javadoc requirements for the method?
2.(b) allowing Topic subscriptions to be shared or not shared across
a cluster.
For an unshared durable topic subscription in a clustered setup, the
requirement is that the JMS RA should be able to generate unique
subscription names for that Activation(MDB) for every server instance
in the cluster.
So if the "shareSubscriptions" ActivationSpec property is set to true,
the subscription name for a durable topic subscription generated by the
RA could be equal to the value returned by
MessageEndpointFactory.getUniqueName().
When shareSubscriptions=false and this is a durable topic subscription
in a cluster, the subscription name generated by the RA could be
MessageEndpointFactory.getUniqueName() combined with the server
instance name in the cluster to ensure that the subscription is not
shared among the various instances in the cluster.
To handle this, CONNECTOR_SPEC-1 proposes a new method
MessageEndpointFactory.getInstanceName for a RA to get hold of the
instance name. Since the instance name is going to be common across MEF
instances, I have suggested that this be moved to
BootstrapContext.getInstanceName.
QUESTION: What do you think of the idea? Suggestions for the method
name, requirements? Is the group fine with the proposed javadoc
requirements for the method?
Once we have a better understanding on this, I will send out a proposed
spec change, API changes for CONNECTOR_SPEC-1.
Thanks
--Siva.
[1] JMS 2.0 jcp project:
http://java.net/projects/jms-spec
[2] JMS 2.0 Working Draft:
http://java.net/projects/jms-spec/sources/repository/content/jms2.0/specification/word/JMS20.pdf
[3] EJB 3.2 PD 3:
http://java.net/projects/ejb-spec/downloads/download/ejb-3_2-core-pd-3.pdf