Demystifying WebSphere Business Services Fabric policy evaluation and dynamic endpoint selection

Learn how the WebSphere® Business Services Fabric Dynamic Assembler uses content, context and contract to dynamically select service endpoints. You'll learn how policies are used to select candidate endpoints, and how the Dynamic Assembler handles policy conflicts and policy resolution.


Addison Goering (, Software Engineer, IBM

Author photoAddison Goering is a course developer and instructor in the WebSphere education development group. He lives in the Chicago area with his wife, five children, five cats and four Australian Shepherds. You can reach Addison at

developerWorks Contributing author

Lawrence Louie (, Technical Support Engineer, IBM

Lawrence Louie photoLawrence Louie is a technical support engineer supporting WebSphere Process Server and WebSphere Business Service Fabric products. He lives in Foster City, CA with his wife and daughter. You can reach Lawrence at

27 February 2008


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.
Figure 1. Typical scenario with severalapplications built leveraging 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.

  1. Should policies dictating access to services be associated with the business applications? Or should policies be embedded in services?
  2. Can this model support giving users varying priority, such as User A over User D?
  3. 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 2. Policy targeting 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:

  1. Can new functionality be incorporated into the existing business processes to account for the new service?
  2. How can current policies be applied to new users?
  3. 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
Figure 3. New users and new 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:

  1. Are there other business processes that may require these services?
  2. What other users and groups may require access to services?
  3. Is it possible for one of more services to become overloaded by too many requests?
  4. What policies are currently in effect, and will new policies conflict with or override them?
  5. 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
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
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
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 assertion called 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 the contract..

Figure 7. Policy example
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
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.

  1. 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
    Figure 9. Natural ordering of policy targets in the business service model
  2. 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.
  3. The Dynamic Assembler determines which policies have a target matching the policy targets for the subscription ID.
  4. 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.
  5. Each policy has an effective date. Any policies that have an effective date after the service invocation date are not considered.
  6. 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
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
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:

  1. All policies that apply for a message are evaluated by the Dynamic Assembler. The output of this step is a set of policies.
  2. The evaluation of this set of policies produces a set of assertions that are used to select an endpoint.
  3. The Dynamic Assembler compares these assertions with the endpoints associated with the service interface passed in the message.
  4. 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.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Business process management on developerWorks

Zone=Business process management, WebSphere
ArticleTitle=Demystifying WebSphere Business Services Fabric policy evaluation and dynamic endpoint selection