Managing applications in a service-oriented architecture creates several challenges. Many operational processes have to be in place to make sure that issues are identified and resolved effectively. Tools that are used in the operational environment need to be installed easily and be flexible enough to fit the service architecture and organizational processes without causing disruption or requiring re-architecting.

Based on open standards, JaxView is designed to integrate easily into the a variety of service-oriented architectures. The JaxView application itself runs on a single server and is accessed using a Web browser. The sections below describe the JaxView application architecture and different deployment options in which it may be used for SOA management to monitor service messaging.

JaxView Deployment Architectures

There are several ways in which JaxView can be deployed into the Web services environment to meet the requirements of SOA management. The following describe the main deployment architectures.

JaxView as Service Gateway / Proxy

JaxView can be used as a proxy server to forward messages from Web services clients to the service endpoints. This allows the JaxView server to be deployed in the role of a service gateway. In this architecture, all service messages are routed through the JaxView proxy where copies of message data are forwarded to the processing modules and service requests are forwarded to service endpoints. It is this deployment architecture that enables the majority of policy enforcement and runtime governance features in JaxView. When installed in this configuration JaxView can be used as an XML firewall and security. It can also enable Closed-loop management of service infrastructures through bi-directional communication with UDDI registries.

JaxView as an Agentless Network Appliance

JaxView can be deployed to monitor Web services as a network appliance. This eliminates the need to install message agents on application servers. In this architecture, JaxView is configured to passively listen to network traffic, monitoring packets for Web service requests and responses. It then records the service information and message data for management purposes. This also enables autodiscovery of Web services and can help uncover rogue services in the environment. This truly agentless monitoring option that has very low overhead and minimizes additional traffic on the network. If the proxy server deployment is not permitted or feasible then this is a perfect, low-impact deployment architecture to use.

JaxView as Enterprise Service Bus Subscriber

JaxView can connect to ESB's from vendors such as BEA, SONIC, Cape Clear,and others that use JMS messaging. JaxView can subscribe to topics on these servers to get copies of both standard SOAP and non-standard Web service messages.

JaxView as Messaging Agents Aggregator

The messaging agent component is a lightweight module that is installed on the container where a Web service is run. This agent is non-intrusive in that generally no code modifications are needed at the Web service nor are header modifications required at the consumer. The container could be an application server (Weblogic, Websphere, Sun One, IIS, etc..) or an ESB or Message Broker that supports JMS. The target application container is made aware of the message agent such that service request and response messages for the Web services are replicated to the JaxView server. Almost no processing of the messages occurs at the container level. The communication protocol between the agent and the JaxView server is either over HTTP or HTTPS.

JaxView Application Architecture

The JaxView application consists primarily of the server which is functional as a standalone component. Depending on the architecture in which JaxView is deployed, other components may also be considered part of the JaxView application architecture as described below.

JaxView Server

The server component handles all processing of monitored Web service data and runtime governance policies. The messages are fed through a monitor engine that generates the necessary metrics and then through a rule/alert engine which checks for correlations and initiates event generation. The data is subsequently passed to logging module where it is written to the storage repository. A report engine retrieves stored data for report generation. The JaxView server also includes the following architecture elements:

• JaxView Open APIs - The application includes a set of program interface points that allows for custom integration with the IT operation infrastructure. A monitor API allows the creation of custom monitor types. An alert API can be used to generate customized event notifications such as a SOAP request to another Web service or Enterprise System Management (ESM) Console. A data logging API allows customization of data storage to be compatible with specific storage schemas and systems. The logging API also allows for integration with an ESM console.
• JaxView Web Service Configuration Interface - JaxView includes a Web service interface that allows for configuration of the application by a SOAP client. This can be used to more completely integrate JaxView into the active and evolving SOA management infrastructure. It also allows JaxView to be deployed in a completely distributed fashion to be able to handle high traffic loads.

Message Agents (optional)

JaxView includes an optional module that may be used as a agent to forward service message data from Web application servers to the JaxView server. The use of messaging agents is only one of the deployment architectures for JaxView as described in the section on JaxView Deployment Architecture. The agent module may be replicated to multiple servlet containers or servers where it forwards data essential for JaxView's management functions. When this option is used, the messaging agents are components of the JaxView system.

External Database (optional)

By default, the JaxView application will use the local file system to store data that it collects and processes. Depending on the deployment options chosen, or the data storage and processing requirements of the organization, JaxView can be configured to use an external database for data storage. In this configuration, JaxView would also use the database for its configuration settings, in which case the external database would be considered a component of the JaxView system.