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 18:37:35 GMT
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

---------------------------------------------------------------------
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