|
|
AquaLogic Service Bus relies on user-configured metadata for resources and services to determine how to process messages. This topic is intended for IT specialists who are responsible for configuring a message broker in an SOA.
The section introduces the AquaLogic Service Bus resources and services, and provides links to more detailed information in the AquaLogic Service Bus documentation set.
This section includes the following sections:
AquaLogic Service Bus resources are reusable definitions or descriptions of entities that typically include metadata for those entities. Resources can be used by multiple services and provide standardized definitions or descriptions for use across an enterprise or department. Examples of AquaLogic Service Bus resources include:
You can organize the resources and services in AquaLogic Service Bus into a set of projects, each with a hierarchy of folders. Organizing resources and services into projects not only avoids name conflicts, but also provides a convenient way to organize resources and services by department or other business category and search for them.
AquaLogic Service Bus also provides sessions to allow you to make a series of changes over a long period, and keep them private until you are ready to submit the changes as a batch of updates for deployment. Multiple sessions can be active. An optimistic locking approach is used, so it is possible that conflicts can occur which have to be resolved before a successful submit.
This section includes the following topics:
Schemas describe types for primitive or structured data. XML Schemas are an XML vocabulary that describe the rules that XML business data must follow. XML Schemas specify the structure of documents, and the data type of each element and attribute contained in the document. XML schemas can import or include other XML schemas. For information on how to create schemas using the AquaLogic Service Bus Console, see "Adding a New Schema" in XML Schemas in Using the AquaLogic Service Bus Console.
AquaLogic Service Bus uses a metadata language called Message Format Language (MFL) to describe the structure of typed non-XML data. The BEA Format Builder tool creates and maintains metadata as a data file called an MFL document. For information on how to create MFL documents, see the Format Builder Online Help.
Transformation maps describe the mapping between two data types. AquaLogic Service Bus supports data mapping using either XQuery or the eXtensible Stylesheet Language Transformation (XSLT) standard. In addition, MFL described data is automatically converted to the equivalent XML for transformation with XQuery or XSLT. The resulting XML is automatically converted to MFL if the target service requires it.
Conditional routing and transformations support content-based routing, allowing AquaLogic Service Bus to mediate between disparate service endpoints and intelligently route between them. In this way, loose coupling of SOA endpoints is achieved. A common example of content based routing is to support a scenario in which different versions of a service are made available. In the following figure, content-based routing at a route node in a proxy service mediates between two versions of a getCustomerCredit service.
AquaLogic Service Bus allows you to enrich services by combining transformation and routing functions. Let us expand on the getCustomerCredit service use case described in the preceding figure to describe a scenario in which combining transformation and conditional routing functionality in a proxy service can result in enriched services and better reuse of those services. In this example scenario, Service Callouts are made to each of two services (getCustInfo and getCustAddress) and the results of the callouts combined by the proxy service. The same content-based routing is configured for getCustomerCredit service as was configured in the preceding figure.
For information on how to create AquaLogic Service Bus XQueries using the BEA XQuery Mapper, see Transforming Data Using the XQuery Mapper.
A WSDL (Web Service Definition Language) interface defines a service interface for a SOAP or XML service. It describes the abstract interface of a service including the operations in that interface and the types of message parts in the operation signature. It can also describe the binding of the message parts to the message (packaging), and the binding of the message to the transport. In addition a WSDL can describe the concrete interface of the service (for example, the transport URL).
For information on how to configure WSDLs using the AquaLogic Service Bus Console, see "Adding a New WSDL" in WSDLS in Using the AquaLogic Service Bus Console.
A WS-Policy describes a security policy. It describes what should be signed or encrypted in a message and the security algorithms to be applied. A WS-Policy also describes what authentication mechanism should be used for the message when received.
Policies are referenced by an URI, either embedded within a WSDL, an HTTP URI, or a policy URI (for example. policy:myPolicy). Policy URIs can reference in-built policies.
For more information on WS-Policy, see the AquaLogic Service Bus Security Guide.
The fundamental concept in AquaLogic Service Bus is that both proxy services and business services invoked by the proxy services are modeled as services.
Services have the following attributes:
AquaLogic Service Bus supports SOAP and XML-based Web services and messaging services. It also supports SOAP and XML services for which only the concrete interface and the service type are defined.
Messages to SOAP-based services are SOAP messages containing XML wrapped in a SOAP envelope. Messages to XML-based services are XML but can be of any type allowed by the proxy service configuration. Messages to a messaging service (a business service or proxy service created to be of messaging service type) can be of different types. A messaging service can exchange messages of very different content-type. These exchanges can be either request/response or one-way. Unlike Web services, the content-type of the request and response need not be the same. Messaging based services do not have WSDL definitions. To learn more about this service type, see Business Services in Using the AquaLogic Service Bus Console.
AquaLogic Service Bus supports the following categories of these three service types:
AquaLogic Service Bus supports request and response as well as one-way paradigms for both the HTTP and the JMS asynchronous transport protocols. If the underlying transport supports ordered delivery of messages, AquaLogic Service Bus can also support it.
AquaLogic Service Bus supports the following transport protocols:
For information on how to configure transport for a proxy service using the AquaLogic Service Bus Console, see "Adding a Proxy Service" in Proxy Services in Using the AquaLogic Service Bus Console. For information on how to configure transport for a business service using the AquaLogic Service Bus Console, see "Adding a Business Service" in Business Services in Using the AquaLogic Service Bus Console.
AquaLogic Service Bus relies on WSDLs for the formal description of Web services. For Web services, a WSDL describes what the Web service's interface is, where it resides, and how to invoke it. AquaLogic Service Bus defines proxy services and business services in terms of two WSDL entities:
Using the AquaLogic Service Bus Console, you import the WSDLs into the WSDL repository. You also use the AquaLogic Service Bus Console to resolve the references in the WSDLs, which ensures all schemas and WSDLs are linked correctly. Once you have stored WSDLs in the repository, they are available for you to use when adding proxy services and business services. For messaging services, AquaLogic Service Bus uses its own representation of the interface.
For information on how to import and resolve WSDLs using the AquaLogic Service Bus Console, see "Adding a New WSDL" in WSDLs in Using the AquaLogic Service Bus Console.
Proxy services are AquaLogic Service Bus definitions of intermediary Web services that are hosted locally on AquaLogic Service Bus. You define a proxy service in terms of an interface, message flows, and policies. If the proxy service requires credential-level validation, you can create a proxy service provider to manage security credentials for the proxy service from the AquaLogic Service Bus Console.
For information on how to configure a proxy service using the AquaLogic Service Bus Console, see "Adding a Proxy Service" in Proxy Services in Using the AquaLogic Service Bus Console. For information on how to configure a proxy service provider using the AquaLogic Service Bus Console, see "Adding a Proxy Service Provider" in Proxy Service Providers in Using the AquaLogic Service Bus Console.
The following sections describe key concepts regarding the structure and definition of proxy services.
All messages sent to and received by the proxy service are defined internally in the proxy service by a set of properties that holds the message data and meta-data related to that message. This set of properties is known as the Message Context (context) and is implemented using Context Variables. It is defined by an XML schema. Each Context Variable relates to a different property.Some Context Variables are predefined and others are user defined.The heart of the proxy service is the Message context. For a complete description of the Message Context and context variables used in the message flow, see Message Context in Using the AquaLogic Service Bus Console.
Predefined variables contain information about the message, the transport headers, security principals, the metadata for the current proxy service and the metadata for the primary routing and publish services invoked by the proxy service. You typically use an XQuery expression to manipulate the context variable in the message flow. It can also be modified using transformation and in-place update actions.
The message related context variables $header, $body, and $attachments represent the canonical format of the message in the message flow. These are wrapper variables that contain the SOAP header elements, the SOAP body element, and the MIME attachments, respectively. The context gives the impression that all messages are SOAP messages and non-SOAP messages are mapped to this paradigm. The following table lists the mappings for each message type.
In the case of attachments, $attachments contains the following for each attachment:
The implementation of a proxy service is specified by a message flow definition. The message flow defines the flow of messages through the proxy service. Four elements are used to construct a message flow. These elements are:
These elements can be combined in arbitrary ways to form a tree structure with the start node always (and only) occurring as the root of the tree and the route nodes only allowed at the leaves. The request message starts at the start node and follows a path to a leaf executing actions in the request pipelines. If the leaf is a route node a response is generated (could be empty if the service is a one way service). If the leaf is an echo node, the request is also considered to be the response. The response follows the inverse path in the tree skipping actions in the branch nodes, but executing actions in response pipelines. A response is then finally sent from the top of the tree if the interface or operation was request/response, otherwise the response is discarded.
A route node is very flexible in its specification. It allows if structures and case structures to be combined (and nested) to define a single endpoint and operation to route the message. For information about how to configure route nodes, see "Adding a Route Node" in
Proxy Services in Using the AquaLogic Service Bus Console.
A set of transformations that affects context variables can be defined before the message is sent to the selected endpoint or after the response is received. A Web services callout can be an alternative to an XQuery or XSLT transformation to set the context variable. For information on how to configure AquaLogic Service Bus transformation maps, see Transforming Data Using the XQuery Mapper.
WS-Security processing as well as authorization is transparently performed at the Start node. WS-Security processing is transparently performed when invoking a business service with a ws-policy. For information on how to configure AquaLogic Service Bus security, see the AquaLogic Service Bus Security Guide.
For more information about pipeline pairs, stages, and actions, see Message Flow Definition on page 1-18.
For an example of a typical message flow diagram, see Figure 1-11 in Operational Pipelines on page 1-21.
For more information on Message Flows, see Modeling Message Flows in the AquaLogic Service Bus User Guide.
AquaLogic Service Bus has a built-in type system that is available for use at design time. When creating an XQuery expression in a condition, in-place update action, or transformation, the variable can be declared to be of a given type in an editor to assist in easily creating the XQuery. The types can be the following:
Each stage can have a sequence of steps to execute if an error occurs in that stage. This sequence of steps constitute an error pipeline for that stage. In addition, an error pipeline can be defined for a pipeline (request or response) or for an entire proxy service. The lowest scoped error pipeline that exists is invoked on an error.
This error pipeline allows you to handle the error in the following ways:
Business services are AquaLogic Service Bus definitions of the enterprise services with which you want to exchange messages. A business service definition is similar to that of a proxy service, but it does not have a pipeline. If AquaLogic Service Bus needs to provide authentication when connecting to a business service, you can use the AquaLogic Service Bus Console to create a service account that acts as an alias resource for the required username and password pair. For more information, see Business Services and Service Accounts in Using the AquaLogic Service Bus Console.
If a business service requires credential-level validation, you must use WebLogic Server directly to manage its security credentials. For more information on business service security considerations, see the AquaLogic Service Bus Security Guide.
|