WebSphere Commerce store archive separation
By default all assets for a WebSphere Commerce site is packaged and deployed within a single application, the WebSphere Commerce EAR. After feature pack enablement WebSphere Commerce search assets are moved by default into a separate Search_instance_name.ear EAR file. Your site administrators and developers can also choose to separate store assets into a separate store EAR.
The following diagram shows the default process for developers to build and deploy assets into the production environment. In this process, when your site has multiple development teams that are simultaneously customizing WebSphere Commerce, the teams must schedule asset deployment to prevent errors or conflicts during the build process.

If asset deployment is not coordinated, errors and conflicts can occur during the build and deployment process when both teams are updating the WebSphere Commerce EAR simultaneously. By separating the store WAR, development teams that customize storefront assets can package and deploy store assets independently from teams that are customizing and deploying non-storefront assets. By deploying store assets into a separate EAR, the build and deployment process does not conflict with the deployment of non-storefront assets into the WebSphere Commerce EAR. The following diagram shows the process for developers to build and deploy assets after the store WAR is separated into a new store EAR.

In this build and deployment process, storefront and server-side development teams can create or update assets independently of the other team. The teams can build and deploy packages of assets from the development environment into a run time environment with a separated store archive. In this run time environment, storefront developers deploy the package of storefront assets into the store EAR. Developers deploy the package of server-side assets into the WebSphere Commerce EAR. Any assets that are deployed into the WebSphere Commerce EAR that must be referenced by logic or assets in the store EAR are referenced using a shared library.
When the store WAR is separated into a new store EAR, two shared libraries are configured to link the store EAR and WebSphere Commerce EAR. One shared library is intended for assets and logic that is provided by default with WebSphere Commerce. The second shared library is intended for your custom assets and logic. With these shard libraries, your store developers can separate the custom logic for your site from the logic that is provided by WebSphere Commerce.
If your site includes both a staging and production run time environment as shown in the preceding diagram, assets that are deployed to the staging environment must be published to the production environment. Administrators can use WebSphere Commerce utilities to propagate the new or changed assets from the separated EAR files to the corresponding locations in the production environment.
When the store WAR is separated into a new store EAR, the store EAR and WebSphere Commerce EAR still run as part of the same WebSphere Application Server process. The two EARS, while independent, run within the same Java virtual machine (JVM). Since the two EAR files operate within the same JVM, the store EAR can access classes and assets within the WebSphere Commerce EAR through shared libraries and a configured server level extension class loader. Each EAR however operates independently and all method invocations are still local calls without the use of remote calls. Any dependencies between custom store assets and default-provided assets remain.
Store separation enablement
To enable store separation, an administrator must use the WebSphere Commerce feature enablement framework to update your WebSphere Commerce instance to support store archive separation. The store WAR separation can be completed after feature pack enablement by running a script to enable the store separation. The store separation script exports a copy of the store WAR from the WebSphere Commerce EAR. The separation process then moves the copied WAR and store assets for all stores within the WebSphere Commerce instance into the new store EAR. The separation process disables the original store WAR that is within the WebSphere Commerce EAR. The new store WAR within the store EAR uses the same context root that was used before the store separation. For more information about completing the task to separate the store WAR into a new store EAR, see Separating the store WAR from the WebSphere Commerce EAR.
The WebSphere Commerce Build and Deployment tool is updated to provide developers the option to deploy packaged assets into the WebSphere Commerce EAR, WebSphere Commerce search EAR, or a separated store EAR.
When the store archive is separated into a new store EAR, the two new shared libraries are configured along with a new server level extension class loader.
Shared libraries
A shared library is a configuration that points to a group of JAR files that can be accessed by a JVM. These shared libraries serve as a link between the applications. The store EAR application can use the shared libraries to access and use assets within the WebSphere Commerce application. Each shared library is associated with an extension class loader that loads the shared library so that other libraries or applications can reference the contents within the library. For more information about shared libraries, see Shared libraries.
- Shared library for assets that are provided by WebSphere Commerce
This library is used for all of the JAR files and resources from the WebSphere Commerce EAR that a store can use. By default, the separation process identifies the assets and logic that are used by default-provided resources for a store and points to these assets with the shared library. For instance, the separation process configures the shared library to point to all Java archive (JAR) files that were in the WebSphere Commerce EAR.
- Shared library for custom logic
This shared library does not need to point to any files by default. When your store developers complete customization of store assets, the developers must then update the shared library to point to any custom logic that must be included within the WebSphere Commerce EAR and used by the store EAR.
Class loaders
Class loaders are part of the JVM code and are responsible for finding and loading class files. A class loader can enable an EAR application to access the repositories of available classes and resources for WebSphere Commerce.
A server level extension class loader is associated with the new shared libraries that the separation process creates. Associating shared libraries with a class loader for an application server makes the shared library available to all applications on that server. By using this extension class loader, the new store EAR can make local function calls to use assets within the WebSphere Commerce EAR through a shared library. An extension class loader must be configured for use on each server that your site uses. The class loader configuration cannot be shared within a cluster or cell level. By default, the separation process creates an extension class loader for use on each server. The separation process creates an extension class loader to associate with each of the two new shared libraries. For more information about class loaders, see Understanding Class Loaders.
Benefits and capabilities
By separating the store WAR into a new store EAR, your store and site developers can gain some of the following benefits and capabilities.Considerations
What to do after store separation
After your store administrators enable the store separation, your store developers must deploy any custom assets for your site into the appropriate new location. When your store developers create or change assets, they can package and deploy the assets with the WebSphere Commerce Build and Deployment tool. Administrators can then publish the changed files to the production environment store EAR with existing WebSphere Commerce utilities. For more information, see Deploying new and changed store assets into a separated store EAR.
To ensure that your site and store operate correctly, ensure that site administrators and developers update any store functions and processes that use store assets to reference the new location for the assets in the store EAR or shared libraries.