Re: [xmlblaster-devel] Announce: JMS

[Michele Laghi <laghi at swissinfo.org>]

Hi,

Peter Antman wrote:
> On Fri, 2003-09-26 at 18:19, Michele Laghi wrote:
>
> > Hi,
> >
> > Peter Antman wrote:
> >
> > > Hi,
> > > I had a first look at it, seems that its some more coding to do ;-)
> >
> > Of course, but I hope it was at least sufficient to start a discussion ;)
>
>
> Oh, yeas. I find it fantastic that someone evetually took the time to
> make a first impl.
>
> > > Some comments and questions though.
> > >
> > > 1. It seems as if its not written agains JMS 1.1. That would be nicer,
> > > since JMS 1.1 contains a unified API:
> > >
> > > ConnectionFactory f = ctx.lookup("TopicFactory");
> > > Destination d = ctx.lookup("my/topic")
> > > Connection c = f.createConnection();
> > > Session s = c.createSession(false,Session.AUTO_ACKNOWLEDGE);
> > > MessageProducer p = s.createProducer(d);
> > > Message m = s.createTextMessage("MyMessage");
> > > p.send(m, 
> > > 	DeliveryMode.NON_PERSISTENT,
> > > 	HIGH_PRIO,
> > > 	TTL);
> >
> > The idea isto implement the 1.1 api, the simple example
> > though is based on the 1.0.2, so the first interfaces implemented are 
> > the ones used in the example.
>
>
> Actually, I don't think GlobalUtil will be of any direct help here. Why?
> Since it is not a way to get a Global from the server to the client when
> the client is not in the same VM.
>
> Here are some alternatives:
> 1. Include a true JNDI implementation with remote semantics (from
> JBoss).
> 2. Only make JNDI available if XmlBlaster is run in a server environment
> where JNDI is available.
> 3. Only make JNDI available if client is running in VM with the server,
> through org.xmlBlaster.test.j2ee.MemContext.
> 4. Write our own JNDI implementation.
>
>
> Basically all these alternatives requires the possibility to create
> serializable Factories and Topics which contains enough information to
> connect to the XmlBlaster server in question, i.e without requiring the
> loading of a local Global instance...
OK, I would prefere alternative 1 and for the global we must make it 
serializable.

> > Regarding the lookup it is still an open 
> > issue but I believe your GlobalUtil solves the most of the problems and 
> > the rest are probably just details.
> >
> >
> > > 2. It would be swell if the different QoS could also be defined in the
> > > looked up components. I have always (and still have) found it hard to
> > > really get a good view of all the configurable properties in the QoS,
> > > but basically I would say this: stuff that is connected to the
> > > destination (queue setting, exact/xpath, mm) should be configured in the
> > > Destination (XBTopic), everything else, that is not part of the JMS API,
> > > should be configurable in Factory.
> >
> > About the XPath I was thinking of having virtual topics which in effect 
> > consist of an XPATH query (either as the topic name or via some 
> > xmlBlaster specific setters/getters). The big question here is how these 
> >  topics would be administrated. To make is feasible there should be a 
> > mechanism to create topics on the fly if none with the used name is 
> > found. The other option would be to only allow a certain amount of xpath 
> > queries. For the first option I currently only can imagine to acheave 
> > this with an own InitialContext. I think however that we should tackle 
> > this problem in a second phase since this in not even specified/required 
> > by the jms specification (that's a nice plus for xmlBlaster users ;))
>
>
> Hm, sounds a little bit complicated to me. XmlBlaster today allows
> arbitrary "topic", the only different with a JMS "Topic" is that it is
> an administered object, i.e its properties may be defines at serverside
> by an administrator and looked up by name by clients.
Yes I agree it was a little contorted but Session.createTopic(String) 
gives us the possibility to create such objects on the fly and thereby 
keeping the possibility to have 'arbitrary' topics for the queries.

> Here's some stub code:
>
> At server side:
> SubscribeKey sq = new SubscribeKey(glob,"myTopic");
> Topic t = new XBTopic(glob, sq);
> JNDIUtils.bind(ctx,t,"topic/myTestTopic");
>
> At client side
> Destination d = ctx.lookup("topic/myTestTopic");
> MessageConsumer c = s.createConsumer(d, "myId=1");
>
> This would translate in the a call like this:
>  SubscribeQos sq = new SubscribeQos(d);
>  sq.addAccessFilter(new AccessFilterQos(glob, "JMXFilter", "1.0",
> "myId=1"));
>  SubscribeKey sk = ((XBTopic)d).getSubscribeKey();
>  connection.subscribe(sk, sq);
Ok, but I think we need another approach for the creation of the topic. 
The SubscribeKey can not be used since it would make that topic unusable 
for publishes. Either we pass to the constructor even a PublishKey or we 
let the send/subscribe methods add these keys.
> > About the Qos I am not sure I understood you right: would you have ready 
> > qos objects registered in the naming service which one can lookup with 
> > given names ? 
>
>
> Something like that. What a mean is that apart from the setters/getters
> thats available in the JMS API, all other configurations that has to to
> with such things as: how do I connect to the server, how long will my
> session live, how many sessions are I allowed to create, which
> queue/cache plugins should be used, how is my Topic/Queue defines and so
> forth, should be contained in the two "administered" objects that are
> looked up through JNDI: i.e the ConnectionFactory and the Destinations.
It is clear to me how to handle that in Destination but I don't know how 
to handle that in a portable way in the ConnectionFactory. My idea was 
to put the names of these properties in ConnectionMetaData and then set 
these vendor specific properties in the Destination objects

> Of course: when run in an non managed/non JNDI environment it would be
> perfectly fine to allow the client to programmatically create the
> factory and destination, and let the be configured through the normal
> Global based mechanism in XmlBlaster.
>
>
> > Some of the features in the qos map 1:1 to JMS so there 
> > are already setters/getters specified, for the other more xmlBlaster 
> > specific there is always the generic way of setting these properties
> >
> >
> > > 3. The factory today takes an Global. As far as I know this will not
> > > work in a standard app-server scenarion where you would want to bind the
> > > factory into JNDI, which means it must be Serializable, or the some of
> > > the Reference tricks.
> >
> > Yes, as said before your GlobalUtil should make the trick.
> >
> >
> > > 4. How are you planing to implement the Queue destination? If I have
> > > understood XMlBlaster correct, there are no support for that type of
> > > stack based destinations.
> >
> > That's an old issue and it has been discussed in the past on different 
> > occasions. Personally I would see this as a specific implementation of 
> > the DispatcherPlugin where all messages are for only one client: wrapped 
> > in a Queue object. Jms clients would send a message to that Queue. Every 
> > session of that xmlBlaster client would be a "QueueConsumer" (in jms 
> > terminology) and the dispatcher plugin would give the message to the 
> > first consumer available. This way the classical MQ-Series "first to the 
> > base" behaviour would be simulated. By implementing it as a plugin we 
> > could easily switch to other approaches, for example a more complex load 
> > balancer where the plugin could keep track of earlier processing times 
> > for the different consumers and distribute the messages in a more 
> > "intelligent" way.
>
>
> Sound ok.
>
> > Another important open question is the implementation of the 
> > QueueIterator on which I did'nt spend any attention yet.
> >
> >  Any ideas on how the selectors will work, or will will that be a non
> >
> > > standard part, where selectors is substituted with XPath expressions?
> >
> > I believe the best place to do the filtering is in the AccessPlugin. The 
> > syntax to be used I would prefere the standard way and exclude Xpath. We 
> > use xpath to filter the topics (is "transtopically" a good word ?). For 
> > selections in the same topic (is "panatopically" a good word ?) it would 
> > be best to keep is as jms-standard as possible.
> > Did you have any thoughts about this ?
>
>
> I know there are no standards, but I think it would also be swell to be
> able to specify XPath expressions (both against headers and body) from
> the JMS API. How this should be done I don't know. I do know that having
> to use provider specific code (as one has to do when working with Sonic
> for example) is generally bad. To mee, the best thing is to make it a
> serverside/destination/session based configuration and that its possible
> to specify an XPath as the selector if the managed objects allows it.
>
> //Peter
>
> > Saluti
> > Michele
> >
> >
> >
> >
> > > //Peter
> > >
> > >
> > > On Thu, 2003-09-25 at 20:51, Michele Laghi wrote:
> > >
> > >
> > > > Hi everybody,
> > > > a first step has been made to make xmlBlaster among other things a *JMS 
> > > > Provider*. The initial code is on org.xmlBlaster.j2ee.jms. The code is 
> > > > far from functional yet, but there is already a very simple working demo 
> > > > with a topic publishing and subscribing on 
> > > > demo/javaclients/j2ee/jms/SimpleJmsDemo.java.
> > > >
> > > > Many of you have already done quite a lot of work with xmlBlaster in 
> > > > conjunction with jms, so as always:
> > > > comments, ideas, suggestions and *code* are all welcome !
> > > >
> > > > Michele
> >
> > --
> > Michele Laghi
> > mailto:laghi at swissinfo.org
> > tel. +46 8 7492952 / mob. +46 70 4103964
> > http://eclettic.tripod.com
> > http://www.xmlBlaster.org


Michele