axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Nagy <>
Subject Re: [axis2] Pinging capability to services deployed in Axis2
Date Mon, 12 Feb 2007 17:39:34 GMT
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.


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 <> 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:
> > For additional commands, e-mail:
> >
> >

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message