Re: JMS Outbound with Connector 1.5

Hi Johan,

now I see...

I had the impression that ManagedConnectionFactory.createConnectionFactory()
returns a cci.ConnectionFactory and thus I thought it is hard linked to CCI.
However, now I realize it returns java.lang.Object and so I can return any
connection factory (even a javax.jms.ConnectionFactory!).

Completely my fault.

Sorry!

Thanks,
Andreas

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

----- Original Message -----
From: "Johan Eltes" <[email protected]>
To: <[email protected]>
Sent: Saturday, August 30, 2003 1:40 PM
Subject: Re: JMS Outbound with Connector 1.5


> Andreas,
>
> There are two option when provifing a resource adapter:
>
> - Implement CCI
> - Implement any other interface of your choice, as long as there is a
> connection factory interface and a connection interface.
>
> IBM/WebSphere 5 is wrapping all JMS providers with a generic JMS
connector.
> WLS is not, which over the ysers has made it impossible to get reliable
> outbound JMS processing with WLS and MQSeries (reliability solved with WLS
> 8, but not configurability). Pointning at the cci as being "guilty" for
> causing problems related to outbound JMS is not valid.
>
> Take a look at WebSphere 5 and you will get the idea of how the connector
> spec is intended to be used.
>
> /Johan
>
> Den 03-08-30 11.22, skrev "Andreas Mueller" <[email protected]>:
>
> > 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".
> >
>
>
===========================================================================
> 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".