This three-part best practices series focuses on the tips and techniques involved in integrating WebSphere eXtreme Scale DynaCache into WebSphere Commerce Server environments. The tips and techniques in this series are based on successful launch experiences with some of the largest WebSphere Commerce Server installations. The series includes information about designing, deploying, configuring, and tuning applications in WebSphere Commerce environments.
The series does not provide step-by-step instructions for installation and configuration of the WebSphere eXtreme Scale DynaCache in WebSphere Commerce Server environments. Basic WebSphere eXtreme Scale DynaCache setup information is found in Bohn's article "Configure WebSphere Commerce to use WebSphere eXtreme Scale for dynamic cache to improve performance and scale" and also in the "Configuring the dynamic cache provider for WebSphere eXtreme Scale" topic in the WebSphere eXtreme Scale information center, see Resources.
WebSphere Commerce Server
The WebSphere Commerce Server is an IBM e-commerce framework that is widely used in retail environments of many sizes. The WebSphere Commerce Server contains the components for the various B2B and B2C functionalities needed in a retail environment.
WebSphere Commerce Server applications use databases for their operations and to speed up the operations of the applications. The applications also use Dynamic Cache (DynaCache) APIs from IBM WebSphere Network Deployment. DynaCache APIs from IBM cache are used to construct objects. Until WebSphere Commerce V184.108.40.206, WebSphere Application Server Network Deployment only provided an implementation of DynaCache APIs known as traditional DynaCache. A traditional DynaCache implementation caches portions of the data that are used in the available heap space of the WebSphere Commerce Server Java™ virtual machines (JVMs). The JVMs also store the rest of the overflow disks that are provided as expensive Storage Access Network (SAN) volumes.
With WebSphere eXtreme Scale, there is now an alternative implementation of the DynaCache APIs that is coherent, elastic, and does not use disks. When compared to traditional DynaCache, the WebSphere eXtreme Scale DynaCache implementation has the potential to provide:
- Up to a 25% reduction in average response time
- Up to a 40% improvement in time to reach steady state after full or partial site restart or after full cache invalidation
Potential benefits of WebSphere eXtreme Scale DynaCache include:
- Consistent response time
- Fast WebSphere Commerce recovery time
- Organic cache warm-up
- Simpler administration
- Simpler tuning
WebSphere eXtreme Scale DynaCache is a coherent global cache with only one source of data that eliminates any possibility of serving stale data. The global WebSphere eXtreme Scale DynaCache also eliminates the cold cache hits on the back-end. Benchmark results with earlier versions of WebSphere eXtreme Scale DynaCache are discussed in the "Enhancing WebSphere Commerce performance with WebSphere eXtreme Scale" article.
It is important that you understand the typical cacheable entities that are involved in a WebSphere Commerce-based multi-channel e-commerce solution. This understanding allows you to create an effective caching strategy between WebSphere Commerce and WebSphere eXtreme Scale. This understanding is also important when considering how the cacheable entities are identified and their lifecycle is defined including the eviction strategy.
A typical WebSphere Commerce Server-based solution has cacheable entities that can be classified as:
- WebSphere Commerce data cache (object cache) - Includes the Java™ objects that have database data encapsulated.
- Command cache - Includes the Java objects that are executed as part of satisfying an inbound request. These typically enforce system-specific business logic or perform atomic transaction. There is some overlap between this cache type and data cache.
- HTTP response cache (JavaServer pages (JSP) or View Cache) - Includes the Java object that typically represents the http response generated corresponding to an inbound http request. This response is displayed on the web site.
Figure 1 illustrates the relative position of each of the cache categories in the overall WebSphere Commerce solution programming framework.
Figure 1. Cache categories
For a better understanding of the commerce solution components, refer to the "WebSphere Commerce common Architecture" topic in the WebSphere Commerce information center documentation, see Resources.
Figure 1 illustrates how the HTTP response cache corresponds to Java objects that are generated in the presentation layer of the solution. It also illustrates how the command cache corresponds to the Java objects generated in the business logic layer. And how the WebSphere Commerce data cache corresponds to Java object representation of the data in the persistence layer of the solution.
This cache can be stored in the default traditional DynaCache provider for the WebSphere Application Server provider or the WebSphere eXtreme Scale DynaCache provider. The traditional DynaCache provider for the WebSphere Application Server provides an in-memory cache with the ability to offload the cache to disk. There are two key drawbacks when you use this cache provider:
- Cache entities are localized to each server of the application cluster.
- Cache invalidation must be done on each server of the application cluster.
These drawbacks result in the lifecycle of the cache entity (creation, management, and eviction) being repeated for each server in the application cluster.
Both of these drawbacks are addressed when you use the WebSphere eXtreme Scale DynaCache provider in a solution. The result is only one lifecycle (creation, management, and eviction) for each cacheable entity in the overall solution. This reduces cache eviction challenges and priming of cache for the application.
Best practices for caching design and decisions
An important decision in the caching design is to determine which cache type would be the best fit for each of the eligible caching scenarios in the application.
The key points to consider when selecting an appropriate cache type for a scenario are:
- The frequency of access to a data or function by the application. Consider caching data or an application logic operation if it is accessed frequently by the application and it remains fairly constant or has limited variation for user groups over a significant period of time.
- The cost to access the data and perform the application logic operation with every transaction,
and the size of the cached entity. The use of command cache is typically more beneficial than a JSP
or View cache. Most of the operations that take a lot of system resources and time (like external
system integration, database operations, and business computations) are done in the business-logic
tier (commands). Therefore, it is effective to include command cache in the overall solution design.
In a typical implementation, full-page or fragment cache-entry (HTTP response cache) is typically
larger than the corresponding business-logic-tier command cache-entities. If you choose the
HTTP-response cache type, the full-page cache option may be preferred over the fragment cache.
NOTE: Full-page cache is preferred because aggregating many fragment caches has performance costs and implications.
- The frequency of invalidation of the cached entity by the application. A cached entity that is invalidated frequently based on user action or system changes is critically evaluated for the cache-worthiness. If the entity is cache-worthy, the traditional DynaCache provider is the best choice. This is because you must avoid the use of the WebSphere eXtreme Scale cache provider for the cacheable entities that require frequent invalidation.
- The personalization characteristic of the cached entity in the application. For personalized customer data or operations, command cache is preferred to full page cache. An example is a personalized product recommendation or marketing content recommendation that is displayed on the web site. The personalization could be based on a customer's registration state (registered or anonymous), member group affiliations, or various other parameters. To effectively implement the caching of an entity that contains personalized data, you use the user identifier or member group association that is based on the request attributes (example: a cookie) to identify the user state or the member group affiliation and use it to create a cache ID for the cached-entity. For a relatively static data or response, you can use JSP cache. A good example of this situation is the Contact Us or Help pages. These are pages where the information is not personalized or dynamic in nature.
Table 1 provides the cache types and their typical preference rank (1 highest to 4 lowest) based on our field experience.
Table 1. Cache types and preference ranking (highest to lowest)
|1||WebSphere Commerce data cache|
|3||HTTP response cache (full page cache)|
|4||HTTP response cache (fragment cache)|
The caching design and the application design must be complementary. Instead of using the data bean directly with JSPs, you can use a pattern in the Business logic tiers (commands) to create an aggregate value object or value object that is then passed to JSP or View Cache to create the response. This helps in the caching of business logic commands that are invoked frequently by the application.
WebSphere Commerce data cache (object cache) overview and implementation specifics
The WebSphere Commerce programming framework allows you to perform more caching of database query results. This additional caching code is referred to as the WebSphere Commerce data cache, and it uses the functionality that is provided by WebSphere dynamic cache service. This functionality reduces the database trips and improves the system throughput and response time and is available in WebSphere Commerce V7.0 or later.
NOTE: This programming framework is not enabled by default. You need to perform specific actions to enable it for WebSphere Commerce Server feature pack 4 and earlier.
WebSphere Commerce data cache is classified in two types that are based on tenure of cache and its usage or applicability across multiple user requests.
- Cross transaction cache (recommended) - Cache that persists across multiple transactions (corresponding to different user requests). This cache offers the most benefit due to long life of the cache and reusability across multiple transactions. Cross transaction cache is the recommended cache pattern.
- Local transaction cache - Cache that persists only until the transaction boundary associated with a specific user's request. This cache pattern is for objects that use database information multiple times during a single transaction scope.
WebSphere Commerce data cache is implemented with either of two approaches:
- Command caching - Caching approach that uses the cachespec.xml (dynamic Cache service cache configuration file) for the cache entry specification. If cachespec.xml is used for defining data cache, then cache entries, by default, go to Base Cache instance. This caching approach is usually not the best choice for the implementation of data caching.
- Distributed map caching approach (recommended) - Caching approach that configures the object-cache instances using the information that is provided in the "Using the Distributed and DistributedObjectCache interfaces for the dynamic cache" topic on the WebSphere Application Server information center, see Resources.
You define the object-cache instances in the WebSphere Application Server. You can define the object-cache instances either with the integrated administration console or with scripting. Remember that not all the object-cache instances are configured to use the WebSphere eXtreme Scale provider. However, object-cache instances that are configured to use WebSphere eXtreme Scale as the cache provider need the appropriate custom properties that are defined for the object-cache instance. For more information about data cache, refer to the "Enabling WebSphere Commerce data cache" topic in the WebSphere Commerce information center, see Resources.
Define the cache entry to object-cache-instance mapping. Defining the cache entry is done with the WebSphere Commerce configuration XML file named wc-server.xml. The data cache is configured based on the scope of the cache entry using the CrossTransactionCache or LocalTransactionCache tag within the InstanceProperties element of the WebSphere Commerce configuration file. This configuration is for long-lived cache entries. If you use the wc-server.xml file, the entries go to the dynamic maps (DMAP) that are configured in WebSphere eXtreme Scale. For the details on this configuration, refer to the "Additional WebSphere Commerce data cache configuration" topic on the WebSphere Commerce information center, see Resources.
Best practices for WebSphere Commerce data cache implementation
Configure the DMAPs to exist in WebSphere eXtreme Scale cache provider for the data cache
entities that are used frequently across multiple user transactions and not invalidated frequently.
Cached entities that are invalidated, either programmatically or using the DynaCacheInvalidationCmd,
should be configured to use the traditional DynaCache provider. It is important for you to remember
that the WebSphere Commerce data-cache components do not only fetch the entities from WebSphere
eXtreme Scale. They also cause the programmatic cache entry invalidation calls to reach WebSphere
eXtreme Scale. Frequent invalidation messages are not cheap and idempotent. They can cause an
increase in CPU utilization on WebSphere eXtreme Scale servers. For this reason, invalidation
frequency and count is an important design and implementation consideration. For example, business
context service (BCS)-related cache, that is implemented using the class
com.ibm.commerce.component.contextservice.commands.ContextDataSerValueCache CmdImpl, is
frequently invalidated based upon the user's action on the web site. So, it is recommended that you
do not offload this cache entry to WebSphere eXtreme Scale.
Table 2 provides the recommended destination for the DMAPs that are available with WebSphere Commerce data cache. This table is not a comprehensive list, but the table is accurate as of WebSphere Commerce V7.0 FEP 4.
Table 2. Recommended destination of the DMAPs
|DMAP Name||Preferred Destination||Comments|
|WCSystemDistributedMapCache||WebSphere eXtreme Scale||You determine the appropriate cache size that is based on your commerce foundational data setup,
such as the supported languages, currency, country, states, shipping, and fulfillment data.|
Initially, you keep the cache count size at 20000. You then optimize it based on the cache hit-or-miss ratio and the least recently used (LRU) evictions.
| WCSessionDistributedMapCache||Traditional DynaCache||The DMAP holds the commerce business context service (BCS) related data.|
Initially, you can keep the cache count size at 5000. You then optimize it based on the cache hit-or-miss ratio and LRU evictions.
|WCContractDistributedMapCache||WebSphere eXtreme Scale||Initially, you can keep the cache count size at 5000. You then optimize it based on the cache hit-or-miss ratio and LRU evictions.|
| WCPromotionDistributedMapCache||WebSphere eXtreme Scale||This DMAP holds the commerce promotion engine-related runtime data. The DMAP size is determined
by looking at the types of promotions that are configured, the number of promotions that are
configured, and the creation of a shopping cart by the guest on the web site.|
Initially, you can keep the cache count size at 30000. You then optimize the cache count that is based on the cache hit-or-miss ratio and LRU evictions.
| WCMarketingDistributedMapCache||WebSphere eXtreme Scale||Initially, you can keep the cache count size at 3000. You then optimize the cache count that is based on the cache hit-or-miss ratio and LRU evictions.|
| WCUserDistributedMapCache||Traditional DynaCache ||Initially, you can keep the cache count size at 3000. You then optimize the cache count that is
based on the cache hit-or-miss ration and LRU evictions.|
You can start with Traditional DynaCache. However, you must also test with WebSphere eXtreme Scale as the destination. If the invalidation cost is NOT high in WebSphere eXtreme Scale, then you can use WebSphere eXtreme Scale as the destination.
| WCCatalogGroupDistributedMapCache||WebSphere eXtreme Scale||You determine the appropriate cache size that is based on your catalog structure and setup.|
Initially, you can keep the cache count size at 20000. You then optimize the cache size that is based on the cache hit-or-miss ratio and LRU evictions.
| WCCatalogEntryDistributedMapCache||WebSphere eXtreme Scale||You determine the appropriate cache size that is based on your catalog structure and setup.|
Initially, you can keep the cache count size at 20000. You then optimize the cache size that is based on the cache hit-or-miss ratio and LRU evictions.
| WCPriceDistributedMapCache||WebSphere eXtreme Scale||You determine the appropriate cache size that is based on your price rule and offer setup.|
Initially, you can keep the cache count size at 20000. You then optimize the cache count that is based on cache hit-or-miss ratio and LRU evictions.
| WCDistributedbutedMapCache||WebSphere eXtreme Scale||Initially, you can keep the cache count size at 1000. You then optimize it based on the cache hit-or-miss ratio and LRU evictions.|
WebSphere eXtreme Scale servers
The WebSphere eXtreme Scale grid contains two types of WebSphere eXtreme Scale servers:
- Catalog server - Provides management of the entire grid.
- Container server - Contains all the cached data.
Catalog servers play an important role during grid recoveries that start or stop container servers. For example, catalog servers play this role during communication failures, hardware failures, and when clients connect to the grid for the first time. However, catalog servers do not play much of a role when already connected clients are accessing a grid in steady state.
In a typical grid, data is partitioned into a number of container servers. A WebSphere eXtreme Scale grid must be designed to avoid the loss of a subset of container servers during run time. For high availability, catalog servers are clustered. This ensures that data is not lost if the catalog service becomes unavailable and the entire grid of both the catalog and container servers must be restarted. You also need at least two catalog servers in any catalog-server cluster.
WebSphere eXtreme Scale grids can be updated with newer versions of the WebSphere eXtreme Scale software without a complete grid restart that results in data loss. For a WebSphere eXtreme Scale software upgrade, depending on the version of the WebSphere eXtreme Scale software, catalog servers are upgraded before the container servers. For ease of upgrade and general grid maintenance, catalog and container servers are hosted in separate machines. If it is not possible to have separate machines, you can have separate installations for the catalog and the container servers.
For details on WebSphere eXtreme Scale servers, refer to the "Caching architecture: Maps, containers, clients, and catalogs" topic on the WebSphere eXtreme Scale information center, see Resources.
Best practices for forming a catalog server cluster
- For high availability, a catalog-server cluster consists of at least two, preferably three,
catalog servers. Also, no two cluster members can reside in the same physical machine or LPAR. A
three-member catalog-server cluster ensures that if one catalog server machine goes down for
maintenance, there are still two active catalog servers to avoid a Single Point of Failure (SPOF).
NOTE: For efficient intracatalog server-cluster member communication, you cannot have more than four catalog servers in any catalog-server cluster.
- All the catalog-server cluster-members must belong to the same core group. This restriction is automatically enforced in catalog servers that are created in stand-alone environments. You can also configure catalog servers in large WebSphere Application Server environments to satisfy this restriction.
- All the catalog-server cluster-members are in the same subnet. This provides reliable intracatalog server communication that simplifies grid administration and configuration by preventing a potential grid condition called islanding. Islanding occurs when the WebSphere eXtreme Scale grid is partitioned into multiple independent grids.
WebSphere eXtreme Scale DynaCache topologies
The WebSphere eXtreme Scale DynaCache client is embedded in the WebSphere Application Server JVMs. You install the WebSphere eXtreme Scale client on the WebSphere Application Server installations on all the machines. The client (and the complete WebSphere eXtreme Scale server) installation contains the DynaCache plug-in code that is used by the WebSphere Commerce Server code to interact with the WebSphere eXtreme Scale DynaCache grid.
The WebSphere eXtreme Scale server code provides the implementation of DynaCache grid. The WebSphere eXtreme Scale DynaCache grid is typically configured in one of two topologies:
- Embedded partitioned - Where cached data is partitioned in the WebSphere Commerce Server JVM. Embedded partitioning provides coherent caching service. However, it is of limited value in WebSphere Commerce Server environments.
- Remote partitioned - Where WebSphere eXtreme Scale DynaCache is on a separate tier and not on the WebSphere Commerce Server JVMs. Remote partitioning provides a coherent cache with excellent isolation from client. This is the most widely used topology for WebSphere eXtreme Scale DynaCache in WebSphere Commerce Server environments.
The remote WebSphere eXtreme Scale DynaCache grid can be hosted on stand-alone JVMs or on WebSphere Application Servers. Both are viable deployment topologies and are used successfully in large production environments.
WebSphere eXtreme Scale DynaCache in WebSphere Application Server
WebSphere eXtreme Scale is tightly integrated with the WebSphere Application Server. The hosting of the WebSphere eXtreme Scale server on the WebSphere Application Server JVMs allows the use of the built-in features of the WebSphere Application Server to monitor, administer, test, and debug WebSphere eXtreme Scale. For example, the Performance Monitoring Infrastructure (PMI) of the WebSphere Application Server, the admin console, the logging, and the tracing facility can be used in WebSphere eXtreme Scale servers that are hosted in WebSphere Application Server Network Deployment environments. The WebSphere eXtreme Scale grids that are hosted in WebSphere Application Server Network Deployment environments can also be stopped without bringing down the corresponding WebSphere Application Server JVMs. It is also convenient to host and administer multiple WebSphere eXtreme Scale grids on the same WebSphere Application Server cluster.
WebSphere Application Server Network Deployment run time uses memory of about 100 MB in 32-bit architectures and 200 MB in 64-bit architectures for its operation. WebSphere eXtreme Scale container servers that are hosted on a WebSphere Application Server have memory available for caching data. However, the WebSphere eXtreme Scale containers of similar heap size on stand-alone JVMs do not. If you have many WebSphere eXtreme Scale servers in the DynaCache grid, you must explicitly administer core groups when these WebSphere eXtreme Scale servers are hosted on the WebSphere Application Server environments. For more information on WebSphere eXtreme Scale, refer to the "Super cluster to the rescue, Part 2: Maximum scalability using WebSphere DMZ Secure Proxy Server, ORD, and WebSphere eXtreme Scale" article. The use of the WebSphere Application Server to host WebSphere eXtreme Scale grid also involves more licensing costs. However, if you are familiar with the administration of the WebSphere Application Server, you can host the WebSphere eXtreme Scale server on your existing middleware to reduce your learning curve and increase productivity.
DynaCache in stand-alone JVMs
Because there is no WebSphere Application Server run time in stand-alone JVMs, there is more
memory available for caching objects than there is in WebSphere Application Server JVMs of identical
heap size. However, there is not a significant difference in speed when performing cache operations
between stand-alone or WebSphere Application Server environments to host a WebSphere eXtreme Scale
DynaCache grid. The DynaCache grid can be administered with the WebSphere eXtreme Scale
xscmd command-line tools, see Resources.
To start DynaCache grids, you can use simple shell scripts. In stand-alone environments, even for large grids with many container servers, you do not have to worry about core-group configuration. WebSphere eXtreme Scale software automatically creates core groups of appropriate sizes. In stand-alone environments, you also do not have WebSphere Application Server licensing costs.
Best practices for WebSphere eXtreme Scale DynaCache grid topology
The remote topology is the recommended topology. In this topology, the WebSphere Commerce application uses the WebSphere eXtreme Scale DynaCache client to access the remote cache. To host the WebSphere eXtreme Scale DynaCache in the WebSphere Application Server environments, you must:
- Pay for the extra licensing cost of WebSphere application server network deployment.
- Have the memory that is needed for WebSphere application server run time.
- Be familiar with the administration of the WebSphere application server network deployment.
If you do not want to host the WebSphere eXtreme Scale DynaCache in the WebSphere Application Server environments, then consider hosting the WebSphere eXtreme Scale DynaCache grid on stand-alone JVMs. The use of stand-alone JVMs as WebSphere eXtreme Scale servers is more popular in WebSphere Commerce Server environments. This series focuses on the remote WebSphere eXtreme Scale DynaCache topology hosted on stand-alone JVMs and all the relevant tips and techniques. The series also points out the strategic differences that are involved if you choose to deploy the WebSphere eXtreme Scale DynaCache grid in an WebSphere Application Server network deployment.
This three-part series focuses on WebSphere Commerce environments. However, most of the techniques are also applicable to general WebSphere eXtreme Scale DynaCache usage in any pure WebSphere Application Server network deployment or in WebSphere portal server environments. You can apply the tips and techniques in this series in your WebSphere Commerce implementation of the WebSphere eXtreme Scale DynaCache environment.
WebSphere eXtreme Scale is a rapidly evolving technology. There is an increasing investment in consumability, performance, monitoring capability, and domain of applicability of WebSphere eXtreme Scale and WebSphere eXtreme Scale DynaCache. As additional tips and techniques emerge and more utilities for monitoring are developed, the authors will provide updates to the WebSphere eXtreme Scale DynaCache series.
The authors are grateful to the following people for technical discussions regarding their work with WebSphere Commerce and WebSphere eXtreme Scale: Kyle Brown, IBM DE, ISSW; Brian Martin, STSM, WebSphere eXtreme Scale and XC10 Lead Architect; Douglas Berg, WebSphere eXtreme Scale Architect; Chris Johnson, WebSphere eXtreme Scale Architect; Jared Anderson, WebSphere eXtreme Scale Architect; Rohit Kelapure, WebSphere Application Server Development; Joseph Mayo, XC10 Development; Surya Duggirala, WebSphere Application Server Performance Lead; Matt Kilner, JDK L3; Brian Thomson, STSM, WebSphere Commerce Server CTO; Misha Genkin, WebSphere Commerce Server Performance Architect; Robert Dunn, WebSphere Commerce Server Development; Kevin Yu,ISS-IS. The authors would also like to acknowledge Mary A. Brooks for her superb copy editing. And a very special thanks to Cheenar Banerjee for her assistance in proofreading and suggesting several readability improvements.
- "Enhancing WebSphere Commerce performance with WebSphere eXtreme Scale" (developerWorks, Dec 2010).
- "Configure WebSphere Commerce to use WebSphere eXtreme Scale for dynamic cache to improve performance and scale" (IBM WebSphere eXtreme Scale and DataPower XC10 Appliance WIKI, Mar 2011).
- "Super cluster to the rescue, Part 2: Maximum scalability using WebSphere DMZ Secure Proxy Server, ORD, and WebSphere eXtreme Scale" (developerWorks, Jul 2009).
- Read about "WebSphere eXtreme Scale" in the WebSphere eXtreme Scale information center documentation.
- Read more about "Configuring the dynamic cache provider for WebSphere eXtreme Scale" in the WebSphere eXtreme Scale information center documentation.
- Read more about "Caching architecture: Maps, containers, clients, and catalogs" in the WebSphere eXtreme Scale information center documentation.
- Read more about "Sample:
xsadminutility" in the WebSphere eXtreme Scale information center documentation.
- Read more about "Administering the
xscmdutility" in the WebSphere eXtreme Scale information center documentation.
- Read more about "Dynamic cache capacity planning" in the WebSphere eXtreme Scale information center documentation.
- Read about "WebSphere Commerce" in the WebSphere Commerce information center documentation.
- Read more about "WebSphere Commerce common architecture" in the WebSphere Commerce information center documentation.
- Read more about "Enabling WebSphere Commerce data cache" in the WebSphere Commerce information center documentation.
- Read more about "Additional WebSphere Commerce data cache configuration" in the WebSphere Commerce information center documentation.
- Read about "WebSphere Application Server" in the WebSphere Application Server information center documentation.
- Read more about "Using the Distributed and DistributedObjectCache interfaces for the dynamic cache" in the WebSphere Application Server information center documentation.
- In the developerWorks Commerce area, get the resources that you need to advance your knowledge of Commerce products.
- Stay current with developerWorks technical events and webcasts that are focused on various IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools as well as IT industry trends.
- Follow developerWorks Commerce communities.
- Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
Get products and technologies
- Download IBM Extended Cache Monitor.
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
- Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.