P41. A service shall provide heartbeat and traffic monitoring

Skip to end of metadata
Go to start of metadata


A heartbeat is necessary to be able pro actively react when a service is not responding according to SLA

We want to keep track of the following:

  • Does the service provide business value?
  • Is the service functioning according to its SLA
  • Where is a service-composition failing


  • Monitor and understand which services are used, and how many times they are used.
  • Understand which services are candidates for change orders
    • if a service is unused, it does not provide value to its owners/users
  • Locate services to be terminated
  • A heartbeat is necessary to be able pro actively react when a service is not responding according to SLA
    • This monitoring can will tell you which service(s) are not working
    • A heartbeat is proof of SLA conformance/non-conformance

Exceptions/special cases


See: P32. A service shall document its Service Level Agreement SLA (response time=30ms, availability=99.995%)


Doc status H2A A2A ACS CS Last PAB discussion

PAB discussions

Design-Time Governance - SOA Design Rules FAQ

  • [Question still to be asked..]
policy_h2a policy_h2a Delete
policy_cs policy_cs Delete
policy_acs policy_acs Delete
policy_a2a policy_a2a Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. May 26, 2010

    Any sugestions on tools we can use to fulfill this rule?

    1. May 26, 2010

      If you are using Web Services you could use SoapUI-scripts and automate them with maven, and then use some kind of automatic build-server like continuum to run your tests. It's not a specially tailored solution, and it's quite rudimentary, but it does work.

      The advantage of this solution is the simplicity, since you are just calling your services through a SoapUI test you can be sure that it's actually running and not a health script returning OK. You may run into problems if your service changes state (a "write" services), but we have implemented a "test-flag" on all Web Services that lets you call "write"-services this way. This works well, and we have a monitoring applications (Indicative Firehunter) that constantly pols the services every 5 or 10 minutes. This way you can also proove that your services are responding according to maximum response time in your SLA.

  2. May 26, 2010

    Monitoring by JMX and heartbeat by sending UDP heartbeat packages is usually recommended practice

    1. May 26, 2010

      In order to be proactive in regards to memory and CPU usage (and much more) JMX is definately the way to go (if you're using Java). Most modern professional monitoring suites support JMX.

  3. May 27, 2010

    Thnx folks. Will look into JMX for this purpose.

    Not sure it will solve the error notification task though. Totto previously sugested XMPP for this.
    Will look into that too.

    The challenge is really to have a good solution for listening to these messages, and then do some action based on the incoming info. This is what I hoped Nagios would do for me. Do you know of any good alternatives?

    1. May 27, 2010

      I think the most important thing is to base the solution on open standards. That way you can probably adopt any kind of monitoring software, like XMPP or SNMP. Of course, something as simple as e-mail could also work.