Monitoring Services
JaxView segments monitors into three different categories: performance, transaction, and availability monitoring. Performance monitors track the performance and operability of the services to which they are applied, including response time, message size, fault rate, and usage. Performance monitors can be base lined to ensure alerts are triggered with respect to previous performance trends. Transaction monitoring allows you to teach JaxView how messages are related by context (there is support for WS-Transaction and WS-Coordination) across services and then see the transaction tracked as it moves through its members. There is passive SOAP transaction tracking and also an active heartbeat mode where JaxView will issue dye messages that you configure in accordance with the transaction context. The third type of monitor – active heartbeat – involves sending canned requests to service endpoints (both SOAP and REST styles) to keep up with service performance even when not in use by consumers.

JaxView alerts are driven by rules that you configure with respect to monitors, which in turn generate events when a condition is met, like the breach of a threshold. Rules can be complex in that they consider data from multiple monitors. For example, if monitor A has breached its threshold and monitor B has not, fire the rule. Standard rule types include “always,” “once,” and “multiple.” These rules always fire when an error condition is present, once for a string of recurring errors, and once until a variable number of recurrences happen, respectively. Alerts in JaxView are tied to rules, are reusable, and perform notification actions. Alert types include email, J2EE JMS channel, SMNP, SOAP callout, and script execution. Alerts fit in the service hierarchy below rules that are themselves tied to monitors. The hierarchy is visible in Figure 1.

Managing Services
Managing services involves applying policies to service-consumer interactions. Such policies include security policies as well as routing, transformation, and throttling policies. Consistent with best practices for policy administration and enforcement, policies in JaxView are defined and managed globally and can be reused across multiple services in the service hierarchy. Security policies in JaxView run the gamut – access control, encryption/decryption, digital signature validation, and SSL handshake between the JaxView proxy and the service endpoint. Access control is quite interesting in that policies can be written that directly interact with client access lists (client records administered in JaxView) as well as against LDAP/AD. In the case of access control, JaxView can authenticate service users in one of three ways. First, direct client bind to LDAP with the inbound request username/password can be used. Also, an identity assertion on a user ID against LDAP can be used where the username/password is searched and then used to bind to the LDAP server. Last, role-based access control (RBAC) is achieved by configuring the LDAP search for services and user IDs to return role assignments – if no role mappings are returned, access is denied.

When JaxView is used as a proxy, transformation policies can be enforced where the request or response is altered with an XSLT transform. Requests can be throttled in the presence of too many requests, either total requests or on a per-client basis. In addition, content routing policies can be applied whereby requests are re-routed (or blocked entirely) based on an expression (regex or XPath) match against request content. Routing policies can also be scheduled to apply only at certain times of the day. JaxView will also import and enforce WS-Policy as well as publish policies to a UDDI registry.

Reports
JaxView includes both scheduled and on-demand performance and operability reports for the services it monitors. Scheduled reports include general performance reports and SLA reports that include summary performance and fault data as well as SLA violations, and you can configure JaxView to email the reports to a distribution group. Of course, the reports are also available in the JaxView console. On-demand reports include dynamic reports that give a view of the performance and operation of a service over a configurable window of time, including all monitors assigned to the service in both tabular and graphical format. Figure 3 illustrates the tabular section of such a report while Figure 4 is a slice of the graphical section. A message report type is also available in which message traffic between services and consumers is displayed for a configurable period of time.

Other Interesting Features
By now I am sure you have picked up on the fact that JaxView is, on the one hand, easy-to-use and get started with and, on the other, quite feature-rich. Some other interesting bits include its agent stub library – covering SunOne, WebLogic, WebSphere, Tomcat/Axis, Systinet, IONA Artix, and .NET. It also has an open API that lets you develop your own active monitors, alerts, custom logs, and request and response modification policies. JaxView is also industrial strength – it can be deployed in a cluster configuration to support high availability and scale requirements.

Conclusion
If you have been looking for a web service monitoring and management tool but don’t have a boatload of money, look no further – JaxView from Managed Methods is the tool for you. It is remarkably easy-to-use and provides quick time-to-value while offering a deep and wide set of governance features that are otherwise found on tools with a much larger footprint and price. You’ll love the monitoring, management, and reporting features and will find the tool easy to grow into to suit your governance needs.