On Fri, Jun 13, 2008 at 10:51 AM, ant elder <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 13, 2008 at 3:41 PM, Rajith Attapattu <[EMAIL PROTECTED]> > wrote: > > > On Fri, Jun 13, 2008 at 8:42 AM, ant elder <[EMAIL PROTECTED]> wrote: > > > > > On Fri, Jun 13, 2008 at 1:27 PM, Asankha C. Perera <[EMAIL PROTECTED]> > > > 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/[EMAIL > PROTECTED] > > > >. > > > > 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/
