The Service doing "Ping"
0 likes750 views
1) Ping utilities were originally used to test network reachability but have been phased out since 2003 due to security risks and added load to systems. 2) In a service-oriented architecture, using ping operations or services to monitor other services' availability or deduce business information like SLAs is prone to error, as ping results do not guarantee the real request will pass through or that an unsuccessful ping means the request would fail. 3) Rather than using pings, services should call each other directly and implement proper error handling to determine actual availability and responsiveness over time based on real requests. This leads to more successful requests and better business outcomes.
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>
- 6. Real-life example 2: A special ping service
- 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.
- 13. Conclusion Death to ping services or operations.
- 14. Conclusion Rather use proper error handling!