-
1. Re: jpdl syntax for jms activity
tom.baeyens Dec 10, 2009 3:49 AM (in response to tom.baeyens)i think connectionFactory should be connection-factory. we always use dashes instead of camelcase in jpdl.
for attribute 'destination', are you sure that you can code for queue's and topics in the same way? if not, you might need different attributes for that. for example replace attribute destination="MyDestination" with queue="myQueue" or topic="MyTopic". to me using attributes queue and topic reads more naturally. what do you think ? -
2. Re: jpdl syntax for jms activity
tom.baeyens Dec 10, 2009 3:54 AM (in response to tom.baeyens)i would prefer to use tag names to indicate the message type. e.g. use element text for text messages and element map for map messages
<jms name="send message" connectionFactory="ConnectionFactory" queue="queue/MyQueue"> <text> This is the body </text> <transition to="wait" /> </jms>
<jms name="send message" connectionFactory="ConnectionFactory" queue="queue/MyQueue"> <map> <entry> <key><string value="one" /></key> <value><int value="3" /></value> </entry> </map> <transition to="wait" /> </jms>
Note that with this map, I used the syntax that is already in jpdl for maps. So you can leverage the map parsing and it will be more consistent.<jms name="send message" connectionFactory="ConnectionFactory" queue="queue/MyQueue"> <object expr="#{someObjectExpression}" /> <transition to="wait" /> </jms>
-
3. Re: jpdl syntax for jms activity
tom.baeyens Dec 10, 2009 4:09 AM (in response to tom.baeyens)we should also consider the properties. e.g.
<jms name="send message" connectionFactory="ConnectionFactory" queue="queue/MyQueue"> <text> This is the body </text> <property name="aString"><string value="txt" /></property> <property name="aBoolean"><false /></property> <property name="aShort"><short value="8" /></property> <property name="aByte"><byte value="8" /></property> <property name="anInt"><int value="4" /></property> <property name="aLong"><long value="8888888888" /></property> ... and so on for all basic types... <property name="someExpression" expr="#{person.address.number}" /> <transition to="wait" /> </jms>
for the expression, (and probably for the other basic types too) you can use the setObjectProperty method. it only accepts the basic types that are supported. but we can leave it to that jms message to throw an exception if a non-supported type is supplied via the expression. -
4. Re: jpdl syntax for jms activity
koen.aers Dec 10, 2009 8:50 AM (in response to tom.baeyens)OK about the connection-factory, I should have thought about it in the first place.
I am certainly not married to the destination attribute. It actually would make things easier to implement as well if it was split in queue and topic.
I also agree on your refactoring of the message element into meaningful tags.
So pretty much agreed about everything ;-)
Cheers,
Koen -
5. Re: jpdl syntax for jms activity
kukeltje Dec 10, 2009 2:21 PM (in response to tom.baeyens)Me to, but a 'destination' with a 'type="queue/topic" attribute would have been ok to. But do whatever is easiest.
-
6. Re: jpdl syntax for jms activity
aguizar Dec 16, 2009 7:20 AM (in response to tom.baeyens)The big change between JMS 1.0 and 1.1 was the unification of messaging domains, the ability to treat a queue the same way as a destination and more importantly, to switch between them easily should operating requirements change. Since there is no implementation constraint to distinguish between topics and queues, I believe we should not do so in jPDL. -
7. Re: jpdl syntax for jms activity
aguizar Dec 16, 2009 7:42 AM (in response to tom.baeyens)One more thing: if you want to make a distinction between queues and topics, you have to code the activity twice: once with the PTP domain interfaces, and again with the Pub/Sub domain interfaces!
QueueConnectionFactory qcf = context.lookup(); Queue q = context.lookup(); QueueConnection qc = qcf.createQueueConnection(); QueueSession qs = qs.createQueueSession(); QueueSender sender = qs.createSender(q);
TopicConnectionFactory tcf = context.lookup(); Topic t = context.lookup(); TopicConnection tc = tcf.createTopicConnection(); TopicSession ts = ts.createTopicSession(); TopicPublisher pub = ts.createPublisher(t);
The common interfaces make it all cleaner:
ConnectionFactory cf = context.lookup(); Destination d = context.lookup(); Connection c = cf.createConnection(); Session s = s.createSession(); MessageProducer mp = s.createProducer(d);
Of course, you can cheat and pass either a Queue or a Topic to Session.createProducer(). Doing so validates the point of using plain Destinations in the first place.