Understanding > WebSphere Commerce and service-oriented architecture (SOA) > WebSphere Commerce Web services > WebSphere Commerce BOD command framework

Commerce Feature Pack

Service module configuration

Configuration data for BOD service modules is organized into base, and custom configuration. Configuration files are loaded before the service module can process service requests. The configuration class loader automatically discovers the configuration directories, by following certain naming conventions.

Base (or bootstrap) configuration enables basic service module functionality. It contains the configuration data provided with the WebSphere Commerce service modules. You can also create custom configuration to add new functionality or customize existing functions. To change or extend this configuration, place you configuration in the WCDE_installdir\xml\config\servicemodulename-ext\ directory with the configuration files named as the same as those you want to change or extend.

Whether the configuration overwrites the default configuration or extends it depends on the function that uses that configuration.

Configuration file loading

When resolving configuration, custom configuration always takes precedence over base configuration. Depending on the load policy (extend versus override), the base configuration is either parsed or skipped. The load policy is specified in the parser class implementation. You can check whether the policy is overridable by calling the isOverridable() method.

For more complex configuration data structures, that cannot be represented as name-value pairs (for example, heavily structured, nested data), you can provide your own configuration file and configuration parser. This requires more work from the developer, but is completely flexible - any kind of configuration file can be read, parsed, and retrieved in your service module Java code. If you are writing your own configuration parser, must extend from the AbstractConfigurationImpl abstract class.

Extend Policy

When the extend policy is used, the configuration information for both bootstrap and custom configuration is loaded and returned to the caller as a list of configuration objects. In the list, custom configuration precedes bootstrap configuration. The caller must traverse the list and pick the configuration.

Override Policy

If the override policy is used, the loading process only loads the custom configuration. The bootstrap configuration is ignored. Thus, any metadata placed in custom configuration files will completely override the metadata from the base.

During development, you may want to modify and reload configuration, without having to restart the server. To enable volatile reloading for all service modules, create an empty .reloadconfig file in xml/config/com.ibm.commerce.foundation/. This will cause every service module to check the timestamps on its configuration files, each time it is called. Configuration files that have changed from the time that they were last loaded will get re-parsed. Also, if a configuration file was added or removed, all files in the same directory are reloaded. To enable volatile reloading for a particular service module, create an empty .reloadconfig file under the service module configuration directory . For example, xml/config/com.myco.myservicemodule. Volatile reloading will only be enabled for that service module.

Naming conventions

The configuration loader uses directory names to discover a service module's bootstrap and custom configurations.

Bootstrap configuration

xml/config/servicemodulename/

Custom configuration

xml/config/servicemodulename-ext/
In both cases above, servicemodulename represents the name of your service module or the WebSphere Commerce service module you are configuring.

Configuration filenames follow a strict naming convention – these names are used by the configuration loader.

Every service module contains the following files:

wc-component.xml

Contains the development configuration of a component. It can occur in both the base and custom configuration directories.

wc-admin-component.xml

Contains the administration configuration of a component. It can occur in both the base and custom configuration directories.

wc-application.xml

Contains the development configuration information applicable to all components within an application. This file will only exist under the foundation component directory.

wc-admin-application.xml

Contains the administration configuration information applicable to all components within an application. This file will only exist under the foundation component directory.

SDO.properties

Used for loading the initialized logical SDO classes. Specifies a class that declares the logical SDO classes that need to be initialized. For example, the SDO.properties file for the Member component contains: com.ibm.commerce.member.facade.datatypes.impl.MemberPackageImpl.

wc-component-client.xml

Specifies the bindings from URL to Web services. For example, the component-client.xml for the Member service module is shown in the following XML sample: 
<_config:DevelopmentClientConfiguration xmlns:_config="http://www.ibm.com/xmlns/prod/commerce/foundation/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/config ../xsd/wc-component-client.xsd">
  <_config:invocationservice>
    <_config:invocationbinding bindingImpl="com.ibm.commerce.foundation.internal.client.services.invocation.impl.J2SEWebServiceInvocationBindingImpl">
      <_config:property name="url" value="http://hostname:8007/webapp/wcs/component/member/services/MemberServices"/>
    </_config:invocationbinding>  
  </_config:invocationservice>  
</_config:DevelopmentClientConfiguration>

wc-business-object-mediator.xml

Contains configuration information for the Business Object Mediator.

wc-object-relational-metadata.xml

Contains Object-relational metadata.

The configuration files are guided by an XSD (XML Schema Definition). The XSD provides documentation describing the purpose of each configuration file. The XSD is located in the xml/config/xsd directory. By observing the XML file in an editor, use the XSD to determine the respective supported elements, as well as the annotation about the configuration.

Configuration files

The following configuration files are typically used for BOD-based services:

The following configuration files are typically used for SOI-based services:

Related concepts

WebSphere Commerce BOD command framework

Access control in the BOD command framework

Data service layer

Related tasks

Work with WebSphere Commerce service modules

Implementing the service commands in the BOD command framework

Implementing access control in the BOD command framework

Add a custom user or error message to a BOD service module

Deploying the client library

Last updated: 25 November 2009