I'm confused Dennis .. are you *for* changing the message receiver
interface to have a ping() method? If not, how does the message receiver
receive the ping request?
Wait, are you suggesting that we modify the AbstractMessageReceiver
class to have this behavior built-in?
Sanjiva.
On Mon, 2007-02-12 at 12:08 +1300, Dennis Sosnoski wrote:
> The discussed approach was that the default message receiver
> implementation first loads the service class instance to make sure it
> loads properly. It next checks if the service class implements a
> Pingable interface. If the service class *does* implement the interface,
> the message receiver calls the method defined by that interface and just
> passes back whatever is returned. That allows service classes to easily
> implement their own ping handling. If the service class *does not*
> implement the interface, the message receiver just returns a successful
> ping response directly. If the message receiver can't load the service
> class for any reason, it returns a failure ping response.
>
> So in the case of a service implemented by a Java class a successful
> ping response says at a minimum that the service is ready to accept
> requests all the way through to the actual service class instance. If
> services choose to implement a "deeper" ping they can easily do so.
>
> I don't know how this would work for the javascript case - does the
> javascript get compiled to a class file, or is there some other way of
> checking the validity of the script?
>
> - Dennis
>
> Sanjiva Weerawarana wrote:
> > OK can you tell me how you'd implement service level ping?? Take the
> > following cases:
> > - service implemented by a java class
> > - service implemented by javascript
> >
> > Assume that in both cases the services have a flaw .. say class can't be
> > loaded and script has an error. The question is what "ping" gives you.
> > Is it just answering the question "is this service deployed"?
> >
> > Sanjiva.
> >
> > On Sun, 2007-02-11 at 08:38 +0000, Paul Fremantle wrote:
> >
> >> I agree with Dennis. I think operation-level ping is adding complexity
> >> for no great benefit. The service level ping seems perfect.
> >>
> >> Paul
> >>
> >> On 2/11/07, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
> >>
> >>> It still seems like overkill to me, but if people really want the
> >>> operation-based ping then sure, this sounds fine.
> >>>
> >>> I don't think ping is going to be a module, though. If the
> >>> implementation uses a method added to the MR classes, as we've been
> >>> discussing, I'd think the functionality would be core Axis2. There's
> >>> also the issue that modifying the MR classes still has an outstanding -1
> >>> from Nicholas Gallardo, I think.
> >>>
> >>> - Dennis
> >>>
> >>> Sanjiva Weerawarana wrote:
> >>>
> >>>> Even to find out whether the service as a whole is working, you need to
> >>>> be able to ping down to at least one MR. I'm fine with the ping module
> >>>> having a property that users can set that allows users to control which
> >>>> operations' MR's to contact. Something like
> >>>> <property name="pingOperations">a b c</property>
> >>>> We can also have "*" as a special value. This approach would solve your
> >>>> groups of operations issue as well.
> >>>>
> >>>> The question comes down to what the default is .. maybe we can default
> >>>> to "ping the first operation in the AxisService's list of operations"?
> >>>> That'll basically touch *some* operation and if the user wants more
> >>>> control they have it thru the property.
> >>>>
> >>>> Sanjiva.
> >>>>
> >>>> On Sun, 2007-02-11 at 10:26 +1300, Dennis Sosnoski wrote:
> >>>>
> >>>>
> >>>>> In my experience the individual operations of a service generally use
> >>>>> the same backend functions. This generally means that either all
> >>>>> operations are working properly, or nothing of any significance is
> >>>>> working properly. It's possible to do things differently, grouping a
> >>>>> bunch of unrelated functionality into a single service, but I have a
> >>>>> hard time understanding the benefit of doing this.
> >>>>>
> >>>>> If there *are* different groups of operations within the service, I'd
> >>>>> think it would make more sense to allow the user to define names for the
> >>>>> groups and pass that group name. So for instance, if someone combined
> >>>>> air, car, and hotel reservations in a single service while using
> >>>>> separate backend systems to process each type of reservation, they could
> >>>>> support ping("air"), ping("car"), and ping("hotel") for clients that
> >>>>> only needed one particular function.
> >>>>>
> >>>>> So I just don't see the point in taking this down to the operation
> >>>>> level. It seems to me that doing so adds a lot of complexity to the
> >>>>> handling of the ping without much added value.
> >>>>>
> >>>>> - Dennis
> >>>>>
> >>>>> Thilina Gunarathne wrote:
> >>>>>
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>>
> >>>>>>> I'm especially unclear about how this would work at the individual
> >>>>>>> operation level, which was also part of what was discussed. My memory
> >>>>>>> is
> >>>>>>> that there's (normally?) just one message receiver per MEP. So if the
> >>>>>>> intent is to offer a per-operation ping, I suppose you could pass the
> >>>>>>> operation name to the ping method. That seems somewhat ugly to me in
> >>>>>>> that the user code now has to be able to identify operations. Perhaps
> >>>>>>> it's better to instead have the ping only at the service level, where
> >>>>>>> it
> >>>>>>> can be more clearly defined.
> >>>>>>>
> >>>>>>>
> >>>>>> We can introduce "ping" in two levels.. The service level ping would
> >>>>>> ping message receivers belonging to each and every operation listed
> >>>>>> under that service. The operation level ping would ping just the given
> >>>>>> operation.. We assume a certain "ping" request as a service level ping
> >>>>>> whenever the operation name is missing in the body.. In this case we
> >>>>>> might need to think bit more about the response message structure..
> >>>>>>
> >>>>>> <complexType name="operationStatus">
> >>>>>> <complexContent>
> >>>>>> <restriction base="anyType">
> >>>>>> <xs:sequence>
> >>>>>> <xs:element name="status" type="xs:boolean"/>
> >>>>>> <xs:any minOccurs="0" maxOccurs="unbounded"
> >>>>>> namespace="##any"
> >>>>>> processContents="lax"/>
> >>>>>> </xs:sequence>
> >>>>>> <attribute name="operationName" type="string" />
> >>>>>> </restriction>
> >>>>>> </complexContent>
> >>>>>> </complexType>
> >>>>>>
> >>>>>> The return type can be an array of operationStatus type..
> >>>>>>
> >>>>>> Just my two cents :)..
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Thilina
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> This does mean that the ping() method would need to pass some form of
> >>>>>>> structured response back to the message receiver, rather than just a
> >>>>>>> boolean. Perhaps we could define a PingResponse class along these
> >>>>>>> lines
> >>>>>>> to make it easy:
> >>>>>>>
> >>>>>>> public class PingResponse {
> >>>>>>> private boolean up;
> >>>>>>>
> >>>>>>> public PingResponse(boolean up) {
> >>>>>>> this.up = up;
> >>>>>>> }
> >>>>>>>
> >>>>>>> public isUp() {
> >>>>>>> return up;
> >>>>>>> }
> >>>>>>>
> >>>>>>> public List getAddedElements() {
> >>>>>>> // user classes can override to return a list of OMElement
> >>>>>>> return Collections.EMPTY_LIST;
> >>>>>>> }
> >>>>>>> }
> >>>>>>>
> >>>>>>> I don't think the ping request really needs to be extensible, but
> >>>>>>> passing a String parameter is easy. That would allow the operation
> >>>>>>> name
> >>>>>>> to be passed as previously proposed by Sameera, if someone does want
> >>>>>>> an
> >>>>>>> operation-specific ping. So perhaps the ping logic calls each message
> >>>>>>> receiver ping() implementation in turn until it gets a non-null
> >>>>>>> PingResponse result?
> >>>>>>>
> >>>>>>> - Dennis
> >>>>>>>
> >>>>>>> ---------------------------------------------------------------------
> >>>>>>> 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]
> >>>>>
> >>>>>
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> 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]
