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 too. Paul On 10/16/06, Asankha C. Perera <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
