Tata AIG General Insurance Company - Insurer Innovation Award 2024
The Service doing "Ping"
1. The Service doing “Ping”
In a Service-Oriented Architecture, implementing
“ping” utilities to monitor services and to deduce
business information such as checking SLAs is prone
to error Ignaz Wanders
2. The Ping Utility
• Ping is originally a computer network administration utility used to test the
reachability of a host on an IP network and to measure the round-trip time for
messages sent from the originating host to a destination computer. (Wikipedia)
• The term originates from active sonar technology
• Defined in 1983
• Phased out from 2003 onwards
– Exploited by internet worms to find new computers
– Added load to the system, causing problems with routers across the internet
– Considered a security risk
• E.g., Ping of Death (malformed ping resulting in buffer overflow)
See http://en.wikipedia.org/wiki/Ping_(networking_utility)
3. The world of services
Service
Consumer
application
Service
Service
“My service provider says he is
available at least 90% of the time, so
I will check him out regularly if he
keeps his promise!”
2
“My service depends on
another service, so I will not
make my service available if
my service provider is not
available.”
3
1
“If I depend on the availability of
another service, I’ll ask if it is
available, just before I use it.”
“I need a ping!”
4. The world of service pings
Service
Consumer
application
Service
Service
Ping()
Ping()
Ping()
Each service offers a Ping operation
in the interface (WSDL)
“I need a ping!”
5. Real-life example 1: A service with special ping operation
<wsdl:operation name="ping">
<soap:operation style="document" soapAction="" />
<wsdl:input>
<soap:header message="tns:Ping" part="header" use="literal" />
<soap:body parts="body" use="literal" />
</wsdl:input>
<wsdl:output>
<soap:header message="tns:PingResponse" part="header" use="literal" />
<soap:body parts="body" use="literal" />
</wsdl:output>
</wsdl:operation>
7. See if it is there, by using ping
1 “If I depend on the availability of
another service, I’ll ask if it is
available, just before I use it.”
This is brilliant. The network is known to have availability
issues every now and then, especially with synchronous
protocols like HTTP.
So before calling a SOAP web service, let’s do a ping first. If the
service doesn’t answer, we don’t call it with the real request.
Flaws:
1. There is no guarantee that after a successful ping, the real
request will pass through.
2. An unsuccessful ping does not guarantee that the real
request would not have passed through.
The conclusion drawn from the result of the ping can very well be wrong
8. See if it is there, by using ping
1 “If I depend on the availability of
another service, I’ll ask if it is
available, just before I use it.”
Solution:
Just call the service with the real request and make sure that
you handle a connection error properly.
This way, you have never taken the wrong decision.
Compared with the ping “solution,” there will be more
successful hits, which means more business.
9. Monitoring, by using ping
“My service provider says he is
available at least 90% of the time, so
I will check him out regularly if he
keeps his promise!”
2 Let’s do a ping every n minutes, and calculate the availability
percentage of the provider. This is a measure of the uptime of
the service provider.
Flaws:
1. There is no guarantee that between two successful
pings, the service was really available.
2. An unsuccessful ping can be an intermittent network
issue of very short duration, but it may be counted as n
minutes
The conclusion drawn from the monitoring by pinging has nothing to do with
the real statistics of uptime of the provider
10. Monitoring, by using ping
“My service provider says he is
available at least 90% of the time, so
I will check him out regularly if he
keeps his promise!”
2
Solution:
Just call the service with the real request and make sure that
you handle a connection error properly.
It doesn’t matter if the service provider is off-air in between
requests. All that matters is that at least x percent of your
requests are served correctly. That’s what needs to be stated
in a service level agreement. And that is what is measurable.
11. Proactive service provisioning, by using ping
“My service depends on another
service, so I will not make my service
available if my service provider is
not available.”
3 Let’s do a ping of the service provider. If he doesn’t answer I
will close down my web application so consumers can’t use
this functionality. That avoids frustration of the people
receiving connection errors.
I’ll open the web application again after a successful ping.
(no kidding, this exists in real life!)
Flaws:
1. There can be no guarantee the service is down. The web
application will sometimes be shut down erroneously.
This can result in missed business.
The conclusion drawn from the unsuccessful ping is invalid.
12. Proactive service provisioning, by using ping
“My service depends on another
service, so I will not make my service
available if my service provider is
not available.”
3
Solution:
Just call the service with the real request and make sure that
you handle a connection error properly.
Even in this way you can shut down the web application, for
example after p unsuccessful requests.
Compared with the ping “solution,” there will be more
successful hits, which means more business.
