Matthew Lovett wrote:
> Aleksander Slominski <[EMAIL PROTECTED]> wrote on 02/08/2006 13:42:25:
>
>   
>> hi,
>>
>> one way to get around this problem and allow for easy load balancing
>> is to allow serialize context into XML - this is really handy when 
>> you need to move processing to another node [1] or just restart 
>> processing in case of RM.
>>
>> best,
>>
>> alek
>> [1] http://www.extreme.indiana.edu/labpubs.html#lifang:den:gw2005
>> Liang Fang, Aleksander Slominski, and Dennis Gannon. Web Services 
>> Security and Load Balancing in Grid Environment.
>>
>>     
>
> Hi Aleksander,
>
> The debate isn't about the format of the saved data (be it XML, comma 
> separated, or some proprietary form). The debate is about which pieces of 
> state should be saved, and how the code helps or hinders discovery of that 
> state.
>   
they are both very much related: what you save and how you save it - i
think that using built-in java serialization is not the best way to do
it as the most of information saved will be XML (as most of it is XML
message and its decorations)
> OO design suggests that the owner of the state (e.g. the object in 
> question) knows more about the state then anyone else, and should provide 
> methods to allow others to call save/restore processing. The current 
> Sandesha persistent storage keeps a separate class, which 'knows' what 
> state matters, and persists it itself. Obviously that is more fragile, and 
> I think it really runs into trouble when there are 3rd party modules (e.g. 
> not core axis ones) in the processing chains. Of course, 90% of the time 
> the 3rd party modules run before Sandesha outbound, and after Sandesha 
> inbound, so they are unaffected. However, a 3rd party security module is 
> all out of luck!
>   
yes - all modules need to contribute and say what they want to save by
storing it in message context and marking as "persistable" in some way -
runtime (axis2) should take care of persisting and then restoring
message context when a message is to be re-injected.
> In addition, the class that 'knows' which state to save doesn't seem to be 
> in the apache repository, so anyone creating another persistent store 
> needs to duplicate its logic. If we defined a proper mechanism along the 
> lines I mentioned earlier then we would be able to reuse the code.
>   
yes - clearly the problem requires to have it solved on higher level so
solution can be shared by sandesha with other axis  modules ...

best,

alek

-- 
The best way to predict the future is to invent it - Alan Kay


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to