Hi, Sanjiva, Thanks for the comments. I have tagged your comments with <sanjiva>text</sanjiva> to keep the indentation from getting too deep and put my responses below your comments with the tags <amr2>text</amr2>. Ann
> <amr> > The save/restore of a MessageContext object hierarchy attempts to > reduce the duplication of parent-child objects in that MessageContext > object graph. The re-established MessageContext object graph keeps > the *Context objects to a single set and gets the Axis* objects > through the ConfigurationContext object associated with the AxisEngine > where the MessageContext was restored. So, the *Context objects are > unique across restored MessageContexts but the Axis* objects are > easily shared/re-used across restored MessageContexts. A future > refinement for the save/restore of the MessageContext is to find a way > to share *Context objects across restored MessageContexts. This is > actually a fairly small set of objects and involves the > OperationContext, ServiceContext, and ServiceGroupContext objects. > </amr> <sanjiva> Hmm. I don't think your approach will work if there's any serializable state the user has put into say ServiceContext and if that state gets modified by handlers after message reincarnation. There will be two different service contexts around and the "shared" value will no longer be shared. </sanjiva> <amr2> You have a good point. In particular, I think this would apply to properties that are set on the ServiceContext. I think that figuring out how to reconcile a restored ServiceContext with an existing ServiceContext would be worthwhile to add to the proposal. </amr2> > 5. How will this map to a environment where somebody wants to save the > MC in a database. For example Sandesha2 has a StorageManager inferace > which could be implemented by different storage mechanisms. How will > you support such a scenario with this. > > <amr> > The MessageContext is saved to an output stream, and the output stream > can be directed to a variety of mechanisms. A storage mechanism that > implements the Sandesha2 StorageManager interface could set up an > output stream that is appropriate for the target database, for > example, a byte array or a file. > </amr> <sanjiva> Isn't that rather weird?? Writing an object output stream to go to a database? Maybe its just me (and I don't know anything about databases so could easily be wrong). </sanjiva> <amr2> While I am not a database expert, I would expect that someone would use JDBC to access a database and then use an appropriate data structure to save to and retrieve from the database. </amr2> Ann WebSphere Development, Web Services Engine IBM 11501 Burnet Rd IZip 9035G021 Austin, TX 78758 (512)838-9438 TL 678-9438
