Re: JMS Outbound with Connector 1.5

Hi Jim,

I don't think that JMS outbound messaging works that way by just providing a
javax.jms.Connection. This is how it works today and the app server proxies
this Connection (which is actually a handle) to enlist tx etc. The
implementation of this layer differs from app server to app server, of
course.

However, what we like to do is to provide a 1.5 RA to plug in our JMS in any
J2EE 1.4 compliant app server so that it can be used for JMS inbound and JMS
outbound messaging in a standard way. Inbound is not the problem but
outbound seems to be completely unspecified!!

The 1.5. spec states that a ManagedConnectionFactory creates a
cci.ConnectionFactory which in turn creates a cci.Connection which isn't
compatible with a javax.jms.Connection due to the different exceptions of
the close and the different meta data of the getMetaData method.
ManagedConnectionFactory is required to be deployed as a RA. So there is no
other way than ManagedConnectionFactory.

JMS is a J2EE API. It is not some proprietary API of an EIS or whatever
which a component has to access via generic Interaction interfaces. So I
expect a spec how to use JMS outbound from an app server component and how
these JMS stuff is integrated with the resourse adapter.

Could someone from the expert group please comment on this. You guys should
know what you have specified.

Andreas

--
Andreas Mueller
IIT GmbH, Bremen/Germany
http://www.swiftmq.com

----- Original Message -----
From: "Jim Gish" <[email protected]>
To: <[email protected]>
Sent: Friday, August 29, 2003 7:11 PM
Subject: Re: JMS Outbound with Connector 1.5


Here's the section that talks about message provider pluggability:

  J2EE applications may use two different patterns to interact with a
message provider:


  . It may directly use specific messaging APIs, such as Java Messaging
Service (JMS), to send
  and synchronously receive messages. This is achieved using the standard
connector
  contracts for connection management. See Chapter 6, "Connection
Management". Any
  message provider may provide a connector resource adapter that supplies
connection
  objects for use by applications to send and synchronously receive messages
using the
  specific messaging API. [This is the outbound case that your question asks
about]


  . It may use message-driven beans to asynchronously receive messages via a
message
  provider. The EJB specification (See Related Documents, page 302, [1])
describes the
  message-driven bean component contract in detail.


My bet is that a message provider resource adapter wouldn't implement CCI.
What's the advantage?  So, in the case of JMS, it would just implement the
javax.jms.Connection and you would proceed as with any JMS connection.

Jim


At 04:37 AM 8/29/2003, Andreas Mueller wrote:

  Hi,

  according to the spec the app component looks up a
  javax.resource.cci.ConnectionFactory and obtains a
  javax.resource.cci.Connection. The latter is actually a handle to the
  physical (Managed) connection.

  To use the EIS, the app component casts the javax.resource.cci.Connection
to
  the resp. EIS connection and uses that. Is that right till here?

  Now with a JMS RA I would expect the javax.resource.cci.Connection is a
  javax.jms.Connection (JMS 1.1) and thus the app component casts it to this
  type. However, this is not possible because both
  javax.resource.cci.Connection and javax.jms.Connection are incompatible.
  They throw different exceptions on close and return different MetaData.

  Also I would assume that outbound JMS messaging via a RA is specified
  somewhere. I don't find it in the specs. If that is not specified then the
  API is not standardized via a RA and in a worst case an app component has
to
  change its code if the JMS vendor changes.

  Or is the JMS pluggability only for message inflow? That would be indeed a
  big disadvantage.

  Could someone clearify, please?

  Thanks,
  Andreas

  --
  Andreas Mueller
  IIT GmbH, Bremen/Germany
  http://www.swiftmq.com


===========================================================================
  To unsubscribe, send email to [email protected] and include in the
body
  of the message "signoff CONNECTOR-INTEREST".  For general help, send email
to
  [email protected] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff CONNECTOR-INTEREST". For general help, send email to
[email protected] and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff CONNECTOR-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".