You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Sameera Madushan <sa...@gmail.com> on 2007/02/06 19:28:37 UTC
[axis2] Pinging capability to services deployed in Axs2
Hi all,
Managing the deployed web services is becoming mandatory and important,
because the usage of web services is increasing in the enterprise. One
requirement which can arise in managing the web services is to monitor the
availability of the services and to check the status of the services whether
they are up and running. And also service managers may need to perform these
activities periodically. In some cases, services can be down for
maintenance, then there has to be a way for the requesters to check its
availability.
In the current situation invoking the service is the only option to get the
status of the services. But invoking each and every service for this purpose
is not a good idea either.
The above requirements can be satisfied by introducing a pinging capability
to the service deployed in Axis2. Here is how it happens. Users can send
ping requests to the specified services. For these requests, ping responses
can be sent indicating service status.
Extending the AbstractMessageReceiver api with a method(say ping) which
returns a boolean value, will enable message receiver implementors to write
their own logic to test the status of the service. For an example in this
ping method, one can check whether the required dependencies for the service
is available or not.
In order to identify ping requests soapaction can be used. Based on the
soapaction "ping handler" can invoke the ping method of message receiver.
Thanks
Sameera Madushan
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Davanum Srinivas <da...@gmail.com>.
Sounds good to me! +1
On 2/9/07, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Paul Fremantle wrote:
> > Dennis
> >> Only if the user actually implements the ping-handling code themselves,
> >> and checks the various conditions that can go wrong in the operation of
> >> the service code. Was that the intention, that this be exposed to the
> >> user to implement? I don't know see offhand how this would work, given
> >> that somewhere around 95% of Axis2 services are using generated code.
> >> Just having it go to a MessageReceiver default implementation seems to
> >> add zero value beyond what you get by querying the admin service.
> >
> > There is a simple value that can be had from going to the MR - the MR
> > can try to instantiate the Java object. This at least tests a few of
> > the major classpath issues that you might get from a service deployer.
> >
> > Ideally we could also generate a ping() method on skeletons that would
> > encourage users to write a more thorough test. We could use reflection
> > to invoke it if it exists.
>
> I really dislike using reflection for this type of thing, since it means
> that "magic" methods change the behavior of things at runtime. It'd be
> easy enough to do this as an interface, though. So the message receiver
> could check if the service class implements the pingable interface, and
> if so it calls the method defined by that interface. Otherwise, it just
> checks that it can create an instance of the service class.
>
> That seems like a reasonable approach - no impact on users who just use
> the default behavior, but easy for anyone who wants to support the added
> value to do so. Does anyone object to implementing it this way?
>
> - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Sanjiva Weerawarana wrote:
>
> Are you in agreement with Thilina's point: we need to add a ping()
> method to MR which would in turn interrogate the service class (at least
> for Java class implemented services .. obviously it does squat for a
> service implemented as bpel script or javascript or something else).
>
>
Yes, I'm convinced (once we agree on the details, which are important
since this is becoming a part of the public API).
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2007-02-09 at 23:19 +1300, Dennis Sosnoski wrote:
>
> I really dislike using reflection for this type of thing, since it means
There's no reflection involved .. the generate MR would have the right
code in it.
> that "magic" methods change the behavior of things at runtime. It'd be
> easy enough to do this as an interface, though. So the message receiver
> could check if the service class implements the pingable interface, and
> if so it calls the method defined by that interface. Otherwise, it just
> checks that it can create an instance of the service class.
This is fine with me too.
> That seems like a reasonable approach - no impact on users who just use
> the default behavior, but easy for anyone who wants to support the added
> value to do so. Does anyone object to implementing it this way?
Are you in agreement with Thilina's point: we need to add a ping()
method to MR which would in turn interrogate the service class (at least
for Java class implemented services .. obviously it does squat for a
service implemented as bpel script or javascript or something else).
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Thilina Gunarathne <cs...@gmail.com>.
Hi Dims,
I don't see any possibility to implement what's mentioned in the
following mail without changing the MR interface... Any clues??
> http://marc.theaimsgroup.com/?l=axis-dev&m=117101637929286&w=2
Thanks,
Thilina
> thanks,
> dims
>
> On 2/9/07, Nicholas L Gallardo <nl...@us.ibm.com> wrote:
> >
> > I'm -1 on a change to the actual MessageReceiver interface. That would require that we implement these semantics for JAX-WS services that may not implement the Pingable interface.
> >
> > I would prefer this be an additional interface that the MessageReceiver impl could choose to implement, but is not required.
> >
> > That's just my opinion though.
> >
> > Regards,
> >
> > Nicholas Gallardo
> > WebSphere - WebServices Development
> > nlgallar@us.ibm.com
> > Phone: 512-838-1182
> > Building: 901 / 5G-016
> >
> >
> >
> > "Thilina Gunarathne" <cs...@gmail.com>
> >
> > 02/09/2007 07:16 AM
> >
> > Please respond to
> > axis-dev@ws.apache.org
> >
> >
> > To axis-dev@ws.apache.org
> >
> > cc
> >
> >
> > Subject Re: [axis2] Pinging capability to services deployed in Axs2
> >
> >
> >
> >
> >
> >
> >
> > > > easy enough to do this as an interface, though. So the message receiver
> > > > could check if the service class implements the pingable interface, and
> > > > if so it calls the method defined by that interface. Otherwise, it just
> > > > checks that it can create an instance of the service class.
> >
> > Seems like we are agreeing on having service classes implement the
> > pingable interface.But in order to do that we need to add a (ping)
> > method to the message receiver interface, since message receiver needs
> > to have some method to check the service class (if the message
> > receiver has a associated service class)..
> >
> > I'm +1 for having both of the above..
> >
> > ~Thilina
> > > >
> > > > That seems like a reasonable approach - no impact on users who just use
> > > > the default behavior, but easy for anyone who wants to support the added
> > > > value to do so. Does anyone object to implementing it this way?
> > >
> > > +1 from me. This will be really useful - we can improve the failover
> > > that we do in Synapse to use this.
> > >
> > > Paul
> > >
> > > --
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Thilina Gunarathne
> > WSO2, Inc.; http://www.wso2.com/
> > Home page: http://webservices.apache.org/~thilina/
> > Blog: http://thilinag.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
> >
>
>
>
> --
> Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Nicholas L Gallardo <nl...@us.ibm.com>.
Thanks Dims... I guess I missed that in the previous threads.
Must read more carefully...
Regards,
Nicholas Gallardo
WebSphere - WebServices Development
nlgallar@us.ibm.com
Phone: 512-838-1182
Building: 901 / 5G-016
"Davanum Srinivas" <da...@gmail.com>
02/09/2007 10:37 AM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: [axis2] Pinging capability to services deployed in Axs2
Nick,
Yes, a separate interface is what we are rallying around now...
http://marc.theaimsgroup.com/?l=axis-dev&m=117101637929286&w=2
thanks,
dims
On 2/9/07, Nicholas L Gallardo <nl...@us.ibm.com> wrote:
>
> I'm -1 on a change to the actual MessageReceiver interface. That would
require that we implement these semantics for JAX-WS services that may not
implement the Pingable interface.
>
> I would prefer this be an additional interface that the MessageReceiver
impl could choose to implement, but is not required.
>
> That's just my opinion though.
>
> Regards,
>
> Nicholas Gallardo
> WebSphere - WebServices Development
> nlgallar@us.ibm.com
> Phone: 512-838-1182
> Building: 901 / 5G-016
>
>
>
> "Thilina Gunarathne" <cs...@gmail.com>
>
> 02/09/2007 07:16 AM
>
> Please respond to
> axis-dev@ws.apache.org
>
>
> To axis-dev@ws.apache.org
>
> cc
>
>
> Subject Re: [axis2] Pinging capability to services deployed in Axs2
>
>
>
>
>
>
>
> > > easy enough to do this as an interface, though. So the message
receiver
> > > could check if the service class implements the pingable interface,
and
> > > if so it calls the method defined by that interface. Otherwise, it
just
> > > checks that it can create an instance of the service class.
>
> Seems like we are agreeing on having service classes implement the
> pingable interface.But in order to do that we need to add a (ping)
> method to the message receiver interface, since message receiver needs
> to have some method to check the service class (if the message
> receiver has a associated service class)..
>
> I'm +1 for having both of the above..
>
> ~Thilina
> > >
> > > That seems like a reasonable approach - no impact on users who just
use
> > > the default behavior, but easy for anyone who wants to support the
added
> > > value to do so. Does anyone object to implementing it this way?
> >
> > +1 from me. This will be really useful - we can improve the failover
> > that we do in Synapse to use this.
> >
> > Paul
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> Thilina Gunarathne
> WSO2, Inc.; http://www.wso2.com/
> Home page: http://webservices.apache.org/~thilina/
> Blog: http://thilinag.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Davanum Srinivas <da...@gmail.com>.
Nick,
Yes, a separate interface is what we are rallying around now...
http://marc.theaimsgroup.com/?l=axis-dev&m=117101637929286&w=2
thanks,
dims
On 2/9/07, Nicholas L Gallardo <nl...@us.ibm.com> wrote:
>
> I'm -1 on a change to the actual MessageReceiver interface. That would require that we implement these semantics for JAX-WS services that may not implement the Pingable interface.
>
> I would prefer this be an additional interface that the MessageReceiver impl could choose to implement, but is not required.
>
> That's just my opinion though.
>
> Regards,
>
> Nicholas Gallardo
> WebSphere - WebServices Development
> nlgallar@us.ibm.com
> Phone: 512-838-1182
> Building: 901 / 5G-016
>
>
>
> "Thilina Gunarathne" <cs...@gmail.com>
>
> 02/09/2007 07:16 AM
>
> Please respond to
> axis-dev@ws.apache.org
>
>
> To axis-dev@ws.apache.org
>
> cc
>
>
> Subject Re: [axis2] Pinging capability to services deployed in Axs2
>
>
>
>
>
>
>
> > > easy enough to do this as an interface, though. So the message receiver
> > > could check if the service class implements the pingable interface, and
> > > if so it calls the method defined by that interface. Otherwise, it just
> > > checks that it can create an instance of the service class.
>
> Seems like we are agreeing on having service classes implement the
> pingable interface.But in order to do that we need to add a (ping)
> method to the message receiver interface, since message receiver needs
> to have some method to check the service class (if the message
> receiver has a associated service class)..
>
> I'm +1 for having both of the above..
>
> ~Thilina
> > >
> > > That seems like a reasonable approach - no impact on users who just use
> > > the default behavior, but easy for anyone who wants to support the added
> > > value to do so. Does anyone object to implementing it this way?
> >
> > +1 from me. This will be really useful - we can improve the failover
> > that we do in Synapse to use this.
> >
> > Paul
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> Thilina Gunarathne
> WSO2, Inc.; http://www.wso2.com/
> Home page: http://webservices.apache.org/~thilina/
> Blog: http://thilinag.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Sanjiva Weerawarana wrote:
> On Mon, 2007-02-12 at 13:32 +1300, Dennis Sosnoski wrote:
>
>> I'd personally support changing the message receiver interface to add a
>> ping() method, with the AbstractMessageReceiver class implementing it as
>> discussed. The reason is that I see this as something that should be a
>> mandatory part of the framework.
>>
>
> If we add the method then I'd prefer to have a module that supports the
> features we've discussed but not always engaged. The reason is that this
> is a non-standard feature and so its something we should encourage
> people to engage (globally) but not require. Are you ok with that?
>
Sure, on consideration I think a module is the right way to go.
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Rajith Attapattu <ra...@gmail.com>.
Sorry for jumping in the middle. but I have a few questions, just to get my
self upto speed with the issue.
If I have understood correctly the difference btw an operation level and
service level ping is that.
If the service class or the script is loading properly then a service level
ping is deemed successful.
And for operational level, the service author determines how deeper their
are willing to go.
Is this correct ???
For example if my service talks to a backend service(s) to execute the
operation, as a service author I can decide to actually ping the backend
service(s) as part of my ping operation or else to use a more light weight
approach to say my operation is working as desired.
This can cause serious performance implications if not managed properly and
as Dennis and Paul pointed out the benifit from such a ping may not be
worthwhile the cost. But allowing the service author to implement the ping
method and make a decesion on the level of "deepness" they are willing to go
seems like the right way to go.
>If all the MRs returns true then status of the service is "up". If one
>of MRs return false, the the status of the service will be "down"
I think the status of each operation as thilian pointed out is more useful
than just a blanket yes/no.
However I do recognize that providing the status of individual operations is
more complex.
Regards,
Rajith
On 2/12/07, Sameera Madushan <sa...@gmail.com> wrote:
>
> I have an on going prototype development of the ping module, but it is
> not yet submitted as a patch. It satisfies following requirements as
> they were discussed in this thread.
>
> The ping module supports only the service level ping requests. Once a
> service level ping request is received, it will invoke the ping
> methods of the all the MessageReceivers which handle the operations
> defined in the service and this module assumes that the
> MessageReceiver interface is extended. Consider the following sample
> code.
>
> boolean status = true;
> Iterator iterator = axisService.getOperations();
>
> while (iterator.hasNext() && status) {
> axisOperation = (AxisOperation) iterator.next();
> msgReceiver = (AbstractMessageReceiver)
>
> axisOperation.getMessageReceiver();
> status = msgReceiver.ping();
> }
>
> If all the MRs returns true then status of the service is "up". If one
> of MRs return false, the the status of the service will be "down"
> (say). Or else we can send the status of each operation as proposed by
> thilina.
>
> In most of the times single MR handles several web service operations.
> Therefore Using the above approache, the ping method of a single MR
> can be invoked several times. This is an extra overhead.
>
> One solution to overcome this problem is to cache MR on which the ping
> method is invoked. AFA I think the second option is to send the
> operation name as a parameter to the ping method.
>
> These are just my opinions.
>
> Sameera
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sameera Madushan <sa...@gmail.com>.
I have an on going prototype development of the ping module, but it is
not yet submitted as a patch. It satisfies following requirements as
they were discussed in this thread.
The ping module supports only the service level ping requests. Once a
service level ping request is received, it will invoke the ping
methods of the all the MessageReceivers which handle the operations
defined in the service and this module assumes that the
MessageReceiver interface is extended. Consider the following sample
code.
boolean status = true;
Iterator iterator = axisService.getOperations();
while (iterator.hasNext() && status) {
axisOperation = (AxisOperation) iterator.next();
msgReceiver = (AbstractMessageReceiver)
axisOperation.getMessageReceiver();
status = msgReceiver.ping();
}
If all the MRs returns true then status of the service is "up". If one
of MRs return false, the the status of the service will be "down"
(say). Or else we can send the status of each operation as proposed by
thilina.
In most of the times single MR handles several web service operations.
Therefore Using the above approache, the ping method of a single MR
can be invoked several times. This is an extra overhead.
One solution to overcome this problem is to cache MR on which the ping
method is invoked. AFA I think the second option is to send the
operation name as a parameter to the ping method.
These are just my opinions.
Sameera
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1.
Thilina Gunarathne wrote:
> Hi all,
> There were two -1's from Nick & Bill on extending the MessageReceiver.
> The patch given in the JIRA introduces a new interface called
> Pingable, without changing the MR interface..I assume that's fine with
> both Nick & Bill..
>
> Given that there are no objections so far, I'm going to commit the
> ping module given at Axis2-2233...
>
> ~Thilina
>
> On 2/21/07, Sameera Madushan <sa...@gmail.com> wrote:
>> Hi all,
>>
>> Implementation of the ping module is available in the following JIRA
>>
>> https://issues.apache.org/jira/browse/AXIS2-2233
>>
>> Sameera
>>
>> ---------------------------------------------------------------------
>> 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
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Nicholas L Gallardo <nl...@us.ibm.com>.
Yep, sounds good... +1
-Nick
"Thilina Gunarathne" <cs...@gmail.com>
02/26/2007 06:33 AM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: [axis2] Pinging capability to services deployed in Axis2
Hi all,
There were two -1's from Nick & Bill on extending the MessageReceiver.
The patch given in the JIRA introduces a new interface called
Pingable, without changing the MR interface..I assume that's fine with
both Nick & Bill..
Given that there are no objections so far, I'm going to commit the
ping module given at Axis2-2233...
~Thilina
On 2/21/07, Sameera Madushan <sa...@gmail.com> wrote:
> Hi all,
>
> Implementation of the ping module is available in the following JIRA
>
> https://issues.apache.org/jira/browse/AXIS2-2233
>
> Sameera
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
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
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Thilina Gunarathne <cs...@gmail.com>.
Hi all,
There were two -1's from Nick & Bill on extending the MessageReceiver.
The patch given in the JIRA introduces a new interface called
Pingable, without changing the MR interface..I assume that's fine with
both Nick & Bill..
Given that there are no objections so far, I'm going to commit the
ping module given at Axis2-2233...
~Thilina
On 2/21/07, Sameera Madushan <sa...@gmail.com> wrote:
> Hi all,
>
> Implementation of the ping module is available in the following JIRA
>
> https://issues.apache.org/jira/browse/AXIS2-2233
>
> Sameera
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Sameera Madushan <sa...@gmail.com>.
Hi all,
Implementation of the ping module is available in the following JIRA
https://issues.apache.org/jira/browse/AXIS2-2233
Sameera
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2007-02-16 at 14:30 +0530, Deepal Jayasinghe wrote:
> But how abt the changing the ping method signature as follows ;
>
> public void ping(MessageContext msgCts){
> ThreadContextDescriptor tc = setThreadContext(msgContext);
> try {
> // do the ping logic here
>
> } finally {
> restoreThreadContext(tc);
> }
> }
+1 from me.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Thilina Gunarathne wrote:
>> Sure there is .. MC.getCurrentMC()-> OperationContext -> AxisOperation.
>
> AFAIK We can use this only after the MessageReciver level, since
> message receiver is the one which set's message context to the
> Thread..
But how abt the changing the ping method signature as follows ;
public void ping(MessageContext msgCts){
ThreadContextDescriptor tc = setThreadContext(msgContext);
try {
// do the ping logic here
} finally {
restoreThreadContext(tc);
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Thilina Gunarathne <cs...@gmail.com>.
> Sure there is .. MC.getCurrentMC()-> OperationContext -> AxisOperation.
AFAIK We can use this only after the MessageReciver level, since
message receiver is the one which set's message context to the
Thread..
> In fact even the operation name is not needed .. if dispatch has
> succeeded in finding an operation then its avail if MR wants it. So in
> that case let's simplify by passing nothing in!
According to my undestanding in this case the operation would be ping,
since we are getting the request for the ping module, not for the
operation which we are going to check.. IMHO Dispatch would not be be
able to find the operation. We might need to find the AxisOperation at
the ping module by the operation name(received in the body or found
from some where else).. Please correct me if I'm thinking of
something different to the idea concluded by the discussion...
Thanks,
Thilina
>
> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Thu, 2007-02-15 at 14:01 +0530, Thilina Gunarathne wrote:
> Ping method in the MR will need the AxisOperation to figure out the
> parameters related to the operation which are checking (Eg: service
> class)..
>
> AFAI can see there is no place to look up when we just give the
> operation name to the MR..
Sure there is .. MC.getCurrentMC()-> OperationContext -> AxisOperation.
In fact even the operation name is not needed .. if dispatch has
succeeded in finding an operation then its avail if MR wants it. So in
that case let's simplify by passing nothing in!
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Thilina Gunarathne <cs...@gmail.com>.
Ping method in the MR will need the AxisOperation to figure out the
parameters related to the operation which are checking (Eg: service
class)..
AFAI can see there is no place to look up when we just give the
operation name to the MR..
~Thilina
On 2/15/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> Let's simplify it by sending the op name in both cases .. if the ping
> method needs the AO it can go look it up.
>
> Sanjiva.
>
> On Thu, 2007-02-15 at 13:09 +0530, Thilina Gunarathne wrote:
> > Sameera,
> > According to your diagram I get the feeling that the Pingable
> > interface is going to have two overloaded Ping methods with one having
> > AxisOperation as the parameter & String (operation name) as the
> > parameter for the other one..
> >
> > In this case I would like to see two interfaces..
> >
> > Thanks,
> > Thilina
> >
> >
> > On 2/15/07, Sameera Madushan <sa...@gmail.com> wrote:
> > > Hi,
> > >
> > > On 2/13/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > > 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.
> > > >
> > >
> > > Using the above levels, How "ping" works can be illustrated as in
> > > attached diagram. The PingHandler is registered in the Dispatch phase,
> > > before InstanceDispatcher handler.
> > >
> > > Sameera
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Let's simplify it by sending the op name in both cases .. if the ping
method needs the AO it can go look it up.
Sanjiva.
On Thu, 2007-02-15 at 13:09 +0530, Thilina Gunarathne wrote:
> Sameera,
> According to your diagram I get the feeling that the Pingable
> interface is going to have two overloaded Ping methods with one having
> AxisOperation as the parameter & String (operation name) as the
> parameter for the other one..
>
> In this case I would like to see two interfaces..
>
> Thanks,
> Thilina
>
>
> On 2/15/07, Sameera Madushan <sa...@gmail.com> wrote:
> > Hi,
> >
> > On 2/13/07, Paul Fremantle <pz...@gmail.com> wrote:
> > > 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.
> > >
> >
> > Using the above levels, How "ping" works can be illustrated as in
> > attached diagram. The PingHandler is registered in the Dispatch phase,
> > before InstanceDispatcher handler.
> >
> > Sameera
> >
> > ---------------------------------------------------------------------
> > 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
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Thilina Gunarathne <cs...@gmail.com>.
Sameera,
According to your diagram I get the feeling that the Pingable
interface is going to have two overloaded Ping methods with one having
AxisOperation as the parameter & String (operation name) as the
parameter for the other one..
In this case I would like to see two interfaces..
Thanks,
Thilina
On 2/15/07, Sameera Madushan <sa...@gmail.com> wrote:
> Hi,
>
> On 2/13/07, Paul Fremantle <pz...@gmail.com> wrote:
> > 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.
> >
>
> Using the above levels, How "ping" works can be illustrated as in
> attached diagram. The PingHandler is registered in the Dispatch phase,
> before InstanceDispatcher handler.
>
> Sameera
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Sameera Madushan <sa...@gmail.com>.
Hi,
On 2/13/07, Paul Fremantle <pz...@gmail.com> wrote:
> 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.
>
Using the above levels, How "ping" works can be illustrated as in
attached diagram. The PingHandler is registered in the Dispatch phase,
before InstanceDispatcher handler.
Sameera
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+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 <na...@watson.ibm.com> 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 <na...@watson.ibm.com> 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: 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
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Paul Fremantle <pz...@gmail.com>.
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 <na...@watson.ibm.com> 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 <na...@watson.ibm.com> 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: 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
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Paul;
Cant we do the same thing as we are doing in ServiceLifeCycle interface
in this case too. Let's introduce new interface to manage the service
(ServiceManager) and ask service author to implement that the way he
want (and ask to add entry to services.xml as an optional tag). So once
we get the request we will check the AxisService whether it has impl of
that ServiceManager interface if so we call that and send the response
else ...... (need to decide)
With this approach we are not going to touch the service impl class ,
and that help us to mange the service independent of the session scope.
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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Bill Nagy <na...@watson.ibm.com>.
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 <na...@watson.ibm.com> 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: 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
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi All;
> 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.
Say for an instance we deploy a service in application scope, then the
expected behavior is to have only one instance of the service impl
class, but if we are going to new up a service impl whenever we get the
ping req , then we are doing smt wrong. We are going to have multiple
instance of the same service class even in application scope. For me
that is not good idea.
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Paul Fremantle <pz...@gmail.com>.
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 <na...@watson.ibm.com> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axis2
Posted by Bill Nagy <na...@watson.ibm.com>.
[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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2007-02-12 at 13:32 +1300, Dennis Sosnoski wrote:
> I'd personally support changing the message receiver interface to add a
> ping() method, with the AbstractMessageReceiver class implementing it as
> discussed. The reason is that I see this as something that should be a
> mandatory part of the framework.
If we add the method then I'd prefer to have a module that supports the
features we've discussed but not always engaged. The reason is that this
is a non-standard feature and so its something we should encourage
people to engage (globally) but not require. Are you ok with that?
> But with the -1 from Nicholas Gallardo
> on this approach, the alternative is to define a new interface for the
> message receiver to implement if it's going to support the ping. The
> engine would then need to check if the message receiver implements this
> interface (which would be the case for AbstractMessageReceiver and
> subclasses) before casting and making the call. If the message receiver
> does not implement the interface, I'd say the engine should always
> return a failure response to the ping.
>
> I suppose this message receiver interface could be the same as the
> service class Pingable interface mentioned in the earlier email. That
> way we avoid yet another added interface.
To me this is an ugly hack to get around the right solution.
Nick, you've been quiet since you put the -1. Please explain your
position now given all the discussion we've had on this.
Thanks,
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
I'd personally support changing the message receiver interface to add a
ping() method, with the AbstractMessageReceiver class implementing it as
discussed. The reason is that I see this as something that should be a
mandatory part of the framework. But with the -1 from Nicholas Gallardo
on this approach, the alternative is to define a new interface for the
message receiver to implement if it's going to support the ping. The
engine would then need to check if the message receiver implements this
interface (which would be the case for AbstractMessageReceiver and
subclasses) before casting and making the call. If the message receiver
does not implement the interface, I'd say the engine should always
return a failure response to the ping.
I suppose this message receiver interface could be the same as the
service class Pingable interface mentioned in the earlier email. That
way we avoid yet another added interface.
- Dennis
Sanjiva Weerawarana wrote:
> 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 <dm...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> 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
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 <dm...@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
> >>>
> >>>
> >>>
> >>
>
> ---------------------------------------------------------------------
> 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
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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 <dm...@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
>>>
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Deepal Jayasinghe <de...@opensource.lk>.
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
>
>
In the case of JS , I think the MR need to handle whatever necessary.
Thanks
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 <dm...@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
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Paul Fremantle <pz...@gmail.com>.
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 <dm...@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
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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
>
--
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
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Thilina Gunarathne <cs...@gmail.com>.
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
>
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Thilina Gunarathne wrote:
>> > easy enough to do this as an interface, though. So the message
>> receiver
>> > could check if the service class implements the pingable interface,
>> and
>> > if so it calls the method defined by that interface. Otherwise, it
>> just
>> > checks that it can create an instance of the service class.
>
> Seems like we are agreeing on having service classes implement the
> pingable interface.But in order to do that we need to add a (ping)
> method to the message receiver interface, since message receiver needs
> to have some method to check the service class (if the message
> receiver has a associated service class)..
Yes, the discussions convinced at least me that having this go through
to the message receiver made sense, and that while the handler-based
approach could always be used it wouldn't necessarily be be as useful. I
think there are still some details to be worked out, though.
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.
If the ping is limited to the service level, then it becomes an
arbitrary decision as to which message receiver should be used to
respond to the request (assuming there's more than one). Or do people
want to have all the message receivers polled?
Finally, if we're going to implement this (in whichever variation) I
suggest making the ping response extensible with added user data. So
perhaps it's of the form:
<xs:element name="pingResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="status" type="xs:boolean"/>
<xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any"
processContents="lax"/>
</xs:sequence>
</xs:complexType>
</xs:element>
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
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2007-02-09 at 09:47 -0600, Nicholas L Gallardo wrote:
>
> I'm -1 on a change to the actual MessageReceiver interface. That
> would require that we implement these semantics for JAX-WS services
> that may not implement the Pingable interface.
We don't *have to* implement them .. the default in AbstractMR will be
to return true; meaning service was pinged.
Since JAX-WS APIs don't have a ping notion built into them I see no loss
in not improving the fidelity of "ping".
> I would prefer this be an additional interface that the
> MessageReceiver impl could choose to implement, but is not required.
That's doable too but it would make it harder to have this codegen'ed
etc. because we'd need to apply the "make-me-pingable" policy in order
to get this code generated.
> That's just my opinion though.
Same here :-).
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Nicholas L Gallardo <nl...@us.ibm.com>.
I'm -1 on a change to the actual MessageReceiver interface. That would
require that we implement these semantics for JAX-WS services that may not
implement the Pingable interface.
I would prefer this be an additional interface that the MessageReceiver
impl could choose to implement, but is not required.
That's just my opinion though.
Regards,
Nicholas Gallardo
WebSphere - WebServices Development
nlgallar@us.ibm.com
Phone: 512-838-1182
Building: 901 / 5G-016
"Thilina Gunarathne" <cs...@gmail.com>
02/09/2007 07:16 AM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: [axis2] Pinging capability to services deployed in Axs2
> > easy enough to do this as an interface, though. So the message
receiver
> > could check if the service class implements the pingable interface,
and
> > if so it calls the method defined by that interface. Otherwise, it
just
> > checks that it can create an instance of the service class.
Seems like we are agreeing on having service classes implement the
pingable interface.But in order to do that we need to add a (ping)
method to the message receiver interface, since message receiver needs
to have some method to check the service class (if the message
receiver has a associated service class)..
I'm +1 for having both of the above..
~Thilina
> >
> > That seems like a reasonable approach - no impact on users who just
use
> > the default behavior, but easy for anyone who wants to support the
added
> > value to do so. Does anyone object to implementing it this way?
>
> +1 from me. This will be really useful - we can improve the failover
> that we do in Synapse to use this.
>
> Paul
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Thilina Gunarathne <cs...@gmail.com>.
> > easy enough to do this as an interface, though. So the message receiver
> > could check if the service class implements the pingable interface, and
> > if so it calls the method defined by that interface. Otherwise, it just
> > checks that it can create an instance of the service class.
Seems like we are agreeing on having service classes implement the
pingable interface.But in order to do that we need to add a (ping)
method to the message receiver interface, since message receiver needs
to have some method to check the service class (if the message
receiver has a associated service class)..
I'm +1 for having both of the above..
~Thilina
> >
> > That seems like a reasonable approach - no impact on users who just use
> > the default behavior, but easy for anyone who wants to support the added
> > value to do so. Does anyone object to implementing it this way?
>
> +1 from me. This will be really useful - we can improve the failover
> that we do in Synapse to use this.
>
> Paul
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Paul Fremantle <pz...@gmail.com>.
> It'd be
> easy enough to do this as an interface, though. So the message receiver
> could check if the service class implements the pingable interface, and
> if so it calls the method defined by that interface. Otherwise, it just
> checks that it can create an instance of the service class.
>
> That seems like a reasonable approach - no impact on users who just use
> the default behavior, but easy for anyone who wants to support the added
> value to do so. Does anyone object to implementing it this way?
+1 from me. This will be really useful - we can improve the failover
that we do in Synapse to use this.
Paul
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Paul Fremantle wrote:
> Dennis
>> Only if the user actually implements the ping-handling code themselves,
>> and checks the various conditions that can go wrong in the operation of
>> the service code. Was that the intention, that this be exposed to the
>> user to implement? I don't know see offhand how this would work, given
>> that somewhere around 95% of Axis2 services are using generated code.
>> Just having it go to a MessageReceiver default implementation seems to
>> add zero value beyond what you get by querying the admin service.
>
> There is a simple value that can be had from going to the MR - the MR
> can try to instantiate the Java object. This at least tests a few of
> the major classpath issues that you might get from a service deployer.
>
> Ideally we could also generate a ping() method on skeletons that would
> encourage users to write a more thorough test. We could use reflection
> to invoke it if it exists.
I really dislike using reflection for this type of thing, since it means
that "magic" methods change the behavior of things at runtime. It'd be
easy enough to do this as an interface, though. So the message receiver
could check if the service class implements the pingable interface, and
if so it calls the method defined by that interface. Otherwise, it just
checks that it can create an instance of the service class.
That seems like a reasonable approach - no impact on users who just use
the default behavior, but easy for anyone who wants to support the added
value to do so. Does anyone object to implementing it this way?
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2007-02-09 at 09:30 +0000, Paul Fremantle wrote:
>
> Ideally we could also generate a ping() method on skeletons that would
> encourage users to write a more thorough test. We could use reflection
> to invoke it if it exists.
Absolutely; that's what I thought we'd be doing too- generate a method
that does as much as it can to give a meaningful answer.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Paul Fremantle <pz...@gmail.com>.
Dennis
> Only if the user actually implements the ping-handling code themselves,
> and checks the various conditions that can go wrong in the operation of
> the service code. Was that the intention, that this be exposed to the
> user to implement? I don't know see offhand how this would work, given
> that somewhere around 95% of Axis2 services are using generated code.
> Just having it go to a MessageReceiver default implementation seems to
> add zero value beyond what you get by querying the admin service.
There is a simple value that can be had from going to the MR - the MR
can try to instantiate the Java object. This at least tests a few of
the major classpath issues that you might get from a service deployer.
Ideally we could also generate a ping() method on skeletons that would
encourage users to write a more thorough test. We could use reflection
to invoke it if it exists.
Paul
>
> - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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?".
That's true if the handler is not providing any useful response
information. If the handler can report that the service is accepting
requests and delivering non-Fault responses that seems to be more useful
information than you'd get just by going to the message receiver.
> 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.
>
Only if the user actually implements the ping-handling code themselves,
and checks the various conditions that can go wrong in the operation of
the service code. Was that the intention, that this be exposed to the
user to implement? I don't know see offhand how this would work, given
that somewhere around 95% of Axis2 services are using generated code.
Just having it go to a MessageReceiver default implementation seems to
add zero value beyond what you get by querying the admin service.
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Sameera ;
>
>
> There can be two types of ping requests.
>
> 1. Service level ping requests.
> 2. Operation level ping requests.
>
> In the first case, you are correct, we need to ping all the operations
> within the service. Then in the ping response simply we can say
> whether the service is up or not, or we can include all operations and
> their status.
>
> In the second case we can directly ping the MR assinged to the
> requested operation and the response accordingly.
This is not clear to me , are you saying that service author need to
create a his service with ping capability . Does he need to write a MR
to handle the ping req for his service.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Sameera ;
>
>
> There can be two types of ping requests.
>
> 1. Service level ping requests.
> 2. Operation level ping requests.
>
> In the first case, you are correct, we need to ping all the operations
> within the service. Then in the ping response simply we can say
> whether the service is up or not, or we can include all operations and
> their status.
>
> In the second case we can directly ping the MR assinged to the
> requested operation and the response accordingly.
This is not clear to me , are you saying that service author need to
create a his service with ping capability . Does he need to write a MR
to handle the ping req for his service.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sameera Madushan <sa...@gmail.com>.
Hi deepal,
>
> >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.
> >
> >
> Service might have more than one MRs (most of the time it does) so
> checking only one MR wont give you the accurate results. The other
> problem I have is which MR you are going to call when you receive a ping
> request , are you going call all the MRs or only one.
There can be two types of ping requests.
1. Service level ping requests.
2. Operation level ping requests.
In the first case, you are correct, we need to ping all the operations
within the service. Then in the ping response simply we can say whether the
service is up or not, or we can include all operations and their status.
In the second case we can directly ping the MR assinged to the requested
operation and the response accordingly.
This implies that we need to develop a schema for the ping requests and ping
responses.
thanks
Sameera.
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Nicholas L Gallardo <nl...@us.ibm.com>.
+1 to David's point. I would prefer this be optional and not required for
all MessageReceivers.
Nicholas Gallardo
WebSphere - WebServices Development
nlgallar@us.ibm.com
Phone: 512-838-1182
Building: 901 / 5G-016
"David Illsley" <da...@gmail.com>
02/09/2007 03:25 AM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: [axis2] Pinging capability to services deployed in Axs2
So how about a handler approach, with an optional interface that MRs
can implement if they do support being interrogated about current
status?
David
On 09/02/07, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Angel Todorov wrote:
> > ...
> >
> > What Dennis suggests is useful, but in reaility there may be
> > situations where the service is randomly invoked by clients with
> > crappy soap header / body (think about bots & worms or developers of
> > web service clients in an open WS environment), to which a fault is
> > produced, and this doesn't mean that the service is "inoperative", if
> > a "proper" client knows exactly what he wants from the service. The
> > whole problem with the SOAP faults actually lies in this that, you can
> > never know how a service implementor will manage and create SOAP
> > faults - will this only be done in case of a real business logic
> > error, or will this happen if the client sends crap, or even for
> > Exceptions which can be managed internally by the logic.
>
> These are certainly valid points. I wasn't saying that the handler
> approach would be a bulletproof way of checking the successful operation
> of the service, only that it would offer useful information beyond what
> you'd get by just having an echo at the message receiver level.
>
> A true robust approach requires client-side code to support switching to
> another service instance when the in-use service fails to respond
> properly, along with a central registry of services instances so that
> the client can find a new one when it needs to. If the client switches
> between different service instances and continues to have problems it
> knows that either the problem is due to something fundamental to the
> service (backend database crashed, network disconnection, etc.) or it's
> making bad requests.
>
> - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by David Illsley <da...@gmail.com>.
So how about a handler approach, with an optional interface that MRs
can implement if they do support being interrogated about current
status?
David
On 09/02/07, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Angel Todorov wrote:
> > ...
> >
> > What Dennis suggests is useful, but in reaility there may be
> > situations where the service is randomly invoked by clients with
> > crappy soap header / body (think about bots & worms or developers of
> > web service clients in an open WS environment), to which a fault is
> > produced, and this doesn't mean that the service is "inoperative", if
> > a "proper" client knows exactly what he wants from the service. The
> > whole problem with the SOAP faults actually lies in this that, you can
> > never know how a service implementor will manage and create SOAP
> > faults - will this only be done in case of a real business logic
> > error, or will this happen if the client sends crap, or even for
> > Exceptions which can be managed internally by the logic.
>
> These are certainly valid points. I wasn't saying that the handler
> approach would be a bulletproof way of checking the successful operation
> of the service, only that it would offer useful information beyond what
> you'd get by just having an echo at the message receiver level.
>
> A true robust approach requires client-side code to support switching to
> another service instance when the in-use service fails to respond
> properly, along with a central registry of services instances so that
> the client can find a new one when it needs to. If the client switches
> between different service instances and continues to have problems it
> knows that either the problem is due to something fundamental to the
> service (backend database crashed, network disconnection, etc.) or it's
> making bad requests.
>
> - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Angel Todorov wrote:
> ...
>
> What Dennis suggests is useful, but in reaility there may be
> situations where the service is randomly invoked by clients with
> crappy soap header / body (think about bots & worms or developers of
> web service clients in an open WS environment), to which a fault is
> produced, and this doesn't mean that the service is "inoperative", if
> a "proper" client knows exactly what he wants from the service. The
> whole problem with the SOAP faults actually lies in this that, you can
> never know how a service implementor will manage and create SOAP
> faults - will this only be done in case of a real business logic
> error, or will this happen if the client sends crap, or even for
> Exceptions which can be managed internally by the logic.
These are certainly valid points. I wasn't saying that the handler
approach would be a bulletproof way of checking the successful operation
of the service, only that it would offer useful information beyond what
you'd get by just having an echo at the message receiver level.
A true robust approach requires client-side code to support switching to
another service instance when the in-use service fails to respond
properly, along with a central registry of services instances so that
the client can find a new one when it needs to. If the client switches
between different service instances and continues to have problems it
knows that either the problem is due to something fundamental to the
service (backend database crashed, network disconnection, etc.) or it's
making bad requests.
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Angel Todorov <at...@gmail.com>.
Hi all,
a service in the Axis2 may not even have any implementation class. It
is very difficult to get any value out of the pinging in terms of
reaching a message receiver. The best and most guaranteed way to check
the status of a service is to actually invoke it with a request, which
is known to produce little overhead on the business logic - predefined
request/response, i.e a request to which a service business logic (not
necessarily a class!) will always respond with an echo.
If the ping functionality (described above , even to the MR level)
doesn't work in 99 % of the cases either the whole Axis2 is down or
the service is simply not deployed or corrupted (faulty).
As for statistics: There may be a "handler" which gathers such
statistics and routes requests (not in the DNS level as one would
normally do clustering) but that's more useful in the situation where
you'd like to have some form of load-balancing or failover. Statistics
will show you history/previous invocations, not the state of that
service at the moment of a new invocation.
What Dennis suggests is useful, but in reaility there may be
situations where the service is randomly invoked by clients with
crappy soap header / body (think about bots & worms or developers of
web service clients in an open WS environment), to which a fault is
produced, and this doesn't mean that the service is "inoperative", if
a "proper" client knows exactly what he wants from the service. The
whole problem with the SOAP faults actually lies in this that, you can
never know how a service implementor will manage and create SOAP
faults - will this only be done in case of a real business logic
error, or will this happen if the client sends crap, or even for
Exceptions which can be managed internally by the logic.
Best,
Angel
On 2/9/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Fri, 2007-02-09 at 11:54 +0530, Deepal Jayasinghe wrote:
> > Service might have more than one MRs (most of the time it does) so
> > checking only one MR wont give you the accurate results. The other
> > problem I have is which MR you are going to call when you receive a ping
> > request , are you going call all the MRs or only one.
>
> You have to check all of them ... each MR could be loading a different
> script for example.
>
> In reality there are < 5 and certainly < 10 operations in a service for
> 99% of the time. So I don't see this being a big deal.
>
> 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: 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
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2007-02-09 at 11:54 +0530, Deepal Jayasinghe wrote:
> Service might have more than one MRs (most of the time it does) so
> checking only one MR wont give you the accurate results. The other
> problem I have is which MR you are going to call when you receive a ping
> request , are you going call all the MRs or only one.
You have to check all of them ... each MR could be loading a different
script for example.
In reality there are < 5 and certainly < 10 operations in a service for
99% of the time. So I don't see this being a big deal.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi All;
>
>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.
>
>
Service might have more than one MRs (most of the time it does) so
checking only one MR wont give you the accurate results. The other
problem I have is which MR you are going to call when you receive a ping
request , are you going call all the MRs or only one.
Thanks
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sameera Madushan <sa...@gmail.com>.
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 <sa...@opensource.lk> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
+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
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.
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).
- Dennis
Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
Sameera Madushan wrote:
> Hi Dims, Deepal
>
> Actually the idea is to develop a custom ping module with appropriate
> handlers. One of the ping handlers should be added to the dispatch
> phase before the 'InstanceDispatcher' (Inflow). If the service is
> deployed and it is active, then ping handler can get the service
> status from AxisConfiguration. If the service is not deployed then the
> service information is not available in the AxisConfiguration. Then
> the ping module can respond to the ping requests accordingly.
>
> well... this is the fundamental functionality of the ping module,
> monitoring the availability of the services deployed in axis2. But
> extending the MessageReceiver api with a ping method will enhance this
> functionality. Since the method is added to the
> AbstractMessageReceiver it will not break the existing implementations
> of the MessageReceiver interface. This ping method can be used to
> check real status of the services, whether they are up and running.
> There may be instances, where the services are available but they are
> not in a position to respond to requests. If the required dependencies
> are not available for the services, then they fail to respond and also
> in some cases there may be some things to be completed before the
> services can actually respond. These service dependent issues can be
> monitored using the pinging capability, if we provide the ping method
> to the message receiver implementers.
>
> Thanks
> Sameera
>
>
>
> On 2/7/07, *Deepal Jayasinghe* <deepal@opensource.lk
> <ma...@opensource.lk>> wrote:
>
> Hi Sameera ;
>
> > Hi all,
> >
> > Managing the deployed web services is becoming mandatory and
> > important, because the usage of web services is increasing in the
> > enterprise. One requirement which can arise in managing the web
> > services is to monitor the availability of the services and to check
> > the status of the services whether they are up and running. And also
> > service managers may need to perform these activities
> periodically. In
> > some cases, services can be down for maintenance, then there has
> to be
> > a way for the requesters to check its availability.
> >
> > In the current situation invoking the service is the only option to
> > get the status of the services. But invoking each and every service
> > for this purpose is not a good idea either.
> >
> > The above requirements can be satisfied by introducing a pinging
> > capability to the service deployed in Axis2. Here is how it
> happens.
> > Users can send ping requests to the specified services. For these
> > requests, ping responses can be sent indicating service status.
> >
> > Extending the AbstractMessageReceiver api with a method(say ping)
> > which returns a boolean value, will enable message receiver
> > implementors to write their own logic to test the status of the
> > service. For an example in this ping method, one can check
> whether the
> > required dependencies for the service is available or not.
>
> I dont see any requirement of changing API , if you want to know the
> service is up and running then what you can do is get the service
> state
> from AxisConfiguration. You can get the status of the ho from
> AxisConfiguration where it is active or not.
>
> Thanks
> Deepal
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Davanum Srinivas <da...@gmail.com>.
Sorry, IMHO, changing the interface is not my definition of "clean fix".
-- dims
On 2/8/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> Yuck! We have a clean fix why not do it?
>
> Anyway, +1 for a patch.
>
> Sanjiva.
>
> On Wed, 2007-02-07 at 21:35 -0500, Davanum Srinivas wrote:
> > I think i'd like to see a patch before we go further. Am not convinced
> > this is the best approach. We could do a custom dispatcher that could
> > insert a java dynamic proxy[1] under certain conditions (custom soap
> > header?) to get the same kind of behavior.
> >
> > Thanks,
> > dims
> >
> > [1] http://java.sun.com/j2se/1.4.2/docs/guide/reflection/proxy.html
> >
> > On 2/7/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > > The ping response is a best effort. The default is to say "it reached
> > > the msg receiver so all is ok." Obviously that's not always true- e.g.,
> > > class load errors can occur after that. (Or imagine the service is
> > > implemented by a BPEL script- one of the external services may be
> > > missing.)
> > >
> > > So a given message receiver can do better if it can and wants to. If its
> > > a Java MR it can try to load the class before replying for example. We
> > > don't want to dictate terms to the MR.
> > >
> > > Its well and good that the message made it thru the handlers but that
> > > doesn't say that the service will work (or is likely to work; this is
> > > not a transactional thing after all) when its invoked. Delivering the
> > > ping all the way to the MR gives maximum opportunity for the best effort
> > > answer of "how are you doing" to be as good as it can be.
> > >
> > > Unfortunately there's no way to do that without adding another method to
> > > the MR interface. We will provide a default impl which simply returns
> > > true .. meaning "yep ping went thru" but we encourage MR authors
> > > (including our tools) to do better.
> > >
> > > Thanks,
> > >
> > > Sanjiva.
> > >
> > > On Wed, 2007-02-07 at 12:13 +0530, Deepal Jayasinghe wrote:
> > > > > Hi Dims, Deepal
> > > > >
> > > > > Actually the idea is to develop a custom ping module with appropriate
> > > > > handlers. One of the ping handlers should be added to the dispatch
> > > > > phase before the 'InstanceDispatcher' (Inflow). If the service is
> > > > > deployed and it is active, then ping handler can get the service
> > > > > status from AxisConfiguration. If the service is not deployed then the
> > > > > service information is not available in the AxisConfiguration. Then
> > > > > the ping module can respond to the ping requests accordingly.
> > > >
> > > > +1
> > > >
> > > > >
> > > > > well... this is the fundamental functionality of the ping module,
> > > > > monitoring the availability of the services deployed in axis2. But
> > > > > extending the MessageReceiver api with a ping method will enhance this
> > > > > functionality.
> > > >
> > > > Managing a service (like sending a ping message) is generic requirement
> > > > or a specific requirement, as I can see it is very specific requirement.
> > > > So Im not that much like to change the MR api to cope with requirement.
> > > >
> > > > > Since the method is added to the AbstractMessageReceiver it will not
> > > > > break the existing implementations of the MessageReceiver interface.
> > > > > This ping method can be used to check real status of the services,
> > > > > whether they are up and running. There may be instances, where the
> > > > > services are available but they are not in a position to respond to
> > > > > requests.
> > > >
> > > > So , how come that response to ping request if it is in such a position :)
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Yuck! We have a clean fix why not do it?
Anyway, +1 for a patch.
Sanjiva.
On Wed, 2007-02-07 at 21:35 -0500, Davanum Srinivas wrote:
> I think i'd like to see a patch before we go further. Am not convinced
> this is the best approach. We could do a custom dispatcher that could
> insert a java dynamic proxy[1] under certain conditions (custom soap
> header?) to get the same kind of behavior.
>
> Thanks,
> dims
>
> [1] http://java.sun.com/j2se/1.4.2/docs/guide/reflection/proxy.html
>
> On 2/7/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > The ping response is a best effort. The default is to say "it reached
> > the msg receiver so all is ok." Obviously that's not always true- e.g.,
> > class load errors can occur after that. (Or imagine the service is
> > implemented by a BPEL script- one of the external services may be
> > missing.)
> >
> > So a given message receiver can do better if it can and wants to. If its
> > a Java MR it can try to load the class before replying for example. We
> > don't want to dictate terms to the MR.
> >
> > Its well and good that the message made it thru the handlers but that
> > doesn't say that the service will work (or is likely to work; this is
> > not a transactional thing after all) when its invoked. Delivering the
> > ping all the way to the MR gives maximum opportunity for the best effort
> > answer of "how are you doing" to be as good as it can be.
> >
> > Unfortunately there's no way to do that without adding another method to
> > the MR interface. We will provide a default impl which simply returns
> > true .. meaning "yep ping went thru" but we encourage MR authors
> > (including our tools) to do better.
> >
> > Thanks,
> >
> > Sanjiva.
> >
> > On Wed, 2007-02-07 at 12:13 +0530, Deepal Jayasinghe wrote:
> > > > Hi Dims, Deepal
> > > >
> > > > Actually the idea is to develop a custom ping module with appropriate
> > > > handlers. One of the ping handlers should be added to the dispatch
> > > > phase before the 'InstanceDispatcher' (Inflow). If the service is
> > > > deployed and it is active, then ping handler can get the service
> > > > status from AxisConfiguration. If the service is not deployed then the
> > > > service information is not available in the AxisConfiguration. Then
> > > > the ping module can respond to the ping requests accordingly.
> > >
> > > +1
> > >
> > > >
> > > > well... this is the fundamental functionality of the ping module,
> > > > monitoring the availability of the services deployed in axis2. But
> > > > extending the MessageReceiver api with a ping method will enhance this
> > > > functionality.
> > >
> > > Managing a service (like sending a ping message) is generic requirement
> > > or a specific requirement, as I can see it is very specific requirement.
> > > So Im not that much like to change the MR api to cope with requirement.
> > >
> > > > Since the method is added to the AbstractMessageReceiver it will not
> > > > break the existing implementations of the MessageReceiver interface.
> > > > This ping method can be used to check real status of the services,
> > > > whether they are up and running. There may be instances, where the
> > > > services are available but they are not in a position to respond to
> > > > requests.
> > >
> > > So , how come that response to ping request if it is in such a position :)
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
>
> --
> Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
>
> ---------------------------------------------------------------------
> 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
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Davanum Srinivas <da...@gmail.com>.
I think i'd like to see a patch before we go further. Am not convinced
this is the best approach. We could do a custom dispatcher that could
insert a java dynamic proxy[1] under certain conditions (custom soap
header?) to get the same kind of behavior.
Thanks,
dims
[1] http://java.sun.com/j2se/1.4.2/docs/guide/reflection/proxy.html
On 2/7/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> The ping response is a best effort. The default is to say "it reached
> the msg receiver so all is ok." Obviously that's not always true- e.g.,
> class load errors can occur after that. (Or imagine the service is
> implemented by a BPEL script- one of the external services may be
> missing.)
>
> So a given message receiver can do better if it can and wants to. If its
> a Java MR it can try to load the class before replying for example. We
> don't want to dictate terms to the MR.
>
> Its well and good that the message made it thru the handlers but that
> doesn't say that the service will work (or is likely to work; this is
> not a transactional thing after all) when its invoked. Delivering the
> ping all the way to the MR gives maximum opportunity for the best effort
> answer of "how are you doing" to be as good as it can be.
>
> Unfortunately there's no way to do that without adding another method to
> the MR interface. We will provide a default impl which simply returns
> true .. meaning "yep ping went thru" but we encourage MR authors
> (including our tools) to do better.
>
> Thanks,
>
> Sanjiva.
>
> On Wed, 2007-02-07 at 12:13 +0530, Deepal Jayasinghe wrote:
> > > Hi Dims, Deepal
> > >
> > > Actually the idea is to develop a custom ping module with appropriate
> > > handlers. One of the ping handlers should be added to the dispatch
> > > phase before the 'InstanceDispatcher' (Inflow). If the service is
> > > deployed and it is active, then ping handler can get the service
> > > status from AxisConfiguration. If the service is not deployed then the
> > > service information is not available in the AxisConfiguration. Then
> > > the ping module can respond to the ping requests accordingly.
> >
> > +1
> >
> > >
> > > well... this is the fundamental functionality of the ping module,
> > > monitoring the availability of the services deployed in axis2. But
> > > extending the MessageReceiver api with a ping method will enhance this
> > > functionality.
> >
> > Managing a service (like sending a ping message) is generic requirement
> > or a specific requirement, as I can see it is very specific requirement.
> > So Im not that much like to change the MR api to cope with requirement.
> >
> > > Since the method is added to the AbstractMessageReceiver it will not
> > > break the existing implementations of the MessageReceiver interface.
> > > This ping method can be used to check real status of the services,
> > > whether they are up and running. There may be instances, where the
> > > services are available but they are not in a position to respond to
> > > requests.
> >
> > So , how come that response to ping request if it is in such a position :)
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
The ping response is a best effort. The default is to say "it reached
the msg receiver so all is ok." Obviously that's not always true- e.g.,
class load errors can occur after that. (Or imagine the service is
implemented by a BPEL script- one of the external services may be
missing.)
So a given message receiver can do better if it can and wants to. If its
a Java MR it can try to load the class before replying for example. We
don't want to dictate terms to the MR.
Its well and good that the message made it thru the handlers but that
doesn't say that the service will work (or is likely to work; this is
not a transactional thing after all) when its invoked. Delivering the
ping all the way to the MR gives maximum opportunity for the best effort
answer of "how are you doing" to be as good as it can be.
Unfortunately there's no way to do that without adding another method to
the MR interface. We will provide a default impl which simply returns
true .. meaning "yep ping went thru" but we encourage MR authors
(including our tools) to do better.
Thanks,
Sanjiva.
On Wed, 2007-02-07 at 12:13 +0530, Deepal Jayasinghe wrote:
> > Hi Dims, Deepal
> >
> > Actually the idea is to develop a custom ping module with appropriate
> > handlers. One of the ping handlers should be added to the dispatch
> > phase before the 'InstanceDispatcher' (Inflow). If the service is
> > deployed and it is active, then ping handler can get the service
> > status from AxisConfiguration. If the service is not deployed then the
> > service information is not available in the AxisConfiguration. Then
> > the ping module can respond to the ping requests accordingly.
>
> +1
>
> >
> > well... this is the fundamental functionality of the ping module,
> > monitoring the availability of the services deployed in axis2. But
> > extending the MessageReceiver api with a ping method will enhance this
> > functionality.
>
> Managing a service (like sending a ping message) is generic requirement
> or a specific requirement, as I can see it is very specific requirement.
> So Im not that much like to change the MR api to cope with requirement.
>
> > Since the method is added to the AbstractMessageReceiver it will not
> > break the existing implementations of the MessageReceiver interface.
> > This ping method can be used to check real status of the services,
> > whether they are up and running. There may be instances, where the
> > services are available but they are not in a position to respond to
> > requests.
>
> So , how come that response to ping request if it is in such a position :)
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Davanum Srinivas <da...@gmail.com>.
Sameera,
We've implemented ws-trust/ws-secconv/ws-rm w/o needing to extend the
API. So please take it out of the equation.
thanks,
dims
On 2/7/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
> > Hi Dims, Deepal
> >
> > Actually the idea is to develop a custom ping module with appropriate
> > handlers. One of the ping handlers should be added to the dispatch
> > phase before the 'InstanceDispatcher' (Inflow). If the service is
> > deployed and it is active, then ping handler can get the service
> > status from AxisConfiguration. If the service is not deployed then the
> > service information is not available in the AxisConfiguration. Then
> > the ping module can respond to the ping requests accordingly.
>
> +1
>
> >
> > well... this is the fundamental functionality of the ping module,
> > monitoring the availability of the services deployed in axis2. But
> > extending the MessageReceiver api with a ping method will enhance this
> > functionality.
>
> Managing a service (like sending a ping message) is generic requirement
> or a specific requirement, as I can see it is very specific requirement.
> So Im not that much like to change the MR api to cope with requirement.
>
> > Since the method is added to the AbstractMessageReceiver it will not
> > break the existing implementations of the MessageReceiver interface.
> > This ping method can be used to check real status of the services,
> > whether they are up and running. There may be instances, where the
> > services are available but they are not in a position to respond to
> > requests.
>
> So , how come that response to ping request if it is in such a position :)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> Hi Dims, Deepal
>
> Actually the idea is to develop a custom ping module with appropriate
> handlers. One of the ping handlers should be added to the dispatch
> phase before the 'InstanceDispatcher' (Inflow). If the service is
> deployed and it is active, then ping handler can get the service
> status from AxisConfiguration. If the service is not deployed then the
> service information is not available in the AxisConfiguration. Then
> the ping module can respond to the ping requests accordingly.
+1
>
> well... this is the fundamental functionality of the ping module,
> monitoring the availability of the services deployed in axis2. But
> extending the MessageReceiver api with a ping method will enhance this
> functionality.
Managing a service (like sending a ping message) is generic requirement
or a specific requirement, as I can see it is very specific requirement.
So Im not that much like to change the MR api to cope with requirement.
> Since the method is added to the AbstractMessageReceiver it will not
> break the existing implementations of the MessageReceiver interface.
> This ping method can be used to check real status of the services,
> whether they are up and running. There may be instances, where the
> services are available but they are not in a position to respond to
> requests.
So , how come that response to ping request if it is in such a position :)
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Sameera Madushan <sa...@gmail.com>.
Hi Dims, Deepal
Actually the idea is to develop a custom ping module with appropriate
handlers. One of the ping handlers should be added to the dispatch phase
before the 'InstanceDispatcher' (Inflow). If the service is deployed and it
is active, then ping handler can get the service status from
AxisConfiguration. If the service is not deployed then the service
information is not available in the AxisConfiguration. Then the ping module
can respond to the ping requests accordingly.
well... this is the fundamental functionality of the ping module, monitoring
the availability of the services deployed in axis2. But extending the
MessageReceiver api with a ping method will enhance this functionality.
Since the method is added to the AbstractMessageReceiver it will not break
the existing implementations of the MessageReceiver interface. This ping
method can be used to check real status of the services, whether they are up
and running. There may be instances, where the services are available but
they are not in a position to respond to requests. If the required
dependencies are not available for the services, then they fail to respond
and also in some cases there may be some things to be completed before the
services can actually respond. These service dependent issues can be
monitored using the pinging capability, if we provide the ping method to the
message receiver implementers.
Thanks
Sameera
On 2/7/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
> Hi Sameera ;
>
> > Hi all,
> >
> > Managing the deployed web services is becoming mandatory and
> > important, because the usage of web services is increasing in the
> > enterprise. One requirement which can arise in managing the web
> > services is to monitor the availability of the services and to check
> > the status of the services whether they are up and running. And also
> > service managers may need to perform these activities periodically. In
> > some cases, services can be down for maintenance, then there has to be
> > a way for the requesters to check its availability.
> >
> > In the current situation invoking the service is the only option to
> > get the status of the services. But invoking each and every service
> > for this purpose is not a good idea either.
> >
> > The above requirements can be satisfied by introducing a pinging
> > capability to the service deployed in Axis2. Here is how it happens.
> > Users can send ping requests to the specified services. For these
> > requests, ping responses can be sent indicating service status.
> >
> > Extending the AbstractMessageReceiver api with a method(say ping)
> > which returns a boolean value, will enable message receiver
> > implementors to write their own logic to test the status of the
> > service. For an example in this ping method, one can check whether the
> > required dependencies for the service is available or not.
>
> I dont see any requirement of changing API , if you want to know the
> service is up and running then what you can do is get the service state
> from AxisConfiguration. You can get the status of the ho from
> AxisConfiguration where it is active or not.
>
> Thanks
> Deepal
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Sameera ;
> Hi all,
>
> Managing the deployed web services is becoming mandatory and
> important, because the usage of web services is increasing in the
> enterprise. One requirement which can arise in managing the web
> services is to monitor the availability of the services and to check
> the status of the services whether they are up and running. And also
> service managers may need to perform these activities periodically. In
> some cases, services can be down for maintenance, then there has to be
> a way for the requesters to check its availability.
>
> In the current situation invoking the service is the only option to
> get the status of the services. But invoking each and every service
> for this purpose is not a good idea either.
>
> The above requirements can be satisfied by introducing a pinging
> capability to the service deployed in Axis2. Here is how it happens.
> Users can send ping requests to the specified services. For these
> requests, ping responses can be sent indicating service status.
>
> Extending the AbstractMessageReceiver api with a method(say ping)
> which returns a boolean value, will enable message receiver
> implementors to write their own logic to test the status of the
> service. For an example in this ping method, one can check whether the
> required dependencies for the service is available or not.
I dont see any requirement of changing API , if you want to know the
service is up and running then what you can do is get the service state
from AxisConfiguration. You can get the status of the service from
AxisConfiguration where it is active or not.
Thanks
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Pinging capability to services deployed in Axs2
Posted by Davanum Srinivas <da...@gmail.com>.
Sameera,
Why should we extend the API? Is it not possible to do this with a
custom ping module with appropriate handlers?
thanks,
dims
On 2/6/07, Sameera Madushan <sa...@gmail.com> wrote:
> Hi all,
>
> Managing the deployed web services is becoming mandatory and important,
> because the usage of web services is increasing in the enterprise. One
> requirement which can arise in managing the web services is to monitor the
> availability of the services and to check the status of the services whether
> they are up and running. And also service managers may need to perform these
> activities periodically. In some cases, services can be down for
> maintenance, then there has to be a way for the requesters to check its
> availability.
>
> In the current situation invoking the service is the only option to get the
> status of the services. But invoking each and every service for this purpose
> is not a good idea either.
>
> The above requirements can be satisfied by introducing a pinging capability
> to the service deployed in Axis2. Here is how it happens. Users can send
> ping requests to the specified services. For these requests, ping responses
> can be sent indicating service status.
>
> Extending the AbstractMessageReceiver api with a method(say ping) which
> returns a boolean value, will enable message receiver implementors to write
> their own logic to test the status of the service. For an example in this
> ping method, one can check whether the required dependencies for the service
> is available or not.
>
> In order to identify ping requests soapaction can be used. Based on the
> soapaction "ping handler" can invoke the ping method of message receiver.
>
> Thanks
> Sameera Madushan
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org