Lucas;

Just for the record, WebLogic to JBossMQ is not a
specific scenario I am trying to support, but rather
it is an example of a generic scenario I am trying to
support in my framework.

I see your points, but it is common and supported
practice to serialize ConnectionFactory objects into
JNDI. The factory is static and should be configured
to produce connections that are valid ("conectable")
assuming that the JMS server they are configured to
connect to is up and running. The location of the JNDI
where the ConnectionFactory should be irrelevant.

To further this point, see the Java Doc for the parent
class fo QueueConnectionFactory
(javax.jms.ConnectionFactory) at 
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/ConnectionFactory.html

Quotes:
1.A ConnectionFactory object encapsulates a set of
connection configuration parameters that has been
defined by an administrator. A client uses it to
create a connection with a JMS provider. 
2. A ConnectionFactory object is a JMS administered
object. 
3. Although the interfaces for administered objects do
not explicitly depend on the Java Naming and Directory
Interface (JNDI) API, the JMS API establishes the
convention that JMS clients find administered objects
by looking them up in a JNDI namespace. 

In summary, for a compliant JMS server, I believe that
you shoudl be able to acquire a QueueConnectionFactory
 (either by construction one, as in my SonicExample,
or by looking it up in the JMS server's own JNDI) and
serialize into another JNDI (say an LDAP server).
Subsequent retrievals of the newly serialized
QueueConnectionFactory will deliver an object that
should yield up valid connections to the orogonal JMS
server that the QueueConnectionFactory was configured
to attach to.

At least, it works that way with:
MQSeries 
WebLogic
SonicMQ
Fiorano
iBus
(Working on more.....)

//Nicholas


--- Lucas McGregor <[EMAIL PROTECTED]> wrote:
> So you want to access a Jboss QueueConnectionFactory
> from weblogic.
> 
> Just to make sure that I am being clear on the
> subject (warning, I might
> sound resundant :-), you cannot serialize a
> QueueConnectionFactory. What is
> serialized and registered in the JNDI tree is a
> handle to the connection
> factory. This is analogous to a JDBC connection
> pools, you get access to
> them via a handle object, a DataSource.
> 
> You can take the reference to the handle object from
> the Jboss JNDI registry
> and register it to the JNDI tree that weblogic is
> accessing. Now you have
> two JNDI tree's, each with a reference to a
> QueueConnectionFactory that is
> living in the Jboss JVM. Thus, if you shut down the
> Jboss JVM, you will have
> stale references in your weblogic JNDI tree. So, by
> serializing the
> ConnectionFactory, you are just copying the
> reference to the
> QueueConnectionFactory, not the actual factory.
> 
> Jboss' QueueConnectionFactory is a MBean that Jboss
> loads in response to
> lines in your jboss.jcml file.
> 
> The QueueConnectionFactory API defines no
> constructors, 
>
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/QueueConnectionFacto
> ry.html
> It is up to the vendor to create
> QueueConnectionFactory as they see fit.
> They just have to implement the two
> createQueueConnection() methods.
> 
> How app servers deal with JMS is very similar to how
> they deal with JDBC.
> The actual connections and connection pools are up
> to the app server and the
> driver vendor. How your EJB's (MDB's) interact with
> JMS is defined by the
> EJB 2.0 standard, but how each vendor implements the
> creation and management
> of the resource is not--just like how entity beans
> are bound to
> javax.sql.DataSource resources is defined by the EJB
> spec, but how your app
> server configures, manages, and runs the JDBC
> connections that the
> javax.sql.DataSource represent is not defined. 
> 
> The Sun J2EE Pattern Catalog (requires registration,
> but it's free) has a
> Data Accessor Object
>
pattern(http://developer.java.sun.com/developer/restricted/patterns/DataAcce
> ssObject.html). It is used to isolate the
> differences between DataSource
> implementations. maybe you could adapt it to isolate
> differences in JMS
> implementations. They might have other patterns in
> the JDBC arena that might
> be helpful.
> 
> http://www.theserverside.com/ has had a lot about
> JMS and MDB's in the last
> couple of months, maybe that have something that
> will help your with your
> abstraction layer.
> 
>       Good Luck!
>       Lucas McGregor, NovaLogic
> 
> 
> 
> -----Original Message-----
> From: Nicholas [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 25, 2002 2:23 PM
> To: Lucas McGregor
> Subject: RE: [JBoss-user] Constructor for JBossMQ
> ConnectionFactories
> 
> 
> Hmmm..., what I am trying to do, is write a paper
> that
> describes how to load JMS connection factories (and
> JMS Destinations)into AppServer's JNDI. This is so
> they can be used for deploying and running MDBs. I
> am
> also attempting to write a framework which will
> allow
> developers to easily incoorporate JMS objects from
> any
> vendor.
> 
> So for example, and SonicMQ QueueConnectionFactory
> can
> be constructed as follows:
> 
> QueueConnectionFactory qcf = new
> QueueConnectionFactory(host, port, protocol,
> username,
> password);
> 
> The resulting object is then serialized into JNDI.
> 
> So, my question is, if I need to construct a JBossMQ
> QueueConnectionFactory and load it into WebLogic's
> JNDI so I can drive a WebLogic MDB off a JBossMQ
> queue, how do I create it ? Perhaps I should simply
> encpasulate the retrieval of the factory from an
> instance of JBoss and then serialize into the
> applicable counterpart's JNDI......
> 
> Thanks for the response.
> 
> //Nicholas
> --- Lucas McGregor <[EMAIL PROTECTED]> wrote:
> > I am not sure that this is what you are asking,
> but
> > the JMS connection
> > factory is application specific. Meaning that each
> > app server will construct
> > it's JMS connections and infrastructure
> differently.
> > 
> > 
> > In Jboss, you configure the connection factories
> in
> > the jboss.jcml and Jboss
> > creates them.
> > 
> > ---- start jboss.jcml snippet ----
> > 
> > 
> >   <!-- InvocationLayers are the different
> transport
> > methods that can be used
> > to access the server -->
> >   <mbean
> > code="org.jboss.mq.il.jvm.JVMServerILService"
> > name="JBossMQ:service=InvocationLayer,type=JVM">
> >     <attribute
> >
>
name="ConnectionFactoryJNDIRef">java:/ConnectionFactory</attribute>
> >     <attribute
> >
>
name="XAConnectionFactoryJNDIRef">java:/XAConnectionFactory</attribute>
> >   </mbean>
> > 
> >   <mbean
> > code="org.jboss.mq.il.rmi.RMIServerILService"
> > name="JBossMQ:service=InvocationLayer,type=RMI">
> >     <attribute
> >
>
name="ConnectionFactoryJNDIRef">RMIConnectionFactory</attribute>
> >     <attribute
> >
>
name="XAConnectionFactoryJNDIRef">RMIXAConnectionFactory</attribute>
> >   </mbean>
> > 
> >   <mbean
> > code="org.jboss.mq.il.oil.OILServerILService"
> > name="JBossMQ:service=InvocationLayer,type=OIL">
> >     <attribute
> >
>
name="ConnectionFactoryJNDIRef">ConnectionFactory</attribute>
> >     <attribute
> >
>
name="XAConnectionFactoryJNDIRef">XAConnectionFactory</attribute>
> >   </mbean>
> > 
> >   <mbean
> > code="org.jboss.mq.il.uil.UILServerILService"
> > name="JBossMQ:service=InvocationLayer,type=UIL">
> >     <attribute
> >
>
name="ConnectionFactoryJNDIRef">UILConnectionFactory</attribute>
> >     <attribute
> >
>
name="XAConnectionFactoryJNDIRef">UILXAConnectionFactory</attribute>
> >   </mbean>
> > 
> > ---- end jboss.jcml snippet ------
> > 
> >     This will create four different connection
> > factories: one that is
> > for only internal JVM access, one for RMI access,
> > one for Jboss' OIL
> > protocol, and one for Jboss' UIL protocol. All of
> > these impelement the
> > javax.jms.Connectionfactor interface. They will
> give
> > you access to the Jboss
> > specific connection which implements
> > javax.jms.Connection and will know how
> > to access the Jboss specific ConnectionFactories.
> 
=== message truncated ===


=====
Nicholas Whitehead
Home: (973) 377 9335
Cell: (201) 615 2716
Work(@ JP Morgan): (212) 235 5783
[EMAIL PROTECTED]

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to