synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <pzf...@gmail.com>
Subject Re: XML/JMS
Date Mon, 16 Oct 2006 19:18:45 GMT
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 <pzfreo@gmail.com> 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 <rajith77@gmail.com> 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 <pzfreo@gmail.com> 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 <asankha@wso2.com> 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:
> > axis-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "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
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org


Mime
View raw message