Hi All,
Currently we have { application, request (default), soap-session and transport-session } as the scopes.
I think it's not correct to combine life cycle management and session strategy using this scoping mechanism.
A). The scope should not be used to determine a session mgt strategy. Session mgt should be independent of scoping and life cycle mgt
1.) For performance reasons
2.) from a Scalability POV
3.) from a management POV
B) Web Services shouldn't manage a conversational state explicitly as it defeats the purpose of "Web Services being stateless"
Instead they should leverage a session to carry simple state and/or persist operational data to a back end at the end of every request.
The web service logic should be purely stateless where it doesn't assume any conversational state. Which means,
That the web service container (Axis2) should be able to serve service instances from any of the strategies below.
1.) Create a new instance for each request
2.) Serve from a pool of "n" existing instances ( where n=1.....m)
C) I think our life cycle management should be more complex than just saying Application-scope and Request-scope from a Scalability and HA POV.
We need something in the middle as well. We currently have
A.) Application scope = One Service instance lives as long as application is there
B.) Request scope = A new instance is created for every request
How about another strategy where we maintain several instance in a pool where we can serve clients during a high traffic scenario.
The above 2 cases will not scale very well in such a situation. Lets assume we have 10,000 request for a given service in 5 mins.
1.) In case (A) we will be queuing requests as we have only one single instance - not good
2.) In case (B) we will be creating 10,000 instance within 5 mins and discarding them - not good either
Both cases above are not utilizing resources effectively.
If we can have another option where we have a pool of several instances then we can serve those client using a mix of those two strategies. The pool can shrink and grow depending on the demand and have a upper and lower boundary.
So I propose that we,
A) drop soap-session-scope and transport-session scope (as they are session mgt strategies and not instance/scoping mgt strategies)
B) add another scope where we can denote maintaining a pool of instances instead one or nothing.
If the current naming convention/terminology is not good enough we can come up with something thats agreeable to all, to clearly idenfify the 3 scoping mechanisms.
Regards,
Rajith.
