synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: XML/JMS
Date Mon, 16 Oct 2006 19:27:43 GMT
Paul,

The case for not modifying existing code to bridge/route jms messages will
have strong use cases.
And using synapse or a custom dispatcher in Axis2 to figure out the
"operation" based on the context is inded a good point.
I agree with you now, that we don't have to add a custom header identifying
the operation all the time.

Rajith

On 10/16/06, Paul Fremantle <pzfreo@gmail.com> wrote:
>
> 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