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
