Concepts and Architecture

Overview

This topic introduces AquaLogic Service Bus. It is intended for enterprise architects, operations specialists, and security architects who are responsible for messaging and service oriented architectures (SOA). It includes the following sections:

• Introducing AquaLogic Service Bus
• AquaLogic Service Bus Architecture
• AquaLogic Service Bus Core Feature Set
• AquaLogic Service Bus Message Brokering

 

---

Introducing AquaLogic Service Bus

As businesses strive to be agile, they depend on IT's ability to deliver new services and reuse existing services at the speed of business. This desire to be service-driven is creating a significant pull for IT to adopt Service-Oriented Architecture (SOA). To make SOA a reality, IT requires intelligent service infrastructure that drives and simplifies service reuse and delivers reliable integration across an inherently heterogeneous, multi-vendor computing landscape. BEA AquaLogic Service Bus—part of the BEA AquaLogic family of Service Infrastructure Products—combines intelligent message brokering with service monitoring and administration to provide a unified software product for implementing and deploying your Service-Oriented Architecture (SOA). This converged approach adds a scalable, dynamic routing and transformation layer to your enterprise infrastructure, plus service lifecycle management capabilities for service registration, service usage, and Service Level Agreement (SLA) enforcement. AquaLogic Service Bus is at the heart of BEA's comprehensive business integration solution.

Figure 1-1 BEA's Comprehensive Integration Solution

 

 

AquaLogic Service Bus eliminates the service sprawl that challenges enterprises and their IT departments. The challenges include hard-wired connections between applications and services, resulting in complex, rigid, and tightly-coupled integration. In turn, this results in an impaired ability to reuse services and challenges in managing deployed services. All this results in a high total cost of ownership for the enterprise.

Figure 1-2 The Service Sprawl Challenge

 

 

The specific challenges faced by enterprise architects responsible for messaging and SOA initiatives in today's enterprise include:

• Introducing dynamic behavior and run-time configuration capabilities into a system
• Reusing services that are developed across the enterprise and managing their lifecycle
• Ensuring consistent use of the enterprise services
• Ensuring enterprise services are secure
• Ensuring that the enterprise services comply with the IT policies
• Monitoring and auditing service usage and managing system outages

In short, the goal of the enterprise architect and other specialists is to reuse, streamline, and maintain control over their IT infrastructure. AquaLogic Service Bus is designed to help you achieve these goals.

AquaLogic Service Bus is a configuration-based, policy-driven Enterprise Service Bus (ESB). It provides a feature-rich console for dynamic service and policy configuration, as well as for system monitoring and operations tasks. AquaLogic Service Bus facilitates a loosely coupled architecture, facilitates enterprise-wide reuse of services, and centralizes management—all of which results in an improved total cost of ownership. The AquaLogic Service Bus Console enables you to respond rapidly and effectively to changes in your service-oriented environment.

Figure 1-3 Eliminating Service Sprawl

 

 

AquaLogic Service Bus relies on WebLogic Server run-time facilities. It leverages WebLogic Server capabilities to deliver functionality that is highly available, scalable, and reliable.

AquaLogic Service Bus is an ESB product specifically targeted for service-oriented integration, managing primarily Web Services, and providing traditional message brokering across heterogeneous IT environments.The lightweight, stateless, high-performance architecture of AquaLogic Service Bus delivers an intermediary for use as a core element of distributed services networks.

AquaLogic Service Bus is policy-driven. It enables you to establish loose coupling between service clients and business services while maintaining a centralized point of security control and monitoring.

With AquaLogic Service Bus, you implement service integration relationships dynamically through configuration of policies and proxy services. This approach enables your service architectures to evolve rapidly with respect to the following system characteristics:

• Security
• Service location
• Availability and responsiveness
• Data formats
• Logging and monitoring
• Transport protocols and communications paradigms

Because of the intermediary nature of the proxy service, you can use AquaLogic Service Bus to resolve differences between service client and business service requirements in the following areas:

• Payload contents and schema
• Envelope protocols
• Transport protocols
• Point-to-point and publish and subscription protocols
• One way and request/response paradigms
• Synchronous and asynchronous communication
• Security compliance

AquaLogic Service Bus persists policy, proxy service, and related resource configurations in metadata that you can propagate from development through staging to production environments, and then modify as required. The AquaLogic Service Bus message brokering engine accesses this configuration information from its metadata repository.

A key design philosophy of AquaLogic Service Bus is the physical separation of management functions from service implementations. This separation allows implementations to evolve independently and dynamically as driven by the needs of the business without requiring costly infrastructure development efforts. As part of an enterprise's messaging fabric, AquaLogic Service Bus can be used horizontally across many applications and systems, spanning service implementations in different departments built by different teams.

 

---

AquaLogic Service Bus Architecture

AquaLogic Service Bus is an intermediary that takes in messages, processes them to determine where to route them, and transforms them as specified. It receives messages through a transport protocol such as HTTP(S), JMS, File, FTP, and so on, and sends messages through the same or a different transport protocol. Message response follows the inverse path. The message processing by AquaLogic Service Bus is driven by metadata specified as the message flow definition for a proxy service in the AquaLogic Service Bus Console.

Figure 1-4 Service Consumers and Service Producers Interact with AquaLogic Service Bus

 

 

AquaLogic Service Bus is policy driven. It enables you to establish loose coupling between service clients and business services while maintaining a centralized point of security control and monitoring. The following figure shows the high-level architecture, which shows AquaLogic Service Bus composed of the following subsystems: service management, message brokering, configuration framework, security, and transport and messaging protocols.

Figure 1-5 AquaLogic Service Bus High-Level Architecture

 

 

Deployment Topology

AquaLogic Service Bus runs on WebLogic Server version 9.0 or greater, and can be deployed in the following configurations:

• On a single server that also serves as the administration server.
• On a cluster of servers. A cluster consists of a clustered set of managed servers that perform the message processing. A domain has only one cluster and that cluster has AquaLogic Service Bus deployed to it. This cluster can host other applications in addition to AquaLogic Service Bus. There is one administration server in a clustered domain.

AquaLogic Service Bus can manage and control many distributed service endpoints, thereby providing centralization in the enterprise. For example, you can deploy AquaLogic Service Bus as a single hub that manages all the Web service traffic in an enterprise.

You can horizontally scale an AquaLogic Service Bus hub by clustering the underlying WebLogic Server. This allows the messaging load to be homogeneously spread over the servers in the cluster, thereby preventing bottlenecks in the system. In addition, heterogeneous AquaLogic Service Bus hubs can be connected to create a distributed AquaLogic Service Bus network.

AquaLogic Service Bus supports clustering of the WebLogic managed servers. It propagates configuration and metadata automatically to the managed servers for fast local retrieval, and it automatically collects monitoring metrics from all the managed servers for aggregation and display on the AquaLogic Service Bus Console.

The following figure shows the flow of message data in a basic AquaLogic Service Bus cluster topology.

Figure 1-6 Clustering and High Availability

 

 

Development, Staging, and Production Domains

AquaLogic Service Bus supports best practices for change management in your enterprise systems by enabling you to configure resources and services in a controlled environment. You can then export the configurations for import into separate staging domains for testing and final preparation for promotion into a production domain. AquaLogic Service Bus provides you with the ability to reconfigure environment-specific elements as necessary to meet the requirements of the importing domain. To learn about managing changes and organizing resources in AquaLogic Service Bus, see Change Management and Resource Organization.

 

---

AquaLogic Service Bus Core Feature Set

By fusing the concepts of ESB, message brokering, and Web Services Management (WSM) into a single product, AquaLogic Service Bus provides the foundation for management and integration of messages and services.

The following table describes the core features of AquaLogic Service Bus.

Table 1-1 AquaLogic Service Bus Core Features

For this feature...	AquaLogic Service Bus...
Routing	Supports the following: Routes messages according to XQuery-based policies or callouts to external services Routing policies apply to both point-to-point and one-to-many routing scenarios (publish). For publish, routing policies serve as subscription filters
Routing Transport Protocols	Supports the following: File FTP HTTP(S) JMS (including MQ using JMS, and JMS/XA) E-mail (POP/SMTP/IMAP)
Messaging	Supports the following models: Synchronous Asynchronous Publish Subscribe
Message Types	Supports the following message formats: E-mail with or without attachments JMS with headers MFL (Message Format Language) Raw Data. Raw data is opaque data—that is, non-XML data for which there is no MFL file and therefore no known schema Text SOAP and SOAP with attachments (SOAP that is or is not described by a WSDL) XML and XML with attachments ((XML that is or is not described by a WSDL or a schema)
Transformations	Supports the following functionality for the transformation or processing of messages: Validates incoming messages against schemas Selects a target service or services, based on the message content or message headers Transforms messages based on the target service Transforms messages based on XQuery or XSLT Supports transformations on both XML and MFL messages Message enrichment Supports call outs to Web services to gather additional data for transformation (for example, country code, full customer records, and so on)
Testing	Provides a built-in test console in the development environment: Allows you to test resources and inline XQuery expressions used in the message flow Allows you to test business services and proxy services Provides tracing of the message flow when you test a service using the test console
Logging and Monitoring	Provides a rich set of functionality to audit and monitor services: You can gather statistics about message invocations, errors, performance characteristics, messages passed, SLA violations, and so on The system also supports logging selected parts of messages for both systems operations and business auditing purposes, search capabilities, and so on. You can extract key information from a message and use as it as a search index. The AquaLogic Service Bus Console provides a cluster-wide view of service status and statistics Both business services and AquaLogic Service Bus proxy services are monitored, as are response times, message counts, and error counts Statistics are gathered locally, then aggregated centrally SLA rules run against aggregated data. The system raises alerts, and you can enable or disable services.
Versioning	Provides the ability to deploy new versions of services and allow you to have multiple versions of message resources such as WSDLs and schemas. Versions can include changes to the WSDL, the message schema, the headers, and the security parameters.
Service Level Agreements	Administrators can set service level agreements (SLAs) on the following attributes of proxy services: Average processing time of a service Processing volume Number of errors, security violations, and schema validation errors Administrators can configure alerts for SLA rule violations
Security	Includes the following: Supports authentication, encryption and decryption, and digital signatures as defined in the Web Services Security (WS-Security) specification Uses SSL to support traditional transport-level security for HTTP and JMS transport protocols Supports one-way and two-way certificate based authentication Supports HTTP basic authentication
Resource Cache	Supports the following: Stores information about services, schemas, transformations, WSDLs (Web Service Definition Language), and WS Policies Provides centralized management and distributed access to resources and services Allows you to browse the services registered in AquaLogic Service Bus and import resources from WebLogic Workshop or other applications Allows the propagation of configuration data from environment to environment (for example, from a development domain to a test domain to a production domain). The system allows environment specific settings to be overridden during import. Interoperability with UDDI registries—you can publish a proxy service to and import a business service from version 3-compliant UDDI registries. For more information about UDDI registries, see UDDI.
Error Handling	Supports the following: Allows you to configure your system to format and send error messages, and return messages for consumers of services who expect a synchronous response Allows you to configure error handling for stages in the pipeline, for pipelines, and for proxy services

 

---

AquaLogic Service Bus Message Brokering

AquaLogic Service Bus provides intelligent message brokering functionality for your SOA.

AquaLogic Service Bus supports multiple messaging protocols: HTTP(S), JMS SAF, third party messaging using JMS provider interfaces (MQ Series, Tibco E4JMS), File, FTP, Email (SMTP/POP/IMAP). Multiple transports are supported—end-to-end guaranteed delivery is possible when the transport supports it. You can create a messaging network with JMS Store and Forward and Global Queue Names. Web Services (WSDL, SOAP enveloping) and non-SOAP-enveloped messages are supported.

AquaLogic Service Bus supports multiple communications paradigms including request/response, asynchronous/synchronous, publication/subscription, Web Services with attachments, and so on. A mix and match of transports is possible (for example, sync-to-async bridging is supported).

Figure 1-7 Message Brokering in AquaLogic Service Bus

 

 

The following sections describe the key concepts associated with AquaLogic Service Bus message structures and message processing.

Business Services and Proxy Services

AquaLogic Service Bus provides intelligent message brokering between business services (such as enterprise services and databases) and service clients (such as presentation applications or other business services) through proxy services that you configure using the AquaLogic Service Bus Console.

Business Services

Business services are AquaLogic Service Bus definitions of the enterprise services with which you want to exchange messages. Using the AquaLogic Service Bus Console, you configure a business service by defining its interface and the type of transport it uses, its security requirements, and other characteristics.

For information on how to configure a business service using the AquaLogic Service Bus Console, see "Adding a Business Service" in Business Services in the Using the AquaLogic Service Bus Console.

Proxy Services

Proxy services are AquaLogic Service Bus definitions of intermediary Web services that are hosted locally on AquaLogic Service Bus. Using the AquaLogic Service Bus Console, you configure a proxy service by defining its interface and the type of transport it uses, the logic of message processing in message flow definitions, and by configuring policies.

With AquaLogic Service Bus message brokering, service clients exchange messages with an intermediary proxy service instead of directly with a business service. A proxy service can have an interface that is identical to a business service with which the proxy service communicates, or the proxy service can have an interface that differs from that of the business service.

Since a proxy service can route messages to multiple business services, you can choose to configure a proxy service with an interface that is independent of the business services with which the proxy service communicates. In such cases, you would configure a message flow definition to route a message to the appropriate business service and map the message data into the format required by the business service's interface.

For more information about the structure of proxy services, see Message Flow Definition.

Message Processing

Messages can contain data or status information about application processes, or instructions for the recipient, or both. AquaLogic Service Bus enables you to route messages based on their contents and to perform transformations on that content.

The processing happens through the transport and binding layers of AquaLogic Service Bus.

Figure 1-8 Binding and Transport Layers in AquaLogic Service Bus

 

 

 

The processing of messages occurs in the following sequence of events:

Processing of the inbound transport
Message flow execution
Processing of the outbound transport

After a message is sent to an endpoint (either a business service or another proxy service), AquaLogic Service Bus processes the response message in a similar model as that described in the preceding sequence of events.

The following figure shows a high-level view of how messages flow through AquaLogic Service Bus, from inbound endpoint (a proxy service) to outbound endpoint (the transport URL for a service—a business service or another proxy service).

Figure 1-9 AquaLogic Service Bus Message Processing

 

 

The following sections describe each layer involved in this message processing.

Binding Layer

The binding layer:

• Packs & Unpacks Messages as necessary
• Handles security for messages
• Hands messages off to start the message flows (request and response)

Transport Layer (Inbound)

The inbound transport layer:

• Is responsible for the communication between client services (or service consumers) and AquaLogic Service Bus. The first step for the message is the inbound transport layer, which is responsible for handling communication with the service client endpoint and acts as the entry point for messages into AquaLogic Service Bus. With regard to the message data, the inbound transport layer primarily deals with raw bytes in the form of input/output streams.
• The inbound transport layer is responsible for getting messages into the AquaLogic Service Bus system and sending the response back. It does not perform any data processing.
• Provides support for the transport protocols, including HTTP(S), JMS, FTP, File, Email, and so on.
• Handles meta-data for messages, including endpoint URI's, transport headers, and so on.

Transport Layer (Outbound)

The outbound transport layer:

• Is responsible for the communication between business services (or service producers) and AquaLogic Service Bus. It is responsible for moving messages from AquaLogic Service Bus to the business service or proxy service and for receiving the response from the services back to AquaLogic Service Bus. It is not involved in data processing. The message data, at the transport level, is in raw bytes in the form of input/output streams.
• Provides support for the transport protocols, including HTTP(S), JMS, FTP, File, Email, and so on.
• Handles meta-data for messages, including endpoint URI's, transport headers, and so on.

Message Flow Definition

Message Flows are the definitions of AquaLogic Service Bus proxy services. Pipelines, branch nodes, and route nodes define the implementation of AquaLogic Service Bus proxy services.

Pipelines, branches, and route nodes define the implementation of AquaLogic Service Bus proxy services. Using the AquaLogic Service Bus Console, you configure the logic for the manipulation of messages in proxy service message flow definitions. This logic includes such activities as transformation, publishing, and reporting—the logic is configured in individual actions within the message flow.

The following figure shows a high level view of the components of the message flow definition.

Figure 1-10 Components of Message Flows

 

 

Pipeline Pairs

Pipeline logic occurs in pairs of definitions consisting of a request pipeline definition and a response pipeline definition. The request pipeline definition specifies the actions that AquaLogic Service Bus performs on request messages to the proxy service before invoking a business service or another proxy service. The response pipeline definition specifies the processing that AquaLogic Service Bus performs on responses from the service invoked by the proxy service before the proxy service returns a response. Routing is performed by a route node at the end of the message flow.

Note: WS-Security processing and authorization are transparently performed before and after the pipeline execution.

Pipeline Execution Stages and Actions

Each pipeline is a sequence of stages. A stage is a user-configured processing step such as transformation or publishing. Messages fed into the message flow are accompanied by a set of message context variables that contain the message contents and can be accessed or modified by actions in the pipeline stages.

The following table describes the actions supported in a AquaLogic Service Bus pipeline stages, branch and route nodes.

Table 1-2 AquaLogic Service Bus Actions

Action1	Summary Description
Assign	Assign the result of an XQuery expression to a context variable
Delete	Delete a context variable or all the nodes specified by an XPath expression
For Each	Iterate over a sequence of values and execute a block of actions
If Then	Perform an action or set of actions conditionally, based on the Boolean result of an XQuery expression
Insert	Insert the result of an XQuery expression at an identified place relative to nodes selected by an XPath expression
Log	Construct a message to be logged
Publish	Specify a target service for a message and configure how the message is packaged and sent to that service
Publish Table	Specify a target service for a message and configure how the message is packaged and sent to that service. Use the Publish Table to wrap a set of routing options in switch-style condition logic
Raise Error	Raise an exception with a specified error code and description
Rename	Rename elements selected by an XPath expression without modifying the contents of the element
Replace	Replace a node or the contents of a node specified by an XPath expression
Reply	Specify that an immediate reply is sent to the invoker; can be a reply with success or failure
Report	Enable message reporting for a proxy service
Service Callout	Configure a synchronous (blocking) callout to an AquaLogic Service Bus-registered proxy or business service
Skip	Specify that at run time, the execution of the current stage is skipped and the processing proceeds to the next stage in the message flow
Transport Headers	Set the transport header values in messages
Validate	Validate elements selected by an XPath expression against an XML schema element or a WSDL resource

1. For information about the actions including how to configure them, see Proxy Services: Actions in Using the AquaLogic Service Bus Console.

 

Operational Pipelines

Each pipeline consists of a sequence of stages containing actions. However a single service level request pipeline might optionally branch out into operational pipelines (at most one per operation and optionally a default operational pipeline). The determination of the operation is done through user-selected criteria. The response processing starts with the relevant operation pipeline which then joins into a single service-level response pipeline.

The following figure shows an example of operation pipelines in a proxy service.

Figure 1-11 Example Message Flow

 

 

In the case of one-way operations, the response pipeline is executed with an empty message. This permits a response to be constructed for the proxy service, thus enabling bridging between request/response and one-way operations. The bridging mechanism means that proxy service input can be one-way while its output is request/response or vice versa. The proxy service either absorbs the response from the invoked service or generates one for the client. Actions in the response flow may also be used to do post processing on the message after it has been routed to the business service or the proxy service.

Branch Nodes

A branch node allows processing to proceed down exactly one of several possible paths. Branching is driven by a simple lookup table with each branch tagged with a simple but unique string value. A variable in the message context is designated as the lookup variable for that node, and its value is used to determine which branch to follow. If no branch matches the value of the lookup variable, then a default branch is followed. Setting the value of the lookup variable must be done before reaching the branch node. This approach ensures that exceptions do not occur within the branch node itself. A branch node may have several descendants in the message flow tree: one for each branch including the default branch.

Figure 1-12 Branch Nodes in a Message Flow

 

 

Route Nodes

The route node is used to perform request and response communication with another service. It represents the boundary between request and response processing for the proxy service. When the route node dispatches a request message, request processing is considered finished. When the route node receives a response message, response processing begins. The route node supports conditional routing as well as outbound and response transformations.

Note that you can choose to configure conditions in a route node or in a branch nodes.

The route node represents the boundary between request and response processing; consequently, it cannot have any descendants in the message flow tree.

Figure 1-13 Proxy Service Route Node Communicates With Services