Chamikara, Thanks for your questions. My responses are below and are delimited with <amr>text</amr>.
1. Serialization of parent contexts Does the serialization of parents repeat for every message context or do they get shared. If they do not I guess we hv to find out a way to share them. Otherwise it will be a big waste of the storage. <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> 2. ConfigurationContext I'm not sure on how the information in the ConfigurationContext will be serialized. You haven't mentioned in the list of contexts that get saved with the MessageContext. But this may also contain useful runtime data which may be needed by the entity that uses the MessageContext. <amr> The ConfigurationContext object is not currently saved with the MessageContext object graph. The restored MessageContext gets an active ConfigurationContext from the environment where the restoration of the MessageContext takes place. If the runtime data in the ConfigurationContext object needs to be preserved for the MessageContext, then this work would need to be added to the current implementation. So far, in testing the current implementation of the save/restore of the MessageContext, it hasn't been a problem - although it could be a consideration for more complex application environments. Any advice on this would be appreciated. </amr> 3. What actually happens in the 'msgContext2.activate(configurationContext)' method. <amr> Since only a subset of the MessageContext object graph is saved during serialization, the deserialization of a saved MessageContext only reconstitutes a subset of the MessageContext object graph. In order to re-establish the full MessageContext object graph, the restored MessageContext object needs to be called with an active ConfigurationContext object that is appropriate for the AxisEngine where the deserialization is taking place. This is the MessageContext.activate(ConfigurationContext configCtx) method. The MessageContext.activate() method uses some metadata that was saved/restored to re-establish the links to the appropriate Axis* objects. The metadata typically corresponds to the name associated with the Axis* object. The MessageContext.activate() also handles reconciling the phase/handler chain information that is kept in the MessageContext object. </amr> 4. As a whole your aproach is on making MessageContext implement Externalizable right ? <amr> Yes, the java.io.Externalizable interface provides flexibility to customize what is saved and how it is restored, which is needed to handle the complex object graph associated with a MessageContext. The java.io.Serializable interface is better for a simple object or for an object that has a simpler object graph. </amr> 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> Ann WebSphere Development, Web Services Engine IBM 11501 Burnet Rd IZip 9035G021 Austin, TX 78758 (512)838-9438 TL 678-9438 Lotus Notes: Ann Robinson/Austin/[EMAIL PROTECTED] Internet: robinsona @ us.ibm.com
