Eran and Chamikara,
I located the example and had a looked at it. Good example indeed and so far has given me most understanding about situation.
You are adding a key/value pair to the SrvGrpCtx as you would put in a session object for ex HttpSession
msgContext.getServiceGroupContext().setProperty(Constants.CALCULATOR_PREVIOUS_KEY,Integer.toString(result));
next you retrive it a different method within the same service or different service like u would do from a session object.
next you retrive it a different method within the same service or different service like u would do from a session object.
String previousStr = (String) sgc.getProperty(Constants.CALCULATOR_PREVIOUS_KEY);
Ok, so you treat SrvGrpCtx as the session object to pass key/value pairs across multiple invocations within a ServiceGroup.
The following 3 big questions will figure out whether we need to look beyond ServiceGroupContexts for session mgt or not?
1. Now is this is limited to Services within a ServiceGroup, isnt it? for example if we have to access a service outside of this ServiceGroupContext the notion of a session will fail, am I correct?
2. How is this ServiceGroupContext lifecycle managed with respect to scope?? If session scope will it be removed from the ConfigurationCtx after a session is ended (removed by the client for ex. logout service ) OR timed out (removed without the involement of any service, but by the SessionManager as a housekeeping function)?
3. Is there a possibility of cross-contamination within the ServiceGroupContext across two simultaneous client sessions?
Regards,
Rajith.
On 1/19/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
Eran,Thanks a lot for the interest.
>>We have the SOAP session which is managed via service group context id
>>and application scopesYes I have a identified the SOAP session option based on input from Deepal & Srinath. But they have raised concerns about usign the service grp context ids and also about the client involement wrt to initiating the SOAP header using to identify the SOAP session.Btw I am not a SOAP expert (ramping up using Sanjiva's book :) ), so I may have not understood the implications of SOAP header fully.But I do belive that SOAP session is the way to go to provide an independent session mgt impl, but I need more help and inpput to figure out the concerns service grp context ids and the client code impact.
>>FYI : Chamikara wrote a nice Calculator example using SOAP session,
>>w/o depending on transport session.
Can u get Chamikara to have a go at this proposal based on his experiance with SOAP sessionBtw where can I get access to this example??>>BTW, proposal seems to have understood the problem. can you put this
>>up in the wiki as well.I am working on a doc regarding Scalability & HA wrt to Axis2, I was thinking about attaching something about this there as well.I was thinking about putting this doc under documentation within the main site. Sanjiva things it will attract more attention !!However the proposal can (rather should) be added to the wiki so everybody can have a go at it. Can provide link to the wiki#proposal from the clustering doc from the main site.
Hope we will get a prototype also ;-) .
I am actually working on a prototype on my Sanbox and will keep u updated on the progress.I am actually trying to provide clustering support to Axis2 using WADI, ActiveCluster ..etc (still evaluating),However I realized I first have to sort out the session problem, hence the proposalRegards,Rajith.
On 1/19/06, Eran Chinthaka <[EMAIL PROTECTED] > wrote:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Rajith,
I agree with all except for this.
Rajith Attapattu wrote:
>
>
> 2. The current Axis2 has no clear notion of a session. (Serveral
> ppl expressed this concern
> Currently two concepts exist. a) HttpSession based on cookies, if
> the Transport is http (the most popular)
>
> b) SOAP header for RM & Secure Conversations
>
We do have a notion of sessions which goes beyong transport sessions.
We have the SOAP session which is managed via service group context id
and application scopes. Please correct me if I am wrong.
I agree that we may not have a scalable and distributable session
management system, but for the time being we have session management
which goes a little beyond transport session.
FYI : Chamikara wrote a nice Calculator example using SOAP session,
w/o depending on transport session.
BTW, proposal seems to have understood the problem. can you put this
up in the wiki as well.
Hope we will get a prototype also ;-) .
- -- Chinthaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFDz7kFjON2uBzUhh8RApmGAJ9IoylogS0Eauzpo2axlbmffY5mqACfS3T0
mlPrJNPuRH2EwrlUpEtaSXE=
=pyFN
-----END PGP SIGNATURE-----
