axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: [axis2] Improvements to Service life cycle in handling
Date Sat, 16 Sep 2006 18:57:38 GMT
Sanjiva,

How about this? We define the interface, If people want to use it,
they can. But our code will be smart enough to reflectively look for
the method+parameters and call it even if the class does not implement
the interface. An interface is good for documenting the capabilities
in a easy to understand form for our users.

-- dims

On 9/16/06, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
> (Deepal you forgot the [axis2] on the subject! For others who missed the
> rest of the thread; please go look in your axis-dev folder.)
>
> I'm +1 for doing this. ServiceLifecycle is still not the right name IMO
> for the features it has- it should be ServiceSessionLifecycle: what its
> doing is allowing you to be notified when the session is inited and
> destroyed and also when an operation context is created within that
> session (which happens multiple times within a service session). So its
> even more than ServiceSessionLifecycle- its that plus operation context
> notification.
>
> I'm very uncomfortable with calling the other interface Service. What
> its really doing is notifying the service impl logic when the service is
> inited/destroyed. So its really ServiceLifecycle.
>
> How about this- rather than putting these methods into an interface and
> asking people to implement them, let's have these methods documented and
> then reflectively call them if they're there. The advantage of this
> approach is that it can work even for non-Java services. Suppose a
> service is implemented in JavaScript or Groovy- we can let that message
> receiver do whatever it needs to do the right thing. Having a Java
> interface name is Java-specific.
>
> Performance-wise, the startup(AxisService,ConfigurationContext (I
> presume)) and shutdown() are only called on loading/shutdown, the
> init(ServiceContext)/destroy(ServiceContext) is only called once per
> session. and setOperationContext is the only one that's costly because
> we'd have to reflect to check whether the method is there and only call
> if its there. (Catching the exception is more costly!)
>
> So, my proposal would be to document these methods and invoke them at
> the right time if they're there. No interfaces.
>
> Sanjiva.
>
> On Fri, 2006-09-15 at 09:29 -0400, Tony Dean wrote:
> > Can we fully document the logical semantics behind each method?
> >
> > init(ServiceContext) - To me this use to mean application init.  Now it means session
init.  However, when running scope="Application", it is analogous to application init since
you will only have one session;  but, still probably not appropriate to think in those terms.
> >
> > How should an application use this method?  A session use-case would be nice.
> >
> > destroy(ServiceContext) - inverse of init()
> > Use-case?
> >
> > setOperationContext(OperationContext) - per call.  The messageContext can be obtained
to gain per call instance information.
> >
> > StartUp() - one time initialization... DB connections etc...
> > Shutdown() - inverse of StartUp()
> >
> > Any more insight or corrections to pattern usage would be grateful...
> >
> > Thanks.
> >
> > -----Original Message-----
> > From: robert lazarski [mailto:robertlazarski@gmail.com]
> > Sent: Friday, September 15, 2006 8:49 AM
> > To: axis-dev@ws.apache.org
> > Subject: Re: Improvements to Service life cycle in handling
> >
> > That makes sense to me. I've been using startUp() and it doesn't really fit with
the other methods of the interface in its current form. +1 for 1.1 since its interface changes
and it'd be better to do it now.
> >
> > One question: Currently you need this in services.xml to get startUp() to invoke:
> >
> > <parameter name="load-on-startup" locked="false">true</parameter>
> >
> > I plan on testing this when its ready ... since the spring tutorial depends on it
... so I thought I'd ask if the services.xml param will remain the same.
> >
> > Thanks,
> > Robert
> >
> > On 9/14/06, Deepal Jayasinghe <deepal@opensource.lk> wrote:
> > > Hi All;
> > >
> > > Currently we have an interface called Service and which has few
> > > methods that are used to manage session (or else user can add those
> > > method into service impl class w.o implementing the interface). And
> > > that interface has the following methods ;
> > >
> > > - startUp
> > > - init
> > > - setOperationContext
> > > - destroy
> > >
> > > Three of them are for managing service life cycle ;
> > > - init - will be called when the session start
> > > - setOperationContext - immediately before calling actual java method
> > > - destroy - will be call when the session finishes
> > >
> > > Remember all those method work if and only if you use Axis2 default
> > > message receiver or you code gen.
> > >
> > > The method startUp is not session related method , which is useful
> > > when you want to initialize database connections , create thread etc
> > > ... at the time when you deploy the service. In the mean time
> > > interface name Service is bit confusing to me AFAIK it should be
> > > ServiceLifeCycle. And having method like startUp in that interface confuses
the users.
> > >
> > > So how about the following changes ;
> > > - Rename Service interface into ServiceLifeCycle
> > > - Then remove startUp method from that interface.
> > >
> > > There should be a some other interface (like Module interface) and
> > > which should be optional as well , to have the method startUp. If
> > > someone want to open DB connection or anything at the time of service
> > > deploying , then he need to implement that interface (and for me which
> > > is identical to Module interface). So with this change service element
> > > inside the services.xml will be change to following
> > >
> > > <service name="foo" *class="implementation class of the interface "*>
> > > <parameter name="ServiceClass">ServiceClass</parameter>
> > > </service>
> > >
> > > Here the class attribute is optional , so if someone want to have
> > > loadonStartup feature then he need to implement the Service interface
> > > (new one) and put the impl name as the class attribute. This is very
> > > useful if your service implementation class is not java (if you are
> > > writing a groovy serice).
> > >
> > > So new Service interface will be look like follows; public interface
> > > Service{ //will be called when service is deployed public void
> > > startUp(ConfigurationContext configctx, AxisService service); //will
> > > be called when Axis2 server showdown or when service removed from the
> > > system public void shutDown(ConfigurationContext configctx,
> > > AxisService service); }
> > >
> > > And ServiceLifeCycle interface will look like below;
> > >
> > > public interface ServiceLifeCycle {
> > > public void init(ServiceContext sc);
> > > public void setOperationContext(OperationContext operationContext);
> > > void destroy(ServiceContext sc); }
> > >
> > >
> > > I am +1 on doing this for Axis2 1.1 :)
> > >
> > > Suggestions ........
> > >
> > > Thanks
> > > Deepal
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>


-- 
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message