OK, here's my $0.02: (1)I would argue that reliable delivery of messages is an integral part of a web services stack and therefore deserves special treatment in the core where necessary so long as it does not adversely affect processing when the reliability is achieved through other means (such as being inherent with a transport) or is not required. I believe that exposing a serialization/deserialization API as part of the MessageContext API is a part of this. If this API can't be used by other things, then we should try to make it better (See (3) below.)
(2)I will also argue that, following good design practices (e.g. encapsulation,) objects themselves should be in charge of persisting/restoring their state. Does this increase the amount of code within the objects? Sure. Does it make the objects harder for others to understand? Doubtful -- most of the relevant code is kept within a few methods. Does it make modifications to the object more convenient and less error prone? Certainly -- having all of the code in once place is much easier, although it still requires some degree of vigilance. It's far better to have each object delegate the tasks of serializing to each of its subordinate objects (i.e. fields) than to have a single block of code that understands how to serialize the entire graph -- something which may be impossible if some of the properties stored within the contexts are well encapsulated. (3)This is iterative development -- lets be real, there are a lot of things in Axis2 that don't work quite the way that one would think. I don't believe that anything should be held out simply because it doesn't address every possible usecase, so long as it doesn't break the rest of the system. While Ann's patch is undoubtedly not perfect and will continue to evolve, I do believe that it is a step in the right direction and should be committed. -Bill On Fri, 2006-12-22 at 04:49 +0530, Sanjiva Weerawarana wrote: > On Thu, 2006-12-21 at 11:14 -0600, Ann Robinson wrote: > > I have submitted an updated patch for the message context save/restore > > proposal (under JIRA axis2-1567). Now, when a message context is > > restored, it looks for existing ServiceContext and ServiceGroupContext > > objects to use in its object hierarchy. This means that a restored > > object graph for a MessageContext is made up of mostly existing > > *Context and Axis* objects. In other words, object re-use for the > > *Context and Axis* objects is maximized. And, when existing context > > object are re-used, any saved properties are merged into the existing > > objects. > > > > Just to summarize, when a message context is saved, its state is > > collected and saved, including: > > - the settings for various flags in the message context > > - properties associated with the message context (which are really > > contained in an Options object) > > - the actual message > > - where in the message processing the message is > > - meta data about the handlers associated with processing the message > > - meta data about the AxisOperation/AxisService/AxisServiceGroup > > associated with the message context > > - the OperationContext/ServiceContext/ServiceGroupContext associated > > with the message context > > As far as I can see none of this data is private to a message context; > so the answer to the question I asked earlier appears to be that this > code can perfectly well live in a utility class. > > > When a message context is restored, the message context object graph > > is re-built based on the information that was saved. If possible, > > existing objects are used from the engine where the message context is > > being restored. Names or IDs are used to find existing objects that > > correspond to their counterparts from the saved environment. Where > > existing objects are used, saved properties are merged into the > > existing objects. > > I'm confused. What do you mean by existing objects? A particular message > exchange lives within a particular service context. You can't just put > it back into some exiting object; it must go back into the corresponding > service context etc.. is that what you mean? If so how do you record the > ID of the service context object? Two different message contexts saved > during two save actions could refer to the same service context with > different state values of course. > > > The message context save/restore proposal is intended to benefit > > AXIS2. This proposal gives AXIS2 some functionality that allows AXIS2 > > to be used in more customer environments. > > > > I have indicated in previous postings that the prototype for the > > message context save/restore proposal has been used internally by IBM. > > This statement was not intended to divide the open source community > > along company lines but instead, to indicate that the prototype has > > been tested and reached a level of stability and that negative > > side-effects have been minimized. > > Absolutely. As I stated earlier, there's nothing wrong with providing > hooks that help people who build on top of Axis2. However, the concern I > have with this proposal is that its being proposed at a generic level > when what appears to be needed is a solution that works within the > constrained world of WS-RM. Unless I missed something, this same > proposal can live just fine as FooUtil.writeObject (MC, ..) instead of > mc.writeObject (..). I'd like an answer on why that's not possible. > > > I would really like to get this proposal at a point where it could be > > included in the AXIS2 1.2 release. What other technical or > > architectural issues need to be addressed? > > See above. > > Sanjiva. > -- > Sanjiva Weerawarana, Ph.D. > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ > Director; Open Source Initiative; http://www.opensource.org/ > Member; Apache Software Foundation; http://www.apache.org/ > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
