Skip navigation.

Concepts and Architecture

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

System Administration and Operation Monitoring Concepts

This topic introduces AquaLogic Service Bus system administration and operation monitoring concepts. It is intended for system administrators and operators who manage and monitor AquaLogic Service Bus. It includes the following sections:

 


Security Management

AquaLogic Service Bus leverages the WebLogic Server security architecture and services to support secure message exchanges between services and the clients of those services. WebLogic Server supplies implementations of the following types of security features:

For detailed descriptions of these WebLogic Server security providers and WebLogic Server security architecture in general, see the BEA WebLogic Server Security documentation.

AquaLogic Service Bus security supports the WS-Policy specification. For more information about the WS-Policy specification, see the Web Services Policy Framework (WS-Policy) and Web Services Policy Attachment (WS-PolicyAttachment) which is available at:

http://specs.xmlsoap.org/ws/2004/09/policy/

WS-Policy describes what should be signed or encrypted in a message and what security algorithms should be applied. It also describes the authentication mechanism that should be used for the message when the message is received.

Using the AquaLogic Service Bus Console, you can configure a service with security policies that apply to messages in its interface. You can specify a security policy for a service or for individual messages associated with the operations of a service. When you specify a security policy for a service, the policy applies to all messages to that service.

The AquaLogic Service Bus Console also enables you to manage the credentials required for proxy service transport-level and message-level security. You manage business service and proxy service client credentials directly using WebLogic Server.

AquaLogic Service Bus enables you to use the WebLogic Server security providers at several different levels in its operation. The following sections provide introductions to the security available at each level:

User Management

AquaLogic Service Bus user management is built on the unified WebLogic Server security framework. This framework enables the AquaLogic Service Bus Console to support task-level authorization based on security policies associated with roles assigned to named groups or individual users. For more information on the WebLogic Server security framework, see the BEA WebLogic Server Security documentation.

You use the AquaLogic Service Bus Console to manage AquaLogic Service Bus users, groups, and roles. For information on how to manage AquaLogic Service Bus users, groups, and roles using the AquaLogic Service Bus Console, see Security Configuration in the Using the AquaLogic Service Bus Console.

Console Security

By default, the first user created for an AquaLogic Service Bus domain is a WebLogic Server Administrator. This user has full access to all AquaLogic Service Bus objects and functions, and can execute user management tasks to provide controlled access to AquaLogic Service Bus Console functionality. The following table shows the default roles and groups to which you can assign AquaLogic Service Bus users.

Table 3-1 AquaLogic Service Bus Default Roles and Groups

Role

Associated Group

Description

IntegrationAdmin

IntegrationAdministrators

Has complete access to all AquaLogic Service Bus resources, except cannot create, edit, or delete users, groups, roles, credentials, or access control policies.

IntegrationDeployer

IntegrationDeployers

Has read access to all objects. Can create, delete, edit, import, or export resources, services, proxy service providers, or projects.

IntegrationMonitor

IntegrationMonitors

Has read access to all AquaLogic Service Bus resources.

IntegrationOperator

IntegrationOperators

This group has the following privileges:

  • Has read access to all AquaLogic Service Bus resources

  • Has access to create, view, edit and delete alert rules

  • Has access to session management, including create, commit, discard and undo of sessions.


 

For information on how to manage AquaLogic Service Bus users, groups, and roles using the AquaLogic Service Bus Console, see Security Configuration in the Using the AquaLogic Service Bus Console.

Transport-Level Security

AquaLogic Service Bus supports transport-level confidentiality, message integrity, and client authentication for one-way requests or request/response transactions (from clients to AquaLogic Service Bus) over HTTPS. You can configure HTTP(S) proxy services or business services to require one of the following types of client authentication:

When a proxy service is activated, AquaLogic Service Bus generates and deploys a thin Web application. AquaLogic Service Bus relies on WebLogic Server for server-side SSL support, including session management, client certificate validation and authentication, trust management and server SSL key/certificate manipulation.

Transport security for transports other than HTTP is supported in AquaLogic Service Bus as follows:

For more information, see "Transport-Level Security" in Securing Inbound and Outbound Messages in the BEA AquaLogic Service Bus User Guide.

Message-Level Security

AquaLogic Service Bus supports OASIS Web Services Security (WSS) 1.0. For more information on the WSS specification, see the OASIS Web Services Security TC which is available at:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

WSS defines a framework for message confidentiality, integrity, and sender authentication for SOAP messages.

Using WSS, AquaLogic Service Bus provides support for securing messages using digital signatures, encryption, or both. While not a substitute for transport-level security, WSS is ideal for end-to-end message confidentiality and integrity. It is more flexible than SSL since individual parts of the SOAP envelope can be signed, encrypted or both, while other parts are neither signed nor encrypted. This is a powerful feature when combined with the ability of AquaLogic Service Bus to make routing decisions and perform transformations on the data based on the message content.

AquaLogic Service Bus currently supports WSS over HTTP/S and JMS.

For more information, see "Message-Level Security" in Securing Inbound and Outbound Messages in the BEA AquaLogic Service Bus User Guide.

 


Configuration Metadata Export and Import

AquaLogic Service Bus Console enables you to save your AquaLogic Service Bus resource configurations as metadata and export them in JAR files for import into other AquaLogic Service Bus domains. You can customize configuration settings as necessary to meet the requirements of the new environment before deploying the configuration using the Change Center in the AquaLogic Service Bus Console. This functionality supports an orderly promotion process of AquaLogic Service Bus resource configurations from staging and test environments into production.

Using the features of your source code control system in conjunction with the configuration JAR files, you can provide version and change management for your AquaLogic Service Bus configurations.

For information on how to export and import configuration metadata using the AquaLogic Service Bus Console, see System Administration in the Using the AquaLogic Service Bus Console. For information on how to modify configurations for new environments using the AquaLogic Service Bus Console Change Center, see Using the Change Center in the Using the AquaLogic Service Bus Console.

 


Dashboard, System Metrics, and Alerts

AquaLogic Service Bus aggregates run-time statistics that you can view in a customizable dashboard to monitor system health. You can also use the AquaLogic Service Bus Console to establish service level agreements (SLAs) for the performance of your system, and configure rules that trigger alerts to provide automated responses to SLA violations.

Figure 3-1 AquaLogic Service Bus Dashboard

AquaLogic Service Bus Dashboard


 

Dashboard

The AquaLogic Service Bus Console Dashboard displays information about system health organized by server and services. The health of a service is further You can drill down from summary pages to detailed information about individual servers, services, and alerts.

The Dashboard shows status information for a period of time that you can configure to meet your monitoring requirements. The following table lists the metrics that the Dashboard displays for each service.

Table 3-2 AquaLogic Service Bus Service Metrics

Metric

Description

Average Execution Time

For a proxy service, the average of the time interval measured between receiving the message at the transport and either handling the exception or sending the response.

For a business service, the average of the time interval measured between sending the message in the outbound transport and receiving an exception or a response.

Total Number of Messages

Number of messages sent to the service. In the case of JMS proxy services, if the transaction aborts due to an exception and places the message back in the queue so it is not lost, each retry dequeue is counted as a separate message. In the case of outbound transactions, each retry or failover is likewise counted as a separate message.

Messages With Errors

Number of messages with error responses.

For a proxy service, it is the number of messages that resulted in an exit with the system error handler or an exit with a reply failure action. If the error is handled in the service itself with a reply with success or a resume action, it is not an error.

For a business service, it is the number of messages that resulted in a transport error or a timeout. Retries and failovers are treated as separate messages.

Success/Failure Ratio

(Total Number of Messages - Number of Messages with Errors)/Messages with Errors

Security

Number of messages with WS-Security errors. This metric is calculated for both proxy services and business services.

Validation

Number of validation actions in the flow that failed. This metric only applies to proxy services.


 

These metrics are aggregated across the cluster for the configured aggregation interval. The Dashboard displays information about the overall health of the system, refreshing the display at a specified interval.

For more information about the AquaLogic Service Bus Console Dashboard, see Monitoring in Using the AquaLogic Service Bus Console.

Metric Aggregation

The information displayed on the Dashboard is based on an asynchronous aggregation of data collected during system operation. In an AquaLogic Service Bus production cluster domain, the AquaLogic Service Bus data aggregator runs as a singleton service on one of the managed servers in the cluster. Server-specific data aggregation is performed on each of the managed servers in the domain. The aggregator is responsible for the collection and aggregation of data from all the managed servers at regular, configurable intervals.

Alerts

AquaLogic Service Bus implements Service Level Agreements (SLAs) and automated responses to SLA violations by enabling you to define Rules that specify unacceptable service performance and the system response you require under those circumstances. You construct Rules using the AquaLogic Service Bus Console. AquaLogic Service Bus evaluates Rules against its aggregated metrics each time it updates that data.

When a Rule evaluates to True, it raises an alert. In addition to displaying information about the alert in the AquaLogic Service Bus Console Dashboard, AquaLogic Service Bus executes the action you specified for the Rule when it evaluates to True. You can assign any of the following types of action to a Rule:

It is also possible to configure specific operating times for alerts. For example, you can configure alerts to operate only during normal business hours.

Rule and alert processing is handled by the AquaLogic Service Bus Alert Manager. The Alert Manager resides on the same single managed server as the metric aggregator for the system.

For information on how to configure AquaLogic Service Bus SLAs, see "Alerts Rules" in Monitoring in the BEA AquaLogic Service Bus User Guide.

 


Message Reporting

When you configure a proxy service, you can include a reporting action in its message flow. In the reporting action, you specify the information about each message that you want to have written to the AquaLogic Service Bus Reporting Data Stream. The following figure shows an example Report action:

Figure 3-2 Example Report Action

Example Report Action


 

The JMS Reporting Provider picks up this data and stores it in a message reporting database that acts as the Reporting Data Store. For information on how to configure reporting actions, see "Adding an Action" in Proxy Services in the Using the AquaLogic Service Bus Console.

The AquaLogic Service Bus Console Message Reporting module displays information from the Reporting Data Store. Message Reporting enables you to drill down from summary information to view detailed information about specific messages.

Figure 3-3 Example Message Report Summary in the AquaLogic Service Bus Dashboard

Example Message Report Summary in the AquaLogic Service Bus Dashboard


 

You can customize the display of Message Reporting information by filtering and sorting the data to meet your reporting requirements.

Note: Message Reporting displays information only for messages that traverse a pipeline that includes a reporting action.

AquaLogic Service Bus Console provides purge functionality to help you manage your message data. For other data management functions, you should apply standard database administration practices to the database hosting the Reporting Data Store.

For a list of supported database platforms for the Reporting Data Store, see Supported Database Configurations in Supported Configurations for AquaLogic Service Bus.

 


UDDI

Universal Description, Discovery and Integration (UDDI) registries are used in the enterprise to share Web services and in doing so UDDI services help companies organize and catalog these services for sharing and re-use in the enterprise or with trusted external partners.

Figure 3-4 AquaLogic Service Bus Leverages UDDI

AquaLogic Service Bus Leverages UDDI


 

The preceding figure illustrates how a UDDI registry can be made available to a distributed enterprise to facilitate reuse and sharing of services. In this case, customer credit services are registered with the UDDI registry and can be used by distributed instances of AquaLogic Service Bus.

A UDDI registry service for Web services is defined by the UDDI specification at the following URL:

http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3

UDDI registries are based on this standard specification. It provides the details on how to publish and locate information about Web services using UDDI. The specification does not define run-time aspects of the services (it is only a directory of the services). UDDI provides a framework in which to classify your business, its services, and the technical details about the services you want to expose.

BEA AquaLogic Service Registry is a version 3 compliant UDDI registry certified to work with AquaLogic Service Bus. It is not provided with AquaLogic Service Bus. It is licensed independently from BEA.

For information about AquaLogic Service Registry, see the product documentation at the following URL:

http://download.oracle.com/docs/cd/E13173_01/alsr/docs20/index.html

AquaLogic Service Bus and UDDI

The AquaLogic Service Bus Console makes the AquaLogic Service Registry or any version 3 UDDI-compliant registry accessible and easy to use. In working with UDDI, AquaLogic Service Bus promotes the re-use of standards based Web services. In this way, AquaLogic Service Bus resources can be searched for and discovered and used by a wide and distributed audience. Web services and UDDI are all built on a set of standards, so re-use promotes the use of acceptable, tested Web services and application development standards across the enterprise. The Web services and interfaces can be catalogued by type, function, or classification so that they can be discovered and managed more easily.

A UDDI registry can be configured to work with AquaLogic Service Bus. Proxy services in AquaLogic Service Bus can be published to the registry. After the registry is configured, you can publish AquaLogic Service Bus proxy services to it. A registry entry has certain property types associated with it and these property types are defined when the registry is created.

You can use the AquaLogic Service Bus Console to publish proxy services to AquaLogic Service Registry. For information on how to publish proxy services to a UDDI registry, see "Publishing a Proxy Service to a UDDI Registry" in System Administration in Using the AquaLogic Service Bus Console. You must have an account set up in the UDDI registry to do this. You can publish all proxy services to a UDDI registry—this includes the following service types: WSDL, Messaging, Any SOAP, and Any XML.

You can import services from the registry as AquaLogic Service Bus business services. For information on how to import business services to AquaLogic Service Bus, see "Importing a Business Service from UDDI Registry" in System Administration in Using the AquaLogic Service Bus Console. The service types supported are WSDL services with SOAP over HTTP binding and AquaLogic Service Bus proxy services (used primarily in multi-domain deployments). When importing a WSDL-based service, if multiple UDDI binding templates are encountered, then a new business service is created for each binding template.

Permissions in BEA AquaLogic Service Registry were developed so that administrators can manage users' permissions in BEA AquaLogic Service Registry and create views into the registry, specific to the needs of the different user types. User permissions set in AquaLogic Service Bus govern access to the registries, their content, and the functionality available to you.

The Benefits of Using UDDI to Solve an Enterprise Problem

The goal is to solve a complex multi-tiered problem by allowing everyone in the enterprise to benefit from increasing the visibility of business services and resources used in business applications. Enterprise architects need a way to ensure that the people who need the services can find them and that developers are not developing services that already exist. Management must ensure that services comply with technology, business policies, and application standards and IT and business leaders need to be able to control how the services interoperate both inside and outside the firewall. These basic requirements in the enterprise today are met using the architectural benefits of service-oriented architecture (SOA). A SOA can reliably map business processes with enterprise applications, inspire integration and reuse of applications, and foster effective governance of SOA services—often at dramatically lower costs and with fewer resources.

The benefits of using a global registry can be summed up in the following items:

Related Topics

 

Skip navigation bar  Back to Top Previous Next