[Apache Web Services Wiki] New: ChatAgenda/20041215/ChatLog

[ge...@ws.apache.org]

   Date: 2004-12-15T20:49:57
   Editor: EranChinthaka <er...@gmail.com>
   Wiki: Apache Web Services Wiki
   Page: ChatAgenda/20041215/ChatLog
   URL: http://wiki.apache.org/ws/ChatAgenda/20041215/ChatLog

   no comment

New Page:

topics discussed: In flow of the engine. Providers functionality. Bit of out flow
ACTIONS (AIs?):

{{{


[09:04]  ***  Weekly Axis2 chat

[09:04]<gdaniels> hi all

[09:05]<Ajith> hi glen

[09:05]<Deepal> so shell we start :)

[09:05]<Chinthaka> hi glen, we thought u might be late

[09:05]<Jaliya> Hi Glen

[09:05]<gdaniels> I was a little, but not much :)

[09:06]<Srinath> hi glen 

[09:06]<Srinath> shall we start

[09:06]<gdaniels> Hey Srinath, Jaliya

[09:06]<gdaniels> So engine and client API

[09:06]<Srinath> yes

[09:06]<Jaliya> yes

[09:06]<gdaniels> but I think we'll probably spend the whole time on engine...

[09:07]<Srinath> :D

[09:07]<Srinath> let see 

[09:07]<gdaniels> I'm just bringing prototype2 up in another window

[09:07]<Srinath> glen where shall we start

[09:08]<gdaniels> Well, let's start with handlers, phases, and how the engine knows what to execute

[09:08]<gdaniels> I'm not sure we have a solid shared understanding of this yet

[09:08]<Srinath> yes

[09:08]<Deepal> glen what we do at the deployemnt time is we craete what is call ececutioncahin

[09:09]<gdaniels> Srinath, do you want to slowly walk through the flow from the HttpReceiver?

[09:09]<Deepal> not one three chains fro in , out and fault

[09:09]<Srinath> +1

[09:09]<Srinath> 1)request come to trasnport 

[09:09]<gdaniels> Deepal: let's get there as we're going through the flow, and talk about it when we hit it?

[09:09]<Deepal> .

[09:09]<Deepal> k.

[09:10]<Srinath> 2) transport create mesage context

[09:10]<Jaliya> One more aspect, how to handle the addressing related info through out the path

[09:10]<Srinath> + message (OM)

[09:11]<Srinath> shall we follow the path once and go to detail after 

[09:11]<gdaniels> ok, good so far

[09:11]  *** alek_s joined #apache-axis

[09:11]<gdaniels> I think we should go into detail as necessary now

[09:11]<gdaniels> because there might be places where the detail causes a slightly different path

[09:11]<Srinath> yes while waliking when we hit the point :)

[09:11]<gdaniels> right

[09:11]<gdaniels> but if you want to do it the other way I'd be ok with that too....

[09:12]<gdaniels> up to you

[09:12]<alek_s> hello sorry to be late (christmas shopping)

[09:12]<Chinthaka> hi alek

[09:12]<gdaniels> hi Alek!

[09:12]<Jaliya> Hi Alek

[09:12]<Srinath> 3) Transport reciver calls Engine.recive(Msgctx)

[09:12]<gdaniels> s/recive/receive/ :)

[09:12]<Srinath> yap

[09:12]<Srinath> :)

[09:13]<Srinath> 4) engine inside receive ask for service from the registry 

[09:13]<gdaniels> (alek, we're walking through the flow of control from the transport listener to handle a request through the engine)

[09:13]<gdaniels> whoa

[09:13]<gdaniels> I don't think that's what happens

[09:14]<Srinath> glen do you think we should delay dispatching?

[09:14]<gdaniels> I think the engine gets the name of the transport from the MC, and looks up the appropriate "in" handlers from the registry, and adds those to an ExecutionChain

[09:14]<gdaniels> Srinath: yes, I think we have to for flexibility

[09:14]<dims_> hi all

[09:14]  *** dims_ is now known as dims

[09:14]<gdaniels> Then the engine adds all the "global" phases to the EC up through the Dispatch phase.

[09:14]<Deepal> hi dims

[09:14]<gdaniels> hi dims

[09:15]<Chinthaka> hi Dims_ and dims

[09:15]<Ajith> Hi dims

[09:15]<Jaliya> Hi Dims

[09:15]<Chinthaka> :)

[09:15]<Srinath> glen:I was worrid becouse we do not need global/transport hnadlers to run if the service is not deployed  

[09:15]<gdaniels> so the EC at this point looks like [ transport_handlers, phase1_handlers, phase2_handlers, dispatch_handlers ]

[09:15]<gdaniels> Srinath: yes we do, because those handlers might be the ones who know how to do dispatch

[09:15]<alek_s> Glen: i can see it is deep down async correlations talk :)

[09:16]<gdaniels> If you want to do dispatch via URL and URL alone, you can just put the URLDispatchHandler as the first thing on your transport in chain

[09:16]<Srinath> glen: let take some senario .. say I come and call a WS that is not deployed 

[09:16]<alek_s> did anybody propose to use Future<> form util.concurrent to make client API easier?

[09:16]<gdaniels> then if the service isn't deployed that first handler will throw an error

[09:16]<gdaniels> alek: we're not talking about the client API

[09:16]<gdaniels> This is a walk through a server request

[09:17]<Srinath> do we need the global tranport handler to run even the service is not deployed?

[09:17]<gdaniels> "global transport handler"?

[09:17]<gdaniels> what's that?

[09:17]<Srinath> global and trnasport :)

[09:17]<gdaniels> oh

[09:17]<gdaniels> we need at least one of them to run, yes

[09:17]<gdaniels> because there's no concept of "which service is being invoked" outside of some handler

[09:18]<Jaliya> So there will be  handlers  before the dispatch

[09:18]<gdaniels> The fact that a URL maps to a service is not an Axis core thing, it's a Handler thing (like it is in Axis 1.X)

[09:18]<gdaniels> yes

[09:18]<gdaniels> handlers DO the dispatch

[09:18]<gdaniels> URL dispatch will be the common case

[09:18]<gdaniels> but you could also do SOAPAction-based dispatch, or dispatch by looking at the XML, or...

[09:18]<Srinath> but if the serivce is missing do not we suppose to just fail

[09:19]<gdaniels> yes

[09:19]<gdaniels> but when that happens is dependent on the order of the deployed handlers

[09:19]<gdaniels> for instance there might be a logging handler that's the first thing on your transport chain, that would ALWAYS run, then after that might be a dispatch-by-URL handler which could fail on bad URLs

[09:19]<Srinath> then we are saying it it user's repossiblity to revoke them ?

[09:20]<gdaniels> Not sure what you mean?

[09:20]<Srinath> good example glen yap:)

[09:21]<gdaniels> So if the dispatch handler fails, the log handler gets a revoke() (I actually prefer onFault(), since it's not always actually revoking anything... i.e. the log handler won't "unlog"...)

[09:21]<alek_s> this ordering of handlerexecution does sounds like little workflow again :)

[09:21]<Srinath> glen I mean then we say user should be caerful to handle the case of global handler executing without service and fail

[09:21]<gdaniels> Srinath: handlers which require the service to be set should happen after the Dispatch phase.

[09:21]<gdaniels> That's what the Dispatch phase is for, to make sure that someone (it doesn't matter who) has set the service in the MC by the time that phase ends.

[09:22]<alek_s> including ability to declare BPEL-like fault hanlders on multiple nested levels of execution

[09:22]<gdaniels> alek: Can you give an example of what you mean by that?  Simple scenario?

[09:22]<Srinath> ok glen I take it let us continue :)

[09:22]<gdaniels> Srinath: +1, let's just get what Alek means here first

[09:23]<alek_s> you delcare <sequnce> <invoke handndle or any other logic possibley delcare in WSDL portType> <correlations ...> <catch faiultName .. /> </invoke>

[09:24]<alek_s> i am not saying it is thing to do for first version but maybe more procedural way to descrinbe fault handlers in BPEL-like XML could be easier ...

[09:25]<gdaniels> interesting... I'd want to see a couple of fleshed out examples I think

[09:25]<alek_s> see http://www-128.ibm.com/developerworks/library/ws-bpel/#faulthandlers

[09:25]<gdaniels> can we go on now and you can mail about this later?

[09:25]<alek_s> and loook for example  with <faulthandlers>

[09:25]<Srinath> glen does we have a object call trasnport,global at the EngineRegistry OR  keep everything as Phases?

[09:25]<Srinath> inside service

[09:26]<alek_s> fault handler can be attache dot scope which is very close to what is handler chain

[09:26]<Deepal> so glen : what u talk is o have a methods like ER.getGlobalHandlers().exceute();

[09:26]<gdaniels> Srinath: my view is this.  a given MessageContext has a list of Handlers that it's going to execute.  It's a linear chain, and that chain can be modified as the MC moves through the system.

[09:26]<alek_s> (later there is example with <scope> <faultHandlers .. /> <invoke .../> </scope)

[09:26]<Jaliya> Srinath :So far the tranport and global handlers have been executed and we have identified the service right ?

[09:27]<gdaniels> So initially that chain only has the transport + global handlers on it

[09:27]<Srinath> jaliya:no we have not idenfied the service yet 

[09:27]<gdaniels> Once dispatch happens and we know what service is being invoked, THEN the service handlers get added to the chain in the appropriate places

[09:27]<gdaniels> as far as the engine is concerned it just keeps clicking forward in the execution chain unless there's a failure

[09:27]<Srinath> glen: you mean when the mesage context is created engine add trsport and global handlers?

[09:28]<gdaniels> make sense?

[09:28]<gdaniels> Srinath: well, probably not when it gets created

[09:28]<gdaniels> When engine.receive() is first called though

[09:28]<Chinthaka> glen : what we thought was get the execution chain first and execute

[09:28]<gdaniels> So the registry lookups all take place inside the engine

[09:28]<Srinath> yap geln start of recive(..)

[09:29]<gdaniels> Chinthaka: I think your concept of execution chain might be a little different than mine....

[09:29]<gdaniels> What I'm talking about is demonstrated (very simply, but the idea is there) in the EngineToy I built a while ago

[09:30]<Chinthaka> engine asks for the execution chain and the Service will create the *whole chain* for engine

[09:30]<gdaniels> But how does the engine know which service it is, Chinthaka?

[09:30]<Jaliya> Shall we agree on one, So far the engine has created the chain with transport + global handlers  and executed, when the engine.recieve() is called

[09:31]<Srinath> and what engie does it 1) add transort and global handlers 2) execute the chain

[09:31]<Chinthaka> ok, so what u say is transport and global handlers are added to the EC before dispatch, right ?

[09:31]<gdaniels> Srinath: +1!

[09:31]<gdaniels> that's all it needs to do

[09:31]<Srinath> the chain will gow as it go foward

[09:31]<gdaniels> yes

[09:31]<gdaniels> yes

[09:31]<gdaniels> :)

[09:31]<Srinath> by dispatching phase

[09:32]<Srinath> :) cool

[09:32]<gdaniels> service better have been set at the end, since the Dispatch postcondition checks it

[09:32]<gdaniels> if it hasn't been set, the Dispatch phase fails

[09:32]<gdaniels> but we don't care WHICH handler set it

[09:32]<Srinath> +1

[09:32]<gdaniels> so it's very flexible

[09:32]<Chinthaka> ok, I agree 

[09:32]<Jaliya> +1 glen

[09:32]<Deepal> yep

[09:32]<gdaniels> OK, so now we're at the end of the dispatch phase, and the service HAS been set

[09:33]<alek_s> what about WS-RM? 

[09:33]<gdaniels> so the service-specific handlers have already been added to the ExecutionChain

[09:33]<gdaniels> Alek: great Q

[09:33]<alek_s> if message is out of order there will be no service called but message just stored for later

[09:33]<gdaniels> two options as I see it

[09:33]<gdaniels> either WSRM handler is in the global chain, in which case it might run before the service is dispatched

[09:34]<gdaniels> or WSRM hadnler is service-specific in which case it runs after dispatch

[09:34]<gdaniels> but in either case we have the ability to pause the MC and store it for later restart

[09:34]<Jaliya> ok, that is fine, only concern is the ordering

[09:34]<Jaliya> Ah, ok as long as we have "pause" button displayed, we can do it 

[09:35]<gdaniels> Jaliya: ordering just makes sure that the restarts of the paused MCs happen in the right order

[09:35]<alek_s> that is tricky as we need to worry how to store MC for longer time - we do not want to loose messages (and processing pipeline state) when engine is restarted?

[09:35]<gdaniels> Although we need to make sure that we can send an HTTP 202 Accepted when we "pause" I think...?

[09:35]<gdaniels> Alek: yes, we need to get the details right

[09:36]<gdaniels> There are a few tricky parts to handling RM right

[09:36]<alek_s> moreover one will need to "restart" message chain processing and that includes all transport context so response can be send with correct security etc.

[09:36]<gdaniels> I don't think we need to deal with them all right now, just get a sense that the architecture will be able to grow to handle it

[09:36]<gdaniels> alek: explain?

[09:36]<Srinath> yap back to basic glen:how we store the tranpsrt and global handlers in the Registry? (we have trnsport and global obj ) or we have them as phases (where?)

[09:37]<gdaniels> Srinath: Transports have their own registry area, those are just stored by name.  All the rest are just phases.

[09:37]<alek_s> when message finally arrives that is in order other waiting messages needs to be processed by continuing execution of "paused" pipelines

[09:37]<alek_s> but there is no longer original thread or connection that initiated processing

[09:38]<gdaniels> alek: yes, but security stuff as well as anything else we need has been serialized/stored with MC

[09:38]<alek_s> current thread and connection wil lbe different 

[09:38]<Srinath> +1 glen:we talk about the deploytime phase resolution how sahll we match it here?

[09:38]<Srinath> I seen the possibilites need to clean it up:)

[09:39]<gdaniels> alek: yes, so we need a way to switch contexts.

[09:39]<alek_s> i think there is need for easy to use Engine API that allows programmatic control over handler chains their execution - that is more than just ability yo pause and resume pipeloine execution

[09:39]<Jaliya> Alek, let's clarify, what you mean is when we pause a MC, and the if the incoming thread is over, then there should be some one to drive the rest am I right?

[09:39]<alek_s> i think there are also case when handler will want to build its own handler chain 

[09:39]<alek_s> for exmaple in WS-RM to send ack messages

[09:40]<gdaniels> Srinath: the engine has a list of two things - Phases and Handlers.  Phases are deployed in a particular order, and then Handlers can identify themselves as being in a phase

[09:40]<gdaniels> alek: wouldn't it just use the client API for that?

[09:41]<Srinath> phases are improved HandlerChains at the engine?

[09:41]<gdaniels> Phases need to somehow be associated with the correct pre/post conditions.  I did this with a specialized Phase class (DispatchPhase, for instance), but we could also do it with handlers that run first/last

[09:41]<gdaniels> Srinath: something like that, yes

[09:42]<Srinath> then shall we say message context have 1)Execution chain

[09:42]<Srinath> 2)Excution chainhas phases

[09:42]<Srinath> 3)phases has handlers

[09:42]<gdaniels> +1

[09:43]<Srinath> :) next glen: how should we preservice the deploy time ordering?

[09:43]<Srinath> preserve

[09:43]<gdaniels> Example?  Not sure what you're asking...

[09:44]<Srinath> glen: we resolve 90% of the handler order at the deploy time 

[09:44]<Srinath> but the message context is run time

[09:44]<gdaniels> I'm not sure it's 90% 

[09:45]<Srinath> we want to stored the orderd handlers somwhere so they can dump in to message context at run time

[09:45]<Deepal> glen : from where that global and transport hadnlders come

[09:45]<gdaniels> we do that via phases

[09:45]<Deepal> i mean weher we have spechify them

[09:45]<gdaniels> right - we know the order within a given transport for sure

[09:45]<Deepal> specify

[09:45]<gdaniels> then we know the order for the global stuff

[09:45]<Srinath> glen:I thought we said it 99% deploy time reolution before :)

[09:46]<gdaniels> but then we add the service, and those handlers get added at dispatch time

[09:46]<Srinath> glen:to which extent we do the deploy time handler ordering?

[09:46]<Deepal> yes Srinnath we said like that 

[09:46]<gdaniels> plus we discussed maybe letting Handlers programatically change ordering too

[09:47]<Jaliya> our future BPEL engine ;)

[09:47]<gdaniels> So maybe the way to answer your question is this - when the engine asks the registry for the Transport, it gets a chunk of handlers.

[09:47]<gdaniels> ALL those handlers as a unit get added to the ExecutionChain

[09:47]<gdaniels> then the engine asks for all the global handlers, which consists of a variable number of Phases up to and including Dispatch

[09:48]<gdaniels> all those handlers also get added to the EC

[09:48]  *** chathura joined #apache-axis

[09:48]  *** dims quit FreeNode : Remote closed the connection

[09:48]<gdaniels> so now we've got [transport, phase1, phaseN, Dispatch] in the EC

[09:48]<gdaniels> make sense?

[09:48]<Jaliya> Yes

[09:48]<Deepal> I think now we talk something similar to commonEcecutor what we discussed long time ago ::

[09:48]<Srinath> glen EC?

[09:48]<Deepal> :(

[09:49]<gdaniels> once anyone sets the service, we then get [transport, phase1, phaseN, Dispatch, service1, service2, provider]

[09:49]<alek_s> what is common executor?

[09:49]<gdaniels> ExecutionChain

[09:50]<gdaniels> the provider is the end of the road

[09:50]<Srinath> glen: we decide we store the ordered transport handlers in transport +1 where we store te ohter ordered handlers? 

[09:50]<Jaliya> glen, I thought when the dispatching is done, we don't have transport and global anymore?

[09:50]<Srinath> alek CommonExecuters are long forgotton!

[09:50]<alek_s> what is its purpose? 

[09:50]<gdaniels> Jaliya: depends on when it gets done - if it's the first handler in the transport, there is still probably some transport work to do. :)

[09:51]<gdaniels> Srinath: There is a registry of Phases, plus configuration for the engine which says what order they come in.

[09:51]<Srinath> glen: mean they are in EngineResgitry?

[09:51]<gdaniels> yes

[09:52]<Srinath> +1

[09:52]<Srinath> glen:I belive phases can not overlap?

[09:52]<Deepal> finally we are going to do run time odering , won't it be slow donwn the perpormance ?

[09:52]<Chinthaka> alek : CommonExecutor was the name given to the trio Transoprt, Global and Service. We abandoned that thing :)

[09:53]<Srinath> they are like HandleChains.. one after other

[09:53]<gdaniels> Srinath: they cannot overlap that's correct

[09:53]<gdaniels> (I think)

[09:53]<gdaniels> Deepal: I don't think it'll slow things down much if we do it right.  It's just putting together pre-built lego blocks. :)

[09:54]<Srinath> +1 I think the in flow is quite done

[09:54]<Srinath> we got to look at the out flow

[09:54]<Jaliya> wait, before that shall we see what happen in the provider

[09:54]<gdaniels> Well that involves one more piece of in flow

[09:55]<Jaliya> I mean we need the same to happen when a message is recieved by the client as a response

[09:55]<gdaniels> For the HttpReceiver, which is on a single thread, it has to put the HttpSender into the MessageContext as the "responder"

[09:55]<Srinath> +1

[09:56]<gdaniels> Jaliya: we need to cover the client cases in general too - we discussed all this in Sri Lanka, but it's good to go over it again, so we can turn it into real code. :)

[09:56]<Jaliya> glen: yes

[09:56]<chathura> well rather than having entirely runtime ordering i would prefer to have a deployment time thing , if we wont we can keep room for runtime order changing

[09:56]<alek_s> why not encapsulate chain ordering (registry and friends) into OrderingInterface (following Strategy pattern) so user can choose how handlers ordering should be done?

[09:57]<chathura> reason is i dont think the runtime ordering is a very frequent use case is it?

[09:57]<Chinthaka> glen : I will send an email to mailing list about putting the transport specific stuff to MC and how to use addressing for that

[09:57]<Srinath> glen shall we have a reciver infront of provider which handle the sync/async aspects?

[09:57]<gdaniels> alek: I'm not sure how that would work, and it sounds perhaps a little too much mechanism. :)

[09:57]<Srinath> + in/out aspects

[09:58]<alek_s> for start you have SimpleOrederingAllInDeploymentStrategy 

[09:58]<alek_s> used by engine to figure out order in which handlers are executed

[09:59]<gdaniels> Srinath: Well, let's think about this.  For one-way messages, there's no response, but there might be faults.

[09:59]<gdaniels> (one-way is simplest case)

[09:59]<alek_s> then user can provide their own strategies and interact with engine when setiing how handlers are executed

[09:59]<alek_s> (this encapsulates complexity of hndlers ordering inone place that does just that)

[09:59]<gdaniels> So we need some kind of "faultDeliveryChannel" or something which is the place faults go

[10:00]<gdaniels> We also need a "replyDeliveryChannel" (or "Responder") which is the place where replies go

[10:00]<Srinath> glen: ideas is keep he provider as 1.1 symantics .. recivers handle inout/sync/async by changing reciver we can meke service sinc/async

[10:00]<gdaniels> alek: I'm not sure that's something you can pull out of the engine and still have the engine be useful...

[10:00]<alek_s> if message is really one way message that it has neither response nor fault right?

[10:00]<gdaniels> alek: We have one-way-with-fault MEPs in WSDL 2.0

[10:01]<Srinath> glen:about faults we can have a fault flow .. with a execution chain and just like a outflow

[10:01]<gdaniels> Makes a lot of sense - message is HTTP request, then you either get 202 OK or 500 + fault

[10:01]<gdaniels> Srinath : yes, exactly

[10:01]<alek_s> glen: it woul dmake engine easier to understand if you have part deling with ordering algo separated (and that is main point of using Strategy pattern) but i am not sure how feasible it is ...

[10:02]<gdaniels> alek: I'm not sure that it would actually make it easier to understand, since I think a lot of what the engine *is* is the handler execution model

[10:03]<gdaniels> Srinath: could you explain the sync/async thing?

[10:03]<alek_s> then it is not one-way messaage it is really MEP

[10:04]<Srinath> glen: have a reciver and put sync /async code in the reciver (starting new threads ect)

[10:04]<gdaniels> alek: for "real" one-way (fire and forget), there still may be faults and we may still want to direct them somewhere within our own system, even if they don't get transmitted

[10:04]<alek_s> difference between 'http://www.w3.org/2004/08/wsdl/in-only'. and http://www.w3.org/2004/08/wsdl/robust-in-on

[10:05]<gdaniels> Srinath: Tell me how that works - example?

[10:05]<alek_s> http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#patterns

[10:05]<gdaniels> alek: ya

[10:05]<alek_s> \so in former there is no faults

[10:05]<Srinath> glen see the code org.apache.axis.impl.receivers.*

[10:05]<alek_s> in later there can be fault

[10:05]<gdaniels> alek: no *transmitted* faults

[10:05]<gdaniels> system can still generate them

[10:06]<Srinath> geln:look at SyncInoutReciver

[10:06]<Jaliya> Receiver is infront of provider in the server side, whcih will accept the message after the EC

[10:06]<alek_s> glen: whe you say fault i think about message - i think exception when something happens inside EC that may be passed into fault handler chain (or not)

[10:07]<gdaniels> Srinath/Jaliya: ok, looking

[10:07]<Jaliya> Receiver will use different providers, e.g. java or pure XML etc..

[10:08]<gdaniels> uh

[10:08]<gdaniels> so a Receiver is just something that decides whether to invoke the provider on the same or a new thread?

[10:08]<Jaliya> yes

[10:09]<Jaliya> It will know the message patterns

[10:09]<Srinath> it can handle MEp aspects as well I think

[10:09]<Jaliya> I mean IN-ONLY, IN-OUT etc

[10:09]<gdaniels> how does it do that?

[10:09]<Srinath> idea is seperate provider and sync/async + MEPS logic

[10:10]<gdaniels> it's the provider that knows the MEPs, I think

[10:10]<Srinath> e.g. there may be oneway onely reciver that invoke the provier and forgets 

[10:10]<Jaliya> It should be a deployement decision, I think

[10:10]<gdaniels> hm

[10:11]<gdaniels> OK, this gets into a pretty interesting discussion, I think.

[10:11]<Deepal> u mean selecting provider at the deployemnt time ?

[10:11]<gdaniels> But we're already over time... :(

[10:11]<Srinath> let say differant level of providers (one who know MEPS, one who know how to execute impl ect )

[10:11]<Srinath> glen do you got to run? I canmanage few for mins

[10:12]<gdaniels> I can stay another 15 min or so, but should go after that

[10:12]<Srinath> :) if we do not decided after that let discuss in the dev list

[10:12]<Jaliya> Yes

[10:13]<gdaniels> So a provider has a concept of whether its doing RPC type stuff or not, right?  I.e. it knows if it's going to return something or not

[10:13]<Srinath> glen what do you think about the Reciver (provder who knows MEPS ;) )

[10:13]<Deepal> glen : ragrading Clinet API thing , lets us discuss that using mails :

[10:13]<gdaniels> Srinath: not sure yet. :)

[10:13]<Deepal> it is too late to discuss that in next week

[10:13]<Jaliya> Yes glen provider is specific to the impl

[10:13]<Srinath> glen +1 yas provider know doc lit ect (about impl invocation)

[10:14]<gdaniels> So in particular, I would expect the provider to be the one that calls sender.sendResponse(response)

[10:14]<gdaniels> or just send(response)

[10:14]<Jaliya> users can write it, Receivers are corresponding to the MEPs, and also we can have a receiver at the client side as well wchich will handle the callbacks

[10:14]<Srinath> we cam mke that is reciver call send 

[10:14]<gdaniels> so what does the provider do with the value it gets back from the Java method?

[10:15]<gdaniels> Object ret = method.invoke(deserializedArgs);

[10:15]<Srinath> then by changeing reciver keeping provider we can me a invocation sync <->async

[10:15]<gdaniels> then what?

[10:15]<Jaliya> I will explain

[10:15]<Srinath> glen: send it to mesaeg context 

[10:15]<Srinath> set it to mesage context

[10:16]<Jaliya> If the receiver is sync, then it will wait for the provider's response bloking the current thread

[10:16]<gdaniels> where in MC?

[10:16]<Srinath> as message 

[10:16]<Jaliya> if the receiver is async type then it will start a new thread of its own and wait for the provider's response and start a new client flow

[10:16]<Srinath> wrap by OM (directly /indirectly)

[10:16]<Jaliya> to send the response (if any)

[10:17]<gdaniels> hm.. ok, I think I see where you're going.

[10:17]<Srinath> :)

[10:17]<Jaliya> :)

[10:18]<gdaniels> Sounds OK, need to think about it a little. :)

[10:19]<Jaliya> Yes, agreed, send your thoughts about it :-)

[10:19]<Srinath> glen can you think about it and put a note to dev list ?

[10:20]<gdaniels> so the code that currently says sender = new Sender() in the InOutSyncReceiver will be replaced with sender = msgContext.getSender()

[10:20]<gdaniels> Srinath, Jaliya: Yes, definitely.

[10:20]<gdaniels> Can we make the other changes we talked about earlier too with respect to the ExecutionChain and the engine behavior?

[10:21]<Srinath> glen:yes we can do that (now sender get info from the mesage context to work ) we can set the send in msgctx itself

[10:21]<Jaliya> Glen please explain that msgCtx.getSender() part

[10:21]<Chinthaka> msgContext.getSender() ??

[10:21]<Srinath> glen: I will change the engine to changes we discuss and get back!

[10:22]<gdaniels> Srinath: +1, please get in touch and/or look at EngineToy for ideas

[10:22]<gdaniels> The getSender part is just about the fact that the Sender object has been put in the MC by someone who knows how to send - i.e. the HttpReceiver knows how to send a response back out the HTTP connection

[10:22]<Srinath> sure glen and will get back to you for any clarification if needed :)

[10:23]<gdaniels> The WS-Addr handler knows how to send the reply to the "wsa:ReplyTo" address, etc.

[10:23]<Jaliya> oh, ok. got it

[10:23]<gdaniels> those guys will put a Sender in place

[10:23]<Jaliya> You mean TransportSender in it

[10:23]<gdaniels> I'm not sure it's transport-specific

[10:24]<gdaniels> need to go through some more use-cases

[10:25]<Jaliya> ok, we too, If some one in the request path adds a sender, then we may think the message path as req/res again?

[10:25]<gdaniels> not necessarily

[10:25]<Chinthaka> glen : isn't it enough to put some addressing specific info in to MC to do this

[10:25]<Jaliya> but we can carry the info need to send the response( if any) 

[10:25]<gdaniels> yes

[10:25]<Chinthaka> I mean wihout putting a "Sender" ?

[10:25]<Srinath> glen:sender is one who strt the response flow?

[10:25]<gdaniels> yes to Jaliya, not to Eran

[10:26]<Chinthaka> :(

[10:26]<Jaliya> :)

[10:26]<gdaniels> Srinath: yes, I think so.  Need to go into more detail / talk this out more.

[10:26]<gdaniels> Eran: I'm not sure what you meant

[10:26]<Chinthaka> its like this GLen

[10:27]<Chinthaka> TransportReciever put some info in to MC 

[10:27]<Chinthaka> like To stuff

[10:27]<Chinthaka> if there is a Addressing handler

[10:27]<Srinath> glen:I think it is not hard to change it pattern we decided even later .. let discuss looking at the code

[10:28]<Jaliya> Yep, it may be late for you glen

[10:28]<Chinthaka> it will replace those values in the MC

[10:28]<gdaniels> Eran: Yes, that sounds right

[10:28]<Chinthaka> then the transport sender has all the info from the MC

[10:28]<gdaniels> It's just that the "to stuff" is envisioned as a Sender/Responder/whatever class

[10:29]<Chinthaka> oki

[10:29]<Chinthaka> I start a thread on this in the mailing list, after this chat

[10:29]<gdaniels> Let's try to focus on the rest of this use case (i.e. handing MEPs, response) on the list

[10:29]<gdaniels> Eran: +1

[10:29]<gdaniels> OK, I'm gonna head to bed, guys.  Good chat!!

[10:29]<Chinthaka> Good night

[10:29]<Srinath> glen I think have put that logic at tranport level will pull them up to sender !

[10:30]<Chinthaka> BTW : is Alek here ?

[10:30]<gdaniels> Srinath: k

[10:30]<Srinath> good night  glen:)

[10:30]<Jaliya> Good Night Glen and Alek

[10:30]<gdaniels> good night, everyone, talk to you tomorrow :)

[10:30]<Chinthaka> Alek ???

[10:30]  *** gdaniels is now known as glen-zzzz

[10:31]<Chinthaka> who gonna post the chat log this time, Alek must have far asleep

[10:32]<alek_s> YES

[10:33]<Chinthaka> ahh, r u posting the log ??

[10:33]<alek_s> please post it to mailing list and to wiki

[10:33]<alek_s> i do not have first 10 minutes

[10:33]<Chinthaka> ok

[10:34]<Chinthaka> BTW : I need to have a chat with u regarding addressing

[10:34]<alek_s> let do it next week

[10:34]<Chinthaka> please just drop a hi when u r free :)

[10:34]<Chinthaka> in Yahoo

[10:34]<alek_s> i will be travelling friday/saturday

[10:34]<alek_s> ok

[10:34]<alek_s> will do

[10:35]<alek_s> but if i do not just send me email remainder 

[10:35]  *** dasarath left #apache-axis : 

[10:35]<Chinthaka> ok thx and byee

[10:35]  *** chathura left #apache-axis : 

[10:36]<alek_s> bye

[10:36]  *** alek_s quit FreeNode : "Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]"

[10:36]<Srinath> bye alek (hope you had sucesseful x-mas shopping ;) )

[10:36]<Srinath> bye

[10:36]  *** Chinthaka quit FreeNode : 

}}}