|
|
This section discusses AquaLogic Service Bus service integration and message brokering concepts and its capabilities which support high-speed reliable service mediation and provisioning. It is intended for IT deployment specialists who are responsible for configuring services in an SOA. This section includes the following topics:
AquaLogic Service Bus provides capabilities to extend and integrate applications into enterprise-class services (web and legacy). It also provides facilities for mediating and exposing services for reuse, through intelligent brokering functionality.
Using AquaLogic Service Bus, service providers and clients exchange messages with an intermediary proxy service instead of directly with each other, eliminating complexities resulting from heterogeneous communication protocols and messaging formats. It leverages the following operational capabilities to provide high-speed and reliable service mediation:
Its industry-leading support for Web services, traditional messaging protocols, and compatibility with legacy and proprietary integration technologies, make AquaLogic Service Bus an ideal service integration and message brokering solution. For more details on The following topics describe concepts related to service integration and message brokering using AquaLogic Service Bus.
In AquaLogic Service Bus, service integration relationships are implemented dynamically by configuring policies and proxy services. Both, proxy services and business services invoked by proxy services, are modeled as services that have the following attributes:
AquaLogic Service Bus supports varied service types ranging from conventional Web services (using XML or SOAP bindings in WSDLs) to non-XML (generic) services. The service type is selected by the individual doing the service registration when the business and proxy services are created, and it defines the protocols that can be used to communicate with the service end point. AquaLogic Service Bus service types include:
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 also extends the same support.
AquaLogic Service Bus supports the following service transport protocols:
The service type selected defines the protocol to be used for communicating with the service end point. Table 1 shows the service types and supported transports :
JMS1, HTTP(S)
|
|
XML (no WSDL)2
|
|
1JMS request and JMS response are not supported if WS-Security is enabled 2HTTP GET is only supported for XML with no WSDL. |
AquaLogic Service Bus also provides a Transport SDK to enable addition of native custom connectivity options.
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:
WSDLs can be imported into the WSDL repository using the AquaLogic Service Bus Console. The AquaLogic Service Bus Console can also be used to resolve the references in the WSDLs, to ensure all schemas and WSDLs are linked correctly. After WSDLs are stored in the repository, they are available for use when adding proxy services and business services. AquaLogic Service Bus uses its own representation of the interface for messaging services.
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.
AquaLogic Service Bus accommodates multiple messaging paradigms and supports the following types of communication:
In sync-async bridging, a synchronous client issues a request to an asynchronous provider. For this pattern, AquaLogic Service Bus provides the capability to publish a message on one JMS queue and configure a second JMS queue for the response, with a timeout value for listening for the response. This type of service appears as a synchronous service to the service consumer. Using asynchronous request/response messages has these advantages:
AquaLogic Service Bus supports the following message formats:
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 AquaLogic Service Bus User Guide.
Predefined context variables contain information about the message, transport headers, security principals, metadata for the current proxy service and metadata for the primary routing and publish services invoked by the proxy service. You typically use an XQuery expression to manipulate context variables in a message flow. They 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:
To support interoperability with heterogeneous end points, AquaLogic Service Bus lets service configurations control the content type, JMS type, and encoding used. It does not make assumptions about what the external client or service needs, but instead uses the service-definition information that has been configured for this purpose. AquaLogic Service Bus derives the content type for outbound messages from the service type and interface and uses the following specifications:
The content type can be overridden in the outbound context variable ($outbound) for proxy services invoking a service, and in the inbound context variable ($inbound) for a proxy service response. Additionally, there is a JMS type (byte or text) which can be configured when the service is defined in the Administration Console. Encoding is also explicitly configured in the service definition for all outbound messages.
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.
Resources and services in AquaLogic Service Bus are grouped into a set of projects, each with a hierarchy of folders. Organizing resources and services into projects eliminates name conflicts and provides a convenient way to organize resources and services by business categories and search for them.
This section discusses the following includes the following AquaLogic Service Bus resources:
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.
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:
Transformation maps describe the mapping between two disparate data types of different source and destination services. 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.
A JAR (Java ARchive) is a zipped file that contains a set of Java classes. It is used to store compiled Java classes and associated metadata that can constitute a program. A JAR acts like a callable program library for Java code elements (so that a single compilation link provides access to multiple elements, rather than requiring bindings for each element individually).
JAR files can be registered as reusable AquaLogic Service Bus resources. They are used in Java callout actions that provide a Java exit mechanism, EJB-based business services, and Tuxedo-based business services. For more information on JAR resources, see JARs in Using the AquaLogic Service Bus Console.
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.
Proxy services are AquaLogic Service Bus definitions of intermediary Web services that are hosted locally on AquaLogic Service Bus used to route messages to multiple business services. They are generic services that can be configured with an interface that is independent of the business services. Using generic proxy templates, the proxy service can be defined in terms of an interface, message flow definitions, and policies, that dynamically route messages to appropriate business services, based on content-based routing logic. For more information on proxy templates, see Service Composition, topic Proxy Templates.
A proxy service can also map message data into appropriate protocol formats required by the end-point business service, allowing for dynamic run-time protocol switching. If the proxy service requires credential-level validation, a proxy service provider can be created to manage security credentials, using 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.
Proxy Service Provider resources contain Public Key Infrastructure (PKI) credentials that proxy services use for decrypting inbound SOAP messages and for outbound authentication and digital signatures. PKI credentials are private keys paired with certificates that can be used for digital signatures and encryption (for Web Service Security) and for outbound SSL authentication. The certificate contains the public key that corresponds to the private key. For information on how to configure a proxy service provider using the AquaLogic Service Bus Console, see “Adding a Proxy Service Provider” in Service Key Providers in Using the AquaLogic Service Bus Console.
Alert Destination resources capture a list of recipients that can receive alert notifications from the AquaLogic Service Bus. They are used by Alert actions configured in the message flow, and by SLA alert rules. An Alert destination could include one or more of the following types of destinations: Reporting Data stream, SNMP trap, E-mail, JMS queue, or JMS topic. In the case of E-mail and JMS destinations, a destination resource could include a list of E-mail addresses or JMS URIs, respectively. Alert Destinations can be re-used across alert configurations for services.
For more information on Alert Destination resources, see Alert Destinations in Using the AquaLogic Service Bus Console.
JNDI Provider resources communication protocols and security credentials for accessing remote servers and can be reused from numerous proxy services within AquaLogic. They are global resources that may be used in Alert Destination resources across projects within an AquaLogic Service Bus domain.
For more information on JNDI Providers, see “JNDI Providers” under topic Global Resources, in Using the AquaLogic Service Bus Console.
SMTP Server resources specify the address of SMTP servers corresponding to E-mail destinations, port numbers, and, if required, authentication credentials. They are global resources that are used in Alert Destination resources across projects in an AquaLogic Service Bus domain.
For more information on SMTP Server resources, see “SMTP Server” under Global Resources in Using the AquaLogic Service Bus Console.
AquaLogic Service Bus uses the proven BEA WebLogic Security Framework in BEA WebLogic Server 9.0, as the building blocks for higher-level security services including authentication, identity assertion, authorization, role mapping, auditing, and credential mapping. BEA WebLogic Server security is configured before the Console can be used to configure security.
The Console has predefined rules that simplify using the BEA WebLogic Server security providers at several different levels in its operation. For more information on supported security levels, see section Security Levels.
For more information on AquaLogic Service Bus security functionality, see topic “Understanding AquaLogic Service Bus Security” in AquaLogic Service Bus Security Guide.
Web Services Policy (WS-Policy) is a standards-based framework for defining a Web service's security constraints and requirements. It expresses security constraints and requirements in a collection of XML statements called policies, each of which contains one or more assertions. In AquaLogic Service Bus, WS-Policy assertions are used to specify a Web service's requirements for digital signatures and encryption, along with the security algorithms and authentication mechanisms that it requires.
WS-Policy policies may be included directly in a WSDL document or included by reference, and a WSDL document may import other WSDL documents that contain or refer to WS-Policy policies. An XML file that contains these policies can be used by multiple proxy services or business services. The WebLogic Web Services runtime environment recognizes two types of WS-Policy statements:
The AquaLogic Service Bus runtime environment determines which security token types an abstract policy will accept. For information on configuring the runtime environment, see AquaLogic Service Bus WS-Policy Statements in AquaLogic Service Bus Security Guide.
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 AquaLogic Service Bus Security Guide.
Service Account resources provide a user name and password that proxy services and business services use for outbound authentication or authentication to a local or remote resource, such as an FTP server or a JMS server. For example, if a business service is required to supply a user name and password for transport-level authentication with a Web Service, a service account can be created to specify the user name and password. The business service can then be configured to include the service-account credentials in its outbound requests. One service account can be used for multiple business services and proxy services. For more information on Service Account resources, see Service Accounts in Using the AquaLogic Service Bus Console.
AquaLogic Service Bus provides the following types of security features:
The following topics discuss the security features available in the AquaLogic Service Bus security model.
Inbound Security ensures that AquaLogic Service Bus proxy services handle only the requests that come from authorized clients (by default, any anonymous or authenticated user can connect to a proxy service). It can also ensure that no unauthorized user has viewed or modified the data as it was sent from the client.
Proxy services can have two types of clients: service consumers and other proxy services. Inbound security is set up when proxy services are created and is determined by varying security requirements.For outward-facing proxy services which receive requests from service consumers, strict security requirements such as two-way SSL over HTTPS are used. For proxy services that are guaranteed to receive requests only from other AquaLogic Service Bus proxy services, less secure protocols are used. If a proxy service uses public key infrastructure (PKI) technology for digital signatures, encryption, or SSL authentication, create a proxy service provider to provide private keys paired with certificates.
For each proxy service, the following inbound security checks can be configured:
Outbound security secures communication between a proxy service and a business service. Most of the tasks involve configuring proxy services to comply with the transport-level or message-level security requirements that business services specify. If a business service requires the use of PKI technology for digital signatures, or SSL authentication, a proxy service provider is created, which provides private keys paired with certificates. For more information, see Proxy Service Providers in Using the AquaLogic Service Bus Console.
Options for Identity Propagation allows for decision making when designing security for AquaLogic Service Bus, including how to propagate the identities that clients provide. AquaLogic Service Bus can be configured to do any of the following:
For detailed descriptions of these WebLogic Server security providers and WebLogic Server security architecture in general, see BEA WebLogic Server Security documentation.
AquaLogic Service Bus security supports the WS-Policy specification. For more information on 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/
Using the AquaLogic Service Bus Console, it is possible to configure a service with security policies that apply to messages in its interface. A security policy can be specified for a service or for individual messages associated with the operations of a service. When a security policy is specified for a service, the policy applies to all messages sent to that service.
AquaLogic Service Bus enables you to use the WebLogic Server security providers at several different levels in its operation. The following levels of security are supported:
For more information on security levels, see AquaLogic Service Bus Security Guide.
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.
The AquaLogic Service Bus Console is used 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.
To give users access to administrative functions such as creating proxy services, they can be assigned to one of four security roles with pre-defined access privileges. A security role is an identity that can be dynamically conferred upon a user or group based on conditions that are evaluated at runtime. The access privileges for the AquaLogic Service Bus administrative security roles cannot be changed but the conditions under which a user or group is in one of the roles can be changed.
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 is a list of default roles to which AquaLogic Service Bus users can be assigned:
For information on configuring administrative security, see Configuring Administrative Security in AquaLogic Service Bus Security Guide.
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.
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. It allows HTTP(S) proxy services or business services to be configured 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 AquaLogic Service Bus Security Guide.
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. Though it is 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.
There are several ways to authenticate a client's identity in AquaLogic Service Bus—using Basic Authentication, client certificates (2-way SSL), and Web Service Security. Client credentials associated with a business service and a proxy service are managed directly using WebLogic Server. Client-specified custom authentication credentials for both transport- and message-level inbound requests are also supported. The custom authentication credentials can be in the form of tokens, or a username and password token combination.
AquaLogic Service Bus accepts and attempts to authenticate:
For more information on custom security credentials, see Configuring Custom Authentication in the AquaLogic Service Bus Security Guide.
|