As a flexible and versatile Web service management tool, JaxView can be deployed in different configurations in order to accomplish different objectives. This section describes the different deployment configurations for JaxView monitoring and policy enforcement and what functionality is available with each option. This section also includes an overview of the JaxView data storage options which allow you to scale your deployment to fit your environment. The deployment configuration you choose will depend on what operational requirements, policies, and management objectives you need to meet.
The following table presents the four primary JaxView monitoring and policy enforcement deployments. Each entry includes a short description of the key functionality that is available with each configuration. Use the links in the table to view more information about each option in the sections below the table.
|
Deployment Type |
Description |
|
Virtualizes Web services. All message traffic is directed through a JaxView server which can then meter activity and performance as well as enforce authentication and other policies in the SOA environment. |
|
|
Enables auto-discovery of Web services by identifying Web service message traffic packets through a network analyzer |
|
|
Simplifies Web service message monitoring by subscription to existing Enterprise Service Busses/ Message Brokers in the environment. |
|
|
Provides selective performance monitoring in restricted environments |
This is the most powerful and versatile JaxView deployment option for Web service monitoring and governance. This deployment "virtualizes" multiple Web service provider addresses to a single gateway. This also
Figure 1 - JaxView deployed as a gateway or proxy to collect messages and enforce authentication and other policies.
The following are some reasons to select this deployment configuration:
The following are some considerations for selecting this deployment option:
Multiple JaxView can be clustered behind a load balancer to scale capacity and minimize performance impacts. See the section JaxView Data Management and Reporting Options for a diagram describing this option.
The servers on which JaxView is installed should be sized to accommodate the expected traffic load.
See the section Using JaxView as a Proxy Server for more information about using JaxView as a proxy server.
JaxView can be used together with a network analyzer to auto-discover Web service message traffic and automatically configure itself to monitor the message traffic.
Figure 2 - JaxView deployed to detect Web service endpoints and messages through a connection with a network analyzer.
JaxView and the third-party network sniffer must have access to a network location where all of the message traffic to be monitored passes.
Alternatively, two or more JaxView/network analyzers may be deployed at different network segments and the metrics can be aggregated to an external database. See the section JaxView Data Management and Reporting Options below for more information on using databases with JaxView.
See the section JaxView as Network Appliance for more information about using JaxView in this configuration.
JaxView can be configured to receive Web service messages from a compatible ESB or Message Service Broker. Message data is sent to JaxView using the Java Messaging Service protocol.
Figure 3 - JaxView deployed to collect messages through subscription to an Enterprise Service Bus.
This deployment option is suitable for environments that:
See the section Connecting to an Enterprise Service Bus or Message Broker for more information about using JaxView in this configuration.
This option uses agent stubs that are installed on remote application servers and configured to send copies of messages to JaxView. The following figure illustrates the concept of this deployment option.
Figure 4 - JaxView deployed to aggregate messages from agent stubs installed on Web application containers.
This deployment option is suitable for environments that:
See the section Installing JaxView Agent Stubs for more information about using JaxView in this configuration.
The default data storage for JaxView is the filesystem of the server where JaxView is running. This data store is used to record message statistics and generate performance reports.
JaxView can also be configured to store message metrics data in an external JDBC-enabled database. This can be used for a single JaxView server or to aggregate data from multiple JaxView servers. This allows for report data integrity for several deployment options including:
The following figure illustrates the use of an external database for a JaxView cluster deployed as a gateway behind a load balancer.
Figure 5 - JaxView cluster used as a gateway to Web service providers with data stored in an external database.
The following figure illustrates an example of multiple JaxView servers deployed to listen to multiple Enterprise Service Bus servers.
Figure 6 - JaxView configured to receive messages from ESBs with data stored in an external database.
When JaxView is configured to store data in an external database, both the JaxView configuration settings and monitoring metrics are stored in the database. Storing configuration information in the database enables configuration replication between multiple JaxView servers, such as would be used in a gateway cluster. In some situations, there may be a need to separate the configuration datastore from the monitoring data. For example, in some environments the rate of message data accumulation may be high although changes to the JaxView configuration settings are infrequent. In such as case, JaxView can be configured to use a separate database for storing configuration data and monitoring metrics data. The following figure illustrates this optional configuration.
Figure 7 - JaxView configured to store configuration data in one external database and monitoring metric data in a separate database.