axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: [axis2] Pinging capability to services deployed in Axis2
Date Tue, 13 Feb 2007 02:16:00 GMT
+1 Paul. I don't see why we shouldn't define a way for the system to
give the best possible answer. Sometimes all it can do is give a module
level answer but if the MR and the service cooperate you can give a much
better answer.

This does not bother JAX-WS services who can't be bothered to implement
this new interface. (As they're standards based maybe .. but then we're
talking about the Axis2 JAX-WS impl; so if it wants to be pingable I
imagine it can implement this interface.) 

Paul, I'd s/PingableMR/Pingable/. That's more consistent with the same
interface being implemented by an MR and by a service.

Sanjiva.

On Mon, 2007-02-12 at 19:35 +0000, Paul Fremantle wrote:
> Bill
> 
> If that is your concern, then we should define a clear semantic that
> users can implement with ping. I don't think its that difficult.
> 
> If you really want to make sure there is a consistent interface, then
> we can return a value that identifies what level of ping succeeded:
> 
> 0 - ping failed
> 1 - ping worked at module level
> 2 - ping worked at MR level, plus module level
> 3 - ping worked at service level, MR and module level.
> 
> Paul
> 
> 
> 
> On 2/12/07, Bill Nagy <nagy@watson.ibm.com> wrote:
> > Hi Paul,
> >
> > I'm disagreeing with (2) and (3) (and was agreeing with (1).)  My
> > problem is that the semantics associated with the response to the ping
> > are not captured anywhere and may, in fact, vary between services --
> > i.e. somebody accessing the ping service has no idea what the ping
> > response actually indicates.  If the ping is implemented solely as a
> > module, without any special hooks into MessageReceivers etc., then every
> > ping to a service indicates that the server is aware of the service and
> > is able to handle requests for it.  If a service wants to provide
> > something more specific, then that ability should be explicit within its
> > interface and a user should be expected to consult the service for the
> > extended semantics.
> >
> > If the deployment code wants to do more checking in each case, before it
> > allows a service to be deployed, I'm fine with that.  I'm not OK with a
> > service (which requires changes to the core interfaces) being defined
> > over the entire runtime that behaves in an inconsistent fashion.
> >
> > -Bill
> >
> > On Mon, 2007-02-12 at 14:40 +0000, Paul Fremantle wrote:
> > > Bill
> > >
> > > Maybe I misunderstood the discussion, but I thought we had the
> > > following approach in mind.
> > >
> > > 1) Implement a ping module. This does its best to let you know if the
> > > service is up.
> > > 2) Add a new interface (e.g. PingableMR) that MR's may implement. This
> > > allows the ping module to ask the MR if the service is up. (better
> > > than just the module's answer). For example the MR may try to new up
> > > an instance of the Service class (if that is appropriate) to ensure
> > > classloading is working.
> > > 3) The MR that implements the PingableMR interface can see if the
> > > service implements the PingableService interface. If this is the case
> > > then the MR will call that method. This will allow the service itself
> > > to test things (such as connections to databases, classloading,
> > > whatever). This is the best test.
> > >
> > > Unless you deploy the Ping module then none of this is exposed.
> > >
> > > Paul
> > >
> > > On 2/12/07, Bill Nagy <nagy@watson.ibm.com> wrote:
> > > > [I'm a little late to the conversation but anyways...]
> > > >
> > > > I vote against extending the MessageReceiver interface -- unless you go
> > > > to the service itself (i.e. actually invoke part of its logic,) you're
> > > > going to end up with responses whose meanings you can't interpret (e.g.
> > > > "This service said that it was up, but it's using the Axis2 programming
> > > > model so that means ..., and this service said that it was up, but it's
> > > > using the JAX-WS programming model so that means ..., and this service
> > > > said that it was up, but I have no idea what it's using so....)  If you
> > > > want true service status, then implement that as part of your exposed
> > > > interface.
> > > >
> > > > On the other hand, I think that implementing 'ping' as a module that
> > > > exposes a 'ping' operation is a fine idea; what you would get is a
> > > > consistent answer -- whether or not the service is 'available' from the
> > > > runtime's perspective.  That's what the pinging a machine's network
> > > > interface gives you -- the answer to whether or not the pinged interface
> > > > is active.
> > > >
> > > > -Bill
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> >
> >
> 
> 
-- 
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/


---------------------------------------------------------------------
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