Re: JMS Outbound with Connector 1.5
Jim Gish <[email protected]> Fri, 29 Aug 2003 13:11:15 -0400
| Newsgroups | gmane.comp.java.sun.connector |
|---|---|
| Message-ID | <[email protected]> |
<html> Here's the section that talks about message provider pluggability:<br> <dl><font face=3D"Times New Roman, Times"> <dd>J2EE applications may use two different patterns to interact with a message provider:<br><br> <dd>=95 It may directly use specific messaging APIs, such as Java Messaging Service (JMS), to send <dd>and synchronously receive messages. This is achieved using the standard connector <dd>contracts for connection management. See Chapter 6, =93Connection Management=94. Any <dd>message provider may provide a connector resource adapter that supplies connection <dd>objects for use by applications to send and synchronously receive messages using the <dd>specific messaging API. </font><font color=3D"#0000FF">[This is the outbound case that your question asks about]<br><br> </font><font face=3D"Times New Roman, Times"> <dd>=95 It may use message-driven beans to asynchronously receive messages via a message <dd>provider. The EJB specification (See Related Documents=82 page 302, [1]) describes the <dd>message-driven bean component contract in detail.<br><br> </font> </dl>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.<br><br> Jim<br><br> <br> At 04:37 AM 8/29/2003, Andreas Mueller wrote:<br> <blockquote type=3Dcite class=3Dcite cite>Hi,<br><br> according to the spec the app component looks up a<br> javax.resource.cci.ConnectionFactory and obtains a<br> javax.resource.cci.Connection. The latter is actually a handle to the<br> physical (Managed) connection.<br><br> To use the EIS, the app component casts the javax.resource.cci.Connection to<br> the resp. EIS connection and uses that. Is that right till=20 here?<br><br> Now with a JMS RA I would expect the javax.resource.cci.Connection is a<br> javax.jms.Connection (JMS 1.1) and thus the app component casts it to this<br> type. However, this is not possible because both<br> javax.resource.cci.Connection and javax.jms.Connection are incompatible.<br> They throw different exceptions on close and return different MetaData.<br><br> Also I would assume that outbound JMS messaging via a RA is specified<br> somewhere. I don't find it in the specs. If that is not specified then the<br> API is not standardized via a RA and in a worst case an app component has to<br> change its code if the JMS vendor changes.<br><br> Or is the JMS pluggability only for message inflow? That would be indeed a<br> big disadvantage.<br><br> Could someone clearify, please?<br><br> Thanks,<br> Andreas<br><br> --<br> Andreas Mueller<br> IIT GmbH, Bremen/Germany<br> <a href=3D"http://www.swiftmq.com/"= eudora=3D"autourl">http://www.swiftmq.com</a><br><br> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= br> To unsubscribe, send email to [email protected] and include in the body<br> of the message "signoff CONNECTOR-INTEREST". For general help, send email to<br> [email protected] and include in the body of the message "help".</blockquote></html> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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".