Paul
Especially for the case of non-XML JMS messages, we should decide how to
find the operation for dispatching. i.e. In an existing JMS environment
you may not be able to request for a new JMS header (like SOAPAction) to
be sent along with a message. However we could find the service, as we
know the JMS destination on which the message was received. One possible
solution is to allow the specification of a default as a parameter of
the service
asankha
Paul Fremantle wrote:
I'd like to bring up the issue of XML/JMS. I've been looking for a
simple demo shows off Synapse and WSRM together (since these are two
of my key interests (-: )
And I figured it would make a really nice demo to take XML/JMS
messages and then add a SOAP body, and send them out using WSRM.
I guess to do this we need the "REST" equivalent in the JMS transport.
(I guess in the JMS case we better not talk about REST or we'll be in
serious trouble)
Let's call it POX then.
In fact we could do more than just XML. Imagine a TEXT message comes
in that isn't even XML, we could wrap it in a CDATA wrapper and pop it
into a single element in the message.
If an binary message came in we could pop it into an MTOM holder, same
with an ObjectMessage.
With a MapMessage we could do a simple wrapper into a name-value pairs.
Of course none of this would be a "standard" so we'd have to document
it clearly, but it would be pretty neat way of dealing with non-SOAP
messages coming over JMS.
In fact, if we followed the same rules on outbound, then you could
bridge between two organizations with no coding:
Org1 JMS queue -> Synapse -> SOAP(XML, MTOM, Text, etc)/WSRM ->
Synapse -> Org2 JMS queue.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
