synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <>
Subject Re: XML/JMS
Date Mon, 16 Oct 2006 15:07:09 GMT
So in general the question is how to "dispatch" a JMS message.

For the service we can assume that the queue or topic identifies the
right service. i.e. initially we can assume that every message coming
to queue X is destined for service Y.

For XML messages, the Body based dispatcher can identify the operation
based on the name or qname of the first tag in the body.

But I agree there is a problem with the non-XML message. So as you
suggest, a parameter such as "jms.transport.FixedOperationName" could
be set with a single operation name, e.g. "submit" and then that
operation would be used.

Alternatively, the user could specify a handler that somehow sets the
operation, but this seems a little less nice.

For non-XML content, there is a similar issue: what element do I put
the content in? In general, I would like my binary content to be
placed inside a "holder" element that is inside the body. So I guess
another parameter to set the default holder element qname is important


On 10/16/06, Asankha C. Perera <> wrote:
> 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:
> For additional commands, e-mail:

Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

"Oxygenating the Web Service Platform",

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message