Differences between revisions 3 and 4
Revision 3 as of 2004-11-15 18:35:53
Size: 19723
Comment:
Revision 4 as of 2009-09-20 22:48:51
Size: 19723
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

[chat log provided by Ajith Ranabahu on axis-dev]

[19:45]  ***  Apache Axis Framework for web services
[19:45]  *** [freenode-info] why register and identify?  your IRC nick
is how people know you.  http://freenode.net/faq.shtml#nicksetup :
#apache-axis
[19:47]  *** Jaliya joined #apache-axis
[19:51]  *** Chinthaka_away joined #apache-axis
[19:51]  *** Chinthaka_away is now known as Chinthaka
[19:56]  *** Srinath sets topic for #apache-axis : Apache Axis
Framework for web services [Axis2]
[20:00]<Ajith> Good morning/evening everybody
[20:01]<Deepal> Hi all
[20:02]  *** gdaniels joined #apache-axis
[20:03]<Deepal> hi glen
[20:03]<gdaniels> good morning, folks
[20:03]<Srinath> hi all
[20:03]<Deepal> can we start now
[20:03]<Chinthaka> I think so :)
[20:03]<Deepal> can I start from phase handlers
[20:03]<Deepal>  :)
[20:04]<Deepal> Glen : can u pls tell me wt really mean by phase
[20:04]<Ajith> yeah since glen is here we can clarify that first
[20:04]<Deepal> is that logical collection of handlers
[20:04]<Srinath> Sanjiva Sir is trying to connect .. but said trouble
connecting in :(
[20:04]<Ajith> ah
[20:04]<Deepal> so then wait until he come
[20:05]<Deepal> i mean Dr Snjiva
[20:05]<Srinath> I think we got to start he said he is getting no
response at all ..
[20:06]<Deepal> k
[20:06]<FR^2> Oh, it's wednesday again ;-)
[20:06]<gdaniels> Deepal: Sure, yes, it's a logical collection of
Handlers, which runs in a particular order with respect to a) the
other Phases, and b) certain engine tasks like dispatching
[20:06]<Deepal> Glen can u pls answer the q that I asked
[20:07]<Deepal> how can we ordr handler inside a phase
[20:07]<Ajith> aha ... it is a logical group only right?
[20:07]<Deepal> i mean order
[20:07]<gdaniels> That's a deployment question, Deepal
[20:07]<gdaniels> Up to us :)
[20:07]<Deepal> Glen : in hander 
[20:07]<Deepal> there are proprty call
[20:07]  *** Gabriel_Shear joined #apache-axis
[20:07]<Ajith> glen: in the DD what is the order that you specify
[20:07]<Deepal> before and after
[20:08]<Jaliya> Hi all, 
[20:08]<gdaniels> We discussed having a few options - 1) deploy this
Handler "before" phase X, 2) deploy this handler "in" Phase X, 3)
deploy this handler as the FIRST one in Phase X, etc
[20:08]<Deepal> wt they really represent
[20:08]<gdaniels> Deepal - do you mean "checkPrecondition"/"checkPostcondition"?
[20:08]<Deepal> So u mean b4 and after represnt phases
[20:09]  *** Gabriel_Shear left #apache-axis : 
[20:09]<Deepal> no Glen In hander there are proproty call beore and afte
[20:09]<Deepal> http://wiki.apache.org/ws/FrontPage/Architecture/Deployment
[20:10]<Deepal> in this doc u can see that
[20:10]<gdaniels> looking
[20:10]<Chinthaka> even in http://wiki.apache.org/ws/FrontPage/Axis2 under 1.8
[20:10]<Deepal> 1.6.1
[20:11]<gdaniels> First off, you realize that the stuff in the wiki is
just a strawman for now, right?
[20:11]<gdaniels> So anything there is subject to change/approval/etc
[20:11]<Deepal> hmm
[20:11]  *** dims joined #apache-axis
[20:11]<gdaniels> It looks like this is a swipe at the ordering, but
not necessarily what we'll end up with.
[20:11]<gdaniels> hi dims!
[20:11]<gdaniels> :)
[20:12]<Deepal> so wt if we make before and after as Hnaders
[20:12]<Jaliya> The idea I have is that, the phase is a logical group
of handlers, at the DD we can define any number of phases and the
order can be described using before, after etc.. I am right glen?
[20:12]<gdaniels> Jaliya: sounds right to me
[20:12]<gdaniels> We need to be careful about allowing TOO much
flexibility at first
[20:12]<Chinthaka> jaliya : its true, but here we are talking abt
before and after of handlers
[20:12]<Deepal> Jaliya : order phases is discribd in sercer.xml
[20:12]<gdaniels> That can get complex
[20:13]<gdaniels> But that's the basic idea, yes.
[20:13]<Deepal> jaliya : sorry order of phases 
[20:13]<gdaniels> We need to play with it to make sure it works/is useful enough
[20:14]<Jaliya> Yes
[20:14]<Deepal> Glen i dinnt get u
[20:14]<Srinath> HELP!! is their any HTTP bridge IRC (for Dr Sanjiva )
[20:15]<Chinthaka> Srinath : Miranda ?
[20:15]<Jaliya> I think that also may not use 80
[20:15]<gdaniels> If we allow too many options, Deepal (deploy this
handler before this one, but after this one, and three before this
one's cousin, etc.), it can get confusing for the deployer and hard to
implement for us.  We need to find the right balance between
expressivity and minimalism - keep it small but not too small.
[20:17]<Ajith> glen :  so do you have any control over how the
handlers are ordered INSIDE the phase then??
[20:17]<gdaniels> Ajith: That's up to us to decide. :)  I think a
little, like saying "make this the first handler in phase X", but
maybe not to the level of "this one, then this one, then that one..."
[20:19]<Ajith> aah
[20:19]<Ajith> So it means we have full control over the order of
phases but not the order of handlers inside the phase
[20:19]<Chinthaka> I think that what achieved thru phaseFirst and phaseLast
[20:19]<Jaliya> One more question we had was that, the bounderies of a
phase, can a handler in one phase be interspersed with another pahse
[20:20]<gdaniels> Chinthaka: right
[20:20]<Ajith> yep that is another issue
[20:20]<Ajith> my reckoning was that they should not intersect
[20:21]<Chinthaka> Ajith : didn't get u
[20:21]<gdaniels> no, I think each handler is in exactly one phase
[20:21]<Srinath> any other options than Miranda ?
[20:21]<gdaniels> Miranda?
[20:21]<Jaliya> glen: Ah ok
[20:22]<Srinath> glen:sorry Any HTTP bridge for IRC
[20:22]<Deepal> Glen : phase property of a hander  is  optionl now
[20:22]<Chinthaka> Srinath : XChat is there, but I haven't tried that :(
[20:23]<Deepal> wt if we make it mandatory
[20:23]<Chinthaka> can i say that the before and after attributes
refer either to a handler or to a phase ?
[20:23]<Deepal> then user can speifically say that this hander belong
to this pahse etc..
[20:24]<Deepal> Chinthak : I think it is difficult to implement :(
[20:24]<Deepal> sorry specifically not speifically
[20:25]<Chinthaka> deepal, y ? its just another URI
[20:25]<gdaniels> (sorry was trying to help sanjiva)
[20:25]<gdaniels> Chinthaka: I don't see why not...
[20:25]<gdaniels> Chinthaka: as long as it doesn't conflict with
anything else you claim in the DD
[20:26]<Deepal> Chinthka : I think we can
[20:26]<Ajith> Chinthaka : Sorry I had to take a call. What I meant
was phases should not intersect !
[20:26]<gdaniels> Deepal: I don't think it should be mandatory to
specify phase, but am not sure yet.  There can be a default
[20:27]<Ajith> Glen : you say each hander is in only one phase? should it be
[20:27]<Deepal> that means if user dosent specify the phase its belong
to default ?
[20:27]<Srinath> glen:but if we let before after refer to handlers it
might messay.. as usulally the phase is the only well known thing
[20:27]<Ajith> I mean how about the logging handler
[20:27]<gdaniels> Deepal: yes, something like that
[20:27]<gdaniels> Ajith: each handler type can be in more than one phase
[20:27]<gdaniels> definitely
[20:28]<gdaniels> but for each individual handler configuration, I
think maybe it's only in one phase.... but maybe not! :)
[20:29]  *** Jaliya left #apache-axis : 
[20:30]<Ajith> Ok So you mean that you find each "handler instance" is
uniquely bound to a phase
[20:30]<gdaniels> right
[20:33]<Chinthaka> :
[20:34]  *** sanjiva joined #apache-axis
[20:34]<Deepal> so then before and after can reprsent either pahse or hander ?
[20:34]<sanjiva> hi guys
[20:34]<Deepal> hi sir
[20:34]<Ajith> ok this seems like a great improvement from where we were
[20:34]<gdaniels> Deepal: TBD
[20:34]<Chinthaka> at last
[20:34]<Ajith> hi
[20:34]<Srinath> Hi Sir .. got in at last:)
[20:34]<sanjiva> managed to run my old apache soap tunnel on an IBM
machine and now connected thru that .. old hack comes thru again :)
[20:35]<Srinath> :D
[20:35]<sanjiva> sorry to be late!
[20:35]<gdaniels> so we're talking phased handlers, sanjiva
[20:35]<sanjiva> ok cool - keep going I'll catch up
[20:35]<gdaniels> in particular how to deploy handlers into phases
[20:35]<Srinath> it is bit blurred yet ..:)
[20:35]<gdaniels> ordering, etc
[20:36]<gdaniels> one thing we need to decide is what kind of state
model we want for handlers in Axis2
[20:36]<sanjiva> doesn't stateless work?? I like that model ;-)
[20:36]<gdaniels> Axis has scopes for handlers just like for service
objects - request, application, session
[20:36]<Deepal> sir did u go thoruh the mails abt pahse handers
[20:36]<gdaniels> sanjiva: it does, but the other patterns can be very handy.
[20:37]<gdaniels> we could decide to just do stateless and keep all
state external if we want
[20:37]<sanjiva> other patterns?
[20:37]<sanjiva> I prefer the keep state external approach because of
scalability, perf and ease of arch/impl
[20:37]<gdaniels> yeah, in Axis when you name a handler and then
re-use it elsewhere you get the SAME object
[20:37]<sanjiva> "KISS" @ work
[20:37]<sanjiva> across all services or per invocation?
[20:37]<Srinath> yap I am +1 for statelss too
[20:38]<gdaniels> per invo, but you can also set it to application and
it's a singleton
[20:38]<gdaniels> I'm ok with stateless, but we need to make sure that
the options bag for each handler is correctly available to
getOption/setOption
[20:38]<sanjiva> ah scope=app or scope=session kind of thing for handlers too?
[20:38]<gdaniels> sanjiva: yep
[20:38]<Ajith> since handlers are stateless it would not matter
[20:39]<sanjiva> Yes handlers should get the message context to which
u can set stuff by name/value pairs .. is that what u mean glen?
[20:39]<gdaniels> re: options, I mean when you deploy <handler
name="foo"><parameter name="p1" value="5"/></handler>
[20:39]<Srinath> we can keep everything in message Ctx .. give
differant scope accsess e.g. Gloabl ctx, sessionctx,MessageCtx
[20:39]<gdaniels> getOption("p1") in that 
[20:39]<gdaniels> handler should work
[20:40]<sanjiva> Srinath: right .. in addition to message-level
context there's clearly context of the service associated per
"session" and maybe even globally across all sessions. That's like the
servlet state model .. which IMO we should follow because that's
proven and scales well and is easy for users
[20:41]<sanjiva> (after all it was copied frm the msft mode in ASPs ;-))
[20:41]<sanjiva> s/mode/model/
[20:41]<sanjiva> glen: +1
[20:41]<sanjiva> glen: that's basically the "handler context" ...
which the handler should be able to query and access as needed (and
maybe store in the session context and modify while running for
example)
[20:42]<gdaniels> sanjiva: yes exactly
[20:42]<sanjiva> cool .. so does anyone want to dissent the agreement
that handlers are stateless with the behaviour we've discussed?
[20:43]<gdaniels> no objections, motion carried :)
[20:43]<Srinath> :) 
[20:43]<Deepal> glen :)
[20:43]<Chinthaka> :)
[20:43]<Ajith> :D
[20:43]<sanjiva> Glen's been in too many standards meetings these days ;-)
[20:44]<gdaniels> heh - that'd be funnier if it wasn't true! :)
[20:44]<Srinath> yap :D:D
[20:44]<Ajith> ;D
[20:44]<sanjiva> ok so where were u guys on phase stuff?
[20:45]  *** _chris_ quit FreeNode : Remote closed the connection
[20:45]<Deepal> wt realy implies by before and after
[20:45]<gdaniels> I think we've got the basics down, we were talking
about deployment expressivity for handlers
[20:45]<gdaniels> how much you can say, how hard will it be to
implement and keep everything coherent, etc
[20:45]<Deepal> is taht hander or pahse or both
[20:45]<Deepal> sorry phase
[20:46]<Deepal> handler not hander
[20:46]<gdaniels> Deepal is saying that we were wondering if you can
deploy "before" and "after" a given Phase, a given Handler, or both...
[20:46]<sanjiva> I suggest KISS for now at least .. 
[20:46]<sanjiva> what's the minimal amount we need??
[20:46]<gdaniels> I agree - for the first model, we probably don't
even need before and after
[20:47]<sanjiva> deploy into a phase without ordering within a phase
is absolutely needed I guess
[20:47]<Deepal> glen : )
[20:47]<Srinath> yes I like only pahses there:)
[20:47]<gdaniels> just "in this phase", "first in this phase", "last
in this phase"
[20:47]<sanjiva> maybe first is also useful (for security)
[20:47]<gdaniels> ya
[20:47]<sanjiva> "last in this phase" is prolly not needed for now but
doing that if we're doing "first" should be easy ..
[20:47]<sanjiva> I suggest we stop at that rather than doing "before
X" and "after X" type stuff
[20:47]<sanjiva> let's do those when someone has a need for it!
[20:48]<gdaniels> right
[20:48]<sanjiva> Deepal what do u think?
[20:48]<Deepal> cool
[20:48]<sanjiva> what about the phases themselves?
[20:49]<sanjiva> named by URI yes?
[20:49]<Srinath> and ordered at the server.xml
[20:49]<Deepal> i didnt get u sir
[20:49]<sanjiva> BTW I suggest we *not* parse URI strings into
java.net.URI classes .. I have evidence that that's *very, very* slow.
We can keep them as strings and parse into java.net.URI only if
needed!
[20:50]<Srinath> shall we try give exaple to phases ...
[20:50]<sanjiva> Sorry Deepal - I mean hav we agreed to name phases by
URIs? I think we did at the mtg but its been a while :)
[20:50]<Srinath> e.g.is aythentication is a phase?
[20:50]<gdaniels> sanjiva: ok to Strings from me
[20:50]<gdaniels> in fact I'm not sure I see a need for URIs
[20:50]<sanjiva> Srinath: what's the list of phases you have in mind
for a start?
[20:50]<sanjiva> glen: +1!
[20:50]<gdaniels> "authentication", "dispatch", etc
[20:51]<Srinath> Authentication, Encryption .. dipatch..
[20:51]<gdaniels> I use Strings in my example/toy code
[20:51]<sanjiva> we can still tell users to name them via URI
formatted strings .. just makes it scalable
[20:51]<Srinath> one or more loggin pahses, RM
[20:51]  *** Essington joined #apache-axis
[20:51]<sanjiva> oh I was thinking much simpler than that:
"transport", "global", "service" for a start!!!
[20:51]<sanjiva> That'll give axis1 level function immediately
[20:51]<gdaniels> those are in my model too
[20:52]<gdaniels> though simplistically for now
[20:52]<FR^2> Hi Essington 
[20:52]<Srinath> are service/golbal..ect are pahses ?
[20:52]<Essington> howdy
[20:52]<sanjiva> "authentication" is a logical phase right? I mean
that that could've been called "potato' and it makes no diff to the
engine right??
[20:53]<sanjiva> Srinath: yes! Why not?? There's nothing 'special'
about them except that the ordering is burnt into the engine .. and
other phases have to fit relative to that
[20:53]<gdaniels> right
[20:53]<gdaniels> although!
[20:53]<Srinath> yes sir but where the more specifc one fit in .. as sub phases?
[20:53]<Srinath> specific ones - authentication!
[20:53]<gdaniels> in my impl, a phase is associated with a Phase
object... and that has specific preconditions and postconditions
(optionally)
[20:53]<gdaniels> so "Dispatch" == phases.DispatchPhase, which has a
postcondition of making sure the service is set in the MC
[20:54]<sanjiva> Glen: but how does the engine know that "Dispatch"
should be run after transport and not before?
[20:54]<sanjiva> We can't keep reevaluating all the pre-conds obviously
[20:54]<gdaniels> that's a deployment thing
[20:54]<Deepal> I thnk thats on server.xml 
[20:54]<gdaniels> you evaluate the precondition on entry to the phase,
and the postcondition on exit
[20:54]<gdaniels> once each
[20:55]<Srinath> yap geln: but where the dispatch pahse fit it ?
inside .. outside service/transport!
[20:55]<sanjiva> That'll be like a rule-based engine for phases ..
whcih woudl be cool (and very powerful) but damned slow for the
general case
[20:55]<gdaniels> they're not invariants :)
[20:55]<gdaniels> sanjiva: I don't think it'll be slow, since many
Phases won't use a specific subclass at all.  Just the ones that need
it.
[20:56]<gdaniels> Srinath: don't think inside/outside, think before/after
[20:56]<gdaniels> Dispatch is the last thing before the Service
[20:56]<sanjiva> so glen: I deploy a handler for phase "Dispatch" yes?
And that phase is listed in the something.config to tell the server
where that goes relative to the rest of the phases??
[20:56]<gdaniels> right, although that one might be unchangeable since
it's an engine thing
[20:57]<gdaniels> (you can deploy stuff before/after it, but not take it out)
[20:57]<Srinath> glen:that mean the service/trasport/gobal do not cover evrythig
[20:57]<gdaniels> correct
[20:58]<gdaniels> incoming msg goes transport, global, dispatch,
service, I think
[20:58]<sanjiva> let's be precise: for now let's say there's a
<phaseOrder> element in engine.config say: <phaseOrder><phase
name="uri1"/> ... </phase name="urin"/></phaseOrder>
[20:59]<sanjiva> and we have special uris for transport/global/service
which are constants
[20:59]<Srinath> cool .. amy be we need some conditions like user can
not put thing before global phase ect
[20:59]<gdaniels> outgoing msg goes service, global, transport for now
[20:59]<gdaniels> Srinath: yes
[20:59]<sanjiva> and the user cannot change that order .. i.e., the
default phaseOrder for input is: transport, global, service and the
reverse for output
[21:00]<Srinath> yes .. user can put after or before service as appropriatly
[21:01]<sanjiva> right, I guess we have to be careful to maek sure the
built-in phases are as "small" or "narrow" as possible ..otherwise
we're going to need hiearchical phases to enable maximum flexibility
which would be very bad
[21:01]<gdaniels> sanjiva: +1
[21:02]<gdaniels> ok, it's 7AM here, and I need to hop in the shower
and get ready to head south
[21:03]<gdaniels> anything else to discuss, or shall we adjourn the
official part of the chat for this week?
[21:03]<sanjiva> Ajith: I just sent a reply to your OM note to the axis-dev list
[21:03]<sanjiva> Glen: +1 .. see u in a few hrs!
[21:03]<Srinath> we got to go too .. I think
[21:03]<sanjiva> (let's try to spend some whiteboard time today or
tomorrow on axis2 ..)
[21:04]<sanjiva> good nite guys!
[21:04]<Chinthaka> wait,
[21:04]<gdaniels> sanjiva: +1!
[21:04]<sanjiva> waiting :)
[21:04]<Chinthaka> when is the next week chat
[21:04]<Chinthaka> I mean the time
[21:04]<gdaniels> next week :)
[21:04]<gdaniels> oh :)
[21:04]<Chinthaka> in the morning ? :D
[21:04]<gdaniels> are we switching to the other time?
[21:04]<gdaniels> 10PM EST, 9AM Sri Lanka?
[21:04]<Chinthaka> yeah
[21:05]<Chinthaka> if u have no probs in that
[21:05]<sanjiva> oh yeah .. i can't do 9am eastern :-( ... have to be
at ICSOC (www.icsoc.org) introducing adam bosworth ..
[21:05]<sanjiva> 10pm eastern may work for me!
[21:05]<gdaniels> cool-o
[21:05]<sanjiva> ok! glen will u post the log pls? 
[21:05]<sanjiva> (no alek today)
[21:05]<gdaniels> I'll send reminder mail to axis-dev (and get that
cron job going)
[21:05]<Ajith> I have the logs too
[21:05]<gdaniels> sanjiva: ya
[21:05]<gdaniels> I got it this wk, Ajith
[21:05]<Ajith> I can post them if you guys want to
[21:05]<Ajith> ok cool
[21:05]<Chinthaka> so see u all next week 10PM EST, 9AM Sri Lanka
[21:06]<gdaniels> yup!
[21:06]<sanjiva> ok bye all!
[21:06]<gdaniels> bye for now
[21:06]<Chinthaka> byee all
[21:06]<Deepal> bye all
[21:06]  *** Chinthaka quit FreeNode : 
[21:06]<Srinath> bye all
[21:06]  *** gdaniels quit FreeNode : 
[21:06]  *** Srinath quit FreeNode : "Client Exiting"

ChatAgenda/20041110/ChatLog (last edited 2009-09-20 22:48:51 by localhost)