axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: [axis2] Pinging capability to services deployed in Axs2
Date Sun, 11 Feb 2007 22:53:26 GMT
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 <dms@sosnoski.com> 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: axis-dev-unsubscribe@ws.apache.org
> > >>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
> 
> 
-- 
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message