axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <>
Subject [Axis2] Service lifecycle management and How the current scoping mechanism can be improved
Date Wed, 05 Apr 2006 20:21:55 GMT
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

  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.



View raw message