axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sameera Madushan" <>
Subject Re: [axis2] Pinging capability to services deployed in Axs2
Date Fri, 09 Feb 2007 05:57:35 GMT
Hi all,

Here are the sample message formats for the ping request and ping response.

Ping Request

POST /axis2/services/SomeService HTTP/1.1
SOAPAction: "ping"      //SOAPAction  should be a unique one

<?xml version='1.0' encoding='UTF-8'?>
   <soapenv:Envelope xmlns:soapenv="">
      <soapenv:Header />
         <tns:pingRequest xmlns:tns="http://ping">

Ping Response

HTTP/1.1 200 OK

<?xml version='1.0' encoding='UTF-8'?>
   <soapenv:Envelope xmlns:soapenv="">
      <soapenv:Header />
         <tns:pingResponse xmlns:tns="http://ping">
                <tns:status>up or down</tns:status>    //Giving the simplest

If there are any other options please let me know.


On 2/9/07, Sanjiva Weerawarana <> wrote:
> On Thu, 2007-02-08 at 16:35 +1300, Dennis Sosnoski wrote:
> > +1
> >
> > This is a capability my clients have often wanted. I'm not sure I see
> > the need to do it at the MessageReceiver level, though. The approach
> > I've thought about is to use handlers. The handlers could not only
> The problem is that pinging at the handler level basically amounts to
> just asking "is there such a service?". Having it go to the message
> receiver allows the ping to be responded to based on more useful data-
> such as did the impl class or script or whatever load etc.. So its
> really a question of fidelity- yes some level of liveness checking can
> be done at a handler level but you get much improved info by getting the
> ping to the message receiver.
> > respond to a ping, but could also supply useful information about the
> > actual state of the service as part of the response. I'm thinking of
> > data along these lines:
> >
> >    1. Total number of requests processed in last minute/hour/day
> >    2. Number of Fault responses to these requests
> >    3. Number of non-Fault response to these requests
> >
> > Supplying this information would allow the client (or a coordinator, in
> > the case I'm interested in) to make somewhat intelligent decisions if
> > the service is technically running but inoperative due to internal
> failures.
> These are not what typically happens under the "ping" label .. you're
> talking about statistics type stuff. We have a module like that in WSAS
> and you're welcome to take it (and help improve it if you like!). See:
> (Everything there is under Apache license.)
> > The inbound handler could recognize the ping request and respond
> > directly, rather than sending the request through to the service
> > provider. Individual services could easily activate the ping service or
> > not, just by including the handlers in their configuration (or as a
> module).
> See above for why this is not enough IMO.
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation;
> Founder, Chairman & CEO; WSO2, Inc.;
> Director; Open Source Initiative;
> Member; Apache Software Foundation;
> Visiting Lecturer; University of Moratuwa;
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message