Integrating AquaLogic BPM Suite 6.0 and AquaLogic Service Bus

by Alex Toussaint
07/11/2007

Abstract

AquaLogic BPM Suite 6.0 (ALBPM) is planned for release in July 2007. Ever since ALBPM 5.5, customers have been able to integrate and work with AquaLogic Service Bus (ALSB). In this article we review new features that optimize the work between the ALBPM and ALSB, making the integration faster and more seamless and transparent.

ALBPM은 2007년 7월에 릴리즈되기로 계획되었다.

Introduction

The new AquaLogic BPM Suite 6.0 has several new features to improve business efficiency and enterprise scalability. A complete list of new features will be made available by the time the product launches next month. Here is a summary of some of the main highlights:

• A new version of AquaLogic BPM Studio based on Eclipse (see Figure 1 for an example of the new version)
• A new version of AquaLogic BPM WorkSpace based on JSF
• Support for BPEL 2.0 and XPDL 2.0
• Enhanced business rules support
• New decision activities
• A new WorkSpace extension for JSF, ALUI, and RSS
• Optimized integration with AquaLogic Service Bus
• Two-way custom transport for AquaLogic Service Bus
• Support for WS-Security User Name Token Profile
• A new Configuration Wizard for WebLogic Server
• Improved J2EE deployment of Engine and Projects
• Several usability enhancements

In this article, the main focus will be on the integration work with the AquaLogic Service Bus. The three main goals were:

• Making the consumption and publication of services absolutely simple
• Providing a native authentication mechanism used with the bus
• Improving communication performance by means of the custom transport

In doing so, the integration allows for very seamless work between the products. The ability to seamlessly combine the intelligent routing and management of the bus with business process capabilities is critical for service orchestration (see Figure 1).

The rest of this article shows these improvements in action.

Seamless Integration

In ALBPM 6.0, you can easily connect to any instances of ALSB 2.6, as shown on Figure 2. The product brings a new Introspector wizard that allows users to quickly connect the two products together in a matter of seconds. In just a few clicks you can establish a connection with the bus and gain access to all its proxy services.

It is no longer necessary to log into the bus console to get a list of all available services. Users also don't need to worry about working with WSDL files and trying to guess the URL for a particular services. Everything is available directly from AquaLogic BPM Studio environment, as illustrated in Figure 3.

Once a service is selected, it becomes part of the ALBPM catalog. It can then be used easily by any business process that may be required by that service. Figure 4 shows how the LoanGateway service from the sample project that comes with ALSB 2.6 is being called from a business process.

On the other hand, after a business process is created, it can quickly be exposed as a service and registered with bus. This can also be done directly from AquaLogic BPM Studio, as shown in Figure 5a.

You can also do that from the runtime AquaLogic Process Administrator, as shown in Figure 5b.

Once a process is registered with ALSB, it will become visible in the Project Explorer, as shown in Figure 6. Different users can also make use of the newly exposed service. Again, the main goal was to make it easy to get services to and from ALSB from ALBPM. All the required infrastructure work managing WSDLs and all required registration processes have been automated so that users can focus on the business problem they are trying to solve.

Once a business process is published, it becomes available in the AquaLogic BPM Workspace, as shown in Figure 7. This is one of the Web-based entry points for business users to interact with their processes. In this case, a business process is calling the sample loan application inside ALSB 2.6. The service is part of a business process and can be called directly from the workspace without the need for complex interaction or any knowledge of the bus infrastructure.

The ability to go back and fourth between services in ALBPM and ALSB is critical for orchestration. Users can take advantage of both XPDL 2.0 and BPEL 2.0 to model their business processes, and with just a few clicks they can invoke services and register a business process as a service.

Native Security

The majority of authentication requests in ALSB are made via the WS-Security Username Token Profile, as shown in Figure 8. The ALBPM 6.0 release provides native support to WS-Security. This enables business processes to talk directly with ALSB and vice versa, exchanging credentials through a common format. There is no need to massage credential types to match one another. For the next major release of ALBPM, post-6.0, a few other token flavors are under exploration based on customer demand.

Faster Communication

In ALSB 2.6, a new transport infrastructure has been made available for other applications to customize the communication with the bus. The new version of ALBPM provides both inbound and outbound transports for ALSB. In addition to the improvement in communication performance over time, new capabilities include transaction propagation and the ability to exchange more complex security context.

Figure 9 shows how users can select a transport type inbound to ALSB. Processes calling services inside ALSB would benefit from a faster RMI over T3 protocol communication instead of a typical Web services request.

Figure 10 shows how users can configure a transport type outbound from ALSB. Applications that may need to call a business process as a service registered with ALSB can also benefit from the optimized communication transport.

Communication performance between the two products continues to be optimized. Future releases will aim for faster throughput and minimizing latency across process calls. Better communication performance between ALSB and ALBPM is available when both products are installed on the same machine (making use of the same JVM), using the custom transport. In some cases, we have seen a 30-percent improvement in performance. Using the custom transport in the same JVM allows communication to bypass the use of sockets and serialization that is required during normal communication. ALBPM and ALSB can also be deployed separately, but then performance is dependent on network performance.

Summary

AquaLogic BPM Suite 6.0 provides several exciting new features. Some of them include the optimized integration with AquaLogic Service Bus. This integration features: the ability to register and invoke services directly to and from ALSB without having to deal with WSDLs; support for native security by means of WS-Security Username Token Profile; and the availability of a new custom transport to improve communication performance between the two products. Customers will be able to leverage orchestration capabilities more easily from ALBPM and will also benefit from all the management, routing, and SLA capabilities in ALSB.

References

• Visit the AquaLogic Service Bus and AquaLogic BPM Suite product centers for more articles and blogs

출처 : http://dev2dev.bea.com/pub/a/2007/07/aqualogic-bpm-servicebus.html?page=1

Use X.509 certificates to establish identity

1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit (see Use the Change Center).

            만일 준비가 되어 있지 않다면 , 어드민 콘솔에서  Change Center에서 Lock & Edit을 클릭해라.

      2. In the left pane of the Administration Console, select the name of your domain. This is  the top-level node of the navigation tree. 
        어드민 콘솔의 왼쪽 패널에서 도메인을 선택해라. 네비게이션 트리의 가장 상단에 존재한다.

       3. In the right pane, select Web Service Security.

          오른쪽 패널에서 Web Service Security 를 선택해라.

      4.In the table, click the name of the Web Service security configuration you want to update.

        테이블에서 업데이트 하고자 하는 웹서비스 시큐리티 설정명을 클릭한다.
Web Services programmers associate a Web Service security configuration using the @WssConfiguration JWS annotation; the value attribute specifies the associated configuration name. If the programmer does not specify the value attribute, the Web Service is associated with the default security configuration: default_wss.
      웹서비스 프로그래머는 JWS 어노테이션 @WssConfiguration을 사용하는 설정과 관련있다. 값속성은 연관된 설정값을 명시한다. 만일 프로그래머가 값속성을 명시하지 않았다면,
    웹서비스는 기본 시큐리티 설정인 default_wss와 연관이 있을 것이다.

     5. Select Token Handler.
        토큰 핸들러를 선택하라.

     6. Click New. 
        New를 클릭하라

     7.Enter the following values in the required fields:

•  Name: A name for your token handler. This can be anything you want.

          Name : 토큰 핸들러의 이름. 원하는 것으로 가능

• Class Name: Enter the following exact value: weblogic.xml.crypto.wss.BinarySecurityTokenHandler.

          Class Name : 다음의 값을 정확히 입력해라

• Token Type: Enter the following exact value: x509.

          Token Type :  x509 값을 정확히 입력해라

• Handling Order: Enter an integer to specify the order in which this token handler is handled.

         Handling Order : 토큰 핸들러의 order를 명세화하기 위한  숫자값을 입력하라

     8. Click Finish.  Finish를 클릭하라

     9. In the Token Handlers table, click on the name of the token handler you just created.
        Token Handler 테이블에 방금 생성한 token handler의 이름을 클릭하라.

     10.At the bottom of the page in the Token Handler Properties table, click New.
         Token Handler Propeerties 테이블 에 페이지 아래에 있는 New를 클릭하라

      11. Enter the following values in the fields: 다음 값을 입력하라

• Name: Enter the following exact value: UseX509ForIdentity.
• Value: Enter the following exact value: true.

       12. Click OK.

       13. Click Save.

       14.In the left pane of the Administration Console, select Security Realms.
           어드민 콘솔에서 왼쪽 패널에 Security Realms를 선택하라

        15. In the right pane, click on the myrealm security realm, displayed in the Realms table.
           오른쪽 패널에서 디스플레이된 Realms 테이블에서  myrealm security realm을 클릭하라

        16. Select Providers > Authentication.

         17. Click DefaultIdentityAsserter in the Authentication Providers table.

         18. Select Configuration > Provider Specific.

         19.Ensure that the Default User Name Mapper Attribute Type drop-down list is set to the name of the attribute from the subject DN to use when mapping from the X.509 certificate name token to the WebLogic user name. 
             Default User Name Mapper Attribute Type 드릴다운 리스트는 웹로직 계정에 x.509 인증 네임토큰로부터 맵핑할때 사용하기 위한 subject DN으로 부터 속성의 이름을 설정하는 부분이다.
           

         20. In the Active Types section, move X.509 from the Available to the Chosen box.
              Active Types 섹션에서  X.509를 이동시킨다 이용가능한 박스에서 선택된 박스로.

          21. Ensure that the Use Default User Name Mapper check box is checked.

          22. Click Save.

          23.To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Not all changes take effect immediately—some require a restart (see Use the Change Center).

Create a Web Service security configuration

When a deployed WebLogic Web Service has been configured to use message-level security (encryption and digital signatures, as described by the WS-Security specification), the Web Services runtime determines whether a Web Service security configuration is also associated with the service. This security configuration specifies information such as whether to use an X.509 certificate for identity, whether to use password digests, the keystore to be used for encryption, and so on. A single security configuration can be associated with many Web Services.

메시지 레벨의 시큐리티(WS-Security 스펙에 의해 기술되는 암호화, 전자인증서)를 사용하기 위해서 설정되어진 웹서비스가 웹로직에 디플로이 될때에, 웹서비스 런타임은  웹서비스 시큐리티 설정이 서비스와 연관되어져 있는지 아닌지를 결정한다. 시큐리티 설정은 아이덴티티를 위한 x.509 인증 또는 사용될 패스워드 요약 또는 암호화에 사용할 키스토어 등등에 대한  정보등을 명기한다.
단일 시큐리티 설정은 많은 웹서비스와 연관지어질 수 있다.

WebLogic Web Services are not required to be associated with a security configuration; if the default behavior of the Web Services security runtime is adequate then no additional configuration is needed. If, however, a Web Service requires different behavior from the default (such as using an X.509 certificate for identity, rather than the default username/password token), then the Web Service must be associated with a security configuration.

웹로직 웹서비스들은 시큐리티 설정들과 연과되어지는 것을 요구하지 않는다; 만일 웹서비스 시큐리티 런타임의 기본 행위자가 충분하다면 추가적인 설정은 필요치 않다.
그러나, 웹서비스가 기본적으로 다른 것(아이텐티티를 위한 X.509 인증 사용과 같은) 을 요구한다면 웹서비스는 반드시 시큐리티 설정과 연관성이 있어야 한다.

At development time, a programmer uses the @weblogic.jws.security.WssConfiguration JWS annotation in the JWS file that implements the Web Service to specify the name of the security configuration that is associated with the Web Service. The following procedure describes how to create this security configuration using the Administration Console. Later you can update this configuration with the specific security behavior required by the Web Service.

개발 시점에 , 프로그래머는 웹서비스와 연관되어진 시큐리티 설정의 이름이 명시되어진  JWS 어노테이션을 사용한다. 다음 단계는 어드민 콘솔을 사용해서  어떻게 시큐리티 설정을 할것이냐는 것이다. 나중에 웹서비스에 의해서 명세 시큐리티 행위자와 함께 이 설정이 업데이트 될것이다.

When the programmer uses the @WssConfiguration JWS annotation, they specify the name of the associated security configuration using the value attribute; if the programmer does not specify this attribute, then the service is associated with the default security configuration: default_wss. This default security configuration must also be explicitly created using the Administration Console, as described in this procedure.

프로그래머가 @ WssConfiguration JWS annotation을 사용할 때, value 속성을 사용하여 시큐리티 설정과 관련된 이름을 명세할 것이다. 만일 프로그래머가 이 속성을 명세하지 않는다면, 서비스는 default_wss라는 기본 시큐리티 설정과 연관되어질 것이다. 이 순서에 설명된것처럼, 기본 시큐리티 설정은  어드민 콘솔을 통해 명확하게 생성되어야 한다.

The following procedure describes how to create a simple Web Services security configuration.
다음은 간단한 웹서비스 시큐리티 설정을 생성하는가를 설명한 것이다.

1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit (see Use the Change Center).
2. In the left pane of the Administration Console, click the name of your domain. This is the top-level node of the navigation tree.
3. In the right pane, select Web Service Security.
4. Click New.
5. In the Web Service Security Configuration Name field, enter the name of the new Web Service security configuration.

   If you are creating the default one, call it default_wss. If you are creating one that a particular Web Service needs, name it the same as the value attribute of the corresponding @WssConfiguration annotation.

6. Click OK.
7. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
   Not all changes take effect immediately—some require a restart (see Use the Change Center).

ESB Architecture & Lifecycle Definition

A Brief Introduction

Progress Software developed a comprehensive definition of the Sonic ESB, including its development and deployment lifecycle at an architectural level, using industry-standard modeling techniques. The following is an overview of the ESB definition, which is fully defined in the whitepaper The Sonic ESB: An Architecture and Lifecycle Definition.

Service-oriented architecture (SOA) is fast becoming the systems and software approach of choice for the majority of medium and large enterprises.1 According to the principles of SOA, IT professionals design, implement and deploy information systems from components that implement discrete business functions. These components, called "services", can be distributed across geographic and organizational boundaries, can be independently scaled and can be reconfigured into new business processes as needed. This flexibility provides a range of benefits for both the IT and business organizations.

Core to the IT infrastructure supporting SOA is the enterprise service bus (ESB) which connects and mediates all communications and interactions between services. Given the importance of the enterprise service bus (ESB) to SOA implementation - and its affects on costs, development and deployment processes - it is important to understand the functions and structure of the ESB and how its design permits rapid change in, easy connections to, and clear visibility and control of services and processes in a SOA-based application.

Figure 1 shows an example of SOA used to integrate and mediate a multichannel financial trade process. This represents a combination of existing systems "wrapped" with a services interface and new services created to enhance the business process. This example illustrates how an equity trade order would originate from an Order Management Service, undergo a transformation of data elements to support the requirements of the trading system and the Compliance Service, flow through to trigger a fund transfer with the Funds Transfer Service, and ultimately get logged as a completed transaction in the Logging Service. Rather than an integrated application, in this case the trade process is executed as a sequence of heterogeneous process steps, coordinated by the SOA infrastructure.

Figure 1: Example of SOA Application

In this example the ESB is providing the connectivity with routing between services, the transformation of XML data to allow services with varying interfaces to communicate, and the business process sequencing of services.

Sonic Software introduced the industry's first ESB and has continued to be the market leader in ESB functionality. As such, the Sonic ESB ® (hereafter referred to simply as "ESB") sets a reference mark for the SOA marketplace. The ESB is complemented by additional products in the Sonic SOA Infrastructure family including its Workbench, Orchestration Server, XML Server, Collaboration Server and Database Service.

The approach being taken in this full ESB definition effort is to describe each of the key ESB functional areas through exposition of its function and benefits accompanied by structure diagrams based on an industry-standard approach, UML (Unified Modeling Language). UML Class diagrams provide a definitive architectural definition for the ESB that is useful for learning and discussion. Figure 1 employs an ESB diagramming notation introduced by David Chappell in his book Enterprise Service Bus.

Services, Communication and Mediation

Core to the support of a service-oriented architecture (SOA) is the support of services and their communications. Figure 2 shows a UML Class diagram with an overview of the ESB structures supporting services, communications and mediation.

Figure 2: Overview Architecture for Services, Communication and Mediation

ESB Services (left of Figure 2)

ESB services may be any of a number of types. Typical ESB services which implement mediation are: XML Transformation, Content-Based Routing and User Defined Mediation. An XML Transformation Service provides data conversion from one XML document to another according to an XSLT specification. A Content-Based Routing Service directs messages to various other service endpoints according to configured routing rules. A User-Defined Mediation Service implements a function such as logging or custom validation which complements the core business logic. A User-Defined ESB Service connects to business services (see below) to implement core business logic.

ESB services execute within the ESB Container. The ESB container instantiates ESB services and provides the systems management interface for its services, the management of communication protocols, the capability to have multiple threads executing services for scalability, and the standard capability to execute distributed processes.

Connected Business Services (right of Figure 2)

Connected services implement the business logic for ESB-integrated applications. Types of business services include: Web Services, Legacy Systems, JMS (Java Message Service) Applications and all varieties of Application Server Applications. Each of these types of business services can communicate with each other through the ESB, and with ESB services to perform mediation. In Figure 1 the Order Management Service is a connected service which connects in through an HTTP Connection. The Compliance Service, Trading System and Funds Transfer Service are business services that have been interfaced directly to the ESB as user-defined ESB services.

Communications and ESB Processes (center of Figure 2)

This section of Figure 2 shows the core capability for services (both ESB and business) to communicate and to execute an ESB Process which is a sequence of steps invoking services or other ESB processes. Figure 1 shows an ESB process called Trading Process that has five steps.

An ESB service sends and receives messages through references to ESB endpoints and ESB addresses. For example, an ESB service such as the compliance service in Figure 1 can configure its Exit to refer to the ESB address of another service to receive output messages - in this example that would be the Trading Service. Alternatively, the ESB address can refer to an ESB process.

An ESB process is defined by an ESB Itinerary which contains a sequence of Process Steps. Each process step can invoke one (or multiple) ESB services, other ESB processes, or an external Web service. The ESB itinerary is carried with its associated ESB message providing a completely distributed, and hence reliable, execution environment for the ESB process. There is no central processing engine for the itinerary as each ESB container can process and route the next step in the ESB itinerary. This provides both efficient execution without the need to communicate to a central site and reliability as processing can continue even with some losses of connectivity.

Each ESB service can have its entry and exit endpoints changed without requiring changes to their implementations.

The ESB Endpoint provides the capability for ESB services to send and receive messages with a specified Quality-of-Service, for example "best-effort", "reliable" or "guaranteed, once-and-only-once". The connection tells what supporting messaging channel is used by an ESB endpoint to connect with an ESB service or a business service. This messaging channel can use an ESB native connection, or for external systems can use Web Service Connection, JMS Connection or JCA (J2EE Connector Architecture) Adapter.

The ESB Connection employs user configurable asynchronous and synchronous delivery semantics including "publish-and-subscribe", "send-and forget" and "request-reply". In the example in Figure 1 the ESB connection between the Order Management Service and the Trading Process is Web Services request-reply. If a business or ESB service needs to change the manner in which it connects, this can be affected without requiring changes to its implementation. When services require differing types of connections, the ESB provides the mediation between the differing protocols.

The ESB Message class and the sends and receives associations between ESB endpoint and ESB message create the basic structure for one ESB service to send a message to another ESB service through an ESB service's Dispatcher. The dispatcher manages the sending and receiving of ESB messages between ESB services and external endpoints, in effect implementing the arrows between process steps shown in Figure 1. This dispatcher also manages ESB processes.

Industry-standard WSDL (Web Services Definition Language) Definitions can be created for ESB services and ESB processes. This allows the use of standard tools and integration with other SOA infrastructure components such as a UDDI Registry. For example, in Figure 1 the entire Trading Process ESB process is exposed as a Web service.

Key benefits of this approach to implementing ESB services, mediation and connection to business services include:

• Business agility through rich support for mediation services including XML transformation and built-in support for distributed ESB processes.
  
  
• Broad reach across many kinds of business services and communications protocols; integration of heterogeneous legacy and new Web service elements.
  
  
• Distributed process execution, performance and reliability even in highly-distributed deployments.

ESB Development, Deployment and Production Management

Intrinsic to the ESB is rich support for the entire services life-cycle from development to deployment to management. Figure 3 shows a UML Class diagram with an overview of some of the key structures for this support. The figure is divided to reflect the migration of ESB services from development systems to staging/test systems to a distributed production environment. A critical requirement for the Sonic SOA Suite is to allow such a migration to occur in the easiest error-free manner possible.

Figure 3: Overview Architecture for ESB Development, Deployment and Production Management

Development Systems (left of Figure 3)

The top of this diagram section shows Development Tools while the bottom, labeled "Development ESB" defines the core components of the ESB infrastructure which are used in each stage of the ESB Lifecycle from development to staging/test to production environments.

The Workbench provides each developer with a set of tools for ESB development and deployment including creation of custom ESB Service Type implementations. For example, in Figure 1, the Logging Service would be a custom ESB service type. With a set of Resource Editors, in concert with third party and industry standard development environments, developers create Resource Files which are stored in the ESB Repository (a configuration repository). The Sonic Workbench provides for the creation of Development Projects containing all of the configuration files for a specific service development project in support of a composite or ESB application. In the trading example this would include files describing the ESB process and it's WSDL file, used to expose the process as a Web service. It would also include the Logging Service implementation, among other resource files.

Editors include: the ESB Process Editor for visually creating and editing business process definitions tying together multiple ESB services, the XLST Editor for creating the XLST Stylesheet defining an XML transformation and the Routing Rules Editor to create the configuration file used by content-based routing services.

The Management Console provides the management framework for configuring the Sonic SOA infrastructure for ESB services, ESB containers and the supporting SonicMQ multi-protocol communication server elements. The Management Console allows for the configuration of new instances of ESB services and ESB containers to allow an easy "configure-and-go" approach to managing the SOA infrastructure. Using this console, for example, the ESB Connection between all services in the Figure 1 trade process would be set to "once-and-only-once" to prevent the chance of any message losses.

Staging/Test Systems and Deployment Tools (center of Figure 3)

Moving configurations from Development to Staging/Test to Production environments is done with the Deployment Tool. Selected resource files and configurations are moved through the creation of intermediate archive files and the use of the Deployment Map File to map service and messaging parameters to operate properly in the targeted environment where quality of service settings, security policies and ESB addresses may differ. The diagram shows the promotion and deployment of configurations from the development directory service to the staging/test directory service.

Production Systems (right of Figure 3)

The deployment tools are also used to promote and deploy ESB configurations from the staging/test directory service to the Production ESB Repository.

The management console is used to place ESB containers and their configured services onto multiple distributed systems where interaction policies, transport bindings and communication layer security policies are established.

The ESB provides highly reliable support for distributed systems. As shown in the diagram section labeled "ESB Distributed", an ESB Repository Cache is used to provide local copies of the configuration files used by ESB containers and ESB services executing on distributed systems. This provides the ability for distributed systems to be both high-performance and reliable, and allows continued independent operation even when the production directory service is unavailable or unreachable. This same execution environment is available, but not illustrated, in both the staging/test and development environments.

Having multiple distributed systems in an ESB provides scaling of ESB service capacity across machines and locations. Each distributed system shares the same configuration for reporting faults and sending status back to the management console. In the financial trade process example, it would be possible to replicate the transform service on multiple execution machines such that if it were needed between each step in the process (a likely situation) that there would be multiple instances running across a network of machines that could be recruited to address peak.

The administrator uses ESB services and ESB processes to automate the handling of these errors and notification events in a service-oriented fashion, leveraging the same ESB infrastructure. For example, if errors occurred in the Compliance Service step of the trade process depicted in Figure 1, the normal fault endpoint of that service could be configured to route the error back to the requestor using a reply-to semantic or a separate exception process could be defined to receive the fault on it's entry endpoint.

Key benefits of this approach to implementing ESB development, deployment and management include:

• Rich set of development and management tools allow for easy "configure-and-go" deployment.
  
  
• Deployment tools provide support for the ESB lifecycle and allow for the automated mapping of configurations and movement of implementation resources from development to staging/test to production environments.
  
  
• Distributed execution environment including directory caching allows for high-performance, scalable and continuously-available SOA systems.

For a more thorough definition of the Sonic ESB, including a complete UML class diagram, download the whitepaper The Sonic ESB: An Architecture and Lifecycle Definition.

1Heffner, Randy, "Delivering Real World SOA", Forrester Research, 2005.

<출처: http://www.sonicsoftware.com/products/sonic_esb/architecture_definition/index.ssp>