Ok I dont think I was clear enough in this note. So imagine I have an existing XML/JMS pub/sub network, with lots of JMS clients, getting XML messages, no SOAP involved.
I could modify the publish code to add a new header, but I'd like Synapse to work without modifying any code at all. So instead of expecting a header, I just hardcode a single operation to which all messages get delivered. Its the simple fix. For more complicated scenarios, where I want more than one operation per topic or queue, in those cases I guess you have to write your own dispatcher, that looks into the message and figures out which operation. In Synapse we don't really need to know the operation so we could just do that sort of thing with a content-based routing mediator. Paul [20:07] ramila_rajith: ok [20:07] paulfremantle: no clue about SOAP [20:07] ramila_rajith: ok [20:08] paulfremantle: now we have someone wanting to get that message across the internet [20:08] ramila_rajith: ok [20:08] paulfremantle: so I don't want to have to change my existing pub code [20:08] paulfremantle: to add headers [20:08] ramila_rajith: yes [20:08] paulfremantle: instead I want to config synapse to handle the message [20:09] ramila_rajith: ok, but this will work only if there is a one to one mapping btw a topic and a operation [20:09] ramila_rajith: so we would need a topic or queue per operation [20:09] paulfremantle: yes [20:09] paulfremantle: but actually not true with Synapse [20:10] paulfremantle: because in Synapse you could do some further mediation [20:10] paulfremantle: to choose the right op based on the message On 10/16/06, Paul Fremantle <[EMAIL PROTECTED]> wrote:
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
-- 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]
