Re: [xmlblaster-devel] Announce: JMS

[Michele Laghi <laghi at swissinfo.org>]

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 ;)

> 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. 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 ;))

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

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 ?

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