Synapse IRC weekly chat log (October-19-2006)

[ant elder <an...@gmail.com>]

He's the log from today's chat. Topic discussed were:

- Overview of the new JMS support and the way JMS messages can be mapped
to/from SOAP messages
- Status of Synapse for next release - need to do some tidy up finish the
NIO work
- Status of non-blocking NIO code - mostly stable in a branch, still working
on the SSL support
- Some discussion about how Synapse compares to JBI and ServiceMix

   ...ant

Session Start: Thu Oct 19 12:55:06 2006
Session Ident: #apache-synapse
* Now talking in #apache-synapse
* paulfremantle has joined #apache-synapse
<paulfremantle> hi
<ant> hi
<GlenD> hi Paul, ant
<paulfremantle> hi Glen
<paulfremantle> ps thanks for the s/j note
<paulfremantle> (via Roland)
<GlenD> yup
<GlenD> Will send you a little update on that by email
<GlenD> Roland got the feedback thing wrong
<paulfremantle> oh ok
<paulfremantle> did you see the commits asankha did on the axis2 jms
transport
<GlenD> noticed them but didn't take a close look yet
<paulfremantle> ok.... so what he's done is similar to the REST model for
HTTP
<paulfremantle> in other words you can send an XML message in
<paulfremantle> and it will be wrapped as SOAP
<paulfremantle> but also
<paulfremantle> you can send in a text message
<paulfremantle> and based on a parameter
<paulfremantle> it will wrap it as an element
<paulfremantle> and put that in the body
<paulfremantle> same with a binary message
<paulfremantle> i guess we can add support for ObjectMessage and MapMessage
in the same way
<paulfremantle> (we'd need to define an XML syntax for MapMessage)
<GlenD> *nod*
<paulfremantle> but its quite sweet
<GlenD> that's all fine for incoming JMS messages
<paulfremantle> aha
<paulfremantle> so for outgoing
<GlenD> but you need to configure what to do for outgoing
<paulfremantle> i suggest we have some MC properties
<paulfremantle> so when the message comes in as text
<paulfremantle> and we wrap it as a text element
<paulfremantle> we also can set a MC property
<paulfremantle> capturing the QName of the wrapper
<paulfremantle> if that is present
<paulfremantle> when we are outgoing
<paulfremantle> we can look inside that QName and suck out the text
<paulfremantle> and send that
<GlenD> why wouldn't it just be a standard QName?
<paulfremantle> well it could be
<paulfremantle> we could have an option to override
<paulfremantle> at the moment asankha has a standard of ""
<paulfremantle> i.e. no wrapper element
<paulfremantle> just stuff in the body
<GlenD> <soap:body>text text text</soap:body>
<GlenD> hm
<paulfremantle> yeah not great
<GlenD> I'd rather <soap:body><axis:text>text text</></>
<paulfremantle> well that you can set
<GlenD> where axis:text is a constant
<GlenD> i.e. always the same
<paulfremantle> well given the discussion we've had on the incub pmc
* saminda has joined #apache-synapse
<paulfremantle> please can you reply to asankhas note :p
<GlenD> leave the transform up to something like synapse
<paulfremantle> sure
<GlenD> yup
<saminda> Hi
<GlenD> hey saminda
<paulfremantle> except remember this is also working in axis2
<paulfremantle> and its harder to do the transform there
<saminda> Hi Paul, Hi Glen
<ant> hi saminda
<paulfremantle> so I think we need an option to override the default qname
<saminda> Hi Ant
<paulfremantle> both inbound and outbound
<paulfremantle> hi saminda
<paulfremantle> do you get me?
* asankha has joined #apache-synapse
<paulfremantle> hi asankha
<ant> what do you mean 'also working in axis2'?
<GlenD> why would you want to override it, just out of curiousity?
<asankha> hi Paul...
<paulfremantle> we are just discussing you JMS stuff
<asankha> ok.. sorry i got late
<GlenD> in other words, it seems to me this is like a binding, and the less
variability the more interoperability
<GlenD> but maybe not
<paulfremantle> ant: this is an axis2 transport, so if I want a service to
consume this, I need to have a service operation name that matches the qname
<paulfremantle> and also i need to be able to set the operation
<paulfremantle> glen: I'd want to override it to match my service
submit(String text)
<paulfremantle> so I want
<paulfremantle> <s:Body><my:submit>text text text</my:submit></s:Body>
<GlenD> hm... so you're talking about a separate transport instance per
service, each of which has config
<paulfremantle> maybe
<GlenD> sure, I can see that
<paulfremantle> but I like the idea of a well-defined and DOCUMENTED default
<paulfremantle> better than i like it going straight in the body
<GlenD> *1
<GlenD> +1 that is
<GlenD> *1 is a little ineffective :)
<asankha> i guess this is about the enhancement i did this week.. is what i
did consistent with whats discussed? or we ned to make any changes
<paulfremantle> asankha
<paulfremantle> here is glens suggestion
<paulfremantle> copy and paste from a few mins ago
<paulfremantle> 10[13:08] GlenD: 01why wouldn't it just be a standard
QName?
<paulfremantle> 1013:09] GlenD: 01I'd rather <soap:body><axis:text>text
text</></>
<paulfremantle> 04[13:09] paulfremantle: 01well that you can set
<paulfremantle> 10[13:09] GlenD: 01where axis:text is a constant
<paulfremantle> 10[13:10] GlenD: 01i.e. always the same
<paulfremantle> so in other words
<GlenD> i.e. the default should be some standard element rather than
unwrapped text
<paulfremantle> yes
<paulfremantle> and you could still override it
<paulfremantle> and outgoing it would spot the standard element
<paulfremantle> and unwrap it
<saminda> does this has to be complient with the WSDL
<asankha> ok.. so we do not let the user override this element?
<paulfremantle> saminda - in this case I'm not sure there is a WSDL
<saminda> if the schem says it, why do we bother to wrap it again
<paulfremantle> unless we create a text/jms binding
<paulfremantle> asankha - we could still add the override.... or maybe just
start with this and see if anyone needs an override
<asankha> ok.. i actually commited this code already to axis head
<saminda> can be represent a REST binding in WSDL1.1
<saminda> s/be/we
<paulfremantle> so asankha this is a minor change to your code
<paulfremantle> anyway
<saminda> if a services exposes a service, why can't it expose this with a
different binding other than soap
<paulfremantle> we need glen to post the suggestion to axis-dev/synapse-dev
* Soumadeep has joined #Apache-synapse
<paulfremantle> hey soumadeep
<paulfremantle> wb
<Soumadeep> HI
<Soumadeep> how are you folks doing :-)
<Soumadeep> Hello Saminda...
<paulfremantle> so saminda... we are really talking about the text or binary
case.... not the XML case
<saminda> Hey, Soumadeep, how are you doing man
<paulfremantle> so the REST binding is just like the HTTP case
<Soumadeep> doing good... the webmethods way ;-)
<paulfremantle> in this case it doesn't really make sense to have a WSDL
unless the schema is really xsd:any
<paulfremantle> so in fact
<paulfremantle> once we get 1.1 done
<paulfremantle> we could add the same logic to the axis2 http transport
<paulfremantle> so if someone posts a JPG
<paulfremantle> then we wrap it up as an MTOM
* pvikas has joined #apache-synapse
<paulfremantle> Vikas! Hi
<paulfremantle> welcome webmethods :p
<Soumadeep> :-))
<pvikas> hi guys..
<asankha> paul.. yes.. we can now send a JPG on JMS, and wrap into an MTOM
soap env
<saminda> If we were to use mail transport with this, I'm need to know how
to achive this
<paulfremantle> very cool
<paulfremantle> good question
<paulfremantle> maybe take the text of the message and wrap as <axis2:text>
and the attachments and wrap as <axis2:binary>?
<saminda> no schema support , unless xsd:anyType
<paulfremantle> yep
<paulfremantle> but this is more useful for synapse than axis2
<Soumadeep> so for a JMS based request you will indirectiong to pass it to
axis2 servletby wrapping it in a soap message?
<saminda> yes
<paulfremantle> we are really dealing with outlying cases from an axis2 pov
<paulfremantle> yes
<paulfremantle> it works already
<asankha> yes.. it works for plain text and binary messages now
<paulfremantle> you send in an XML over JMS and we send it out as the Body
of a SOAP/HTTP request
<paulfremantle> (dont forget XML asankha)
<paulfremantle> :-)
<asankha> yes, of course.. POX :)
<Soumadeep> so the response won't be of any use per se...
<paulfremantle> asankha do we send the response to the JMS reply to
<paulfremantle> if there is no WSA reply to?
<Soumadeep> aren't you putting the message in a jms queue?
<paulfremantle> soumadeep.... if there is a SOAP reply, we can unwrap the
body and send that back over JMS
<Soumadeep> or I am missing something here?
<paulfremantle> we are talking about the other way at the moment
<Soumadeep> ok
<paulfremantle> XML/JMS -> Synapse -> SOAP/HTTP
* asankhap has joined #apache-synapse
<asankhap> paul.. yes
* saminda_ has joined #apache-synapse
<asankhap> sorry got d/c
<paulfremantle> ok
<Soumadeep> From a wadl endpoint perspective how are you plaiing to provide
JMS connections details?
<Soumadeep> WSDL
<paulfremantle> so for SOAP/JMS
<paulfremantle> there is a standard
<paulfremantle> (nearly)
<Soumadeep> Are you sure... I saw was and bea using completely different
ways
<GlenD> there is a spec being worked on
<GlenD> you guys all now have access to it as of today
<GlenD> talk to Prasad :)
<paulfremantle> lol
<Soumadeep> can I have the url please
<GlenD> there isn't one, alas
<Soumadeep> :-(
<GlenD> but Prasad has copies
<Soumadeep> ok
<paulfremantle> so who has downloaded and played with Synapse recently :p
<paulfremantle> be honest
<saminda_> I did
<asankhap> me 2 :)
* GlenD glances at the ground and shuffles his feet
<paulfremantle> yeah and me :)
<paulfremantle> so I'd *really* like to do a release soon as the NIO is done
<ant> i'm a bit behind but hope to spend some time getting back up to speed
over the weekend/next week
<Soumadeep> Oh is it... that's would be cool...
<ant> how is the NIO stuff going?
<Soumadeep> using jetty...
<Soumadeep> or home grown?
<paulfremantle> its just I'm not sure we've thrashed it enough for a release
<asankhap> well... i am trying to bring in the SSL stuff.. and need to do
some restructuring to support it..
<asankhap> and was working on a few other things lately..on axis2
<saminda_> is it stable with non-ssl
<paulfremantle> it seems buggy with SOAP12 :p
<saminda_> if then shall we go for a release, there are lots of features to
be published :)
<paulfremantle> yeah we have loads of new stuff
<paulfremantle> like the registry client bit needs some testing too
<asankhap> paul.. you are using the head branch, which has the wrapper
around asyncweb
<paulfremantle> yes I am
<paulfremantle> ok
<paulfremantle> sorry my mistake
<asankhap> i made a new branch for the non blocking code we did.. but it
needs a bit of more work
<paulfremantle> ok... but anyway this is going to go into axis2 eventually
isnt it
<asankhap> yes, it could
<paulfremantle> k
<asankhap> we need to start working on the userguide too
<paulfremantle> i've started
<paulfremantle> i should have said
<paulfremantle> its still on my hard disk
<asankhap> we already got some suggestions on the structure by community we
need to add and completeit
<asankhap> cool :-)
<paulfremantle> yeah I took Tijs outline and im working on it
<asankhap> also cleanup the samples and code.. and we could use same for the
user guide.. i.e. realistic and complete samples one can play around with
<paulfremantle> that would be fantastic
<paulfremantle> I'm also not sure out package layout is perfect yet
<asankhap> yes.. sometime back i did some work on trying to move to maven2..
but its still in my local copy.. if someone wants to do some work, id be
happy to share it
<paulfremantle> ok
<paulfremantle> actually
<paulfremantle> when i was at apachecon
<paulfremantle> hadrian offered to help do that
<asankhap> yes... he is well experienced with maven 2
<paulfremantle> yeah it would be good
<asankhap> it would be great if he could help
<GlenD> of course he'd be more willing to help if we were sending non-SOAP
messages through the system :)
<paulfremantle> lol yeah but he offered the morning after we argued that all
night!
<asankhap> well.. we are already accepting non soap JMS ..
<paulfremantle> i'll ping him and see if the offer was serious
<asankhap> cool
<GlenD> asankha: context is that we had long and involved discussion at
ApacheCon about the fact that Synapse turns everything into a virtual SOAP
message to flow it through the mediators
* saminda has quit IRC (Read error: 110 (Connection timed out))
<asankhap> ok
* asankha has quit IRC (Read error: 110 (Connection timed out))
<GlenD> Hadrian would rather have the option for raw XML to flow, more like
JBI
<paulfremantle> btw
<paulfremantle> when i said package structure
<Soumadeep> I guess servicemix already does it...
<paulfremantle> i meant the source code
<paulfremantle> not the outputs
<Soumadeep> no value adition for Synapse I guess
<paulfremantle> that might need some tidying too
<Soumadeep> addition
<asankhap> paul: yes i agree
<paulfremantle> soumadeep yeah I agree.... I think we have a good niche
<asankhap> also i think the 'extensions' should be brought into core.. as
they are really important to synapse.. but this requires us to bundle xerces
and xalan..
<paulfremantle> ouch
<pvikas> paul: what might the niche be?
<asankhap> i know.. they are both huge..
<paulfremantle> i thought they are already in the JDK anyway
<paulfremantle> vikas: being really really good at SOAP and XML/HTTP
<paulfremantle> and fast, simple, lightweight in those cases
<pvikas> servicemix is component based, jbi compliant and does have
http/jms/soap handling capabilities..
<pvikas> and its soap-stack free..
<paulfremantle> sure....
<paulfremantle> so to do any mediation in JBI
<paulfremantle> the first thing you have to do
<paulfremantle> is start creating JAR files with manifests and code and all
sorts
<paulfremantle> in synapse, just stick in an XML
<paulfremantle> you can even have it dynamically updated, so you modify the
XML and new messages are routed differently
<GlenD> depends on the JBI implementation, of course
<pvikas> i think u got it wrong.. servicemix allows all that u have just
said synapse offers..
<pvikas> its all out-of-the-box..
<pvikas> bindings, services and components :-)
<GlenD> shipping raw JBI without value adds would be sort of silly for
consumers
<GlenD> so containers like ServiceMix have a ton of easy to use stuff on top
<paulfremantle> Glen: sure.... but it also means that its value as an
interoperability standard is minimal
<GlenD> um, no
<GlenD> the interop value is for the component designers
<pvikas> thats actually an advantage for interop..
<Soumadeep> I guess going forward it may compete with SYnapse
<GlenD> propeller-heads
<GlenD> the users (i.e. end users) should just be able to plug and play
things together
<pvikas> aren't both under apache?
<GlenD> but the experience of that is up to the container designers
<paulfremantle> but what i mean glen is that I dont think that users can
really take one JBI ESB and simply swap it out
<GlenD> vikas: yup
<paulfremantle> without significant work
<GlenD> and they can with Synapse? :)
<paulfremantle> unless they have ignored all the value adds that actually
make it easy
<paulfremantle> nope
<paulfremantle> but synapse doesn't claim to be a standard
<GlenD> I don't think you're getting me here
<paulfremantle> I am
<GlenD> the standard aspect of JBI means that components from all different
vendors, etc, will be able to work together
<paulfremantle> the value is in interoperability of the components
<GlenD> it isn't targeted at end users
<GlenD> right
<Soumadeep> To be honest, servicemix has developed all the required
components required for an intermediary
<pvikas> and it supports the JBI spec too..
<Soumadeep> what we are saying is that... the positioning is strong...
<GlenD> Point being I think you were incorrectly dissing JBI for not being
something it wasn't trying to be
<GlenD> that's all
<paulfremantle> Glen I think the question is how its positioned
<paulfremantle> and I dont agree that its being positioned in the very
strict sense you are positioning
<paulfremantle> it
<Soumadeep> That's what I am saying Paul... they are positioning it  that
way...
<Soumadeep> you check their components and you will know...
<Soumadeep> I was myself surprised ...
<GlenD> anyway... I'm not sure the point of this discussion exactly. :)
We'll make Synapse as good as it can be, and likewise for the ServiceMix
guys.
<paulfremantle> +1
<Soumadeep> :-)
<pvikas> +1.. but it would be great if synapse does JBI kinda things..
passing raw xml.. :-)
<paulfremantle> sure we do
<paulfremantle> thats what we were discussing
<paulfremantle> XML/JMS incoming, XML/HTTP outgoing if you like
<GlenD> right, it passes raw xml.... as long as you're cool with it being a
SOAP envelope during processing
<pvikas> not in a JBI standard format..
<paulfremantle> SOAP is a standard
<paulfremantle> in case you hadnt noticed :p
<Soumadeep> :-)
<GlenD> and Vikas, JBI doesn't have a standard format for message content
either
<GlenD> (some might say "alas")
<Soumadeep> There are issues with Servicemix too... as there is a lot of
marshall and unmarshall...
<GlenD> it has to be accessible as an XML Source and that's it
<GlenD> so someone could build a JBI impl that's just as SOAP-specific as
Synapse, for instance
<pvikas> [glen]i get the point..
<Soumadeep> as it is suppose to handle different protocols
<paulfremantle> anyway guys....we've run over
<GlenD> ya, I gotta run
<GlenD> good to chat with y'all again!
<paulfremantle> and I think we've lost the focus on the release work items
<paulfremantle> i'll take it to email
<GlenD> thanks for restarting this Paul
<pvikas> same here.. bye.. looking forward to the log..
<paulfremantle> bye!
* pvikas has quit IRC
<paulfremantle> who is going to post?
<Soumadeep> bye paul
<paulfremantle> ant?
<ant> yes, thanks paul
<asankhap> bye all
<paulfremantle> bye folks
<GlenD> Paul, you got the log?
<GlenD> ant
<GlenD> cool
<ant> ok
<GlenD> bye!
<asankhap> well.. i dont...
<asankhap> hope someone can post the log
<ant> i have it
* Soumadeep has left #Apache-synapse
* GlenD has quit IRC
<paulfremantle> thanks ant
* paulfremantle has left #apache-synapse
<asankhap> thanks Ant..
* asankhap has quit IRC
* Disconnected
Session Close: Thu Oct 19 16:11:52 2006