![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
IBM® WebSphere Business Services Fabric (hereafter called Fabric) provides tooling and infrastructure for authoring, managing, and interacting with IT assets. For a thorough description of the various offerings and capabilities of Fabric, refer to the WebSphere Business Services Fabric V6.1 Developer's Guide, which is found along with documentation for related Business Process Management offerings in the IBM WebSphere Business Services Fabric V6.1 Information Center.
Clustered deployments are a must for serious enterprises. They enhance a customer's ability to deliver reliable and scalable service-oriented architecture (SOA) solutions. This article will address the basics of how to deploy and configure Fabric in clustered environments. Existing knowledge of general SOA principles, Fabric, and WebSphere Process Server (hereafter called Process Server) is assumed. Ideally, this includes familiarity with the installation of enterprise applications and configuring and installing WebSphere Application Server (hereafter called Application Server) and Process Server.
Scope of distributed capabilities
Fabric is comprised of multiple Enterprise Application Archives (EARs) and Process Server extensions that interact directly with the Service Component Architecture (SCA) runtime. Various computations performed by Fabric's runtime are cached to facilitate enhanced performance. However, making these cached computations available in a distributed manner is currently limited.
Some examples of these computations include:
- The business context corresponding to a dynamic assembly component's invocation.
- An expanded subscription detailing various context dimensions.
- A selection policy derived from the invocation context and the business policy rules authored in the Composition Studio or via the Fabric SDK.
- The endpoint selection and related endpoint statistics used in routing.
While each of the above computations are cached by Fabric in typical usage, only the cache pertaining to the first computation invocation context is currently able to be distributed. The benefits and specifics of distributing the context cache in a cluster are described in the following sections.
The automated installers for Fabric will install everything necessary for a clustered deployment on all platforms except for z/OS®. The z/OS operating system is a popular choice for clustered deployments, and the extra steps needed to set it up are easy enough. This exercise also provides a good opportunity to learn about the caches that Fabric uses.
After a successful installation of Fabric and its prerequisites:
- Log in to the Application Server Integrated Solutions Console (admin
console). Next, navigate to the Object Cache Instances, as shown in Figure 1.
Figure 1. Navigating to object cache instances
- After selecting Object cache instances, you are presented with a
screen similar to Figure 2.
Figure 2. Object cache instances
There are two items to note from Figure 2. First, the scope of the cache instances is specified in the first drop down. In this case, you are limiting the view by the Cell called "pschneider-m55Node01Cell". In general, and especially for Fabric clustering, it is important to create the object cache instances at the widest scope possible.
Second, in Figure 2 there are no existing object cache instances. Your particular install may or may not have pre-existing cache instances. However, if you are using the z/OS platform, you will not have Fabric caches. We will create four caches: context cache, endpoint selection cache, interface endpoints cache, and subscription cache.
When you create resources from this view, they are created in the level at which the current scope is specified. When creating the caches for clustering, leave the scope set to the cell in which the cluster will operate. The process for creating each cache is the same. You will create the first cache, and then provide the appropriate parameters for the final three caches. Afterwards, we will discuss what each cache does and how you can tune it.
Creating the Fabric context cache
From the cell scope, click New. You are presented with a configuration screen. Here, you only enter a few pieces of data, as shown in Figure 3.
Figure 3. Cache creation
Let's name the cache WBS Fabric Contexts. The name is
purely descriptive, so you can use what you like. However, set the JNDI name as
services/cache/wbsf.contexts.
This name is used by the Fabric runtime engine to look up the cache instance. As the name implies, this cache holds the context data. For now, leave the "Cache size" and "Default priority" with their default values of 2000 and 1, respectively.
For platforms other than z/OS, the Fabric Foundation Pack installer creates three caches that are currently unused by Fabric. Though you can safely ignore these caches, manual creation steps are described here for forward compatibility purposes.
Table 1 shows the data that needs to be entered for the remaining caches. Enter each in the same manner as above.
Table 1. Remaining cache configuration information
| Cache name | JNDI name | Cache size | Default priority |
|---|---|---|---|
| Fabric Mediation Endpoint Selection Cache | services/cache/fabric/mediation/selection | 1000 | 1 |
| Fabric Mediation Interface Endpoints Cache | services/cache/fabric/mediation/selection | 100 | 1 |
| Fabric Mediation Subscription Cache | services/cache/fabric/mediation/selection | 2000 | 1 |
Note that Fabric additionally creates a number of caches internally that are only accessible via Java Management Extensions (JMX). These caches are scoped to the Java Virtual Machine (JVM) within which the Fabric Engine EAR Application is executing. They are not considered stable storage. Tooling is not currently provided for affecting these caches, and operations performed upon them outside of those issued by Fabric are not supported.
Tuning caches for a clustered Fabric
Fortunately, the tuning parameters for each cache are limited. In fact, there is only one: the cache size. Let's discuss what each cache does before deciding on the appropriate values.
The context cache holds invocation context objects for the dynamic assembler. A context, as it relates to Fabric, contains the salient aspects of the context in which a service is being invoked. These aspects are called dimensions by Fabric. An invocation may have many dimensions, such as the interface of the operation that is being invoked, the application to which the invocation belongs, and so on.
Contexts are important to the dynamic assembler because routing decisions may be altered based upon them. Further, as dynamic assembly components may be nested, multiple levels of context may be built up over multiple invocations. Because of this, you need to store and retrieve contexts efficiently.
In a non-clustered environment, the default number of contexts that the context cache can hold is 2,000. This is likely enough for a non-clustered environment, but it may not be suitable for clustered topologies, depending on the situation. Contexts are disposed after they are no longer necessary, and so the number of instances that this cache holds represents the number of concurrent invocations that are flowing through the Fabric installation.
One subtle point to keep in mind: Long-running asynchronous processes that use dynamic assembly will keep a context in the context cache for as long as the process takes to complete. In the case of a human task operation, this can be days, weeks, or longer. Give special consideration for operations such as these.
Finally, keep in mind that the setting listed here is for the entire Fabric installation, not for each dynamic assembly component. Depending on the number of transactions and the length of each process, a single dynamic assembly component can create 2,000 context instances, which fills up your cache.
The endpoint selection, interface endpoints, and subscription caches are not yet used, so we will not tune their parameters at this time. Keep in mind that for forward compatibility, you can still create them if they do not already exist.
Disk-offload, context persistence, and cluster failures
As mentioned previously, the context data is cached in a cluster-wide cache that scales with the cluster. This cache, provided by WebSphere Application Server, is called dynacache. Dynacache is a distributed cache the enables the sharing of data between clustered application servers. It is fairly complex. For more information about dynacache, see IBM Redbook: Mastering DynaCache in WebSphere Commerce.
There are two more items to discuss pertaining to the context cache and its relation to dynacache. First, the current implementation is not designed to withstand a failure of the entire cluster. Note that if a subset of the application servers within the cluster fails, you can recover the context data. Future releases of Fabric will likely mitigate this risk, perhaps with full context persistence.
Second, you may notice the disk-offload feature during the configuration of the cache instance. By default, this feature is not enabled. Do not confuse the disk-offload feature with persistence. You can use it when the amount of data to be stored in the cache exceeds the main memory of the application server systems. Because data is replicated across the cluster, each server in the cluster has enough main memory to store the entire context data. If this is not the case, disk-offload can help move less-often accessed context data to and from disk-based storage. Again, this is not a persistence feature; this is a memory management feature.
Using WebSphere Business Services Fabric in a clustered environment is straightforward, requiring minimal intervention from the user. This article described how to deploy and configure Fabric in such an environment. It also covered how to correctly tune the applicable caches. Clustering WebSphere Business Services Fabric can help you deliver reliable and scalable SOA solutions in your enterprise deployment.
- Creating
flexible SOA business solutions with WebSphere Business Services Fabric, Part 1: Overview: Part 1 of this series describes the concepts of business
services and composite business services and how Fabric provides
an SOA platform to model, assemble, deploy, manage, and govern composite business
services.
-
Creating flexible service-oriented business solutions with
WebSphere Business Services Fabric, Part 2: Extending the ontology models: Part
2 describes how to model the variability points in the business process as
ontology extensions using the Fabric Modeling Tool.
- IBM Redbook:
Mastering DynaCache in WebSphere Commerce: This book describes how to use WebSphere
dynacache to improve the performance of WebSphere Commerce Web sites.
- WebSphere business process management zone:
Get the latest technical resources for WebSphere BPM solutions, including
articles, tutorials, events, downloads, and more.
- Business Process Management
enabled by SOA: Get complete product information on IBM BPM software, including features and
benefits, downloads, and more.
- WebSphere
Business Services Fabric product information: Get product information, including features and prerequisites.
- Service
Component Architecture (SCA): Get information and the specification for SCA, a technology that simplifies
application development and implementation in an SOA.
- WebSphere
Business Process Management V6.1 Information Center: Get complete product documentation for WebSphere BPM products.
- Getting started with IBM WebSphere Business Services Fabric V6.1:
This IBM Redbook provides a complete overview of Fabric, from an architectural introduction, to an installation guide, and a step-by-step scenario that describes
how to model, assemble, deploy, and manage composite business applications.
Nik Krishna is a Software Engineer at IBM in Austin, Texas. His main focus is enterprise level software and service-oriented architecture. He is currently a developer on the WebSphere Business Services Fabric team.
Patrick Schneider is a Software Engineer at IBM in Austin, Texas. He currently works on the WebSphere Business Services Fabric runtime components team. Patrick is a committer on the Apache Maven project.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
