You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Andreas Veithen <an...@skynet.be> on 2008/06/13 13:45:00 UTC
JMS transport specs/documentation
Hi all,
I was wondering whether there is somewhere a specification or
documentation that gives a clear overview of what types of messages
Synapse's JMS transport is supposed to accept and how it should
process these messages. More precisely I'm looking for a document that
contains requirements such as "If the incoming message is a
BytesMessage and has a 'Content-Type' property, then the
transport ..." etc. Is there already something like that?
If not, are there people who are interested in helping to write this
kind of specification? Note that I believe that the current behavior
of the JMS transport is not always appropriate. E.g. a BytesMessage
with Content-Type 'text/plain; charset=...' produces a binary wrapper,
while I would expect a text wrapper. Therefore the specs to be written
would focus on the to-be situation rather than the as-is situation.
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JMS transport specs/documentation
Posted by Paul Fremantle <pz...@gmail.com>.
I'll happily help out. I think we should also encourage Glen and
Asankha to get involved. Nice idea!
Paul
On Fri, Jun 13, 2008 at 12:45 PM, Andreas Veithen
<an...@skynet.be> wrote:
> Hi all,
>
> I was wondering whether there is somewhere a specification or documentation
> that gives a clear overview of what types of messages Synapse's JMS
> transport is supposed to accept and how it should process these messages.
> More precisely I'm looking for a document that contains requirements such as
> "If the incoming message is a BytesMessage and has a 'Content-Type'
> property, then the transport ..." etc. Is there already something like that?
>
> If not, are there people who are interested in helping to write this kind of
> specification? Note that I believe that the current behavior of the JMS
> transport is not always appropriate. E.g. a BytesMessage with Content-Type
> 'text/plain; charset=...' produces a binary wrapper, while I would expect a
> text wrapper. Therefore the specs to be written would focus on the to-be
> situation rather than the as-is situation.
>
> Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JMS transport specs/documentation
Posted by "Asankha C. Perera" <as...@wso2.com>.
Hi Ant
> How about also something like an SCA compatibility mode so Synapse
> could sit in front of Tuscany/SCA JMS services? It would mainly be
> just setting some header properties. I'm mostly a lurker on the
> Synapse list these days but i could help from the SCA specification
> and Tuscany interop side of things.
Good to hear from you! Sorry for my low knowledge on SCA.. but if what
you would like is for Synapse to front JMS services, you could do that
even right now.. If you could educate us a bit more on what you would
like from Synapse for better SCA support, we could help you..
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JMS transport specs/documentation
Posted by Paul Fremantle <pz...@gmail.com>.
That would be great! Thanks Ant.
Paul
On Fri, Jun 13, 2008 at 1:42 PM, ant elder <an...@gmail.com> wrote:
> On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera <as...@wso2.com> wrote:
>
>> Hi Andreas
>>
>> I was wondering whether there is somewhere a specification or documentation
>> that gives a clear overview of what types of messages Synapse's JMS
>> transport is supposed to accept and how it should process these messages.
>> More precisely I'm looking for a document that contains requirements such as
>> "If the incoming message is a BytesMessage and has a 'Content-Type'
>> property, then the transport ..." etc. Is there already something like that?
>>
>>
>> Sorry, there isn't much external documentation yet..except in my head :-)
>> .. however, I have been planning to update the JMS transport to handle JTA
>> transactions for sometime, and I also wanted to change the design to support
>> both JMS 1.0 and 1.1 in a better way. Some of the current issues we have
>> came about as we came across a user who wanted JMS 1.0 support, at which
>> point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1).
>>
>> We also have plans to adhere to the proposed binding for SOAP over JMS
>> specification<http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E>.
>> At the same time, we need to update our code to not use setMessageListener()
>> etc. which the newer JEE app servers (such as WebSphere) does not allow..
>>
>> If not, are there people who are interested in helping to write this kind
>> of specification? Note that I believe that the current behavior of the JMS
>> transport is not always appropriate. E.g. a BytesMessage with Content-Type
>> 'text/plain; charset=...' produces a binary wrapper, while I would expect a
>> text wrapper. Therefore the specs to be written would focus on the to-be
>> situation rather than the as-is situation.
>>
>> I would certainly be very interested to keep working on the JMS transport
>> and I believe that with your help and that of any others in the community,
>> we could really improve the current implementation to be much better
>>
>> asankha
>>
>
> How about also something like an SCA compatibility mode so Synapse could sit
> in front of Tuscany/SCA JMS services? It would mainly be just setting some
> header properties. I'm mostly a lurker on the Synapse list these days but i
> could help from the SCA specification and Tuscany interop side of things.
>
> ...ant
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: JMS transport specs/documentation
Posted by Andreas Veithen <an...@skynet.be>.
On 18 juin 08, at 13:31, Asankha C. Perera wrote:
> Andreas
>> Please review and provide feedback (in particular on my analysis of
>> the as-is situation and the proposed to-be situation).
> Your analysis is correct, I guess TransportSender will follow shortly
>> Some additional points where contribution is required:
>> * Explain the impact of supporting both JMS 1.0 and 1.1.
> Unfortunately we cannot depend on the Sun's JMS API jar's and thus
> we have a dependency on the Geronimo 1.1 API jar, which creates
> problems, as even if we break 1.0 compatibility, its not found until
> too late. I think a solution to this and a better design would be to
> move JMS 1.0 and 1.1 API specific code into separate classes, and
> make the transport depend on a common interface. Then at least when
> someone makes a fix on the 1.0 code, they can be extra careful.
Breaking 1.0 compatibility could also be detected during the unit
tests. To do this we need
* sufficient unit test coverage (required anyway...);
* a wrapper/proxy that intercepts all JMS calls during the unit tests
and throws an exception whenever a JMS 1.1 feature is used.
We should apply the same strategy to test for JEE compliance. I will
provide a solution for this.
>
>> * I think that a large part of the specifications for the JMS
>> transport should apply equally to the AMQP transport. In
>> SYNAPSE-303 I suggested to create some kind of abstract messaging
>> transport from which both transports would be derived. What is your
>> opinion on this?
> I think we should not do anything AMQP specific in the JMS
> transport, but rather allow the JMS transport to be configured with
> additional properties as required, to support AMQP, MQSeries,
> Tuscany etc. Someday there will be a good native AMQP transport, and
> right now the best 'interoperable' AMQP support there is, is via JMS
>> * Can anybody with knowledge about the proposed SOAP over JMS
>> specification comment on what we need to rework to support it?
> I think we should support the existing Synapse/Axis2 style
> addresses, as well as the new IRI scheme and this shouldn't be much
> of a problem. Maybe we can have a switch per service to state
> whether it prefers the new style or the legacy, and default to the
> new IRI etc. I haven't yet had time to read the links to the new
> SOAP/JMS spec, but I will try to do that before next week, but I
> think this is very much similar to the one posted to the Axis2 dev
> list some time ago.
>
I have one specific question related to the specs and Axis2. The specs
say that when sending out a JMS message, information is used from
[quote]
* The JMS IRI (which may be specified in the WSDL, programmatically,
on the command line etc.);
* WSDL elements or attributes (in addition to the endpoint IRI), and;
* The environment (for example local program variables, system
environment variables etc).
[/quote]
While the first and last items are obvious, I have some doubts about
the second. How can an Axis2 transport have access to the WSDL of the
remote endpoint?
> For supporting transactions, I think we should implement this
> support at the Base transport level if possible, so that if a
> transport is "transactional" its thread pools will only work with an
> active JTA transaction. Sometime back I looked at how Spring and
> Mule supported this and still be able to work within newer JEE app
> servers such as WebSphere 6.1. What they both did was to poll for
> messages continuously with small delay. This is 'somewhat' similar
> to what we do with the nhttp/s transport, but I guess polling would
> be much more expensive with JMS and when transactional. However, I
> do not think there is a better way either..
>
Should we support only the JEE compliant mode or should we also
support using MessageListener when the transport is deployed outside
of a JEE container?
> asankha
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JMS transport specs/documentation
Posted by "Asankha C. Perera" <as...@wso2.com>.
Andreas
> Please review and provide feedback (in particular on my analysis of
> the as-is situation and the proposed to-be situation).
Your analysis is correct, I guess TransportSender will follow shortly
> Some additional points where contribution is required:
> * Explain the impact of supporting both JMS 1.0 and 1.1.
Unfortunately we cannot depend on the Sun's JMS API jar's and thus we
have a dependency on the Geronimo 1.1 API jar, which creates problems,
as even if we break 1.0 compatibility, its not found until too late. I
think a solution to this and a better design would be to move JMS 1.0
and 1.1 API specific code into separate classes, and make the transport
depend on a common interface. Then at least when someone makes a fix on
the 1.0 code, they can be extra careful.
> * I think that a large part of the specifications for the JMS
> transport should apply equally to the AMQP transport. In SYNAPSE-303 I
> suggested to create some kind of abstract messaging transport from
> which both transports would be derived. What is your opinion on this?
I think we should not do anything AMQP specific in the JMS transport,
but rather allow the JMS transport to be configured with additional
properties as required, to support AMQP, MQSeries, Tuscany etc. Someday
there will be a good native AMQP transport, and right now the best
'interoperable' AMQP support there is, is via JMS
> * Can anybody with knowledge about the proposed SOAP over JMS
> specification comment on what we need to rework to support it?
I think we should support the existing Synapse/Axis2 style addresses, as
well as the new IRI scheme and this shouldn't be much of a problem.
Maybe we can have a switch per service to state whether it prefers the
new style or the legacy, and default to the new IRI etc. I haven't yet
had time to read the links to the new SOAP/JMS spec, but I will try to
do that before next week, but I think this is very much similar to the
one posted to the Axis2 dev list some time ago.
For supporting transactions, I think we should implement this support at
the Base transport level if possible, so that if a transport is
"transactional" its thread pools will only work with an active JTA
transaction. Sometime back I looked at how Spring and Mule supported
this and still be able to work within newer JEE app servers such as
WebSphere 6.1. What they both did was to poll for messages continuously
with small delay. This is 'somewhat' similar to what we do with the
nhttp/s transport, but I guess polling would be much more expensive with
JMS and when transactional. However, I do not think there is a better
way either..
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JMS transport specs/documentation
Posted by Andreas Veithen <an...@skynet.be>.
Hi all!
I started to put together some specifications for the JMS transport in
our Wiki space:
http://cwiki.apache.org/confluence/display/synapse/JMS+Transport+Specifications
Please review and provide feedback (in particular on my analysis of
the as-is situation and the proposed to-be situation).
Some additional points where contribution is required:
* The general requirement of interoperability with Tuscany needs to be
translated into more specific requirements.
* Explain the impact of supporting both JMS 1.0 and 1.1.
* I think that a large part of the specifications for the JMS
transport should apply equally to the AMQP transport. In SYNAPSE-303 I
suggested to create some kind of abstract messaging transport from
which both transports would be derived. What is your opinion on this?
* Can anybody with knowledge about the proposed SOAP over JMS
specification comment on what we need to rework to support it?
* There was a discussion recently about support for MapMessages. Is
there any update on this?
Regards,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JMS transport specs/documentation
Posted by Rajith Attapattu <ra...@gmail.com>.
Sorry, gmail has spolied me with the convinient hide-quote thing :)
Will keep this in my mind the next time I reply.
Rajith
On Fri, Jun 13, 2008 at 12:36 PM, Asankha C. Perera <as...@wso2.com>
wrote:
> Rajith
>
> Can you remove unnecessary parts of the messages when replying to a
> specific line.. Else for those of us who does not use Gmail, reading the
> replies on a long threas becomes very messy :D
>
>
> asankha
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: JMS transport specs/documentation
Posted by "Asankha C. Perera" <as...@wso2.com>.
Rajith
Can you remove unnecessary parts of the messages when replying to a
specific line.. Else for those of us who does not use Gmail, reading the
replies on a long threas becomes very messy :D
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JMS transport specs/documentation
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Jun 13, 2008 at 10:51 AM, ant elder <an...@apache.org> wrote:
> On Fri, Jun 13, 2008 at 3:41 PM, Rajith Attapattu <ra...@gmail.com>
> wrote:
>
> > On Fri, Jun 13, 2008 at 8:42 AM, ant elder <an...@gmail.com> wrote:
> >
> > > On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera <as...@wso2.com>
> > > wrote:
> > >
> > > > Hi Andreas
> > > >
> > > > I was wondering whether there is somewhere a specification or
> > > documentation
> > > > that gives a clear overview of what types of messages Synapse's JMS
> > > > transport is supposed to accept and how it should process these
> > messages.
> > > > More precisely I'm looking for a document that contains requirements
> > such
> > > as
> > > > "If the incoming message is a BytesMessage and has a 'Content-Type'
> > > > property, then the transport ..." etc. Is there already something
> like
> > > that?
> > > >
> > > >
> > > > Sorry, there isn't much external documentation yet..except in my
> head
> > > :-)
> > > > .. however, I have been planning to update the JMS transport to
> handle
> > > JTA
> > > > transactions for sometime, and I also wanted to change the design to
> > > support
> > > > both JMS 1.0 and 1.1 in a better way. Some of the current issues we
> > have
> > > > came about as we came across a user who wanted JMS 1.0 support, at
> > which
> > > > point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1).
> > > >
> > > > We also have plans to adhere to the proposed binding for SOAP over
> JMS
> > > > specification<
> > >
> >
> http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E
> > > >.
> > > > At the same time, we need to update our code to not use
> > > setMessageListener()
> > > > etc. which the newer JEE app servers (such as WebSphere) does not
> > allow..
> > > >
> > > > If not, are there people who are interested in helping to write this
> > kind
> > > > of specification? Note that I believe that the current behavior of
> the
> > > JMS
> > > > transport is not always appropriate. E.g. a BytesMessage with
> > > Content-Type
> > > > 'text/plain; charset=...' produces a binary wrapper, while I would
> > expect
> > > a
> > > > text wrapper. Therefore the specs to be written would focus on the
> > to-be
> > > > situation rather than the as-is situation.
> > > >
> > > > I would certainly be very interested to keep working on the JMS
> > transport
> > > > and I believe that with your help and that of any others in the
> > > community,
> > > > we could really improve the current implementation to be much better
> > > >
> > > > asankha
> > > >
> > >
> > > How about also something like an SCA compatibility mode so Synapse
> could
> > > sit
> > > in front of Tuscany/SCA JMS services? It would mainly be just setting
> > some
> > > header properties. I'm mostly a lurker on the Synapse list these days
> but
> > i
> > > could help from the SCA specification and Tuscany interop side of
> things.
> > >
> > > ...ant
> > >
> >
> > Ant could you explain a bit more?
> > Is this for transforming an incomming JMS message into the required SCA
> > fromat?
> > It's been a while since I read the JMS binding spec and can't remember
> off
> > the top of my head whats actually required to do the transformation.
> >
> > --
> > Regards,
> >
> > Rajith Attapattu
> > Red Hat
> > http://rajith.2rlabs.com/
> >
>
> I just meant things like setting the "scaOperationName" JMS user property,
> and there's a Tuscany specific user property to indicate exception messages
> as the spec doesn't define those yet. Those would be the main ones for
> basic
> RPC style services but there's more advanced stuff that could be done like
> with message formats if Synapse wanted to take account of all the SCA
> <binding.jms> options.
>
> ...ant
>
Make sense. Thanks for your reply.
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: JMS transport specs/documentation
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Jun 13, 2008 at 10:51 AM, ant elder <an...@apache.org> wrote:
> On Fri, Jun 13, 2008 at 3:41 PM, Rajith Attapattu <ra...@gmail.com>
> wrote:
>
> > On Fri, Jun 13, 2008 at 8:42 AM, ant elder <an...@gmail.com> wrote:
> >
> > > On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera <as...@wso2.com>
> > > wrote:
> > >
> > > > Hi Andreas
> > > >
> > > > I was wondering whether there is somewhere a specification or
> > > documentation
> > > > that gives a clear overview of what types of messages Synapse's JMS
> > > > transport is supposed to accept and how it should process these
> > messages.
> > > > More precisely I'm looking for a document that contains requirements
> > such
> > > as
> > > > "If the incoming message is a BytesMessage and has a 'Content-Type'
> > > > property, then the transport ..." etc. Is there already something
> like
> > > that?
> > > >
> > > >
> > > > Sorry, there isn't much external documentation yet..except in my
> head
> > > :-)
> > > > .. however, I have been planning to update the JMS transport to
> handle
> > > JTA
> > > > transactions for sometime, and I also wanted to change the design to
> > > support
> > > > both JMS 1.0 and 1.1 in a better way. Some of the current issues we
> > have
> > > > came about as we came across a user who wanted JMS 1.0 support, at
> > which
> > > > point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1).
> > > >
> > > > We also have plans to adhere to the proposed binding for SOAP over
> JMS
> > > > specification<
> > >
> >
> http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E
> > > >.
> > > > At the same time, we need to update our code to not use
> > > setMessageListener()
> > > > etc. which the newer JEE app servers (such as WebSphere) does not
> > allow..
> > > >
> > > > If not, are there people who are interested in helping to write this
> > kind
> > > > of specification? Note that I believe that the current behavior of
> the
> > > JMS
> > > > transport is not always appropriate. E.g. a BytesMessage with
> > > Content-Type
> > > > 'text/plain; charset=...' produces a binary wrapper, while I would
> > expect
> > > a
> > > > text wrapper. Therefore the specs to be written would focus on the
> > to-be
> > > > situation rather than the as-is situation.
> > > >
> > > > I would certainly be very interested to keep working on the JMS
> > transport
> > > > and I believe that with your help and that of any others in the
> > > community,
> > > > we could really improve the current implementation to be much better
> > > >
> > > > asankha
> > > >
> > >
> > > How about also something like an SCA compatibility mode so Synapse
> could
> > > sit
> > > in front of Tuscany/SCA JMS services? It would mainly be just setting
> > some
> > > header properties. I'm mostly a lurker on the Synapse list these days
> but
> > i
> > > could help from the SCA specification and Tuscany interop side of
> things.
> > >
> > > ...ant
> > >
> >
> > Ant could you explain a bit more?
> > Is this for transforming an incomming JMS message into the required SCA
> > fromat?
> > It's been a while since I read the JMS binding spec and can't remember
> off
> > the top of my head whats actually required to do the transformation.
> >
> > --
> > Regards,
> >
> > Rajith Attapattu
> > Red Hat
> > http://rajith.2rlabs.com/
> >
>
> I just meant things like setting the "scaOperationName" JMS user property,
> and there's a Tuscany specific user property to indicate exception messages
> as the spec doesn't define those yet. Those would be the main ones for
> basic
> RPC style services but there's more advanced stuff that could be done like
> with message formats if Synapse wanted to take account of all the SCA
> <binding.jms> options.
>
> ...ant
>
Make sense. Thanks for your reply.
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: JMS transport specs/documentation
Posted by ant elder <an...@apache.org>.
On Fri, Jun 13, 2008 at 3:41 PM, Rajith Attapattu <ra...@gmail.com>
wrote:
> On Fri, Jun 13, 2008 at 8:42 AM, ant elder <an...@gmail.com> wrote:
>
> > On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera <as...@wso2.com>
> > wrote:
> >
> > > Hi Andreas
> > >
> > > I was wondering whether there is somewhere a specification or
> > documentation
> > > that gives a clear overview of what types of messages Synapse's JMS
> > > transport is supposed to accept and how it should process these
> messages.
> > > More precisely I'm looking for a document that contains requirements
> such
> > as
> > > "If the incoming message is a BytesMessage and has a 'Content-Type'
> > > property, then the transport ..." etc. Is there already something like
> > that?
> > >
> > >
> > > Sorry, there isn't much external documentation yet..except in my head
> > :-)
> > > .. however, I have been planning to update the JMS transport to handle
> > JTA
> > > transactions for sometime, and I also wanted to change the design to
> > support
> > > both JMS 1.0 and 1.1 in a better way. Some of the current issues we
> have
> > > came about as we came across a user who wanted JMS 1.0 support, at
> which
> > > point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1).
> > >
> > > We also have plans to adhere to the proposed binding for SOAP over JMS
> > > specification<
> >
> http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E
> > >.
> > > At the same time, we need to update our code to not use
> > setMessageListener()
> > > etc. which the newer JEE app servers (such as WebSphere) does not
> allow..
> > >
> > > If not, are there people who are interested in helping to write this
> kind
> > > of specification? Note that I believe that the current behavior of the
> > JMS
> > > transport is not always appropriate. E.g. a BytesMessage with
> > Content-Type
> > > 'text/plain; charset=...' produces a binary wrapper, while I would
> expect
> > a
> > > text wrapper. Therefore the specs to be written would focus on the
> to-be
> > > situation rather than the as-is situation.
> > >
> > > I would certainly be very interested to keep working on the JMS
> transport
> > > and I believe that with your help and that of any others in the
> > community,
> > > we could really improve the current implementation to be much better
> > >
> > > asankha
> > >
> >
> > How about also something like an SCA compatibility mode so Synapse could
> > sit
> > in front of Tuscany/SCA JMS services? It would mainly be just setting
> some
> > header properties. I'm mostly a lurker on the Synapse list these days but
> i
> > could help from the SCA specification and Tuscany interop side of things.
> >
> > ...ant
> >
>
> Ant could you explain a bit more?
> Is this for transforming an incomming JMS message into the required SCA
> fromat?
> It's been a while since I read the JMS binding spec and can't remember off
> the top of my head whats actually required to do the transformation.
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
I just meant things like setting the "scaOperationName" JMS user property,
and there's a Tuscany specific user property to indicate exception messages
as the spec doesn't define those yet. Those would be the main ones for basic
RPC style services but there's more advanced stuff that could be done like
with message formats if Synapse wanted to take account of all the SCA
<binding.jms> options.
...ant
Re: JMS transport specs/documentation
Posted by ant elder <an...@apache.org>.
On Fri, Jun 13, 2008 at 3:41 PM, Rajith Attapattu <ra...@gmail.com>
wrote:
> On Fri, Jun 13, 2008 at 8:42 AM, ant elder <an...@gmail.com> wrote:
>
> > On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera <as...@wso2.com>
> > wrote:
> >
> > > Hi Andreas
> > >
> > > I was wondering whether there is somewhere a specification or
> > documentation
> > > that gives a clear overview of what types of messages Synapse's JMS
> > > transport is supposed to accept and how it should process these
> messages.
> > > More precisely I'm looking for a document that contains requirements
> such
> > as
> > > "If the incoming message is a BytesMessage and has a 'Content-Type'
> > > property, then the transport ..." etc. Is there already something like
> > that?
> > >
> > >
> > > Sorry, there isn't much external documentation yet..except in my head
> > :-)
> > > .. however, I have been planning to update the JMS transport to handle
> > JTA
> > > transactions for sometime, and I also wanted to change the design to
> > support
> > > both JMS 1.0 and 1.1 in a better way. Some of the current issues we
> have
> > > came about as we came across a user who wanted JMS 1.0 support, at
> which
> > > point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1).
> > >
> > > We also have plans to adhere to the proposed binding for SOAP over JMS
> > > specification<
> >
> http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E
> > >.
> > > At the same time, we need to update our code to not use
> > setMessageListener()
> > > etc. which the newer JEE app servers (such as WebSphere) does not
> allow..
> > >
> > > If not, are there people who are interested in helping to write this
> kind
> > > of specification? Note that I believe that the current behavior of the
> > JMS
> > > transport is not always appropriate. E.g. a BytesMessage with
> > Content-Type
> > > 'text/plain; charset=...' produces a binary wrapper, while I would
> expect
> > a
> > > text wrapper. Therefore the specs to be written would focus on the
> to-be
> > > situation rather than the as-is situation.
> > >
> > > I would certainly be very interested to keep working on the JMS
> transport
> > > and I believe that with your help and that of any others in the
> > community,
> > > we could really improve the current implementation to be much better
> > >
> > > asankha
> > >
> >
> > How about also something like an SCA compatibility mode so Synapse could
> > sit
> > in front of Tuscany/SCA JMS services? It would mainly be just setting
> some
> > header properties. I'm mostly a lurker on the Synapse list these days but
> i
> > could help from the SCA specification and Tuscany interop side of things.
> >
> > ...ant
> >
>
> Ant could you explain a bit more?
> Is this for transforming an incomming JMS message into the required SCA
> fromat?
> It's been a while since I read the JMS binding spec and can't remember off
> the top of my head whats actually required to do the transformation.
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
I just meant things like setting the "scaOperationName" JMS user property,
and there's a Tuscany specific user property to indicate exception messages
as the spec doesn't define those yet. Those would be the main ones for basic
RPC style services but there's more advanced stuff that could be done like
with message formats if Synapse wanted to take account of all the SCA
<binding.jms> options.
...ant
Re: JMS transport specs/documentation
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Jun 13, 2008 at 8:42 AM, ant elder <an...@gmail.com> wrote:
> On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera <as...@wso2.com>
> wrote:
>
> > Hi Andreas
> >
> > I was wondering whether there is somewhere a specification or
> documentation
> > that gives a clear overview of what types of messages Synapse's JMS
> > transport is supposed to accept and how it should process these messages.
> > More precisely I'm looking for a document that contains requirements such
> as
> > "If the incoming message is a BytesMessage and has a 'Content-Type'
> > property, then the transport ..." etc. Is there already something like
> that?
> >
> >
> > Sorry, there isn't much external documentation yet..except in my head
> :-)
> > .. however, I have been planning to update the JMS transport to handle
> JTA
> > transactions for sometime, and I also wanted to change the design to
> support
> > both JMS 1.0 and 1.1 in a better way. Some of the current issues we have
> > came about as we came across a user who wanted JMS 1.0 support, at which
> > point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1).
> >
> > We also have plans to adhere to the proposed binding for SOAP over JMS
> > specification<
> http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E
> >.
> > At the same time, we need to update our code to not use
> setMessageListener()
> > etc. which the newer JEE app servers (such as WebSphere) does not allow..
> >
> > If not, are there people who are interested in helping to write this kind
> > of specification? Note that I believe that the current behavior of the
> JMS
> > transport is not always appropriate. E.g. a BytesMessage with
> Content-Type
> > 'text/plain; charset=...' produces a binary wrapper, while I would expect
> a
> > text wrapper. Therefore the specs to be written would focus on the to-be
> > situation rather than the as-is situation.
> >
> > I would certainly be very interested to keep working on the JMS transport
> > and I believe that with your help and that of any others in the
> community,
> > we could really improve the current implementation to be much better
> >
> > asankha
> >
>
> How about also something like an SCA compatibility mode so Synapse could
> sit
> in front of Tuscany/SCA JMS services? It would mainly be just setting some
> header properties. I'm mostly a lurker on the Synapse list these days but i
> could help from the SCA specification and Tuscany interop side of things.
>
> ...ant
>
Ant could you explain a bit more?
Is this for transforming an incomming JMS message into the required SCA
fromat?
It's been a while since I read the JMS binding spec and can't remember off
the top of my head whats actually required to do the transformation.
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: JMS transport specs/documentation
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Jun 13, 2008 at 8:42 AM, ant elder <an...@gmail.com> wrote:
> On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera <as...@wso2.com>
> wrote:
>
> > Hi Andreas
> >
> > I was wondering whether there is somewhere a specification or
> documentation
> > that gives a clear overview of what types of messages Synapse's JMS
> > transport is supposed to accept and how it should process these messages.
> > More precisely I'm looking for a document that contains requirements such
> as
> > "If the incoming message is a BytesMessage and has a 'Content-Type'
> > property, then the transport ..." etc. Is there already something like
> that?
> >
> >
> > Sorry, there isn't much external documentation yet..except in my head
> :-)
> > .. however, I have been planning to update the JMS transport to handle
> JTA
> > transactions for sometime, and I also wanted to change the design to
> support
> > both JMS 1.0 and 1.1 in a better way. Some of the current issues we have
> > came about as we came across a user who wanted JMS 1.0 support, at which
> > point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1).
> >
> > We also have plans to adhere to the proposed binding for SOAP over JMS
> > specification<
> http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E
> >.
> > At the same time, we need to update our code to not use
> setMessageListener()
> > etc. which the newer JEE app servers (such as WebSphere) does not allow..
> >
> > If not, are there people who are interested in helping to write this kind
> > of specification? Note that I believe that the current behavior of the
> JMS
> > transport is not always appropriate. E.g. a BytesMessage with
> Content-Type
> > 'text/plain; charset=...' produces a binary wrapper, while I would expect
> a
> > text wrapper. Therefore the specs to be written would focus on the to-be
> > situation rather than the as-is situation.
> >
> > I would certainly be very interested to keep working on the JMS transport
> > and I believe that with your help and that of any others in the
> community,
> > we could really improve the current implementation to be much better
> >
> > asankha
> >
>
> How about also something like an SCA compatibility mode so Synapse could
> sit
> in front of Tuscany/SCA JMS services? It would mainly be just setting some
> header properties. I'm mostly a lurker on the Synapse list these days but i
> could help from the SCA specification and Tuscany interop side of things.
>
> ...ant
>
Ant could you explain a bit more?
Is this for transforming an incomming JMS message into the required SCA
fromat?
It's been a while since I read the JMS binding spec and can't remember off
the top of my head whats actually required to do the transformation.
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: JMS transport specs/documentation
Posted by ant elder <an...@gmail.com>.
On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera <as...@wso2.com> wrote:
> Hi Andreas
>
> I was wondering whether there is somewhere a specification or documentation
> that gives a clear overview of what types of messages Synapse's JMS
> transport is supposed to accept and how it should process these messages.
> More precisely I'm looking for a document that contains requirements such as
> "If the incoming message is a BytesMessage and has a 'Content-Type'
> property, then the transport ..." etc. Is there already something like that?
>
>
> Sorry, there isn't much external documentation yet..except in my head :-)
> .. however, I have been planning to update the JMS transport to handle JTA
> transactions for sometime, and I also wanted to change the design to support
> both JMS 1.0 and 1.1 in a better way. Some of the current issues we have
> came about as we came across a user who wanted JMS 1.0 support, at which
> point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1).
>
> We also have plans to adhere to the proposed binding for SOAP over JMS
> specification<http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E>.
> At the same time, we need to update our code to not use setMessageListener()
> etc. which the newer JEE app servers (such as WebSphere) does not allow..
>
> If not, are there people who are interested in helping to write this kind
> of specification? Note that I believe that the current behavior of the JMS
> transport is not always appropriate. E.g. a BytesMessage with Content-Type
> 'text/plain; charset=...' produces a binary wrapper, while I would expect a
> text wrapper. Therefore the specs to be written would focus on the to-be
> situation rather than the as-is situation.
>
> I would certainly be very interested to keep working on the JMS transport
> and I believe that with your help and that of any others in the community,
> we could really improve the current implementation to be much better
>
> asankha
>
How about also something like an SCA compatibility mode so Synapse could sit
in front of Tuscany/SCA JMS services? It would mainly be just setting some
header properties. I'm mostly a lurker on the Synapse list these days but i
could help from the SCA specification and Tuscany interop side of things.
...ant
Re: JMS transport specs/documentation
Posted by ant elder <an...@gmail.com>.
On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera <as...@wso2.com> wrote:
> Hi Andreas
>
> I was wondering whether there is somewhere a specification or documentation
> that gives a clear overview of what types of messages Synapse's JMS
> transport is supposed to accept and how it should process these messages.
> More precisely I'm looking for a document that contains requirements such as
> "If the incoming message is a BytesMessage and has a 'Content-Type'
> property, then the transport ..." etc. Is there already something like that?
>
>
> Sorry, there isn't much external documentation yet..except in my head :-)
> .. however, I have been planning to update the JMS transport to handle JTA
> transactions for sometime, and I also wanted to change the design to support
> both JMS 1.0 and 1.1 in a better way. Some of the current issues we have
> came about as we came across a user who wanted JMS 1.0 support, at which
> point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1).
>
> We also have plans to adhere to the proposed binding for SOAP over JMS
> specification<http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E>.
> At the same time, we need to update our code to not use setMessageListener()
> etc. which the newer JEE app servers (such as WebSphere) does not allow..
>
> If not, are there people who are interested in helping to write this kind
> of specification? Note that I believe that the current behavior of the JMS
> transport is not always appropriate. E.g. a BytesMessage with Content-Type
> 'text/plain; charset=...' produces a binary wrapper, while I would expect a
> text wrapper. Therefore the specs to be written would focus on the to-be
> situation rather than the as-is situation.
>
> I would certainly be very interested to keep working on the JMS transport
> and I believe that with your help and that of any others in the community,
> we could really improve the current implementation to be much better
>
> asankha
>
How about also something like an SCA compatibility mode so Synapse could sit
in front of Tuscany/SCA JMS services? It would mainly be just setting some
header properties. I'm mostly a lurker on the Synapse list these days but i
could help from the SCA specification and Tuscany interop side of things.
...ant
AW: JMS transport specs/documentation
Posted by "Hubert, Eric" <er...@jamba.net>.
Hi Rajith,
it is not much about newer application servers. In fact it is a requirement of the Java EE specification. In the Java EE 1.3 spec it was only forbidden in the EJB container, if I'm not wrong. At least the wording had not been very strict on this. Since J2EE 1.4 all J2EE/JEE servers may throw a JMSException, if an application violates these requirements. This section is more or less unchanged in the Java EE specification, v5. Some application server out there changed their behaviour at some point. Please see below for more details on this!
We also have plans to adhere to the proposed binding for SOAP over JMS specification <http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E> . At the same time, we need to update our code to not use setMessageListener() etc. which the newer JEE app servers (such as WebSphere) does not allow..
Sorry I am not aware of this. Why is this not allowed?
Any pointer to this ?
I can give you at least one pointer: Java(tm) 2 Platform Enterprise Edition Specification, v1.4 (J2EE.6.6 Java(tm) Message Service (JMS) 1.1 Requirements).
[...]
The following methods may only be used by application components
executing in the application client container:
* javax.jms.Session method setMessageListener
* javax.jms.Session method getMessageListener
* javax.jms.Session method run
* javax.jms.QueueConnection method createConnectionConsumer
* javax.jms.TopicConnection method createConnectionConsumer
* javax.jms.TopicConnection method createDurableConnectionConsumer
* javax.jms.MessageConsumer method getMessageListener
* javax.jms.MessageConsumer method setMessageListener
* javax.jms.Connection method setExceptionListener
* javax.jms.Connection method stop
* javax.jms.Connection method setClientID
A J2EE container may throw a JMSException (if allowed by the method) if the
application component violates these restrictions.
Application components in the web and EJB containers must not attempt to
create more than one active (not closed) Session object per connection. An
attempt to use the Connection object's createSession method when an active
Session object exists for that connection should be prohibited by the container.
The container may throw a JMSException if the application component violates
this restriction.
[...]
The JMS specification is available at http://java.sun.com/products/jms.
Regards,
Eric
Re: JMS transport specs/documentation
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Jun 13, 2008 at 8:27 AM, Asankha C. Perera <as...@wso2.com> wrote:
> Hi Andreas
>
> I was wondering whether there is somewhere a specification or documentation
> that gives a clear overview of what types of messages Synapse's JMS
> transport is supposed to accept and how it should process these messages.
> More precisely I'm looking for a document that contains requirements such as
> "If the incoming message is a BytesMessage and has a 'Content-Type'
> property, then the transport ..." etc. Is there already something like that?
>
>
> Sorry, there isn't much external documentation yet..except in my head :-)
> .. however, I have been planning to update the JMS transport to handle JTA
> transactions for sometime, and I also wanted to change the design to support
> both JMS 1.0 and 1.1 in a better way. Some of the current issues we have
> came about as we came across a user who wanted JMS 1.0 support, at which
> point we updated the codebase to JMS 1.0 from what we had (i.e. 1.1).
>
I thought the current implementation has a decent way of handling the
differences between 1.0 and 1.1.
When a destination is not explicitly provided, JMS 1.0 actually gives us a
way of creating a queue with the service name while still using pure JMS
without having to resort to vendor specific extentions.
Asankha, could you highlight some of the issues you have currently? like is
there a list of JIRAs?
This will help me to better understand the problem at hand.
>
> We also have plans to adhere to the proposed binding for SOAP over JMS
> specification<http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E>.
> At the same time, we need to update our code to not use setMessageListener()
> etc. which the newer JEE app servers (such as WebSphere) does not allow..
>
Sorry I am not aware of this. Why is this not allowed?
Any pointer to this ?
>
> If not, are there people who are interested in helping to write this kind
> of specification? Note that I believe that the current behavior of the JMS
> transport is not always appropriate. E.g. a BytesMessage with Content-Type
> 'text/plain; charset=...' produces a binary wrapper, while I would expect a
> text wrapper. Therefore the specs to be written would focus on the to-be
> situation rather than the as-is situation.
>
> I would certainly be very interested to keep working on the JMS transport
> and I believe that with your help and that of any others in the community,
> we could really improve the current implementation to be much better
>
> asankha
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: JMS transport specs/documentation
Posted by "Asankha C. Perera" <as...@wso2.com>.
Hi Andreas
> I was wondering whether there is somewhere a specification or
> documentation that gives a clear overview of what types of messages
> Synapse's JMS transport is supposed to accept and how it should
> process these messages. More precisely I'm looking for a document that
> contains requirements such as "If the incoming message is a
> BytesMessage and has a 'Content-Type' property, then the transport
> ..." etc. Is there already something like that?
>
Sorry, there isn't much external documentation yet..except in my head
:-) .. however, I have been planning to update the JMS transport to
handle JTA transactions for sometime, and I also wanted to change the
design to support both JMS 1.0 and 1.1 in a better way. Some of the
current issues we have came about as we came across a user who wanted
JMS 1.0 support, at which point we updated the codebase to JMS 1.0 from
what we had (i.e. 1.1).
We also have plans to adhere to the proposed binding for SOAP over JMS
specification
<http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E>.
At the same time, we need to update our code to not use
setMessageListener() etc. which the newer JEE app servers (such as
WebSphere) does not allow..
> If not, are there people who are interested in helping to write this
> kind of specification? Note that I believe that the current behavior
> of the JMS transport is not always appropriate. E.g. a BytesMessage
> with Content-Type 'text/plain; charset=...' produces a binary wrapper,
> while I would expect a text wrapper. Therefore the specs to be written
> would focus on the to-be situation rather than the as-is situation.
I would certainly be very interested to keep working on the JMS
transport and I believe that with your help and that of any others in
the community, we could really improve the current implementation to be
much better
asankha