Hey Rajith I'm not sure it covers the usecase where the XML/JMS message is already defined (perhaps something being published to a topic, and Synapse is a new subscriber).
In that model, I think we can just hard code which op to use in the services.xml. Paul On 10/16/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
Specifying the operation name in a header seems like a good solution that covers all the use cases Paul identified. I did the same with the JMS binding for Tuscany. Rajith On 10/16/06, Paul Fremantle <[EMAIL PROTECTED]> wrote: > > 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] > >
-- 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]
