You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Paul Fremantle <pz...@gmail.com> on 2006/10/16 13:18:00 UTC
XML/JMS
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
--
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
Re: XML/JMS
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul,
Sure, I will start the work soon.
Narada comes with the following open source licence from Indiana
University.
Thanks,
-Jaliya
===================================================
Software License, Version 1.0
Copyright 2003 The Trustees of Indiana University. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1) All redistributions of source code must retain the above copyright
notice, the list of authors in the original source code, this list of
conditions and the disclaimer listed in this license;
2) All redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the disclaimer listed in this license in
the documentation and/or other materials provided with the distribution;
3) Any documentation included with all redistributions must include the
following acknowledgement:
"This product includes software developed by the Community Grids Lab. For
further information contact the Community Grid Labs at
http://communitygrids.iu.edu/."
Alternatively, this acknowledgement may appear in the software itself, and
wherever such third-party acknowledgments normally appear.
4) The name Indiana University or Community Grid Labs or NaradaBrokering,
shall not be used to endorse or promote products derived from this software
without prior written permission from Indiana University. For written
permission, please contact the Advanced Research and Technology Institute
("ARTI") at 351 West 10th Street,
Indianapolis, Indiana 46202.
5) Products derived from this software may not be called NaradaBrokering,
nor may Indiana University or Community Grid Labs or NaradaBrokering appear
in their name, without prior written permission of ARTI.
Indiana University provides no reassurances that the source code provided
does not infringe the patent or any other intellectual property rights of
any other entity. Indiana University disclaims any liability to any
recipient for claims brought by any other entity based on infringement of
intellectual property rights or otherwise.
LICENSEE UNDERSTANDS THAT SOFTWARE IS PROVIDED "AS IS" FOR WHICH NO
WARRANTIES AS TO CAPABILITIES OR ACCURACY ARE MADE. INDIANA UNIVERSITY GIVES
NO WARRANTIES AND MAKES NO REPRESENTATION THAT SOFTWARE IS FREE OF
INFRINGEMENT OF THIRD PARTY PATENT, COPYRIGHT, OR OTHER PROPRIETARY RIGHTS.
INDIANA UNIVERSITY MAKES NO WARRANTIES THAT SOFTWARE IS FREE FROM "BUGS",
"VIRUSES", "TROJAN HORSES", "TRAP DOORS", "WORMS", OR OTHER HARMFUL CODE.
LICENSEE ASSUMES THE ENTIRE RISK AS TO THE PERFORMANCE OF SOFTWARE AND/OR
ASSOCIATED MATERIALS, AND TO THE PERFORMANCE AND VALIDITY OF INFORMATION
GENERATED USING SOFTWARE.
===================================================
----- Original Message -----
From: "Paul Fremantle" <pz...@gmail.com>
To: <sy...@ws.apache.org>; "Jaliya Ekanayake" <ja...@apache.org>
Cc: "Paul Fremantle" <pa...@wso2.com>; <ax...@ws.apache.org>
Sent: Tuesday, October 17, 2006 6:47 PM
Subject: Re: XML/JMS
> Jaliya
>
> Yes that would be great. I'd be really interested in any performance
> numbers you can give us. I think Synapse is actually a nice solution
> for this - pretty simple to configure and quite small. You might even
> want to bundle it into your bridge solution.
>
> By the way, remind me what license Narada is under?
>
> Paul
>
>
> On 10/17/06, Jaliya Ekanayake <jn...@gmail.com> wrote:
>> Hi Paul and Others,
>>
>> We have a message broker that supports JMS (Naradabrokering
>> http://www.naradabrokering.org/) which we can use to test the scenario
>> you
>> have mentioned.
>> Few months back I wrote a bridge between Naradabrokering and MQSeries. We
>> had this idea of extending the same concept to XML/SOAP messages as well
>> so
>> we are looking forward to the test that you have mentioned.
>>
>> So we will perform the test and try to get some performance results as
>> well.
>>
>> Let us know your ideas.
>>
>> Thanks,
>> -Jaliya
>>
>> ----- Original Message -----
>> From: "Paul Fremantle" <pz...@gmail.com>
>> To: <sy...@ws.apache.org>; <ax...@ws.apache.org>
>> Sent: Monday, October 16, 2006 7:18 AM
>> Subject: XML/JMS
>>
>>
>> > 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
>> >
>> >
>> >
>> >
>> > --
>> > 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: axis-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: axis-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: XML/JMS
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul,
Sure, I will start the work soon.
Narada comes with the following open source licence from Indiana
University.
Thanks,
-Jaliya
===================================================
Software License, Version 1.0
Copyright 2003 The Trustees of Indiana University. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1) All redistributions of source code must retain the above copyright
notice, the list of authors in the original source code, this list of
conditions and the disclaimer listed in this license;
2) All redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the disclaimer listed in this license in
the documentation and/or other materials provided with the distribution;
3) Any documentation included with all redistributions must include the
following acknowledgement:
"This product includes software developed by the Community Grids Lab. For
further information contact the Community Grid Labs at
http://communitygrids.iu.edu/."
Alternatively, this acknowledgement may appear in the software itself, and
wherever such third-party acknowledgments normally appear.
4) The name Indiana University or Community Grid Labs or NaradaBrokering,
shall not be used to endorse or promote products derived from this software
without prior written permission from Indiana University. For written
permission, please contact the Advanced Research and Technology Institute
("ARTI") at 351 West 10th Street,
Indianapolis, Indiana 46202.
5) Products derived from this software may not be called NaradaBrokering,
nor may Indiana University or Community Grid Labs or NaradaBrokering appear
in their name, without prior written permission of ARTI.
Indiana University provides no reassurances that the source code provided
does not infringe the patent or any other intellectual property rights of
any other entity. Indiana University disclaims any liability to any
recipient for claims brought by any other entity based on infringement of
intellectual property rights or otherwise.
LICENSEE UNDERSTANDS THAT SOFTWARE IS PROVIDED "AS IS" FOR WHICH NO
WARRANTIES AS TO CAPABILITIES OR ACCURACY ARE MADE. INDIANA UNIVERSITY GIVES
NO WARRANTIES AND MAKES NO REPRESENTATION THAT SOFTWARE IS FREE OF
INFRINGEMENT OF THIRD PARTY PATENT, COPYRIGHT, OR OTHER PROPRIETARY RIGHTS.
INDIANA UNIVERSITY MAKES NO WARRANTIES THAT SOFTWARE IS FREE FROM "BUGS",
"VIRUSES", "TROJAN HORSES", "TRAP DOORS", "WORMS", OR OTHER HARMFUL CODE.
LICENSEE ASSUMES THE ENTIRE RISK AS TO THE PERFORMANCE OF SOFTWARE AND/OR
ASSOCIATED MATERIALS, AND TO THE PERFORMANCE AND VALIDITY OF INFORMATION
GENERATED USING SOFTWARE.
===================================================
----- Original Message -----
From: "Paul Fremantle" <pz...@gmail.com>
To: <sy...@ws.apache.org>; "Jaliya Ekanayake" <ja...@apache.org>
Cc: "Paul Fremantle" <pa...@wso2.com>; <ax...@ws.apache.org>
Sent: Tuesday, October 17, 2006 6:47 PM
Subject: Re: XML/JMS
> Jaliya
>
> Yes that would be great. I'd be really interested in any performance
> numbers you can give us. I think Synapse is actually a nice solution
> for this - pretty simple to configure and quite small. You might even
> want to bundle it into your bridge solution.
>
> By the way, remind me what license Narada is under?
>
> Paul
>
>
> On 10/17/06, Jaliya Ekanayake <jn...@gmail.com> wrote:
>> Hi Paul and Others,
>>
>> We have a message broker that supports JMS (Naradabrokering
>> http://www.naradabrokering.org/) which we can use to test the scenario
>> you
>> have mentioned.
>> Few months back I wrote a bridge between Naradabrokering and MQSeries. We
>> had this idea of extending the same concept to XML/SOAP messages as well
>> so
>> we are looking forward to the test that you have mentioned.
>>
>> So we will perform the test and try to get some performance results as
>> well.
>>
>> Let us know your ideas.
>>
>> Thanks,
>> -Jaliya
>>
>> ----- Original Message -----
>> From: "Paul Fremantle" <pz...@gmail.com>
>> To: <sy...@ws.apache.org>; <ax...@ws.apache.org>
>> Sent: Monday, October 16, 2006 7:18 AM
>> Subject: XML/JMS
>>
>>
>> > 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
>> >
>> >
>> >
>> >
>> > --
>> > 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: axis-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: axis-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: XML/JMS
Posted by Paul Fremantle <pz...@gmail.com>.
Jaliya
Yes that would be great. I'd be really interested in any performance
numbers you can give us. I think Synapse is actually a nice solution
for this - pretty simple to configure and quite small. You might even
want to bundle it into your bridge solution.
By the way, remind me what license Narada is under?
Paul
On 10/17/06, Jaliya Ekanayake <jn...@gmail.com> wrote:
> Hi Paul and Others,
>
> We have a message broker that supports JMS (Naradabrokering
> http://www.naradabrokering.org/) which we can use to test the scenario you
> have mentioned.
> Few months back I wrote a bridge between Naradabrokering and MQSeries. We
> had this idea of extending the same concept to XML/SOAP messages as well so
> we are looking forward to the test that you have mentioned.
>
> So we will perform the test and try to get some performance results as well.
>
> Let us know your ideas.
>
> Thanks,
> -Jaliya
>
> ----- Original Message -----
> From: "Paul Fremantle" <pz...@gmail.com>
> To: <sy...@ws.apache.org>; <ax...@ws.apache.org>
> Sent: Monday, October 16, 2006 7:18 AM
> Subject: XML/JMS
>
>
> > 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
> >
> >
> >
> >
> > --
> > 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: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: XML/JMS
Posted by Paul Fremantle <pz...@gmail.com>.
Jaliya
Yes that would be great. I'd be really interested in any performance
numbers you can give us. I think Synapse is actually a nice solution
for this - pretty simple to configure and quite small. You might even
want to bundle it into your bridge solution.
By the way, remind me what license Narada is under?
Paul
On 10/17/06, Jaliya Ekanayake <jn...@gmail.com> wrote:
> Hi Paul and Others,
>
> We have a message broker that supports JMS (Naradabrokering
> http://www.naradabrokering.org/) which we can use to test the scenario you
> have mentioned.
> Few months back I wrote a bridge between Naradabrokering and MQSeries. We
> had this idea of extending the same concept to XML/SOAP messages as well so
> we are looking forward to the test that you have mentioned.
>
> So we will perform the test and try to get some performance results as well.
>
> Let us know your ideas.
>
> Thanks,
> -Jaliya
>
> ----- Original Message -----
> From: "Paul Fremantle" <pz...@gmail.com>
> To: <sy...@ws.apache.org>; <ax...@ws.apache.org>
> Sent: Monday, October 16, 2006 7:18 AM
> Subject: XML/JMS
>
>
> > 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
> >
> >
> >
> >
> > --
> > 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: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: XML/JMS
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul and Others,
We have a message broker that supports JMS (Naradabrokering
http://www.naradabrokering.org/) which we can use to test the scenario you
have mentioned.
Few months back I wrote a bridge between Naradabrokering and MQSeries. We
had this idea of extending the same concept to XML/SOAP messages as well so
we are looking forward to the test that you have mentioned.
So we will perform the test and try to get some performance results as well.
Let us know your ideas.
Thanks,
-Jaliya
----- Original Message -----
From: "Paul Fremantle" <pz...@gmail.com>
To: <sy...@ws.apache.org>; <ax...@ws.apache.org>
Sent: Monday, October 16, 2006 7:18 AM
Subject: XML/JMS
> 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
>
>
>
>
> --
> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: XML/JMS
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <pz...@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 <pz...@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 <ra...@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 <pz...@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 <as...@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
>
>
Re: XML/JMS
Posted by Paul Fremantle <pz...@gmail.com>.
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 <pz...@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 <ra...@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 <pz...@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 <as...@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
Re: XML/JMS
Posted by Paul Fremantle <pz...@gmail.com>.
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 <ra...@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 <pz...@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 <as...@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
Re: XML/JMS
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <pz...@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 <as...@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
>
>
Re: XML/JMS
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <pz...@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 <as...@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
>
>
Re: XML/JMS
Posted by "Asankha C. Perera" <as...@wso2.com>.
Paul
I have updated the JMS transport to support POX, Text and Binary JMS
messages without requiring any additional headers. A service could
optionally provide the QName for the operation to invoke on such
messages where the operation cannot be determined (i.e. pure text/binary
messages with non-xml content), and this could be then specified with a
parameter named "transport.jms.Operation"; this will default to
urn:mediate. A service could optionally provide a QName for an element
that will act as the holder of such content, and this could be specified
with a parameter named "transport.jms.Wrapper" and will default to
"jmsMessage" in the axis2 namespace.
Hence a simple JMS text message with the content "hello world" would be
transformed into the form
<?xml version='1.0' encoding='utf-8'?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header/><soapenv:Body><axis2ns1:jmsMessage
xmlns:axis2ns1="axis2"><![CDATA[hello
world]]></axis2ns1:jmsMessage></soapenv:Body></soapenv:Envelope>
and a simple JMS binary message containing a byte array will be as shown
below
asankha
POST /axis2/services/SimpleStockQuoteService HTTP/1.1
SOAPAction: "urn:__DYNAMIC_OPERATION__"
User-Agent: Axis2
Host: testb.wso2.com:9000
Content-Length: 905
Content-Type: multipart/related;
boundary=MIMEBoundaryurn_uuid_2E8CC8B0B017204A1A11611743285462;
type="application/xop+xml";
start="<0....@apache.org>";
start-info="text/xml";
charset=UTF-8--MIMEBoundaryurn_uuid_2E8CC8B0B017204A1A11611743285462content-type:application/xop+xml;
charset=UTF-8; type="text/xml";content-transfer-encoding:binarycontent-id:
<0....@apache.org>
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header />
<soapenv:Body>
<axis2ns1:jmsMessage
xmlns:axis2ns1="http://ws.apache.org/namespaces/axis2">
<xop:Include
href="cid:1.urn:uuid:2E8CC8B0B017204A1A11611743285461@apache.org"
xmlns:xop="http://www.w3.org/2004/08/xop/include" />
</axis2ns1:jmsMessage>
</soapenv:Body>
</soapenv:Envelope>--MIMEBoundaryurn_uuid_2E8CC8B0B017204A1A11611743285462content-id:
<1....@apache.org>content-type:application/octet-streamcontent-transfer-encoding:binary[[actual
bytes here]]--MIMEBoundaryurn_uuid_2E8CC8B0B017204A1A11611743285462--
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: XML/JMS
Posted by "Asankha C. Perera" <as...@wso2.com>.
Paul
I have updated the JMS transport to support POX, Text and Binary JMS
messages without requiring any additional headers. A service could
optionally provide the QName for the operation to invoke on such
messages where the operation cannot be determined (i.e. pure text/binary
messages with non-xml content), and this could be then specified with a
parameter named "transport.jms.Operation"; this will default to
urn:mediate. A service could optionally provide a QName for an element
that will act as the holder of such content, and this could be specified
with a parameter named "transport.jms.Wrapper" and will default to
"jmsMessage" in the axis2 namespace.
Hence a simple JMS text message with the content "hello world" would be
transformed into the form
<?xml version='1.0' encoding='utf-8'?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header/><soapenv:Body><axis2ns1:jmsMessage
xmlns:axis2ns1="axis2"><![CDATA[hello
world]]></axis2ns1:jmsMessage></soapenv:Body></soapenv:Envelope>
and a simple JMS binary message containing a byte array will be as shown
below
asankha
POST /axis2/services/SimpleStockQuoteService HTTP/1.1
SOAPAction: "urn:__DYNAMIC_OPERATION__"
User-Agent: Axis2
Host: testb.wso2.com:9000
Content-Length: 905
Content-Type: multipart/related;
boundary=MIMEBoundaryurn_uuid_2E8CC8B0B017204A1A11611743285462;
type="application/xop+xml";
start="<0....@apache.org>";
start-info="text/xml";
charset=UTF-8--MIMEBoundaryurn_uuid_2E8CC8B0B017204A1A11611743285462content-type:application/xop+xml;
charset=UTF-8; type="text/xml";content-transfer-encoding:binarycontent-id:
<0....@apache.org>
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header />
<soapenv:Body>
<axis2ns1:jmsMessage
xmlns:axis2ns1="http://ws.apache.org/namespaces/axis2">
<xop:Include
href="cid:1.urn:uuid:2E8CC8B0B017204A1A11611743285461@apache.org"
xmlns:xop="http://www.w3.org/2004/08/xop/include" />
</axis2ns1:jmsMessage>
</soapenv:Body>
</soapenv:Envelope>--MIMEBoundaryurn_uuid_2E8CC8B0B017204A1A11611743285462content-id:
<1....@apache.org>content-type:application/octet-streamcontent-transfer-encoding:binary[[actual
bytes here]]--MIMEBoundaryurn_uuid_2E8CC8B0B017204A1A11611743285462--
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: XML/JMS
Posted by Paul Fremantle <pz...@gmail.com>.
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 <as...@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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: XML/JMS
Posted by Paul Fremantle <pz...@gmail.com>.
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 <as...@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
Re: XML/JMS
Posted by "Asankha C. Perera" <as...@wso2.com>.
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: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: XML/JMS
Posted by "Asankha C. Perera" <as...@wso2.com>.
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
Re: XML/JMS
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul and Others,
We have a message broker that supports JMS (Naradabrokering
http://www.naradabrokering.org/) which we can use to test the scenario you
have mentioned.
Few months back I wrote a bridge between Naradabrokering and MQSeries. We
had this idea of extending the same concept to XML/SOAP messages as well so
we are looking forward to the test that you have mentioned.
So we will perform the test and try to get some performance results as well.
Let us know your ideas.
Thanks,
-Jaliya
----- Original Message -----
From: "Paul Fremantle" <pz...@gmail.com>
To: <sy...@ws.apache.org>; <ax...@ws.apache.org>
Sent: Monday, October 16, 2006 7:18 AM
Subject: XML/JMS
> 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
>
>
>
>
> --
> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org