One of the strengths of WebSphere Business Services Fabric V6.0.2 (hereafter called Fabric) is the Dynamic Assembler's ability to dynamically select an endpoint based on content, context and contract of a message. This article answers the following questions:
- What real-world service-oriented architecture problem does Fabric solve?
- What are the inter-relationships between services, business services, entitlements, assertions, policies and composite business applications?
- How does Fabric make its dynamic endpoint selections?
Business service scenarios
Figure 1 illustrates a scenario seen in many enterprises that have implemented Web services. The user community, comprised of Users A through D, has several business applications available to them. You can assume that each business process leverages one or more services delivered by various back-end resources.
Figure 1. Typical scenario with several applications that leverage Web services.
In Figure 2, you can see that policies have been introduced to the scenario. These policies essentially determine the service-level agreements for the endpoints. For example, a business policy may specify that the 3rd party service is available to User A during normal business hours, while the custom service is available to User D 24 hours a day, 7 days a week. Several questions need to be answered to determine whether the existing model is flexible enough to support the scenario in Figure 2.
- Should policies dictating access to services be associated with the business applications? Or should policies be embedded in services?
- Can this model support giving users varying priority, such as User A over User D?
- If a policy changes, is it the business application or the service that should be redeployed?
Figure 2. Determining the appropriate policy targets is a key decision
Figure 3 introduces more complexity through the addition of a new user and new service. In this scenario, user access policies are often hard-wired into the logic of the business process, which means that the business process must be modified and redeployed. The architects and administrators responsible for this model should consider the following points:
- Can new functionality be incorporated into the existing business processes to account for the new service?
- How can current policies be applied to new users?
- Can access methods be changed easily, such that User A is granted access for thirty days, but in forty-five days both User C and User D need access?
Figure 3. New users and services are introduced
The scenarios outlined in Figures 2 and 3 are not unique. From a system management perspective, the tasks are complex and time-consuming. Analysts and administrators must consider all of the following:
- Are there other business processes that may require these services?
- What other users and groups may require access to services?
- Is it possible for one of more services to become overloaded by too many requests?
- What policies are currently in effect, and will new policies conflict with or override them?
- What are the downstream consequences of changing or adding policies?
Moving from services to business services
In the previous section, we presented several scenarios that posed questions about the management of business processes. In this section, we'll describe a common vocabulary used by Fabric.
Consider a large retail enterprise that conducts thousands of credit approvals on a daily basis. In order to handle this volume of credit approvals, the enterprise has developed and implemented a credit approval process. This business process is comprised of many repeatable business tasks or components. An example of one of those tasks might be credit eligibility. Credit eligibility is an example of a service within the credit approval process.
It would benefit the enterprise if the credit eligibility service could adapt its behavior at run-time. Perhaps the service should behave differently based on who is being served or how the service is requested. Another possible differentiator could be what service levels are available from the potential service providers. Fabric uses a business service to represent a business function whose execution can be adapted at run-time. A business service has three dimensions: who, what, and how.
The dimensions of a business service
Figure 4 shows the three dimensions of the credit check business service. Consider that a customer service representative (CSR) uses the enterprise’s Web portal to access the credit check business service. Business policies describe the business agreements based on how the business service is used. Business policies are the "how" dimension. Risk assessment business policies and pre-approval policies may dictate that higher risk customers are processed with the credit check business service.
Service assertions describe the capabilities, categorizations and access methods of the endpoints. Service assertions are the "what" dimension. The 3rd party service could assert that its service response time must be less than 200 milliseconds. The same service could also assert secured access (SSL vs. non-secured) or service availability (hours of operation).
Entitlements are the user contexts that consume the services. Entitlements are the "who" dimension. Entitlements allow the enterprise to support several different response modes for the user community; for example, a Web portal channel and IVR channel. Each of these channels supports and serves a unique user community and access mode.
Figure 4. The three dimensions of a business service
How Fabric simplifies the business process logic
As shown in Figure 5, when a business process is built and managed without Fabric, the business process must be aware of all the variations of "who" it calls, "how" it is called, and the potential set of providers in order to exploit multiple endpoints. This can make the business process quite complex and difficult to manage. However, if business processes are deployed using Fabric, the business process can reference the business service, which is at a higher level of abstraction.
What are the benefits in this strategy? The business process can be designed and assembled more in line with the actual process it represents. The business process does not need to take into consideration the actual implementation of the service’s endpoints. When designing with Fabric, the business process looks generic and simple. The business process can say, “I'd like to call the business service credit check.” Fabric provides the agility needed in these scenarios by enabling control of policy-driven assembly of services. The driving force behind Fabric’s strategy is the Dynamic Assembler.
Figure 5. Business process complexity with and without Fabric
The Dynamic Assembler – the engine of Fabric
Every high-speed train has an efficient engine to guide it from one point to the next. For Fabric, that engine is the Dynamic Assembler. The Dynamic Assembler is the endpoint selection engine behind the Fabric. When requests are made for an endpoint, the Dynamic Assembler’s job is to guide the request to the appropriate endpoint and return the response to the requester. In a non-Fabric configuration, when a service request is made, the service endpoint is called directly. In a Fabric configuration, the service endpoint is not called directly; instead, the Dynamic Assembler is called by the service provider and acts as a smart proxy to determine the correct endpoint.
Context, content, contract, assertions and policies
The "fuel" for the Dynamic Assembler endpoint selection engine is metadata that is captured and processed. In a message passed to the Dynamic Assembler. The message may supply a user’s role, an organization, a delivery channel or the time of day. This metadata is called the context. Context can be thought of as the conditions under which a service invocation occurs. In the same message, the loan amount, type of customer and loan origination state may also be supplied. This metadata is called content. Content specifies the business details of the service invocation and is housed in the payload of the message. The contract, which is based on the context and content of the request, is the set of requirements that the service provider must meet. For example, maximum response time, hours of operation and regulatory rules.
Figure 6 illustrates the metadata Dynamic Assembler uses in endpoint selection.
Figure 6. Metadata used by the Dynamic Assembler to select and invoke an endpoint
WebSphere Business Services Fabric uses the concept of assertions to make
declarations about service provider endpoints. Service provider endpoints
have assertions, which are the unique characteristics that describe an endpoint’s
capabilities. For example an endpoint for the credit check business
service might be available for a specific number of hours each day. A
manageability assertion called
HoursOfOperationAssertion could be asserted on
that endpoint. Additionally, it might be determined that the endpoint is
considered unavailable when it times out in five seconds. A reliability
TimeOutAssertion could be
asserted on the endpoint. Assertions are also used by the Dynamic
Assembler to evaluate service requests and determine policy requirements,
as we'll describe later.
Business requirements that must be met when a service consumer requests a service are called policies. Policies are the mechanism for providing the Dynamic Assembler the rules for endpoint selection. Policies are modeled in the Fabric Composition Studio, and stored as metadata in the Fabric Business Services Repository. They consist of the three dimensions that we discussed: context of the service request, content and the contract. Policies are modeled with an If-Then structure. Take a look at this policy example for the credit check business service:
IF (state=NY and WebService=getRecord and trxDate< 30 May 2007) THEN (useVersion=2.1 and opHours=24x7)
In this example, the context is
WebService = getClientRecord and
trxDate < 30 May 2007).
The content is
state = NY. The contract
indicates that the business service should
useVersion = 2.1 and
opHours=24x7. Not shown are the assertions on
the endpoints. The selected endpoint’s assertions are the best match for
Figure 7. Policy example
The context and content for a service invocation determine which policies apply. The contract is the intersection of all the requirements specified by the business policies that apply to a particular invocation. The intersection of all the requirements can be thought of as a virtual contract assembled at run-time. In the next section, we'll look at how the intersection of all the requirements comes together to select an endpoint.
The endpoint selection process
When Web service requests are made, the requester sends its requests through the Dynamic Assembler engine instead of calling the actual service endpoint directly. The URI of the Dynamic Assembler is substituted for the URI of the actual endpoint. As stated earlier, policies and run-time message context and content determine which endpoint should be invoked for a specified Web service.
The Dynamic Assembler’s endpoint selection process can be roughly broken down into four steps as shown in Figure 8. This section describes each step.
Figure 8. Overview of the Dynamic Assembler’s endpoint selection process
Step 1: Determine the policies relevant to the message
The first step of the endpoint selection process determines which policies are relevant to the message. The end result of this step is a list of one or more policies. This step is broken down into five sub-steps.
- Policy targets are determined. Each policy must be associated with an
object in the business service model. The business service model is a
design-time structure created to organize the hierarchy of objects.
The highest or most general level is an application suite. The lowest
or most specific level is a user. All other resources fall between
these two levels. The association of a policy with an object in the
business service model is called a policy target. The policy targets
(design-time structure) are used to determine how to merge two
policies (at run-time) with the same assertion in their contracts.
Figure 9 shows a list of policy targets.
Figure 9. Natural ordering of policy targets in the business service model
- A subscription ID is retrieved and defines the context for the policy target. At design time, a subscription ID is created when the service is subscribed to an object in the business service model. Subscription IDs are created by an administrator using the Subscription Manager module, or by an application calling the Subscription Manager API. The subscription ID is used to discover the entire policy target chain that is associated with the service subscription.
- The Dynamic Assembler determines which policies have a target matching the policy targets for the subscription ID.
- The Dynamic Assembler next uses the natural ordering of policy targets to narrow those policies that are applicable. This sub-step uses the most specific policy target level. Natural ordering refers to how conflicts are resolved (see Figure 9). Policies defined at higher order targets can be overridden by policies set at a more specific target for the same assertion type. For example, a target at the Role level overrides a target at the Channel level. However, there is an exception to this rule when a policy has been set as “Locked.” In this case, the locked target is selected, regardless of the existence of policies at a more specific target. A target locked at the Channel level overrides a target at the Role level.
- Each policy has an effective date. Any policies that have an effective date after the service invocation date are not considered.
- Each policy has an expiration date. Any policies that have an expiration date prior to the service invocation date are not considered.
After these sub-steps have completed, the result is a list of policies relevant to the message. Using the example in Figure 10, seven policies have been selected for a particular assertion type. These policies are then passed along to Step 2, where the contract is assembled.
Figure 10. Policy evaluation sample
Step 2: Assemble the contract based on policies
The assembled (aggregate) contract is the combination of policies that match the context and content after conflicts have been resolved. Continuing with the example, the seven policies selected in Step 1 are further evaluated. Policies that do not meet the conditions (context and content) are eliminated. In this example, four policies are kept (P2, P4, P5 and P7). Each policy has its own contract, and the aggregate contract becomes an assembly of the contracts from the selected policies. The result is shown in Figure 11.
Figure 11. The Dynamic Assembler assembles an aggregate contract based on policies
Step 3: Select the endpoint that meets the contract
The next step in the process determines which single endpoint meets the contract assembled in Step 2. The Dynamic Assembler first excludes all endpoints that do not satisfy the required assertions. If multiple endpoints remain (and this is very possible), the Dynamic Assembler locates one or more endpoints based on lowest cost. Cost is metadata created when the endpoint is modeled in Composition Studio. An example of cost might be 1.5 units per transaction for endpoint A and 3.5 units per transaction for endpoint B. If multiple endpoints still remain, the Dynamic Assembler attempts to find the endpoint that most closely meets the values in the assertions by using the comparator set in the ontology. Finally, if multiple endpoints still remain, the Dynamic Assembler can select an endpoint based on an internal algorithm.
Yet another level of endpoint determination that can be accomplished using the EndPointFilter API. The EndPointFilter is called to allow the remaining list of endpoints to be sorted into tiers or rejection states. Endpoints in tier A can be considered over those in a lower tier, such as tier B. This allows the enterprise to more precisely control the endpoint selection process, rather than relying solely on the default behavior of the Dynamic Assembler. Lastly, if an endpoint is not selected, a run-time error is thrown.
Step 4: Invoke the endpoint
The final step is invocation of the selected endpoint. Once the endpoint has been selected, the Dynamic Assembler redirects the SOAP message from the requester to the endpoint. How does the Dynamic Assembler know where to redirect the message? Endpoints are registered in the Business Services Repository and the address of the endpoint is part of the metadata of a business service. The response from the endpoint is sent back to the service requester. If an error is returned by the endpoint, the error message is sent back to the service requester.
What happens after the endpoint is invoked?
There are three options for handling the response from the endpoint. The first option is to simply allow the Dynamic Assembler to act as a proxy, and the response flows back unchanged to the requester. Optionally, two Dynamic Assembler APIs can be used to customize the behavior of the response: the ResponseListener and EventListener.
The ResponseListener can modify the response from a successful endpoint invocation. An example would be a service that produces credit check verification information in a generic printing format. For a specific line of business, the format needs customization. The ResponseListener could be used to add formatting specific for that line of business. It should be noted the ResponseListener is not suitable for creating errors in normal processing.
The EventListener has two methods. One is invoked when an endpoint is found and invoked. The other is invoked when an endpoint cannot be found. The EventListener is used primarily to inform other frameworks, such as ITCAMS, that an invocation has taken place.
The Dynamic Assembler uses policies indicated by the invocation message to find an appropriate endpoint. The evaluation process follows a logical process:
- All policies that apply for a message are evaluated by the Dynamic Assembler. The output of this step is a set of policies.
- The evaluation of this set of policies produces a set of assertions that are used to select an endpoint.
- The Dynamic Assembler compares these assertions with the endpoints associated with the service interface passed in the message.
- The endpoint that best matches the assertions is invoked.
After reading this article, you should have a good understanding of how the Dynamic Assembler employs the concepts of context, content and contract to determine the appropriate endpoint for a request. WebSphere Business Services Fabric has its own vocabulary that is key to understanding how the product works as a whole, and specifically, how the Dynamic Assembler works. This article provided you a solid understanding of the terminology used in Fabric. Additionally, you should be able to contrast the use of a Fabric approach versus a non-Fabric approach to building business processes.
- WebSphere Business Services Fabric product information: Get product information, including system requirements and product features and benefits.
- IBM WebSphere Business Services Fabric Information Center: Get complete product documentation.
- WebSphere Business Services Fabric education: Get a list of Fabric courses.
- Developing adaptive composite business services using WebSphere Business Services Fabric, Part 1 (developerWorks, WebSphere Developer Technical Journal): This series of articles discusses the end-to-end process of creating composite business services with WebSphere Business Services Fabric Version 6.0.
- developerWorks BPM zoneGet complete technical resources for WebSphere BPM solutions, including articles and tutorials, downloads, announcements, webcasts, and more.
Dig deeper into Business process management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.