axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject [Axis2] Chat log 2005-05-11
Date Wed, 11 May 2005 15:43:58 GMT
SUMMARY : Talked about descriptors and contexts, per Sanjiva's message. 
  Naming, functionality, etc...


Session Start: Wed May 11 08:12:50 2005
Session Ident: #apache-axis
[08:12] * Now talking in #apache-axis
[08:12] * Topic is 'Weekly Axis2 IRC Chat'
[08:12] * Set by gdaniels on Wed May 04 22:01:46
[08:13] <Deepal> hi Glen
[08:13] <gdaniels> hi all (sorry to be late)
[08:13] <Jaliya> Hi all,
[08:13] <Srinath> hi Glen
[08:13] <Ajith> we just about to start talking about M2
[08:13] <gdaniels> Excellent
[08:13] <Srinath> does the May 31 realsitic
[08:13] * sanjiva has joined #apache-axis
[08:14] <Srinath> ?
[08:14] <sanjiva> hi guys
[08:14] <Srinath> Hi Sir
[08:14] <sanjiva> sorry for some reason my connection was busted
[08:14] <Srinath> we were think of buzz you :)
[08:14] <gdaniels> hey Sanjiva (I feel better - you were a few seconds 
later than I was! :))
[08:15] <sanjiva> ah :-)
[08:15] <Srinath> where shall we start :)
[08:15] <gdaniels> You want to talk about the context stuff?
[08:16] <Deepal> not bad :)
[08:16] <Srinath> +1
[08:17] <sanjiva> did u get a chance to read thru my email?
[08:17] <gdaniels> So I'll throw this out - I'm not sure we should allow 
the different hierarchies to search each other
[08:17] <gdaniels> yup
[08:17] <gdaniels> i.e. how about if I ask for something in a Context, 
it goes up to SystemContext and that's it
[08:17] <sanjiva> the static and dynamic ones u mean?
[08:18] <gdaniels> I have to use a different API to search up the 
Operation/Service/etc hierarchy
[08:18] <gdaniels> ya
[08:18] <gdaniels> the reason is, I think they're useful for different 
purposes in a lot of cases
[08:18] <gdaniels> Also it'll slow the search
[08:18] <sanjiva> ok ..  the motivating scenario was (IIRC) to enable 
dynamic configuration of params like whether to engage RM
[08:19] <sanjiva> it will slow the search down .. I'm not hung up on it 
at all, but there seemed to be a very elegant motivation. Now I forget :-(.
[08:19] <gdaniels> Well, we could compromise - "pre-fill" the contexts 
with the info in the static descriptors
[08:20] <Srinath> mm .. yes it gives same result I guss
[08:20] <gdaniels> that still ends up mixing the data but it provides 
you with a shorter path
[08:20] <sanjiva> yes that would work
[08:20] <gdaniels> I'm still unsure about whether to mix or separate the 
data tho
[08:20] <gdaniels> I think we need a bunch of examples/use-cases to decide
[08:21] <sanjiva> what about the cost tho (extra memory)? I'm happy to 
leave them decoupled until we find very good motivations for auto 
searching up both trees
[08:21] <gdaniels> +1, I'm good with that
[08:21] <sanjiva> Srinath do u remember the motivation from our chat the 
other day?
[08:21] <sanjiva> in any case its easy to couple them together .. we can 
in fact leave the same API; just that if something isn't found up the 
context chain that's it
[08:21] <Srinath> but u mean last week?
[08:22] <gdaniels> In general I think there are going to be several 
places where we're less than 100% convinced that a particular design 
choice is the right one.  We should, IMO, point these out clearly in the 
README/docs and ask our early users to play with these areas and comment 
on them.
[08:22] <sanjiva> yes when we discussed the context stuff .. what was 
the motivation for crossing over and searching?
[08:22] <sanjiva> Glen: +1
[08:23] * Gayan has joined #apache-axis
[08:23] <sanjiva> So do u have a better name for SystemContext and 
[08:23] <sanjiva> I'd prefer Engineontext and AxisEngine but AxisEngine 
is already taken :)
[08:24] <Srinath> :)
[08:24] <gdaniels> If AxisSystem == the thing we were calling 
EngineConfiguration (the deployment registry, etc), then I think the 
important thing is that be called *Configuration
[08:25] <gdaniels> SystemConfiguration is OK, AxisConfiguration is better
[08:25] <gdaniels> Do we even need a "Context" thing at that level, though?
[08:25] <sanjiva> Hmmm .. .so MessageConfiguration, 
OperationConfiguration, ServiceConfiguration, AxisConfiguration?
[08:25] <sanjiva> I'm ok with that ..
[08:25] <gdaniels> no
[08:26] <gdaniels> I think it's not that uniform
[08:26] <gdaniels> operation metadata should definitely be 
AxisOperation, I think
[08:26] <gdaniels> same with AxisService
[08:26] <sanjiva> Ah so you're  saying Axis{Message,Operation,Service} 
and AxisConfiguration
[08:27] <Srinath> and ConfigurationContext?
[08:27] <gdaniels> yeah... but as I'm thinking about it, I'm wondering 
if "Descriptor" isn't better for some of this stuff
[08:27] <Deepal> wt do u mean by ConfigurationContext
[08:27] <gdaniels> in particular I am worried about people getting 
confused between AxisMessage and the actual runtime Message
[08:27] <Srinath> it is MessageContext
[08:27] <gdaniels> so MessageDescriptor or something might be better
[08:27] <sanjiva> glen: u mean {Message,Operation,Service}Descriptor? +1
[08:28] <Ajith> hmmm
[08:28] <Srinath> mmm....
[08:28] <gdaniels> Srinath: no, I mean the message within the MessageContext
[08:28] <Deepal> SOAPMessage ?
[08:28] <Srinath> glen:yep
[08:28] <gdaniels> the AxisMessage *describes* the message, and the 
SOAPMessage (ya) is the runtime message
[08:28] <gdaniels> it's not bad, but not obvious from the name either
[08:29] <gdaniels> MessageDescriptor is perhaps a little clearer
[08:29] <Srinath> I agree
[08:29] <Ajith> ok so the static info gets linto the descriptors
[08:29] <gdaniels> right
[08:29] <Ajith> and the runtime info in the contexts ?
[08:29] <sanjiva> Sounds good .. and MessageDescriptor is 1-1 with 
WSDLMessage too .. so that fits nicely
[08:30] <sanjiva> Ajith: Those can still be MessageContext etc.
[08:30] <gdaniels> and then the top level isn't quite the same, because 
the metadata is very different (IMHO), so that's 
[08:30] <Ajith> yes i get it
[08:30] <gdaniels> I'm not yet convinced we need ConfigurationContext though
[08:30] <Ajith> having xxdescriptor seems to "self document" the system  :)
[08:30] <sanjiva> Srinath can you explain your motivation for that 
please? IIRC you are the champion for that :-)
[08:30] <gdaniels> The reason we need things like OperationContext is 
that a given Axis instance might have lots of different copies of that 
one OperationDescriptor around... that's not really true at the top level
[08:31] <Srinath> let me take a use case RM
[08:33] * gdaniels listens for the sound of Srinath furiously typing
[08:33] <Srinath> if RM want to send a out a new message with diffratn 
configuration than the curretn one he can make a differant 
ConfigurationContext based on the same AxisConfiguration
[08:33] <Srinath> oops
[08:33] <gdaniels> what's the motivation for that, Srinath?
[08:34] <Srinath> basically the differnt ConfigurationContext may share 
same AxisConfiguration
[08:34] <Srinath> number of engines based on same DD info
[08:35] <gdaniels> but if they're different engines, they can just have 
different AxisConfiguration instances...
[08:35] <Srinath> I though AxisConfiguration is exact represntation of 
the DD
[08:36] <gdaniels> ah ok
[08:36] <gdaniels> got it
[08:36] <Srinath> and the ConfigurationContext has runtime things of it
[08:36] <gdaniels> hm
[08:36] <gdaniels> well, that is a reason to search both then
[08:37] <gdaniels> hm
[08:37] <Srinath> sure u can do with a one .. but with our XXContext and 
AxisXX it seems clean to have both
[08:37] <Srinath> leave AxisConfiguration as exact DD info
[08:38] <gdaniels> I'm not sure it's going to be easier with two objects 
at that level
[08:39] <gdaniels> one might be nicer, and it only writes itself back to 
the persistent store when asked to
[08:39] <gdaniels> but I'm really not sure, just thinking about it
[08:39] <gdaniels> ok either way for now
[08:39] <Srinath> actually second one is exactly the DDs .. so second 
one need not to be written
[08:39] <gdaniels> if we do two, we really do need a way to ask for 
options with a single API and search both, though
[08:40] <Srinath> yes .. serch up and sideway in the diagram
[08:40] <sanjiva> glen: true .. so we could cross left just at that 
level then
[08:40] <gdaniels> Srinath: you still want to be able to control 
serializing it - you don't want it writing itself every time you set an 
integer option...esp if you make a lot of changes
[08:41] <sanjiva> and if we find motivations like that we can do the 
same at other levels .. I think the uniform nature was done to keep 
everything very consistent
[08:41] <Srinath> glen: we have public void setProperty(Object key, 
Object value, boolean persistent) {
[08:41] <Srinath> and keet two map ..
[08:41] <Srinath> default is false
[08:42] <gdaniels> Srinath: You mean currently we have this API?  On 
which object(s)?
[08:42] <gdaniels> Or you're suggesting that's a way to make one object 
work and not two?
[08:42] <Srinath> all the contexts .. it is in AsbtractContext
[08:43] <gdaniels> So you're saying if I write a property to *Context 
and mark it persistent, it gets copied over to the *Descriptor?
[08:43] <sanjiva> wait .. u means if its in all the cntexts then if we 
store a messagecontext then only those that are explicitly requested to 
be persisted are persisted?
[08:43] <gdaniels> Not sure I like that...
[08:43] <Srinath> not only if u store it
[08:44] <Srinath> only when the Contexts are serialized
[08:44] <gdaniels> oh I see
[08:44] <sanjiva> I think we're mixing different usages of persistency 
.. one is persisting stuff back to wsdl/dd. the other is persisting 
contexts (for RM for example)
[08:44] <gdaniels> right - Srinath seems to be talking about serializing 
the contexts
[08:44] <Ajith> the persistent API is for RM like things
[08:44] <Srinath> yep
[08:44] <gdaniels> I was talking about writing back to the descriptors - 
sorry :)
[08:44] <Ajith> they do not go back to DD's at all
[08:45] <gdaniels> cool
[08:45] <sanjiva> yeah .. and do we actually have any model for 
persisting a *Descriptor?? I don't think so right?
[08:45] <gdaniels> sure we do
[08:45] <gdaniels> they live in the Configuration
[08:45] <sanjiva> ah yes .. so if u dump  out the configuration u get 
everything out
[08:45] <gdaniels> right
[08:46] <gdaniels> if I modify an AxisService and write the config, the 
service.xml will change
[08:46] <sanjiva> hmm wait. the configuration is from server.xml .. 
which gets the rest of the data from various service.xml's and various 
WSDLs, policies etc. etc. - so if u dump AxisConfiguration do we want it 
to write everything out?? That seems pretty drastic
[08:46] * Jaliya5712 has joined #apache-axis
[08:46] <Srinath> yep
[08:46] <gdaniels> if you dump AxisConfiguration it should write 
whatever's dirty
[08:47] * Jaliya5712 is now known as Nadana
[08:47] <sanjiva> hmmmmm ok. What worries me is that Axis2 code will be 
editing users's aar files basically
[08:47] <Srinath> glen it is AxisConfiguration actually a reposity
[08:47] <Srinath> can u wirte it out
[08:47] <Srinath> mean it has the class files ect
[08:47] <Deepal> I am not happy with taht if we
[08:47] <Srinath> do we need that?
[08:47] <Deepal> going to cahnge the service.xml and server.xml
[08:47] <Ajith> hmmm
[08:48] <Deepal> when we serialize
[08:48] <Ajith> I am not reallly keen on updating the descriptors
[08:48] <gdaniels> maybe not?
[08:48] <Deepal> we can serilize what ever run time data we want
[08:49] <Deepal> if it is RM what ever rm want
[08:49] <gdaniels> I do want to make sure we can deal with the 
"SimpleConfiguration" (from Axis1) case where you dynamically deploy 
stuff yourself at runtime...
[08:49] <gdaniels> In fact we need that for async ReplyTo's anyway
[08:49] <Srinath> but we do not need to write it out
[08:50] <Srinath> do we?
[08:50] <gdaniels> correct
[08:50] <sanjiva> Glen: +1 but that's sort of what AxisContext (or 
whatever the top level thing) gives us
[08:50] <gdaniels> The AxisContext/ConfigContext/whatever would also be 
a service repository?
[08:51] <Srinath> yes .. Service that is only at the AxisContext
[08:51] <gdaniels> I was thinking it was just for properties/options...
[08:51] <gdaniels> hm
[08:53] <Srinath> it has ServiceContext .. OperationContext ect ..
[08:53] <gdaniels> So essentially you're envisioning "ConfigContext 
implements DeploymentRegistry"....
[08:53] <Srinath> no but wrapping
[08:53] <Srinath> with XXContext s
[08:54] <Deepal> ConfigContext  has ref to Config
[08:54] <gdaniels> But when I'm looking for a service... I look somewhere
[08:54] <gdaniels> If you're saying that things like temporary service 
endpoints get deployed to ConfigContext, then I have to look there
[08:54] <gdaniels> (and it looks in Config if it doesn't find stuff locally)
[08:54] <gdaniels> yes?
[08:55] <Srinath> mm
[08:55] <Srinath> yes
[08:56] <gdaniels> SimpleConfiguration in Axis1 works that way - it *is* 
an EngineConfiguration, but it keeps a dynamic local list of stuff and 
then defers to a "real" FileConfiguration after it doesn't find things 
[08:56] <gdaniels> (actually it defers to any other EngineConfiguration 
you want so you could even stack them)
[08:56] <Srinath> yep
[08:57] <gdaniels> So if that's what we want I'm not sure "Context" is a 
good name for it
[08:57] <Srinath> but we are yet to define the life cycle of the 
ServiceContext clearly
[08:58] <gdaniels> hm - tell you what, I just got my BBQ grill going 
again last night, why don't you all come over for lunch and we'll do 
some whiteboarding? :)
[08:58] <Srinath> would love to
[08:58] <Srinath> :D
[08:59] <Deepal> +1
[09:00] <Srinath> glen:I think we can not handle the Asnyc service 
register if thesystem goes down and come back
[09:00] <Srinath> u r right
[09:00] <gdaniels> hm... yup
[09:00] <gdaniels> we need to deal with that, I think
[09:00] <Srinath> becouse we do the lookup based on the 
AxisConfiguration ...
[09:00] <Srinath> (I check the code)
[09:01] <Srinath> yes .. how about using a preedeplyed service for that
[09:01] <gdaniels> yup, we can do that
[09:01] <Srinath> CallBackService that corelated Messages to callbacks
[09:01] <Srinath> becouse writing the aar file agien is tricky
[09:01] <gdaniels> http://*:*/axis/services/reply/{STUFF}
[09:02] <Srinath> yes
[09:02] <gdaniels> Where {STUFF} is an encoded key to the correct operatoin
[09:02] <sanjiva> +1
[09:02] <Srinath> or me might able to use the relatesTo if it is there
[09:02] <gdaniels> you also have that same info in the WSA headers
[09:02] <gdaniels> ya :)
[09:02] <Srinath> me = we
[09:02] <Srinath> :)
[09:03] <Srinath> +1
[09:04] <Srinath> one problem ..then the reply message goes to diffrant 
service at the client side
[09:04] <Srinath> there may be trouble finding the mep context
[09:05] <gdaniels> ?
[09:05] <Srinath> What I mean is if request is send from foo service
[09:05] <sanjiva> we can encode whatever junk we need to make it work in 
[09:05] <Srinath> result is come to the relyto service
[09:05] <Srinath> reply service
[09:06] <Srinath> but actually both message belong to same service
[09:06] <gdaniels> right... and the reply service's purpose in life is 
to wake up the "real" service
[09:06] <gdaniels> no problem
[09:06] <sanjiva> However, I think we need to have the {STUFF} come 
after the normal URL of the service .. that makes it even clearer what 
the service is
[09:06] <gdaniels> the reply service is an "intermediary", basically
[09:06] <sanjiva> so http://*.*/axis/services/foo/reply/{STUFF}
[09:06] <Srinath> we migh have trouble finding MEPContext that message
[09:07] <sanjiva> MEPContext?
[09:07] <gdaniels> sanjiva: If you do that you need a different architecture
[09:07] <sanjiva> ??
[09:07] <gdaniels> since foo will be handling it's own replies
[09:07] <Srinath> OperationContext
[09:07] <gdaniels> and I'm not sure there's even going to be a "foo" at all
[09:08] <gdaniels> (this is a client we're talking about, which isn't 
always a service)
[09:08] <sanjiva> oh yes sorry
[09:08] <sanjiva> not much sleep last nite
[09:08] <Srinath> yes ..actully problem is opreration
[09:08] <gdaniels> Srinath: What are you worried about exactly?  I'm not 
getting it yet...
[09:08] <Srinath> we can add the old operation to reply service
[09:08] <sanjiva> Srinath: the OpContext can be found the same way as 
before .. use RelatesTo to find the original message and from that the 
[09:08] <gdaniels> reply "service" doesn't have any operations itself
[09:09] <gdaniels> in fact it doesn't really have a MessageReceiver
[09:09] <gdaniels> it just has handlers whose job is to send this 
message to the correct "real" place
[09:09] <sanjiva> Glen, we could actually do it thru a MessageReceiver 
.. its a bit special tho; it does the forwarding
[09:09] <Srinath> since we have the mepcontext in the engine context ..
[09:09] <Srinath> yes it will work
[09:10] <Srinath> I will check and get back if there are troubl
[09:10] <Srinath> e
[09:10] <gdaniels> you put the OperationContext in a map somewhere - 
could be in at the engine level, could be in the reply service itself... 
but yes, it's lookup-able
[09:10] <Srinath> if the map is global it is ok
[09:10] <gdaniels> sanjiva: sure, lots of ways it could work
[09:11] <sanjiva> I'd *love* to get to a point where *all* incoming 
messages are delivered thru a MessageReceiver .. no matter whether its a 
"request" or a "reply". That way we have a fully symmetric arch
[09:11] <Srinath> +27
[09:11] <Srinath> :D
[09:11] <Srinath> actually I belive we can do it
[09:11] <gdaniels> +0 - not convinced that's essential, but sure
[09:12] <Srinath> then if u r at J2EE continer .. servelt can act as the 
[09:12] <Srinath> !!
[09:12] <Srinath> think u r WS busnuss logic invoke a Async web service
[09:15] <Srinath> am I offline ? everyone silent
[09:15] <sanjiva> have to go guys ...
[09:16] <sanjiva> g'{nite,morning,afternoon}
[09:16] <gdaniels> yup, me too...
[09:16] <gdaniels> talk to you all soon
[09:16] <gdaniels> (time for breakfast)
[09:16] * gdaniels is now known as glen-away
[09:17] * Srinath_ has joined #apache-axis
[09:17] <Jaliya> bye all:)
[09:17] * Jaliya has left #apache-axis
[09:17] <Harshap> bye all
[09:17] * Harshap has quit IRC
[09:17] <saminda> Bye,,
[09:18] * saminda has left #apache-axis
[09:18] <Gayan> Bye all
[09:18] * Gayan has left #apache-axis
[09:18] <Srinath_> hey ppl are leaving
[09:18] <Srinath_> :)
[09:19] <Srinath_> I was disconnected
[09:19] <Srinath_> bye then

View raw message