Introduction

This series describes in detail the options for building points of variability (POV) available to developers of composite business services (CBSs). Upcoming articles will use a general concept of workflows, which can be realized using a concrete language such as Business Process Execution Language (BPEL), as an implementation for logic in the CBS. We will focus on introducing variability at the points (steps) where workflows perform service invocations, rather than the workflow structure (steps, branches, and joins in a workflow sequence).

This article introduces the spectrum of options for implementation of POVs, and gives a detailed explanation of their technical aspects. In this article, a service invocation is a step where the workflow:

• Exchanges messages with a destination service endpoint
• Returns control back to the workflow

With this definition, the style of interaction between the workflow and service endpoint could be request/response, one-way request, and so on.

POV in workflows

This section discusses two options for introducing POVs in workflows, as shown in Figure 1. Option 1 on the left is based on choosing an endpoint to invoke. The invocation step, labeled Invoke, represents an arbitrary service invocation step in a workflow.

The dashed arrows represent one of the possible choices (E1, E2, and E3) that the Invoke step can make to choose a service endpoint. Or, the Invoke step may not choose any of the available endpoints, rendering Invoke optional.

For example, consider a BPEL process that retrieves a credit score. The process could be developed to choose one of several available credit agencies, with each agency represented as an endpoint.

To establish a baseline, let's consider a simple implementation based on BPEL and Service Component Architecture (SCA). Figure 2 shows a snippet of this type of implementation. On the left is a BPEL process with a choice step followed by individual instances of Invoke steps, each corresponding to a different service endpoint. The actual endpoints are not defined in the BPEL, but are captured in the SCA wiring diagram shown on the right of the figure. The wiring diagram highlights this implementation's static nature of the relationship between the BPEL process (represented as the SampleChoice element) and the endpoints.

Next, consider the POV option shown on the right side of Figure 1. This option assumes that, based on some choice (which could be as trivial as a default setting), a specific endpoint is selected. Aliasing an endpoint is to change the endpoint after it has been predefined in a workflow or selected by a workflow at runtime. The flexibility of this option is in separating the workflow choice of an endpoint and the actual endpoint that gets invoked.

For example, in the case of a credit score, aliasing a credit agency service endpoint enables a variety of possibilities in how a service request gets processed. The difference in the aliased endpoint could be technical, such as simply using a different URI. Or, a different endpoint could have different business consequences, such as using a service endpoint supplied by another business partner with higher per-transaction charges for processing requests.

SCA has a basic capability for taking advantage of Option 2 POV in Figure 1. For enabling Option 1 POV, WebSphere Enterprise Service Bus (ESB) and WebSphere Process Server (Process Server) provide Web-based, administrative client access to the SCA import components.

Figure 3 shows the ESB/Process Server administrative console for editing the concrete URI specified in the Web service binding for the ChoiceOne import component from Figure 2.

POV implementation options

POV in workflows described options for practical considerations when deciding to introduce POVs in workflows. This section relates POV options to some of the technical issues involved in their implementation. Exploring these technical issues will help characterize concrete WebSphere capabilities as applied to building CBSs.

Dynamicity of service endpoint choices

A key consideration in using the Option 1 POV is whether an implementation allows the pool of service endpoint choices to be modified. The question to ask is: When can the original set of choices (E1, E2, E3) be modified to add a new service endpoint E4, or to remove an endpoint E1? The options are:

Development time

Effectively static, changing the endpoint choices requires changes to the workflow along with its redeployment. The BPEL shown on the left side of Figure 2 is an example of this type of an implementation.

Runtime

Permits modifying the pool of choices while the application is running, and purely through configuration (requires the application to be changed or redeployed).

Invocation time

Equivalent to the runtime option, with an additional constraint that the choices can be modified after a decision to invoke a service endpoint has been made in the workflow. In effect, a type of a service endpoint is selected in the workflow followed by filtering the pool of end point choices to fit the selected type.

Evaluation of service endpoint selection criteria

Figure 1 doesn't impose any semantics on whether the evaluation happens within the scope of, or outside of, the workflow. With the former, the selection criteria has to be defined or used by the workflow. In the latter case, the workflow can be independent of the selection criteria, as shown in Figure 4.

Although capabilities such as business rules can be used to partially separate a workflow from the definition of the selection criteria, complete independence of the selection criteria is a preferred approach because:

• Generic workflows can be designed and scaled at runtime to fit processing requirements by customizing the selection criteria so that each activity step (based on the corresponding invoke step) can be optional. From the implementation perspective, this is a selection criteria that evaluates to an empty pool of endpoint choices, thus rendering an invoke step null. This approach can also scale to provide optional steps in a workflow per instance of a request by having the selection criteria take into account a value from a workflow request.

  For example, in a loan application workflow, the criteria can be designed to make manual application approval an optional step in cases where the applicant has a high credit score.

• Decision points can be expanded to handle new circumstances as needed. In a loan application process, different service endpoints can be used to handle premium and regular customers. Separating the selection criteria from the workflow allows the criteria to be changed without impacting the workflow.

  For example, you could introduce a new tier of loyal customers who constitute a subset of the premium segment.

Figure 5 shows the advantages of the encapsulated selection criteria described above. The null endpoint represents an invoke without a corresponding service endpoint -- an optional step. Additional credit segments can be added without changing the workflow, by having an E3 service endpoint mapping to a credit score of 750 or lower.

Dynamicity options for service endpoint aliasing

Figure 3 shows an example of how the administrative console for ESB/Process Server can be used to change endpoints. Using the administrative console is an option for implementing endpoint aliasing using WebSphere. If your solution relies on endpoint aliasing, you should consider the following characteristics of the different implementation options.

User-driven

Depends on a human to make a change to an endpoint at runtime. The baseline SCA implementation is an example of this option. Although user-driven dynamicity can satisfy the functional requirements for service endpoint aliasing, it is not sufficient for solutions where endpoints must change frequently enough to render dependency on people ineffective.

Scripted

An improvement on the user-driven approach by means of automation. For example, the baseline SCA implementation for endpoint aliasing can be automated using the WebSphere scripting interface (Jacl or Jython scripting).

Programmatic

Using the underlying invocation APIs to change a service endpoint at runtime, possibly right before the service invoke. For example, aliasing can be implemented as part of a Java™ snippet doing service invocation with SCA APIs, as shown in Listing 1. The aliased endpoint is passed in the endpoint variable highlighted in bold.

				
com.ibm.websphere.sca.addressing.EndpointReference eRef = 
  com.ibm.websphere.sca.addressing.EndpointReferenceFactory.
  INSTANCE.createEndpointReference();--------------------------------------------------(1)

eRef.setAddress(Endpoint); ------------------------------------------------------------(2)

com.ibm.websphere.sca.Service echoService = 
  (com.ibm.websphere.sca.Service)com.ibm.websphere.sca.ServiceManager.INSTANCE.
  getService("echoService", eRef);-----------------------------------------------------(3)
	
commonj.sdo.DataObject response = (commonj.sdo.DataObject)echoService.
  invoke("echo",ServiceInput);---------------------------------------------------------(4)

Protocol independent service endpoint aliasing

Different service endpoints are used to handle different message delivery protocols. Aliasing a service endpoint may also involve a change in a message delivery implementation. Consider the situation in Figure 6, where a chosen endpoint (E1) is aliased to E2, where E1 uses SOAP/HTTP as the message and delivery protocols, but E2 uses SOAP/Java Message Service (JMS). When considering how to implement endpoint aliasing (discussed in the next section) that provides protocol-independent aliasing, use the following criteria:

• Permit runtime aliasing to message and delivery protocols different from those specified during development or deployment.

  For example, consider a loan application workflow that needs to switch from using a SOAP/HTTP credit score provider endpoint to a SOAP/JMS endpoint.

• Handle the protocols specified during design and development.

  For example, when designing the loan application workflow, if the workflow is expected to use SOAP/HTTP and SOAP/JMS endpoints, the implementation must be verified to ensure that it is capable of handling these protocols.

• Support extensibility so the implementation can be customized to handle message and delivery protocols different from those specified during design and development.

  For example, an implementation capable of configurable aliasing between SOAP/HTTP and SOAP/JMS protocols should be capable of enabling aliasing to other protocols, such as SOAP/SMTP or XML/HTTP.

Message exchange pattern independent service endpoint aliasing (MEPISEA)

There are many options for exchanging messages between a workflow and a service endpoint. One of the most common approaches is a synchronous request/response message exchange, as shown in Figure 7. The workflow sends a request message to the service endpoint and expects a response from the endpoint within some configurable period of time. Traditional request/response using SOAP/HTTP is an example of this message exchange pattern. Although it's a commonly used approach, it clearly is not optimal when the service endpoint requires significant processing time, thus forcing the workflow to block processing before receiving a response.

An alternative message exchange pattern, such as one-way request, can be appropriate when the response of a service endpoint isn't needed for workflow processing. The asynchronous request/response model is suitable for workflows enabled to correlate response messages to originating requests (for example, using BPEL correlation sets). An implementation supporting MEPISEA should satisfy criteria similar to the protocol independent implementations:

1. Permit runtime aliasing to message exchange patterns different from the ones specified during development or deployment.

   Consider a loan application workflow that requests and receives applicant credit scores within 60 seconds. This workflow should be configurable to use a different credit score agency that services requests within 24 hours. For implementation, the change in configuration amounts to switching from a synchronous to an asynchronous request/response.

2. Handle message exchange patterns specified during design and development.

   Since there is a finite number of possible message exchange patterns, it is feasible to anticipate the possible patterns in a specific implementation (see Resources for examples).

3. Support extensibility to new message exchange patterns.

   Though it's feasible to anticipate message exchange during the design phase (see criteria #2 above), practical constraints may prohibit implementing support for all of the possible patterns. You should consider extensibility to new message exchange patterns when assessing the flexibility of a MEPISEA point of variability implementation.

Back to top

Choosing a POV implementation

This section compares the basic capabilities of the SCA components to some sophisticated approaches for implementing both options for POV. The six implementations shown on the left in Figure 8 are discussed. An overview of salient capabilities that differentiate the approaches and add value, are included. (Look for a detailed technical discussion of implementing these approaches in future articles in this series.)

Baseline SCA implementation

This approach is described earlier in this article and is illustrated in Figure 2 and Figure 3.

Business rules

Rule groups and rules are one option for implementing an SCA component in WebSphere Integration Developer (Integration Developer). Business rules can implement selection of a service endpoint in a workflow, and they can be edited during development and runtime.

During development, you can use Integration Developer to define an initial implementation of endpoint selection based on criteria embedded in a business rule. The selection criteria can be expressed using a business rule specific language, which is a subset of Java expressions with capabilities of querying Service Data Objects (SDOs). Alternatively, the workflow containing the business rule can have an equivalent selection expression in a Java snippet and simply pass the result to the business rule.

Two types of business rule implementations are relevant to endpoint selection:

• If-then business rules for evaluating a selection criteria.
• Action rules containing endpoint invocations that are executed depending on the outcome of selection criteria evaluation.

At runtime, an application can use the Process Server Business Rule Manager to modify the business rules. When selection criteria is specified purely in the business rules expression language, the criteria can be rewritten entirely. Naturally, at runtime the criteria can only be modified within the limits of the input parameters that are passed to the business rule. This limitation can be anticipated and mitigated by passing the entire workflow state to the rule. When the selection criteria is captured using a Java snippet, it cannot be modified using the rule manager application.

An Option 1 POV implementation (see Figure 1) using business rules is limited to choosing from a collection of endpoints specified during development. This is a limitation because each rule must be defined in a context of a rule group, and the action rules are limited to defining invocations that use partner links that have been predefined in a rule group.

Reliance on binding to partner links also limits the Option 2 POV implementations based on business rules. Since partner links resolve to SCA wires, aliasing for business rules is the same as for the default SCA implementation.

Selectors

Selectors are special purpose SCA components that are part of Process Server and are partially supported by Integration Developer (described later in this section). You can use a selector to indirectly wire a workflow with one or more SCA import components. When a workflow sends a request through a selector, the selector routes the request to an endpoint based on a selection criteria that is evaluated for each request.

At the writing of this article, the full capabilities of selectors have not been exposed through tooling and runtime user interfaces. Integration Developer 6.0.2 provides out-of-the-box support only for selectors that use date as a variable in selection criteria. Extending the selectors to use more complex criteria, specified using Java, requires that you write custom code that implements the SelectionAlgorithm interface.

At runtime, the selectors can be modified using the administrative console, though this applies only to the Integration Developer supported selectors. Custom selectors implementing the SelectionAlgorithm interface do not qualify. The console has screens for editing selector tables that can point to specific service endpoints compliant with the selector's Web service operation. Unlike the approaches described earlier, there is support for protocol-independent aliasing using a selector table. Since each entry in a selector table resolves to an SCA component, an entry can be an import component with HTTP or a JMS binding. Selectors also support runtime dynamicity of endpoint choices. Once an SCA module is deployed to a process server, the module's binding components can be added as entries in a selector table.

Selectors can be good candidates for a POV implementation. However, it's important to assess the risks of deploying selectors to production and to fully understand the capabilities of the POV implementations based on mediation modules, service registries, and dynamic assembly.

The selector-based implementation requires access to the Process Server administrative console. It might not be suitable in environments where security requires separation of access rights for the role responsible for editing the selector choices and the role of the Process Server administrator. This security risk is particularly serious in cases where selectors are used to implement POV in business logic that should be inaccessible to system administrators. In many production environments, business users should not have capabilities of a Process Server administrator (stopping or deleting applications, changing system configuration, and so on).

POV implementations that rely extensively on selectors are also a regression risk for development organizations. When deploying a new version of an application, developers must update the runtime selector tables from an existing version of an application before an upgrade. When the selectors tables change frequently, this may mean downtime of existing applications.

Because selector tables are modified through the Process Server administrative console, they do not allow invocation time dynamicity for service endpoints. Process Server provides scripted access to the administrative console capabilities, including selection table modification, but the performance impact of using this scripting interface at endpoint invocation time is unacceptable to most applications.

Mediation module

In ESB/Process Server terminology, a mediation module (MM) is a type of SCA component. MMs are designed to perform message transformations, usually between application specific (ASBO) and generic business objects. MMs are not limited to mediating content; each module's implementation, called mediation flow, can contain alternative service invocation steps, along with associated logic routing the control flow to a specific step.

Although MMs lack runtime and administrative user interfaces to access and modify routing logic, ultimately they are more flexible than selectors for service endpoint aliasing.

MMs are a step up from selectors in terms of flexibility and tooling support. WebSphere Integration Developer provides a collection of mediation primitives that assist in developing complex protocol and endpoint independence implementations. For example, there are primitives available for logging, event notification, and request routing. From the point of view of the WebSphere product line, MMs are the only type of SCA components that are supported strictly by WebSphere Enterprise Service Bus; the broader WebSphere Process Server product supports MMs and other SCA components.

Mediation with a service registry

Thus far, our discussion of options for implementing POVs ignored the issue of managing service endpoint choices. Implementations based on selectors, business rules, and mediation modules do not provide a standard approach for storing, querying, and manipulating information about service endpoints.

WebSphere Service Registry and Repository (WSRR) can be used in conjunction with WebSphere Enterprise Service Bus or WebSphere Process Server to enable dynamicity of service endpoint choices at runtime. WSRR exposes Java and Web service APIs for managing service endpoints in an internal registry. WSRR can also keep track of classification metadata for describing service endpoints. For example, an endpoint can be stored in WSRR along with:

• Associated metadata describing the WSDL interface of the endpoint
• Alternative service endpoints with different protocols or message exchange patterns
• Business information, such as the name of the company hosting the service endpoint

In terms of implementation, SCA mediation modules can be written to query WSRR to retrieve service endpoints prior to performing a service invocation. In parallel, BPEL workflows or other WSRR clients can modify the pool of service endpoints, potentially changing the behavior of the mediation modules querying WSRR. Governance features help ensure that WSRR clients are not affected when such changes are made.

Dynamic assembly

WebSphere Business Services Fabric (WBSF) provides dynamic assembly capability for workflows. Implementations based on dynamic assembly differ from the other options because they rely on out-of-workflow scope evaluation of selection criteria for service endpoints. A business analyst can implement the selection criteria in Composition Studio (a tooling part of WBSF) using a simple expression language, without any need for Java programming skills.

A POV implementation using WBSF is an approach that offers the most flexibility to developers of CBS. When deciding to use WBSF, however, it's important to understand the additional development requirements of WBSF.

For example, preexisting BPEL workflows cannot be retrofitted to leverage WBSF without changes to the workflows and implementation of additional data and logic structures for the dynamic assembly engine.

Summary

In this article you learned about classified options for exposing POVs and benefits of adding more advanced capabilities to a solution. You learned about how WebSphere product features enable POVs, including business rules and selectors, mediation using an enterprise service bus, dynamic routing using WebSphere Service Registry and Repository, and dynamic workflow assembly using WebSphere Business Services Fabric.

The next article in this series describes how WebSphere Business Services Fabric enables service behavior adaptation based on the content of a service request, policies, service definition, and semantics. You learn how to bind at runtime a service invocation in a BPEL process to one of several related endpoints by using ontology extensions and the WBSF Dynamic Service Assembler. Using a credit card scenario, you'll see the implementation steps and explore some of the issues we encountered. You'll also learn the advantage of using WebSphere Business Services Fabric over other SCA components, such as business rules, selectors, and mediation modules.

Resources

Learn

• "Building SOA composite business services, Part 1: Develop SOA composite applications to enable business services" (developerWorks, Oct 2006) introduces composite business services and discusses the term point of variability.
  
  
• Read a definition of dynamicity.
  
  
• Message Exchange Patterns details the possible message exchange patterns as proposed in the WSDL 2.0 specification.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  
• In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
  
  
• RSS feed for this series. (Find out more about RSS.)
  
  

Get products and technologies

• Build your next development project with IBM trial software, available for download directly from developerWorks.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Participate in developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

Dr. Germán Goldszmidt is a Distinguished Engineer in the IBM Software Group. His focus is on architecture of an integrated platform to deliver, customize, and deploy SOA composite business services. Previously, he was a researcher at the IBM T.J. Watson Research Center, and led the design and implementation of several technologies, including Oceano, the first prototype autonomic computing eUtility, and Network Dispatcher, the load balancer component of WebSphere Application Server.

Carl Osipov is an experienced software architect with the Strategy and Technology organization in IBM Software Group. His skills are in the area of distributed computing, speech application development, and computational natural language understanding. He has published and presented on Service-Oriented Architecture and conversational dialog management to peers in the industry and academia. His current focus is on design of reuse techniques for composite business services.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• POV in workflows
• POV implementation options
• Choosing a POV implementation
• Summary
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Integration Developer (in the SOA Sandbox: Connect)
• Demo: Process automation, adoption pattern
• Webcast: Develop innovative applications efficiently using the right application foundation in today's economy
• Briefing: WebSphere flexible business processes
• Buy: WebSphere Integration Developer (in the SOA Sandbox: Connect)

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers