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=" http://schemas.xmlsoap.org/soap/envelope/";> <soapenv:Header /> <soapenv:Body> <tns:pingRequest xmlns:tns="http://ping";> <tns:operationName>someOperationName</tns:operationName> </tns:pingRequest> </soapenv:Body> </soapenv:Envelope>0 Ping Response HTTP/1.1 200 OK .. <?xml version='1.0' encoding='UTF-8'?> <soapenv:Envelope xmlns:soapenv=" http://schemas.xmlsoap.org/soap/envelope/";> <soapenv:Header /> <soapenv:Body> <tns:pingResponse xmlns:tns="http://ping";> <tns:status>up or down</tns:status> //Giving the simplest response </tns:pingResponse> </soapenv:Body> </soapenv:Envelope> If there are any other options please let me know. Sameera On 2/9/07, Sanjiva Weerawarana <[EMAIL PROTECTED]> 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: http://wso2.org/repos/wso2/trunk/commons/statistics/ (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; 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
