All,
This is in relation to the implementation of a change [1] I requested
in the latest draft of the W3C's SOAP-JMS spec. However I still think
the fixed, and now working, example JMS code [2] is flawed, or at
best misleading. Would anyone with strong JMS-coding-style opinions
care to comment? I don't want to badger the SOAP-JMS committee
unnecessarily ;)
Basically, I think that the javax.jms.MessageProducer QoS setter
methods [3] should only ever be used to change defaults, and to set
QoS on a per-message basis the four-argument send method [4] should
*always* be used instead. Also note that their example code will now
permanently alter the producer's QoS settings for all subsequent
messages. As it is, the code at least works, but I think it is bad
style, and should not be present in a W3C standards-track document.
Also, does anyone know if Qpid can be used as part of a SOAP-JMS
system easily and/or effectively? I know CXF has an implementation
[5] in version 2.3 and it would be interesting to see how we perform
as a provider, particularly in terms of interoperability. What about
SOAP over AMQP directly? I guess the problem with that is the lack of
a formal AMQP API for Java, but I see no reason why one could not
perform asynchronous RPC directly using AMQP. There is apparently a
Python implementation [6] called QAM.
Also, I found an InfoQ article [7] that describes RPC over AMQP like
this:
An exemplary RPC in AMQP looks like this: the RPC client declares a
reply queue with a unique name (e.g. an UUID) and the properties
auto-deleted and exclusive. Then it sends some request to some
exchange and includes the name of the previously declared reply
queue in the reply-to property of the message. The RPC server would
answer to these requests by sending message to the default
exchange, using the value in the reply-to field as routing key
(relying on the above mentioned default bindings between the
default exchange and all queues). Note that this is just a
convention. Depending on the contract with the RPC server it could
interpret any property (or even the body) of the message to
determine where to reply.
Additionally, there is the related (draft) proposal for a JMS URI
specification [8] which I think we should implement in 0.10 or 0.12
or something soon, to go along with the BURL and ADDR syntaxes. Is
this the sort of thing I should write up a QIP for, or just raise a
JIRA?
Apologies for the long message ;)
[1] http://www.w3.org/2002/ws/soapjms/tracker/issues/68
[2] http://dev.w3.org/cvsweb/~checkout~/2008/ws/soapjms/
soapjms-2010-10-CR.html?rev=1.10#binding-header-props-xmp
[3] #setPriority(int), #setDeliveryMode(int), #setTimeToLive(long)
[4] #send(Message, int, int, long)
[5] http://cxf.apache.org/docs/soap-over-jms-10-support.html
[6] http://packages.python.org/qam/introduction.html
[7] http://www.infoq.com/articles/AMQP-RabbitMQ
[8] https://datatracker.ietf.org/doc/draft-merrick-jms-uri/
Cheers,
Andrew.
--
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;
Begin forwarded message:
Resent-From: [email protected]
Andrew
You're welcome - thanks for raising the issue.
I was keen to keep both techniques for setting the properties
because I
felt that was more in the spirit of the original sample, but I
agree that
there are potential pitfalls in using the methods on the producer...
particularly if the producer is shared by many requesters.
To mitigate this I noted in the comments that the four parameter send
method can be used as an alternative which will not change the
producer's
default. I believe this should be sufficient to alert people to a
potential problem, but I'd be happy to change the example
(relegating the
producer.set* methods to comments) if there's a consensus that the
current
example will lead to bad practices.
Regards
Mark
On 14 Dec 2010, at 13:42, Mark Phillips wrote:
To complete ACTION-234 [1] I applied the proposed resolution for
ISSUE-68
[2] which was outlined in my email of 7th December.
The changes involved altering the code sample in Section 2.2.2.1
to replace
the jmsMessage.setJMSDeliveryMode() call with
producer.setDeliveryMode(),
and jmsMessage.setJMSPriority() with producer.setPriority().
