The WebSphere Commerce service module contains
all the assets used by a WebSphere Commerce service. If you are planning
on providing new WebSphere Commerce services, you must create a new
service module, then further customize and extend the assets it creates.
About this task
The Java Emitter Template (JET) is used to generate the
base code for the new service module from a simple XML file. By describing
the service module in a specialized XML syntax, the service modules
can be generated. This allows you to start directly with the service
module implementation without having to spends hours with the setup
and configuration of a service module.
What to do before creating a new service
- Determine if a new service is needed or an existing service can
be extended. When custom information is required, there are three
options:
- Include custom information in the UserData area of an existing
noun
- Include custom information as an overlay of an existing noun
- Create a custom service
- Determine the service name. A service consists of a collection
of related nouns and the operations that can be performed on those
nouns. For example, the Catalog service consists of the Catalog,
CatalogGroup, and CatalogEntry nouns and supports retrieving, creating,
updating, and deleting these nouns.
- Determine the service nouns. See Nouns for
information describing nouns.
- Determine the operations (verbs) for each noun. See Verbs for
information describing the verbs we support.
- Determine the service implementation (SOI vs BOD). See SOI and BOD service modules for
information describing the differences between the two implementations.
Procedure
To create a new WebSphere Commerce
service module:
- Start
WebSphere Commerce Developer.
- Create the pattern application definition file to create
the base code:
- Create the service module input file.
- Right-click on the WebSphereCommerceServerExtensionsLogic project
and select and
click Next.

- Click Next.
- Select Create XML file from an XML schema file and
click Next.

- Select Select file from Workspace, select and click Next.

- Click Finish.
- Create the XML file to describe the WebSphere Commerce
service module, starting by pasting the following XML sample (these
are not the final values):
<_pattern:commerceComponent xmlns:_pattern="http://www.ibm.com/xmlns/prod/commerce/foundation/pattern"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/pattern
../../WC/xml/config/xsd/wc-component-patten.xsd "
name="MyServiceModuleName" packagenameprefix="com.mycompany.commerce" company="MyCompany"
namespace="http://www.mycompany.com/xmlns/prod/commerce/9/MyServiceModuleName" nlsprefix="myco" type="SOI/BOD">
<_pattern:noun name="MyBusinessObject" get="true" process="true" change="true" sync="false" />
</_pattern:commerceComponent>
Where My Company is your company name.
This file
is used to create the starter assets and configuration required to
create a service module. Within this file, the subsystem and company
information is required. Also required is each noun that is to be
included with the subsystem and the supported verbs for that noun.
Currently WebSphere Commerce supports only four verbs and the pattern
addresses only these four verbs.
- Replace the following values under commerceComponent
with values appropriate for your implementation:
- name=" MyServiceModule"
- The name of your new service module
- packagenameprefix="com. mycompany.commerce"
- Used to prefix the generated starter store code
Note: Do not include
the component name in this prefix. That is, this prefix should only
represent the prefix for your organization.
- namespace=http://www.mycompany.com/xmlns/prod/commerce/myservicemodule
- The namespace to associate with your component. This namespace
should represent your organization.
- nlsprefix="mycompany"
- The xml schema prefix to associate with the name space. To avoid
collision with the WebSphere Commerce prefix, avoid using an underscore
(_) as the first character of the namespace prefix.
- type="SOI/BOD"
- Specify the type of service module. If you specify SOI, the pattern
will create a service module that provides service-oriented integration
into your existing controller commands, access beans, and EJBs.
If
you specify BOD, the pattern will create a service-oriented architecture
service module that will use commands developed using the BOD command
framework. These BOD commands will act upon Structured Data Objects
(SDOs) and use the Business Object Mediator to persist and retrieve
these SDOs.
- Replace the following values under noun:
- name=" MyBusinessObject" where MyBusinessObject is
the name of your new noun.
Nouns define the name of
each data element in the logical model, and assign that name to a
data type. The data type can be a primitive XML schema type such as
boolean, or a complex type. A complex type is a construct of data
elements such as CurrencyType which contains price (represented by
a double type) and currency (represented as a string). A noun can
contain one or more noun parts (sometimes referred to as noun elements).
A Noun part is a complex XML type within a noun that can be acted
upon independently. Noun parts represent parts of a logical noun.
Separating a noun into parts simplifies coding by reducing the scope
of commands and mediators. Instead of handling the entire noun, code
is limited to only processing the noun part. When a request arrives,
it is broken into its different parts and the appropriate command
for each part is run. For example, the CatalogEntry noun contains
a list of descriptions. A catalogEntry description is considered a
noun part and is processed using the ChangeCatalogEntryDescriptionCmdImpl
and ChangeCatalogEntryDescriptionMediator.
For each of the verbs,
Get
Request / Show Response,
Process
Request / Acknowledge Response,
Change
Request / Respond Response, and
Sync
Request / ConfirmBOD Response, indicate whether you want to
support this operation against your noun. For example:
- get="true"
- process="true"
- change="true"
- sync = "false"
Note: You can create multiple <noun>
elements in one service module, although in this example we just create
one. Do not choose Get, Process, Change, or Sync as the name of your
noun (they are reserved for use as verbs).
- Save the file (Ctrl S).
- Right-click MyServiceModule.xml and
select .
- In the Transformation section:
- Select the following ID:
- com.ibm.commerce.toolkit.internal.pattern.componentprojects
- Click OK.
- After the pattern is applied, verify that the following
projects are created:
- MyServiceModule-Client
- Contains the client library Java code.
- MyServiceModule-DataObjects
- Contains the XSD, WSDL and generated SDOs.
- MyServiceModule-Server
- Contains the component facade implementation.
- MyServiceModule-UnitTests
- Contains a project designed for unit testing the client implementation.
- MyServiceModuleServicesHTTPInterface
- The Web module used to enable the service module for Web services
over HTTP.
- MyServiceModuleServicesJMSInterface
- The EJB module used to enable the service module for Web services
over JMS.
- Add
the generated modules to the Websphere Commerce Application.
- Next steps:
- Create your SDO genmodel
file.
Note: In this page, complete upto step
3.g. Do not do step 3.h and step
3.i, these steps are redundant and are carried out later
in the next page.
- Generate code from your
SDO genmodel file.
- Create the component
facade for an SOI service module.
- Implementing the service commands in the BOD command framework
- Create the
client library.