[Ws Wiki] Update of "Frontpage/Axis2/f2f 2/Scribe29" by EranChinthaka

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.

The following page has been changed by EranChinthaka:
http://wiki.apache.org/ws/Frontpage/Axis2/f2f_2/Scribe29

New page:
{{{
[09:46] * Now talking in #apache-axis
[09:46] * Topic is 'Apache Axis -- WSDL SOAP XML-RPC'
[09:46] * Set by FR^2 on Fri Mar 11 13:14:28
[09:53] * Jaya has joined #apache-axis
[09:54] * Jaya has quit IRC (Client Quit)
[09:58] * Jaya has joined #apache-axis
[09:58] <dims> hi Jaya
[09:59] <Jaya> hi dims
[09:59] <Jaya> seems like not much actvity. you might be hearing to presentation right
[09:59] * Chinthaka has joined #apache-axis
[09:59] <dims> we are looking at the flash digaram
[09:59] <dims> glen is asking questions
[09:59] <dims> we just got internet connect
[09:59] <dims> ion
[10:00] <Jaya> you saw the unique way the message flows a little while in the in-flow route while actually it's out-flow
[10:01] <dims> i don't understand
[10:01] <sanjiva> we're discussing the architecture preesntation
[10:01] <Jaya> okay
[10:04] <dims> ISSUE: How many message contexts are there? 
[10:04] <dims> ISSUE: what is their relationship (between them?)
[10:05] <Jaya> three 
[10:05] * ashutosh has joined #apache-axis
[10:05] <Jaya> sry
[10:07] <Jaya> I've answered how many different types of contexts are there - global, message and session
[10:07] <dims> Question from Geoffrey: Can we have light-weight WS-Context based way of storing/retrieving contexts?
[10:08] <Chinthaka> Jaya : its not about contexts, its about message contexts
[10:08] <dims> Question from Geoffrey: Should we have a hierarchical contexts? Can Axis be an engine for a full in memory BPEL/WS-Context/RM implementation
[10:09] <Chinthaka> the issue was how many message contexts do we have in a single message context
[10:10] <Jaya> interesting
[10:17] <dims> long winding discussion...can we use the terminology and concepts in current specs to things in out architecture
[10:20] <dims> chicken and egg problem: can we implement Axis2 using a BPEL engine?
[10:21] <dims> Need a map of how our concepts are related to stuff in WS-* specs
[10:22] <dims> switching to the ppt (from flash)
[10:22] <dims> Ajith is takling about AXIOM
[10:25] * Chinthaka_ has joined #apache-axis
[10:25] * Chinthaka has quit IRC (Read error: 104 (Connection reset by peer))
[10:27] <dims> FAQ: Why doesn't AXIOM do the full infoset?
[10:27] * Chinthaka_ has quit IRC (Read error: 54 (Connection reset by peer))
[10:27] * Chinthaka has joined #apache-axis
[10:27] <ashutosh> when they say data binding integration with OM, do they plan to write one or use something existing like castor?
[10:28] <dims> FAQ (Answer): Talk to dasarath :)
[10:30] * Chinthaka_ has joined #apache-axis
[10:31] * {eng}bar4ka has quit IRC ("Chatzilla 0.9.67 [Firefox 1.0.2/20050317]")
[10:32] <dims> Talking about DOM/AXIOM
[10:32] <dims> AXIOM should be able to load/save all the xml's in XML 1.0 w3c test suite.
[10:33] <dims> Could be done by Ashu/Jaya/Venkat
[10:34] <dims> http://www.w3.org/XML/Test/
[10:35] * smdahlen has joined #apache-axis
[10:35] <smdahlen> hello.. how's the conference going ;)
[10:35] <smdahlen> couldn't sleep much, so thought I join here for a bit
[10:36] <dims> AXIOM needs to do SOAP 1.2 as well
[10:36] <dims> hi shawn
[10:36] <Chinthaka_> hi Shawn :D
[10:36] <smdahlen> hi
[10:37] * alek_away has joined #apache-axis
[10:37] <smdahlen> are you guys using IRC much?
[10:37] <dims> we had a tsunami scare warly morning
[10:37] * Chinthaka has quit IRC (Read error: 60 (Operation timed out))
[10:37] <dims> going thru ppt
[10:37] <dims> am trying to scribe
[10:37] <smdahlen> ok..
[10:37] <ashutosh> yeah read abt tsunami, but its ok now i guess
[10:38] <Chinthaka_> Dims : helping u a bit :)
[10:38] <Chinthaka_> Overview ppt
[10:38] <Chinthaka_> now ppt on WSDL
[10:39] <dims> thanks
[10:40] <dims> WOM can represent both WSDL1.1 and 1.2(2.0)
[10:40] <dims> need a way to load WSDL 2.0
[10:40] <dims> we are starting a new project WODEN 
[10:41] <dims> http://www.mail-archive.com/general@incubator.apache.org/msg04586.html
[10:41] <dims> deployment - we have a new .aar file
[10:42] <smdahlen> you guys have the ppt for WSDL posted somewhere?
[10:42] <dims> self contained jar
[10:42] <dims> yeop
[10:42] <dims> hang on
[10:43] <dims> http://wiki.apache.org/ws/FrontPage/Axis2/f2f-2
[10:43] <dims> more specifically here - http://people.apache.org/~ajith/summit/
[10:43] <smdahlen> thanks
[10:43] <dims> talking about Client API
[10:44] <dims> can we bake ws-addressing into code?
[10:45] <dims> glen's view and decision at first f2f. bake concepts into core, may not be the exact spec.
[10:45] <smdahlen> do you mean directly into the API?
[10:46] * Chinthaka__ has joined #apache-axis
[10:46] <dims> yep
[10:47] <smdahlen> I believe so.. big proponent of it
[10:47] * alek_away_ has joined #apache-axis
[10:47] <dims> "Message based code": we already do it but need to rename stuff
[10:47] <smdahlen> i just responded to Eran's email on the "Messaging and Indigo" thread talking about this
[10:48] <dims> ok
[10:48] <Chinthaka__> Yeah, I saw dat
[10:48] <Chinthaka__> will answer that
[10:48] * GlenD has joined #apache-axis
[10:49] * GlenD changes topic to 'Axis2 Face-To-Face in Sri Lanka'
[10:49] <dims> Question: why do we need AXIOM (why not use xmlbeans?)
[10:49] <dims> xmlbeans can't do rpc/enc
[10:49] <dims> xmlbeans can't do mtom
[10:50] * alek_away_ is now known as alek_s
[10:50] <smdahlen> how important is rpc/enc?
[10:50] <alek_s> hi!
[10:50] <GlenD> very
[10:50] <GlenD> There is a lot of legacy stuff out there that deals with it
[10:50] <alek_s> the most important reason for not using Xmlbeans i would say is that it does nto support streaming
[10:50] <alek_s> and it is all DOM with extra carriage of Java/XML Schemas stuu that is not optional
[10:50] <Jaya> yeah it needs to load whole of the bject model into memeory
[10:50] <GlenD> Plus, a lot of the scripting languages (PERL, Python, etc) have SOAP toolkits which are (at present anyway) RPC based
[10:51] <smdahlen> agree with the need for streaming..
[10:51] <smdahlen> Glen: see your point about the scripting languages..
[10:51] <Jaya> are there any *standards* to back XMLBeans implementtaion, so that interoping is possible???
[10:51] <GlenD> Dasarath sez XMLBeans can do streaming....
[10:52] * Chinthaka_ has quit IRC (Read error: 145 (Connection timed out))
[10:52] <smdahlen> Glen: for rpc/enc, could Axis 1.x be the supporter of that though? so Axis2 can represent next-gen stuff and keep a small footprint?
[10:53] <GlenD> Shawn: Not really - b/c for one thing I want to use the new handler/module/deployment framework with RPC services...
[10:53] <Jaya> what is the point of maintaining the wholistic view of XML message if we don't use it. XMLBeans technology emphasises on having the original XML documnet in tact all through the processing
[10:53] <dims> Shawn: anyone should be able to do anything in SOAP and W3C spec using Axis2. right?
[10:54] <GlenD> +1 dims
[10:54] * alek_away has quit IRC (Read error: 60 (Operation timed out))
[10:54] <smdahlen> even if goes against the basic profile?
[10:55] <dims> basic profile conformance is a switch
[10:55] <dims> which is very important too.
[10:55] <dims> Question: why don't we do JDOM
[10:56] <dims> Answer: It is an implementation not an API that we can implement
[10:56] <smdahlen> ok, i'm cool if there is a need.. for RPC services, what scenarios would you use that for, where Doc/Lit could not be used?
[10:57] <dims> or for supporting existing client code?
[10:57] <alek_s> JDOM does nto do streaming ... so you can not stream SOAP:Body
[10:57] <GlenD> Shawn: Some of us are not hugely up on the Basic Profile anyway...
[10:57] <dims> JDOM can't be used for WS-Security
[10:58] * chathura has joined #apache-axis
[10:58] <alek_s> i think in future WS-Security should be done with streaming library - this will make huge difference for performance
[10:58] <dims> does TSIK do streaming stuff?
[10:59] <dims> JDOM loses info (2 consecutive text nodes get collpsed)
[10:59] <alek_s> what is TSIK?
[10:59] <dims> Verisign toolkit
[10:59] <dims> http://www.xmltrustcenter.org/developer/verisign/tsik/
[11:00] <dims> or IBM's xss4j for that matter
[11:00] <dims> we started late
[11:01] * chathura has quit IRC
[11:02] <dims> now we start messaging proposal
[11:32] <dims> there's a toy in SVN
[11:34] * smdahlen has quit IRC (Remote closed the connection)
[11:35] * smdahlen has joined #apache-axis
[11:35] <Chinthaka__> Srinath starting a proposal for a message based core
[11:35] * chathura has joined #apache-axis
[11:35] <Chinthaka__> a presentation
[11:35] <smdahlen> sorry got kicked
[11:35] <Chinthaka__> Chathura can u please host your wsdl ppt on the web
[11:40] * chathura has quit IRC (Read error: 145 (Connection timed out))
[11:40] <dims> Question: should we use Registry or Configuration (to store info on services and associated metadata)
[11:40] <dims> just a question of name
[11:41] <smdahlen> ithink both are adequate
[11:42] <dims> ok
[11:43] <dims> Sanjiva got goodies
[11:43] <dims> for lunch
[11:43] <dims> what is a "dialog"?
[11:44] <dims> PRPOSAL: rename AxisRegistry to AxisConfiguration
[11:44] <smdahlen> cool
[11:44] <dims> MessageBus == Handler Framework + Engine
[11:46] <smdahlen> like that as well
[11:46] <dims> Messaging API == Let's u send and receive stuff (soap envelope level)
[11:47] * Lilantha has joined #apache-axis
[11:47] <sanjiva> Srinath's proposal document: http://people.apache.org/~ajith/summit/material/Proposal4Axis2Core.pdf
[11:48] <dims> difference between Call and "Messaging API"
[11:48] <dims> Messaging API is fire and forget
[11:48] <dims> Call is implemented using Messaging APU
[11:48] <smdahlen> Q: at a messaging level, is the contract between two parties implicit? (i am in favor of this)
[11:48] <smdahlen> much like sending a JMS message
[11:49] <sanjiva> Shawn: yes it seems to be .. we're still stuck on the overall arch slide :-)
[11:49] <smdahlen> only at a service level does the service descriptor play a part 
[11:49] <sanjiva> +1 for that
[11:49] <smdahlen> sorry :)
[11:51] <dims> http://svn.apache.org/viewcvs/webservices/axis/trunk/archive/java/scratch/srinath_jaliya/src/org/apache/axis/
[11:51] <dims> Srinath's TOY 
[11:51] <smdahlen> and since (at a messaging level) the contracts are implicit, how does the programming model support the user specifying which handlers to use (from the sender's point of view)? A Question that has been plaguing me :(
[11:52] <smdahlen> In Indigo I noticed that a message is sent through a Channel which is configured for exactly 
 one endpoint
[11:55] * dblevins has joined #apache-axis
[11:55] <dblevins> so this is where the part is
[11:55] <alek_s> i think it would be nice if a peer (client or server) could cotnrol what handlers are invoked and maybe even manually add loginc to it (like conditions)
[11:55] <dblevins> s/part/party/
[11:57] <smdahlen> alex: i'm for that
[11:57] <smdahlen> how could that be accomplished?
[11:58] <smdahlen> both programmatically and config files or?
[12:00] <alek_s> i was thining about it recently
[12:00] <dims> welcome david
[12:00] <Chinthaka__> Srinath is proposing a message receiver after the transport listener
[12:00] <alek_s> i think that you could put together simple api for client to use to execute handler chain
[12:01] <dims> alek: Axis2 we should be able to reconfigure handlers at runtime
[12:01] <Chinthaka__> transport listener gets the incoming message and
[12:01] <alek_s> client means anybody using this api
[12:01] <Chinthaka__> hands that over to MessageReceiver to create the msgctxt 
[12:01] <alek_s> that is different than reocnfiguration - more - you can control step-by-step how handler chain (or whole network of handlers) is executed
[12:02] <alek_s> in simple case of hanlder cain it just passes MessageContext to handlers until last handler or fault/exception happened
[12:02] <alek_s> but program could pause this process or even freeze it (if message context can be serialized)
[12:02] <Chinthaka__> now Glen works with Srinath in the board
[12:03] <Chinthaka__> :)
[12:03] <smdahlen> ha
[12:03] <smdahlen> great visual
[12:04] <Chinthaka__> well Dims will visualise it more by taking some pictures :D
[12:04] <alek_s> i hope somebody takes digicam pictures of the board ...
[12:04] <Chinthaka__> yeah
[12:05] <smdahlen> i can't remember who mentioned it, but looking at RM, Security, Transactions etc as a case study will certainly help flush out this messaging concept
[12:05] * smdahlen has quit IRC (Remote closed the connection)
[12:05] <sanjiva> yep .. that's what we've been doing .. 
[12:05] * smdahlen has joined #apache-axis
[12:06] <smdahlen> these hours are a killer :)
[12:07] <smdahlen> i have to get up for work in 5 hours :(
[12:07] <Chinthaka__> Shawn, why ? is it night for you ?
[12:07] <Lilantha> me too
[12:07] <Lilantha> 1 AM
[12:07] <smdahlen> ya.. Pennslyvania, US
[12:07] <Lilantha> here
[12:07] <smdahlen> oh ya? in Philly?
[12:07] <Chinthaka__> well, I will try to record the stuff and make it downloadable
[12:08] <Lilantha> that's good
[12:08] <Chinthaka__> but the mike I have is not that good
[12:08] <Chinthaka__> :((
[12:08] <alek_s> recording in mp3 (or something like that) with picture would be good
[12:08] <Chinthaka__> yeah, its nice to have, but difficult to achieve with constraint resources :(
[12:08] <Chinthaka__> :)
[12:09] <Chinthaka__> anyway, now the situ is we have some argument
[12:09] <Chinthaka__> going on with Srinath's proposal
[12:09] <Lilantha> what is Skype contact details
[12:12] <Chinthaka__> me ?
[12:12] <Chinthaka__> eran.chinthaka
[12:12] <Lilantha> anyone,
[12:13] <dims> Here a digram 
[12:13] <dims> http://brutus.apache.org/~dims/
[12:13] <dims> http://brutus.apache.org/~dims/P3290131.JPG
[12:14] <dims> moved it to http://brutus.apache.org/~dims/axis2/
[12:14] <Chinthaka__> Lilantha : Your Skype call got disconnected
[12:15] <alek_s> thanks Dims!
[12:15] <Lilantha> I'll call again
[12:15] <Chinthaka__> anyway, I'm not sure you all can here well even thru Skype
[12:15] <Chinthaka__> as the mike is not that good
[12:16] <alek_s> i could not hear well - there was too much noise and feedback from time to time that made voice disappear in noise
[12:16] <dims> talking about MsgSender
[12:16] <dims> going to look at code
[12:17] <dims> http://svn.apache.org/viewcvs.cgi/webservices/axis/trunk/archive/java/scratch/srinath_jaliya/src/org/apache/axis/outapi/?rev=159350
[12:18] <dims> http://svn.apache.org/viewcvs.cgi/webservices/axis/trunk/archive/java/scratch/srinath_jaliya/src/org/apache/axis/outapi/SendAndReciveAsyncDialog.java?view=markup
[12:19] <alek_s> i think it would be very useful to have handful of use cases (like RM) when discussing async dialogs
[12:19] <Chinthaka__> people here are going thru code
[12:21] * chathura has joined #apache-axis
[12:25] <dims> talking about http://rafb.net/paste/results/snwTNB76.html
[12:25] <smdahlen> i'm off to bed.. thanks for the talk.. hopefully I can join again tomorrow evening.
[12:25] * smdahlen has quit IRC ("goodbye")
[12:26] <dims> talking about shawn's code
[12:29] <dims> http://marc.theaimsgroup.com/?l=axis-dev&m=110954194020616&w=2
[12:29] <dims> How to set up the call back stuff
[12:30] <alek_s> java has now Future class that allows for much easier to use callbacks for async calls
[12:31] <Chinthaka__> any references, Alek ?
[12:31] <alek_s> Future is simply a standardized way to express callback operations
[12:31] * chathura has quit IRC (Read error: 60 (Operation timed out))
[12:32] <alek_s> see http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/doc/api/edu/emory/mathcs/backport/java/util/concurrent/Future.html
[12:32] <alek_s> this is backport of utilconcurrent form JDK5 to JDK1.4
[12:33] <dims> Question: What's the lifetime of the correlation? where is the data stored?
[12:34] <alek_s> correlation in WS-Addressing would be based on message-id
[12:35] <alek_s> but that could be more flexible (for  exmaple in BPEL it can be both transport level like WSA and business logic using SOAP:Body)
[12:35] <alek_s> if WS-RM is used then correlation for messages may need to surivve machine restart
[12:35] <Chinthaka__> wait the question is how to "keep" the correlation data ?
[12:35] <dims> clear model for where meta-data is stored is absent
[12:36] <dims> glen asks are we talking about interop or implementations?
[12:36] <dims> "specific implementations"
[12:36] <alek_s> for Shawn correlator in-memory hashtable (or database) would work fine
[12:38] <alek_s> if correlator is flexible than it should be able to interop with any async services (it would be nice if it was described in WSDL2 ..)
[12:38] <dims> where can we save correlation ids?
[12:39] <dims> do we need a generic context store?
[12:40] <alek_s> in Shawn code it was called "correlator"
[12:40] <dims> default is "in-memory" store that does not survive reboot?? (or we will start need a database in the default footprint)
[12:40] <alek_s> and it looked lie global hashtable could just do the job as he used message-id for correlation
[12:40] <dims> ws-conext can work with an external service for store?
[12:40] <Chinthaka__> If u people need to listen a bit of things happening in the summit (I'm not sure how well U can hear), get on to skyoe
[12:41] <alek_s> if you reboot the code that listened for callback disappeared - you would need ot save not only correlation id but also state of execution
[12:41] <alek_s> essentially do continuation
[12:41] <dims> hmm. interesting
[12:41] <alek_s> whoich is very difficult in generla case in Java
[12:42] <alek_s> async invocations is essentially the same problem that ppl deal when working on web services that interact with browser and require state
[12:42] <alek_s> in that case correlation id is simply cookie
[12:42] <dims> Geoffrey is talking about "need an interface to store/retrive data/metadate", need to classify that we store
[12:43] <alek_s> but should that be part of core engine?
[12:43] <dims> not sure
[12:44] <alek_s> :-)
[12:45] <dims> hierarchical, named bags of stuff - sanjiva's quote
[12:46] <alek_s> isnt "hierarchical, named bags of stuff" == XML?
[12:47] <dims> Need to do BPEL, BPEL needs correlations to be persistent, then we should be able to plug in a db backed way to store the connection info.
[12:47] <dims> hehe
[12:48] <Lilantha> if these are dynamic data/meta do they need to be XML
[12:49] <Chinthaka__> some funny stuff going on between Sanjiva and Glen :)
[12:50] <Chinthaka__> question is to which one is gonna look up the correlation info
[12:50] <Chinthaka__> and do the rest
[12:50] <Chinthaka__> Glen back saying its a handler
[12:51] * chathura has joined #apache-axis
[12:51] <alek_s> in BPEL you can freeze state of execution - which is like writing whole local stack and doing continuation when you restore it
[12:51] <alek_s> message with reply when is coming back will need to get to seom endpoint
[12:51] <alek_s> and that endpoint may have as many handlers as user need
[12:52] <Chinthaka__> Question : who cleans the stuff that has been put in the Global Context
[12:52] <Chinthaka__> Glen says its by the people who actually put, meaning guys who are responsibel
[12:52] <alek_s> after mesaage is correlated then any global info needed for correlation for this message-id can be deleted
[12:53] <Chinthaka__> Alek, by whom ?? That was G Fox's question
[12:53] <alek_s> it is in one of hanlders (last handler) that will pass message to callback
[12:54] <Lilantha> I belive in the same order as it put data in, need to remove them fromthe ctx
[12:54] <dims> need to store these stuff as xml to be language indepdent
[12:55] <dims> don't use java serialization
[12:55] <Lilantha> good idea; how would the performance will be?
[12:56] <sanjiva> binary serialization of xml infoset .. 
[12:56] <alek_s> i would be very careful with binary serialization of XML infoset - and for sure avoid java serialization
[12:56] <alek_s> XBIS may be good
[12:57] <Chinthaka__> Alek, is there any binary serializations of XML which provides a stax api ?
[12:57] <alek_s> no AFAIK
[12:57] <alek_s> but it is not difficult to adapt any seialization to StAX API 
[12:57] <alek_s> after all StAX API is just presenting XML events - more or less the same as SAX events (and that is what XBIS is based on)
[12:58] <Chinthaka__> ok, at least do we have an impl of binary serialisation which works in SAX ?
[12:58] <alek_s> i would be only very careful not to repeat AXIS 1.x SAX recorder ...
[12:58] <sanjiva> alek why would u be careful with binary serialization of xml?
[12:58] <alek_s> yes
[12:58] <alek_s> because you need ot make sure you knwo if you gain speed/smaller meory footprint 
[12:59] <alek_s> XML is text so serializing it as binary events will not gice big gains in smaller size or performance
[12:59] <dims> lunch time
[12:59] <alek_s> AFAIR in XBIs the baest was 30% but typical was 50% (2x smaller, 2x faster) 
[12:59] <Chinthaka__> :D
[12:59] <dims> back 45 mins
[12:59] <dims> max 1 hr.
[13:00] <Lilantha> bed time for us
[13:00] <Chinthaka__> Guys, u can sleep for an hour :D
[13:00] <Lilantha> :)
[13:00] <Chinthaka__> ok ..
[13:00] <alek_s> sending async sleep message to alek endpoint ;-)
[13:00] * chathura has quit IRC (Read error: 60 (Operation timed out))
[13:00] <Lilantha> :)
[13:01] <alek_s> when i get message corelated i will wake up
[13:01] <alek_s> bye
[13:01] * alek_s is now known as alek_away
[13:02] <Lilantha> xml - > binary coding with some algo, will introduce some averhead
[13:03] <Lilantha> ok, going to bed..., talk to you tomorrow
[13:03] <Lilantha> bye]\
[13:04] * Lilantha has left #apache-axis
[13:47] * Disconnected
[14:00] * Attempting to rejoin channel #apache-axis
[14:00] * Rejoined channel #apache-axis
[14:00] * Topic is 'Axis2 Face-To-Face in Sri Lanka'
[14:00] * Set by GlenD on Tue Mar 29 11:19:15
[14:00] <dims|away> were back
[14:01] <Deepal> bakk to f2f after lunch
[14:01] * Chinthaka has joined #apache-axis
[14:02] * chathura has joined #apache-axis
[14:03] * dims|away: you need to be a channel operator to do that
[14:03] * dims|away is now known as davanum
[14:05] <davanum> dasarath: do you want to scribe a bit?
[14:06] * dims has quit IRC (Remote closed the connection)
[14:06] * davanum is now known as dims
[14:06] <Chinthaka> I put the wsdl ppt that Chathura will do 
[14:06] <Chinthaka> here http://people.apache.org/~chinthaka/summit/Code%20gen.ppt
[14:07] <dims> MessageSender / AxisSender?
[14:07] <dasarath> MessageSender or Call?
[14:08] * Srinath has joined #apache-axis
[14:08] <Deepal> +1 MessageSender
[14:09] <dasarath>  +1 MessageSender
[14:11] * Jaliya has joined #apache-axis
[14:11] <sanjiva> package name: org.apache.axis.MessageSender
[14:13] <sanjiva> So we want to make all the main/top-level classes/interfaces be at org.apache.axis.*
[14:14] <Chinthaka> including Handler, Provider, MessageSender
[14:19] <Deepal> what should go into MessageSnder
[14:19] <Deepal> sender.send(MC mc);
[14:19] <Deepal> sender.send(SE se);
[14:19] <Deepal> MC : message context   SE : soap envelop
[14:22] <Chinthaka> sender has its own scope properties
[14:22] * GlenD has quit IRC (Read error: 113 (No route to host))
[14:22] * Jaliya has left #apache-axis
[14:23] * Jaliya has joined #apache-axis
[14:25] <dasarath> implementation details of the message context
[14:26] <dasarath> glen: the implementation of the message context should provide a user friendly API which is efficient as well
[14:27] <dasarath> the message context will have its own scope
[14:28] <dasarath> the MessageSender has its own scope
[14:30] <dasarath> sanjiva: what should be the scope of the message sender
[14:31] <dasarath> MessageSender API
[14:31] <dasarath> MessageSender.send(MessageContext)
[14:31] <dasarath> MessageSender.send(SOAPEnvelope)
[14:31] <dasarath> if we feel that we need to change the above API, that will be done in future
[14:32] <dasarath> what is the role of the receiver?
[14:32] <sanjiva> also additional methods to capture WS-Addr properties directly in the MessageSender class
  (e.g., MessageSender.setReplyTo (..))
[14:33] <dasarath> will there be any problems in letting the user access the message context? like
[14:33] <dasarath> what if somebody were to mess with the handler chain
[14:34] <dasarath> It should be possible to create a MessageContext with minimal effort
[14:36] <dasarath> When the message context is constructed by the user who is going to populate the handler chain?
[14:36] <Chinthaka> Question 
[14:36] <Chinthaka> how can the handlers be set up ?
[14:36] <Chinthaka> dynamically
[14:37] <dasarath> In the context of ws-policy
[14:38] <Chinthaka> put the information in MsgCtxt
[14:38] <dasarath> here certain dicisions can be made statically while certain others have to wait until the time of actual service invocation when the policy negociation takes place
[14:40] <dasarath> how do you turn on modules?
[14:41] <dasarath> why do we setup the handler chain at the message level... can it not be done at a higher level..?
[14:43] <Chinthaka> ??
[14:45] <dasarath> is it better to configure modules at the application level?
[14:49] <dasarath> how do we contrast axis against workflow languages like BEPL
[14:50] <dasarath> can we not use a workflow language for specifying handler deployment
[14:51] <dasarath> will that make handler deploy a very heavy wait thingy...
[14:53] <dasarath> fox: why not declare handler deployment to be a programming problem... for axis2.0 ver 1.0 that langugage will be a just a list of handlers but with time... we can support more comprehensive languages
[14:59] <dasarath> how to deploy module: proposal from glen
[15:00] <dasarath> in a module we allow a piece of code which is execute when the module is deployed... this is like an init method
[15:00] <dasarath> the method may add handlers as necessary...
[15:02] <dasarath> how does a message "instance" engage a module?
[15:03] <dasarath> in otherwords how do u get the set of handlers belonging to a particular module into the handler chain located in the message context?
[15:09] <dasarath> are we allowing applications to tweak module specific parameters?
[15:10] * Thilina has joined #apache-axis
[15:10] <dasarath> is there a specification which details how handlers should be ordered?
[15:12] <dasarath> WS-Ordering*...
[15:13] <dasarath> policy stuff will provide some incites into what handlers must be run through
[15:14] <dasarath> axis 2.0 should provide a flexible way to configure the handler chain on a per message basis
[15:15] <dasarath> independent of any specification 
[15:16] <Chinthaka> there has to be some module api
[15:16] <dasarath> module discussion wrapup
[15:18] <dasarath> are the modules broken down into a set of handlers at the deployment time?
[15:18] <dasarath> or
[15:19] <dasarath> is it that each time one sends a message we engage the module to figure out what handlers we need to deploy
[15:19] <dasarath> the discussion has been deferred for tomorrow
[15:22] * Srinath has quit IRC ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]")
[15:25] * GlenD has joined #apache-axis
[15:25] <Deepal> Tea back in 10 min
[15:26] * Thilina has quit IRC (Read error: 131 (Connection reset by peer))
[15:30] * sanjiva has quit IRC (Read error: 110 (Connection timed out))
[15:33] * Jaliya has quit IRC ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
[15:39] * GlenD has quit IRC (Read error: 145 (Connection timed out))
[15:50] <dasarath> back from tea break:)
[15:50] <Chinthaka> :)
[15:52] * sanjiva_ has joined #apache-axis
[15:52] <Chinthaka> Tea break = 25 mins , Great !!
[15:52] * sanjiva_ is now known as sanjiva
[15:54] * Thilina has joined #apache-axis
[15:54] <dasarath> handler deployment...
[15:55] <dasarath> glen proposes that when a module is deployed it gets a one time chance to deploy its handlers
[15:58] <Chinthaka> What are in a module ?
[15:58] <Chinthaka> Handlers, Services, ...
[16:16] <Chinthaka> Meaning of Global and Service is not they are phases, but they are about the scope of the handlers
[16:16] <Chinthaka> meaning, Global handlers will run for any message
[16:17] <Chinthaka> but service handlers will run for per service basis
[16:17] <Chinthaka> and those Global and Service handlers can overlap
[16:17] <Chinthaka> there is nothing as Global handlers should execute first
[16:17] <Chinthaka> and then service handlers
[16:18] <Chinthaka> Those global and service handlers can be mixed
[16:18] * GlenD has joined #apache-axis
[16:19] <dasarath> can we dispatch a message before you run the security handlers
[16:19] <dasarath> meaning before we decrypt the message
[16:21] * Srinath has joined #apache-axis
[16:21] <dasarath> the problem with having the dispatch phase late on in the execution chain is that once u know the service the service may want to deploy several more handlers which should be deloyed in a phase which has been passed already
[16:21] <dasarath> so we may have to go through the execution chain again
[16:22] <dasarath> we can solve this problem if we can do the dispatching the message upfront
[16:23] * Jaliya has joined #apache-axis
[16:23] <Jaliya> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsroutetowsadd.asp
[16:24] <Jaliya> This has the Msft support for WS-Addressing headers encrypted
[16:30] * Jaliya has quit IRC (Read error: 104 (Connection reset by peer))
[16:35] <dasarath> glen is in favour of resolving the handlers at run time
[16:35] <Chinthaka> ideas to resolve handlers using a rule based approach
[16:35] <dasarath> correction: glen is in favour of resolving the handlers at deploy time on per service basis
[16:36] <dasarath> rule base approah may kill performance
[16:36] <Chinthaka> finally decided to do the handler resolvment "statically"
[16:36] <GlenD> correction: Glen is in favour of NOT having a rules engine to define the handler ordering on a per-message basis :)
[16:36] * Thilina has quit IRC (Read error: 54 (Connection reset by peer))
[16:36] <GlenD> I'm not sure about deploy time vs. run time
[16:37] <Chinthaka> :)
[16:37] * Thilina has joined #apache-axis
[16:38] * Ajith has joined #apache-axis
[16:38] <dasarath> glen if u do not use rules how do u resolve handlers at runtime?
[16:39] <dasarath> we need to figure out what rules are thought...
[16:41] <Chinthaka> guys, I think its better if we can put the whole log in to the wiki
[16:41] <Srinath> FYI:http://www.eweek.com/article2/0,1759,1779296,00.asp?kc=EWRSS03119TX1K0000594 .. (Indigo preview is out)
[16:41] <Chinthaka> I mean the IRC log
[16:41] <Chinthaka> I don't have all 
[16:41] <dims> ok i will do that
[16:41] <Chinthaka> Dims, thankx :)
[16:44] <dasarath> glen: we should design the engine to be as much as possible within our performance goals
[16:47] <dasarath> problem from srinath
[16:47] <dasarath> if u keep handlers sorted out on a per service basis and when u do not know the service 
[16:48] <dasarath> at the front of the message processing chain how do u apply the handlers?
[16:52] <dasarath> sanjiva: securiy handler should be run on all messages if securiy is enable since we cannot do anything else when parts of the message are encrypted
[16:52] <dasarath> so should we burn in this behaviour into the engine?
[16:52] <dasarath> glen is NOT in favour of this 
[16:55] <dasarath> do soap intermediaries need to look at soap headers which may be encrypted and what are they suppose to do
[16:55] * Jaliya has joined #apache-axis
[16:55] <Jaliya> Now that WSE 2.0 supports WS-Addressing, you can safely sign and encrypt SOAP messages without facing the challenges introduced by WS-Routing. This is due to the fact that WS-Addressing headers are immutable—they are not for modification by intermediaries. Hence, you can sign and encrypt your messages, including the WS-Addressing headers, to achieve the appropriate level of security for your needs
[16:55] <Jaliya> .
[16:59] <Ajith> here you go
[16:59] <Ajith> http://dev2dev.bea.com/technologies/webservices/articles/ws_addressing_intro.jsp
[16:59] <Ajith> addressing
[17:06] <Thilina> it seems that there will be a problem when ws-security comes with MTOM
[17:06] <Thilina> in the case of encryption
[17:06] <dasarath> can we run handlers on different machines from the one in which axis is running?
[17:07] <dasarath> thilina what is the problem?
[17:07] <Thilina> In the MTOM model we have to identify the <xop:include> element before building the AXIOM
[17:07] * FR^2 has joined #apache-axis
[17:07] <Deepal> thilina : so wt is the prob.
[17:07] <Thilina> so if the <Xop:include> is encrypted then we can't identify the attachment
[17:08] <FR^2> Hiho
[17:08] <Deepal> that is why security handler run first
[17:08] <Deepal> hi paul
[17:08] * Jaliya has quit IRC ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
[17:08] <Ajith> Paul ?
[17:08] <chathura> ?
[17:09] <Thilina> then another problem
[17:09] <Thilina> Soap message is coming in the Root mime part
[17:09] <Deepal> FR^2 -paul ?
[17:09] <Thilina> How securtiy acesses the MIME root part
[17:10] <chathura> paul is pzf
[17:11] <Deepal> Thilina : in the tarnsport we ahve to pick the MTOMBuilder
[17:12] <Deepal> and it can handle that 
[17:12] <Chinthaka> and this is something builder independant stuff
[17:13] <Thilina> that means security has to come  in between builder and the parser
[17:13] <Chinthaka> no no
[17:13] <Chinthaka> security works on OM
[17:13] <Chinthaka> the security handler reads the stuff thru OM
[17:14] <Chinthaka> and do whatever it likes thru OM
[17:14] <Deepal> yep : chinthaka
[17:14] <Chinthaka> this will not depend whether this is MTOM or not
[17:14] <Thilina> in the case of encrypted message is there any way of identifying the <xop:include>
[17:14] <dasarath> done for the folks
[17:14] <Chinthaka> Seems like we gonna wrap up
[17:15] <Chinthaka> for the day
[17:15] <Thilina> :D
[17:16] <FR^2> Deepal: Hmm?
[17:16] * dasarath has left #apache-axis
[17:16] <Deepal> nope just asked  :)
[17:18] <Chinthaka> so c u all tomorrow
[17:18] <Chinthaka> 8.30 am Local Time (GMT +6)
[17:19] <Jaya> a good day of work, all you guys
[17:19] <Jaya> c ya tomorrow
[17:19] <Jaya> bye
[17:19] <Deepal> paul if u can try to be with irc tomorrow
[17:20] * Jaya has quit IRC
[17:20] * Chinthaka has quit IRC ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]")
[17:20] * GlenD has quit IRC
[17:20] * chathura has quit IRC
[17:20] * Thilina has left #apache-axis
}}}