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".