The challenges of monitoring SOA can be overcome by instrumenting the services for monitoring and management. A service that does not provide any status on its health or the execution of a transaction is like a black box - the service consumer and the administrators who monitor the environment cannot tell if things are working.

There are several techniques for instrumenting services for monitoring. You can implement a heart beat whereby the service sends an "I am alive" message that can be picked up by a monitor. This is a simple task but does not really tell you if the service is working - only that it is running and has the ability to send a message. This however, is more that an OS level monitor will tell you. You can set up the monitor to automatically register the service for monitoring when it sees the heart beat the first time.

You can also develop a monitoring interface I call a "ping" interface. You send the ping interface a message and the interface can do some internal verifications of functionality and respond. This tells you more than the service is simply up and running. You can also build in the support of a "synthetic transaction" where you send specific transactions to a set of services and they execute the transaction but with no impact to the business - like updating a test account. But, to tell if a service is running properly in the context of all business transactions you have to develop a framework for application-level monitoring.

Application-level monitoring requires status data about each business transaction. The ability to monitor an application in a business or transactional context requires a monitoring interface within the service to send messages detailing the transaction's status specific to the service invocation. This requires each service to send a status message at critical steps in the business transaction. You can then build a real-time viewer to correlate status messages (based on the semantics of the message - e.g. transaction ID) with the services within the composite application. This provides an end-to-end view of the business transaction for SLA management, fault tracing and problem determination.

The monitoring interface could also support a "trace mode" for problem determination, in which more detail is provided in the status messages. An audit service is responsible for recording messages in the monitoring framework. The audit service should be implemented as a state machine that can consume and record messages based on criteria defined in its configuration. A generic exception handler can also use the audit service to support a centralized view of problems that occur in the enterprise SOA - to support exception-based monitoring.

If you have existing services that are not using a monitoring framework, the services can be monitoring using an agent. The agent should be customized to understand the proper pattern of behavior for the service and send an exception message if the service shows aberrant behavior. The agent could also implement a ping and heart beat for the service by interacting with the service as a consumer.

Based on Forrester's ratings, the vendor coming out on top is Progress Software, with strong offerings also available from IBM, SOA Software, WSO2, and Managed Methods. As Heffner describes in the evaluation report, "Progress Actional has visibility into the broadest range of SOA infrastructure, and its agents have among the deepest capabilities to correlate service requests and responses as they flow through Java and .NET runtimes."

Progress's offerings received a weighted rating of 4.33 on a scale of 1 to 5, including factors such as monitoring and management reach and richness, performance and availability management, business transaction management, trust enablement, policy management, and product architecture. SOA Software was the runner-up with a rating of 3.53 for its product set.

Progress also topped the list in terms of strategy (4.65), while IBM took the lead in market presence (4.39).