Hi
[Sorry for the long email :)]
Thanks Jesper, Wilson and Fred for sharing your comments on
CONNECTOR_SPEC-1. I had a discussion with the JMS spec leads and the
platform spec leads, and here is an analysis of the two approaches and
a way to move forward.
- I am attaching a doc to use as a refresher that highlights the
changes proposed by the two approaches, and a list of their benefits
and issues.
Analysis:
- The benefits that the original approach brings is that it continues
to retain the goal that the MDB container be unaware of the
messaging system that is represented by the RA. A side-effect of
defining the new capabilities(such as instance name) is that non-JMS
RAs could also leverage them.
However the original approach cannot handle scenarios of
non-MDB MEF implementations of standalone connector containers
(that Section 3.5 of the Connectors spec allows), unless we require
such containers to support JNDI and make the necessary objects
available in JNDI so that the RA can perform a lookup during
endpointActivation to get to these objects. The original approach
requires us to support JNDI lookup during endpointActivation as
discussed in
http://java.net/jira/browse/CONNECTOR_SPEC-4.
- The benefit that the new approach brings is that it bridges the JMS
RA directly with the MDB container especially since some of the changes
being discussed were driven from JMS requirements. By requiring the MDB
container to handle the specifics of working with
the JMS RA, this approach leaves it to the MEF implementation to handle
the integration. This should work well with non-MDB based MEF
implementations, since the JMS RA is completely unaware of the MEF
implementation and the only interface it expects the MEF implementation
to satisfy is the JMSActivationSpec requirements.
However the new proposal results in the MDB container needing to do
JMS-specific operations (such as populating a JMSActivationSpec), and
prevents the use of the new capabilities by non-JMS RAs.
Design considerations:
- We must continue to keep MDB containers as generic as possible, and
not require the MDB container to know that they are delivering to JMS
RAs. This was the goal of the generic Message Inflow by RAs/Message
Endpoint/MEF separation in Connectors 1.5 and the MDB enhancements in
EJB 2.1.
- We should optimize our design towards valid supported Java EE
scenarios, than trying to handle corner-case scenarios such as non-MDB
component containers in standalone connector containers.
Proposal:
I would like to suggest that we go with the original approach,
considering the two points discussed above.
To address the problem of the original approach not being able to
handle non-MDB MEF implementations, if the EG feels that it is
important, we could do one of the following:
- require that any Message Inflow implementations must support JNDI or
- leave it to the JMS RA to handle such edge-scenarios (where JNDI may
not be available) or
- define other schemes (that is generic for the MDB container, but
still allows portability of the RA, such as defining special schemes
in config property names to request lookup of objects in the container
and have them set automatically in an ActivationSpec property etc).
What do you think? Please share your comments and inputs.
Thanks
--Siva.
On Wednesday 12 December 2012 05:56 PM, Frederick W Rowe wrote:
> I agree with moving appendix B to JMS spec to resolve CONNECTOR_SPEC-5
> I agree with Jesper's suggestion for meeting the feature request in
> CONNECTOR_SPEC-1.
>
> Regards,
>
> Fred Rowe
>
> WebSphere Architect
> Senior Software Engineer
> IBM Software Group
> frowe_at_us.ibm.com
>
>
> *Sivakumar Thyagarajan <sivakumar.thyagarajan_at_oracle.com>*
>
> 12/06/2012 10:18 AM
> Please respond to
> jsr322-experts
>
>
>
> To
> jsr322-experts_at_connector-spec.java.net
> cc
> Wilson Tian <wilson.tian_at_oracle.com>
> Subject
> [connector-spec-users] [jsr322-experts] Re: JMS RA requirements
> (Discussion on CONNECTOR_SPEC-1 and CONNECTOR_SPEC-5)
>
>
>
>
>
>
>
>
> Hi Jesper and Wilson
>
> On Thursday 06 December 2012 01:17 PM, Wilson Tian wrote:
> > I like Jasper's proposal of using a special JmsActivationSpec, and
> which seems should be defined in JMS SPEC.
>
> This looks like a very good proposal. Thanks for sharing this.
> I am working offline with the JMS and the EJB spec leads, to see
> how we can take this proposal forward. Please see some
> comments inline.
>
> > Furthermore, we may consider to move all JMS related new features
> > including CONNECTOR_SPEC-4 to this class:
> > public interface JmsActivationSpec extends ActivationSpec {
> > public String getActivationUniqueName();
> > public void setActivationUniqueName(String v);
> >
> > public String getInstanceName();
> > public void setInstanceName(String name);
> >
> > public Destination getDestination();
> > public void setDestination(Destination destination);
> >
> > public ConnectionFactory getConnectionFactory();
> > public void setConnectionFactory(ConnectionFactory cf);
> >
> > ... // anything required by JMS adapter
> > }
> > These new properties are all used by JMS adapter only at least in this
> > moment and I am not sure they make sense for other adapters.
>
> The ability to know if a RA is operating in a clustered environment and
> know the instance name and activation name may be useful for other
> RARs. However, I have not heard of this requirement with specific
> usecases that needs these information outside the JMS context.
> So, this looks like a good choice.
>
> > Since it is MDB container, when Endpoint application is MDB, that is
> > responsible for setup correct values for ActivationSpec, it would be
> > nature to require MDB container to do lookup in its namespace based on
> > destinationLookup/connectionFactoryLookup before pass the ActivationSpec
> > instance to endpointActivation call. Adapters will no longer required to
> > do JNDI lookup anymore.
>
> Yes.
>
> > Furthermore, IIUC, Endpoint applications do NOT necessarily mean MDB;
> > they may be non-MDB as long as AS supports and this is allowed by
> > Connector 1.6 SPEC. Non-MDB Endpoint applications may or may not have
> > java:comp namespaces. Therefore we'd better not put hard requirement on
> > this in Connector SPEC.
>
> Yes, Message Endpoints may be non-MDBs (for instance non-MDB
> endpoints supported by a standalone connector container
> implementation that supports Message Inflow through an approach
> different from MDBs - Section 3.5 of the Connectors spec).
>
> > By moving these method to JmsActivationSpec, Endpoint application
> > providers, no matter MDB container or anything else, are free to use its
> > own solution to provide those objects based on
> > destinationLookup/connectionFactoryLookup values.
>
> Agreed.
>
> Thanks
> --Siva.
>
> > Thanks
> > Wilson
> >
> >
> >> -----Original Message-----
> >> From: Jesper Pedersen [mailto:jesper.pedersen_at_redhat.com]
> >> Sent: Thursday, December 06, 2012 3:22 AM
> >> To: jsr322-experts_at_connector-spec.java.net
> >> Subject: [jsr322-experts] Re: JMS RA requirements (Discussion on
> CONNECTOR_SPEC-1 and CONNECTOR_SPEC-5)
> >>
> >> Hi,
> >>
> >> On 12/05/2012 01:38 PM, Sivakumar Thyagarajan wrote:
> ...
> >>> QUESTION: What do you think? Any other choice for the method name?
> >>> Is the group fine with the proposed javadoc requirements for the method?
> >>>
> >>
> >> The activation is based on the ActivationSpec, so why not do
> >>
> >> package javax.jms.ra;
> >>
> >> public interface JmsActivationSpec extends ActivationSpec {
> >> public String getActivationUniqueName();
> >> public void setActivationUniqueName(String v); }
> >>
> >> ?
> >>
> >> Yes, it would make the contract more loose, but the whole area is
> pretty loose anyway. The component (f.ex. MDB
> >> container) creating the MessageEndpointFactory would detect that it is
> a JmsActivationSpec instance and fill out
> >> the values needed.
>
> Arguably, this makes the contract between the JMS RA and the MDB container
> more stronger and clearer. So, this is good. Since this proposal also
> extends the ActivationSpec, this is a backward compatible change.
>
> Thanks
> --Siva.
>
> >>> 2.(b) allowing Topic subscriptions to be shared or not shared across a
> >>> cluster.
> >>>
> >>
> >> As above, with the additional information needed.
> >>
> >> Best regards,
> >> Jesper
> >>
>
>
- application/pdf attachment: stored