+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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- 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]
