Web services and WebSphere Commerce

A web service is an interface that describes a collection of operations that are accessible through the network by using standardized XML messaging.

A web service is described by using a standard, formal XML notation, called a service description, where:

The service description includes all the details necessary to interact with the service, including its message formats (that detail the operations), transport protocols, and location.
The interface hides the implementation details of the service, allowing it to be used independently of the hardware or software platform on which it is implemented. The interface can also be used independently of the programming language in which it is written.
The foundations for web services are standards such as Simple Object Access Protocol (SOAP), the Web Services Description Language (WSDL), and the Universal Description, Discovery, and Integration (UDDI) registry.

Web services are self-contained, self-describing, modular web applications that can be published, located, and invoked across the web. Web services perform functions that can be invoked, ranging from a simple request to complicated business operations. If a web service is deployed and registered, other applications can discover and invoke it.

Web services allow applications to be integrated more rapidly, easily, and less expensively than ever before. Integration focuses on the XML messages that define the services rather than the protocol used to relay these messages. These characteristics are ideal for connecting business functions across the web, both between multiple enterprises and within a single enterprise. They provide a unifying programming model, so that application integration, both inside and outside the enterprise, can be done with a common approach, by using a common infrastructure. The integration and application of web services can be done in an incremental manner, by using existing languages and platforms and by adopting existing applications.

Topic overview

This topic contains several sections of interest that are related to web services and WebSphere Commerce.

The following list helps summarize the key areas of interest:

Web services in WebSphere Commerce
WebSphere Commerce services functional architecture
IBM and service-oriented architecture (SOA)
SOA adoption and service-oriented integration (SOI) in WebSphere Commerce
Data service layer (DSL)
Advantages of implementing SOA and using DSL in WebSphere Commerce
Web services entry points in the Information Center
Additional information about Web services

Web services in WebSphere Commerce

WebSphere Commerce is designed to support web services, both as a provider of web services, and as a consumer (client) to other web services.

For example, external web service clients can connect to WebSphere Commerce and use the web services that are provided, as illustrated in the following diagram:
Diagram summarizing the high-level flow that is associated with WebSphere Commerce as a service provider: Web service clients send SOAP requests to and receive SOAP responses from WebSphere Commerce.

Diagram summarizing the high-level flow that is associated with WebSphere Commerce as a service provider: Web service clients send SOAP requests to and receive SOAP responses from WebSphere Commerce.

Alternatively, WebSphere Commerce can connect to other web service providers and request information, as illustrated in the following diagram:
Diagram summarizing the high-level flow that is associated with WebSphere Commerce as a service consumer: WebSphere Commerce sends SOAP requests to and receives SOAP responses from web service providers.

Diagram summarizing the high-level flow that is associated with WebSphere Commerce as a service consumer: WebSphere Commerce sends SOAP requests to and receives SOAP responses from web service providers.

WebSphere Commerce uses web services to expose its data and business logic to applications that run outside the server, for example a Distributed Order Management (DOM) system. In addition, WebSphere Commerce components interact with each other using these services.

WebSphere Commerce services are designed for applications that access or update small amounts of information at a time. For example, the Management Center. Conversely, the services are not designed to load large amounts of data. The Data Load utility is used to perform this task.

Typical web service architecture

The web service architecture describes three roles: service provider, service consumer, and service broker; and three basic operations: publish, find, and bind. A network component can play any or all of these roles. The service providers publish web services to a service broker. Service consumers find required web services by using a service broker and bind to them.

Diagram summarizing the web service architecture roles and operations that are detailed in this section.

In a typical scenario, a service provider hosts a network-accessible service module, which is an implementation of a web service. The service provider defines a service description for the web service and publishes it to a service consumer or a service registry. The service consumer uses a find operation to retrieve the service description locally or from the service registry hosted by the service broker. The service consumer uses the service description to bind with the service provider and invoke or interact with the web service implementation.

This solution provides runtime support to enable business operations that are defined by WebSphere Commerce as web services.

WebSphere Commerce services functional architecture

The starting point of a WebSphere Commerce service is the definition of the high-level business object that is called the noun. Based on the noun, services are defined based on supported verbs that can act upon that noun. These combinations of verb and noun form the Open Applications Group Integration Specification (OAGIS) messages that represent a WebSphere Commerce service request and the corresponding response. OAGIS provides a consistent message structure and model for messaging by using XML. The functional architecture is structured around the transmission of these OAGIS messages from the client (for example, a portlet in a WebSphere Commerce Portal server) to the WebSphere Commerce Server, and back again.

The following diagram shows how a client such as a portlet can use WebSphere Commerce business logic:

The client (for example, a portlet in a WebSphere Portal Server) uses the client library to create an OAGIS message.
The service binding routes the request.
The service binding handles the serialization and deserialization of the OAGIS message and sends the request to the component facade.
The component facade calls the appropriate WebSphere Commerce commands.
The component facade forms the response.
The service binding routes the response back to the client library.
The client library returns the response message to the client.

How a client such as a portlet can use WebSphere Commerce business logic

Component facade

A component facade is used to group a set of related business services, such as catalog or order. Component facades are implemented as Java interfaces and their business services are implemented as methods on these interfaces. Each method in a component facade represents the request business object document (input argument to the method) and the corresponding response business object document (result of the method). The method name is the request verb name plus the noun name. For example, a member component facade might implement the Get verb on the Person noun, which results in a getPerson() method on the facade.

The component facade accepts OAGIS messages that contain a combination of verb and noun. It then calls WebSphere Commerce commands to provide the business logic that is associated with different services. WebSphere Commerce component facades accept four types of service requests:

A verb can perform many business tasks. Business tasks correspond to activities, such as a customer who adds a business profile or updates an address. Business tasks usually correspond to controller commands in WebSphere Commerce. To distinguish which business task should be performed when a verb is called on a noun, a parameter that is known as an action is passed in the call to the verb. The possible combinations of verbs and the many actions that are associated with them result in many predefined services. WebSphere Commerce services leverage the existing WebSphere Application Server command framework. All business logic is represented as commands.

Service binding

The service binding resides between the client library and the services. Its responsibility is to provide the transport mechanism to pass data, by using service data objects, between the client and the service. This transport mechanism can be web services or local Java binding.

The service binding can be leveraged with or without the client library.

HTML requests use the Struts framework, which calls the client library. The requests are received as name-value pairs and are converted into the appropriate OAGIS messages.
JSP requests use the WebSphere Commerce foundation tag library, which calls the client library.
SOAP requests already receive XML documents, and in these cases there is no need to use the client library.

By leveraging the service binding, these assets can also be used outside of the WebSphere Commerce application and they still call the component facade.

Client library

The client library provides Java-friendly libraries that build the service requests that the WebSphere Commerce service accepts. Clients of a WebSphere Commerce service are advised (but not required) to use the client library to build the service request. The client library hides all the complexity of web services requests, reducing the cost of development and maintenance of the client. Client libraries provide a mechanism for the client to easily switch between web services and local Java calls depending on the deployment without needing to change the client code.

Clients use this library to build service requests from a Java application, WebSphere Portal Server, or any other web-enabled application. This client composes request Java objects and initiates the service communication.

IBM and service-oriented architecture (SOA)

IBM describes service-oriented architecture as a process, lifecycle, and a set of tools to enable agile business transformation. It is this particular practice of deriving the IT implementation of the system from the business requirements that is known as IBM SOA. In the industry, there are many instances where one might find that SOA is equated with web services. The IBM perspective on SOA is not solely about technology; hence, there is no SOA platform that one deploys their solution on. Instead, IBM SOA defines an architecture that aligns the business world with the world of IT in a way that makes both more effective. Changes in one can quickly be reflected in the other, allowing for agile business transformation.

In IBM SOA, there is a lifecycle that is defined which flows from gathering the business requirements to maintaining the system. This lifecycle guides one in building an SOA architecture. The lifecycle begins with the business analyst producing a business design that captures the business processes of the organization. The business analyst then works with the IT architect to model the appropriate artifacts. These models are then transformed in to IT assets that are then assembled. The assets are then deployed, and then the day-to-day operations are monitored and managed. This simple flow is what is known as the IBM SOA lifecycle of Model, Assemble, Deploy, and Manage. Tools are provided to aid in activities that are performed at the stage of the lifecycle; these tools are known as the IBM SOA Foundation tools.

A key concept in SOA is that of Services. Services are repeatable tasks that are found within business processes. Service-orientation is a way of integrating your business as a set of linked services. A service-oriented architecture, then, uses the principles of service-orientation to achieve a tighter relationship between the business and the information systems that support the business.

Implementing IBM SOA can help your company realize the following benefits:

Greater alignment of business and IT.
Loosely coupled components and systems.
A network-based infrastructure, enabling geographically and technologically, diverse resources to work together.
Greater code reuse.
Better process standardization throughout the enterprise.

See IBM's SOA Foundation - An Architectural Introduction and Overview for exhaustive coverage of IBM's SOA architecture and vision.

One of the diagrams you repeatedly see referenced from the IBM's SOA Foundation white paper is the following diagram, which shows services that are communicating through the enterprise service bus (ESB):

services that are communicating through the enterprise service bus (ESB)

SOA adoption and service-oriented integration (SOI) in WebSphere Commerce

IBM describes four phases for SOA adoption, as described in the following table:


Phase	Name	Description
1	Implementing individual web services	Creating services from tasks that are contained in new or existing applications
2	Service-oriented integration of business functions	Integrating services across multiple applications inside and outside the enterprise for a business objective
3	Enterprise-wide IT transformation	An architected implementation that enables integration across business functions throughout an enterprise
4	On Demand Business Transformation	Broad transformation of existing business models or the deployment of new business models

WebSphere Commerce Enhancements address phase 2 adoption, which is known as service-oriented integration (SOI). Unlike phase 1 where a set of services are provided in a more ad hoc basis to enable applications to communicate, phase 2 is more focused on enabling scenarios. Hence, while an adoption at phase 1 can enable an external system to update the inventory in your application via the exposure of an UpdateInventory service or get the price by using a PriceCheck service, phase 2 would expose a related set of inventory services on your application. This set of services enables your application to delegate inventory responsibilities to an external system.

Inter-connectivity between services

As part of service-oriented integration of business functions, WebSphere Commerce enabled service-oriented integration (SOI) scenarios that are focused on back-office integration. WebSphere Commerce is defining connections from its Business Application Services to Access Services (these services are defined further in IBM's SOA Foundation - An Architectural Introduction and Overview). The two scenarios of focus are with external order management systems (OMS) and with enterprise resource planning systems (ERP).

This stage of SOA adoption allows you to:

Incorporate WebSphere Commerce into an overall SOA Enterprise Architecture as both a producer and consumer of business services.
Integrate with legacy systems and third-party vendors by using a service-oriented integration model.
Dynamically adapt WebSphere Commerce processes and services to fit their business.

WebSphere Commerce web services transition to SOA

As part of the WebSphere Commerce transition to SOA, there is an effort to de-couple components to allow reuse of WebSphere Commerce business services in other environments besides the WebSphere Commerce application. In order to support this de-coupling, the core infrastructure is the first piece that must run independently so it can be leveraged in other environments as well. The request handling changes to create a consistent runtime environment that new and existing components can use. This consistent run time focuses on the processing of business object documents (BODs). This architecture paves the road to SOA adoption by standardizing on how clients talk with SOA components.

WebSphere Commerce provides 4 SOI service modules that have logical groupings of business objects that are grouped to standardize communication. These service modules are Member, Order, Catalog, and Contract.

Note: Extending BOD services with Overlays is not supported. Instead, you must extend an SOI service with Overlays. For more information, see Tutorial: Extending an SOI service with Overlays.

WebSphere Commerce Portal integration

Interaction services

WebSphere Portal integration provides the interaction services in the diagram above. These interaction services provide the presentation layer to support the business services that communicate over the ESB. Portals allow for aggregation and interaction of different services that are provided by different systems, and enable sharing contextual information across different services, for example, authentication information. For example, by using WebSphere Commerce Portal integration, you can provide a presentation for business application services provided by WebSphere Commerce and other service providers, and enable interactions between these service providers.

Business object document (BOD) command framework

In the current WebSphere Commerce services architecture, the following different layers of the application are used: the presentation layer, the business logic layer, the persistence layer, and the data service layer. WebSphere Commerce also includes a command framework for the business logic layer - the Business Object Document (BOD) command framework. The concept of a BOD is used in prior versions of WebSphere Commerce, but in WebSphere Commerce Version 7, the entire command framework is tailored to using BODs.

In prior versions of WebSphere Commerce, there are implementation dependencies between the various layers. The current architecture uses well-defined interfaces to de-couple the implementation of the presentation layer, business logic layer, persistence layer, and data service layer. From the business logic layer perspective, OAGIS messages are used as the interface for making requests to retrieve business data or invoke business logic. The BOD command framework provides the capability to process these BOD requests and responses.

Data service layer (DSL)

The data service layer (DSL) provides a layer for data access that is independent of the physical schema.

The purpose of the data service layer is to provide a consistent interface (called the data service facade) for accessing data, independent of the object-relational mapping framework (such as EJB, DAS, or JPA). In its turn, the abstracted mapping framework is used to transform the data that is retrieved from the database into a collection of Java objects. These objects are implemented as physical service data objects (SDOs).

The following diagram shows the different layers of the WebSphere Commerce programming model and how the data service layer fits into the model:
BOD programming model layers

Advantages of implementing SOA and using DSL in WebSphere Commerce

Implementing SOA and using DSL in WebSphere Commerce includes a number of consistency benefits. It provides consistency within the programming model, unifying all actions against the server. That is, SOA and DSL provide a consistent base for how WebSphere Commerce can interact with its own components and data, and with other components and their data.

As integrated features are enabled by using services over time, these services further build upon consistency within the programming model. In short, SOA and DSL are the building blocks for current and future WebSphere Commerce components, where consistency in the programming model can lead to an easier to implement and more reusable platform.

The following WebSphere Commerce components are examples of where SOA and DSL are used, or partially used:

WebSphere Commerce starter stores, for example, the Madisons and Elite starter stores
Management Center
Distributed Order Management (DOM)
WebSphere Commerce SOA tutorials, and optionally, your own custom web services
Remote widgets
WebSphere Commerce search
Distributed Order Management (DOM) with Sterling Selling and Fulfillment Suite (SSFS)
REST services
Location-based services

The advantages of reuse in SOA and DSL provides the same interface, whether in WebSphere Commerce or from external sources. For example, you can code it once, implement it in WebSphere Commerce starter stores, and even in external systems, while all going through the same code path.

Web services entry points in the Information Center

After you become familiar with the overall web services concepts in WebSphere Commerce, you can use the web services task documentation according to each approach.

Web services tasks and related information:

Web services documentation entry points
Entry point	Description and usage
Working with WebSphere Commerce SOI services	You can develop client libraries, new commands, and business logic. The Java Emitter Template (JET) is provided and documented to assist you with these tasks. Use this information when you want to work with WebSphere Commerce services using the WebSphere Commerce foundation feature. The WebSphere Commerce foundation feature adds new groups of services to the WebSphere Commerce server. For example, WebSphere Commerce foundation creates new services and updates the existing services that are required to support feature pack features. The services in this task are typically used in the following layers: Business logic layer Persistence layer
Creating WebSphere Commerce services	You can set up the development environment, create and extend client libraries, and set an EMF genmodel. The Java Emitter Template (JET) is provided and documented to assist you with these tasks. Use this information when you create WebSphere Commerce services by using WebSphere Commerce Developer. Best practice tasks are outlined so that you can create your services to adhere to the WebSphere Commerce programming model. The services in this task are typically used in the following layers: Business logic layer Persistence layer
Developing the business logic layer using the BOD command framework WebSphere Commerce BOD command framework	You can use well-defined interfaces to decouple the implementation of the presentation layer, business logic layer, and persistence layer. From the business logic layer perspective, OAGIS messages are used as the interface for making requests to retrieve business data or invoke business logic. The BOD command framework provides the capability to process these BOD requests and responses. Use this information to develop service modules in WebSphere Commerce. WebSphere Commerce service modules contain the definitions for the nouns, generated code, and other information about the services that are supported. That is, a service module is a collection of related business objects for some business purpose. You can develop BOD Get, Process, Change, and Sync services. The services in this task are typically used in the following layer: Business logic layer (Business Object Document)
Working with the data service layer Data service layer	You can customize the Data Service Layer (DSL) to suit your business needs. The DSL consists of 3 pieces: the business object mediation service, the physical persistence service, and the data service façade. The business object mediation service initializes mediators. These are classes that transform between the logical and physical representations of the domain model. This allows the business logic layer to deal only with the logical representation of the data. Each service module provides its own mediators, and there are 2 kinds: Read and Change mediators. They are listed in the BOM configuration file. Read mediators are used to process the OAGIS Get requests. Change mediators handle the OAGIS Change, Process, and Sync requests. The mediators access the physical data through the physical persistence service. This service translates XPath queries to SQL queries. The services in this task are typically used in the following layers: Data service layer Persistence layer
WebSphere Commerce Web services with JSP pages	You can enable WebSphere Commerce to be a service provider by enabling its business functions as web services that can be accessed by external systems. You can also allow WebSphere Commerce to be the service consumer by enabling it to invoke web services that are hosted by external systems. Use this information when you are working with web services and JSP files. WebSphere Commerce is designed to support web services, both as a provider of web services and as a consumer (client) to other web services. Alternatively, WebSphere Commerce can connect to other web service providers and request information. The services in this task are typically used in the following layers: Persistence layer Presentation layer
Working with Web service feeds	You can use a RESTful framework to include web service feeds in starter stores. Your site can use feeds to syndicate store information so customers can access that information on websites external to WebSphere Commerce. For example, you can let customers subscribe to a feed from an e-Marketing Spot that displays the Deal of the Week. In addition, WebSphere Commerce remote widgets display feed content to customers by using this RESTful framework. Use this information when you want your site to contain web service feeds. If you are creating a custom feed from a web service, you must use the stated URL structure in your customization, as the URL structure adheres to the principles of REST (Representational State Transfer). The services in this task are typically used in the following layer: Business logic layer
WebSphere Commerce foundation tag library	You can use a collection of provided custom tags to support the authoring of WebSphere Commerce JSP files. Use this information when you are working with web services and JSP files. For example, the `<wcf:getData>` tag, part of the WebSphere Commerce foundation tag library, allows you to retrieve service data objects from any WebSphere Commerce service and associate them with a newly declared scripting variable with a given ID. This specified ID also associates the SDO objects with a specified scope. The services in this task are typically used in the following layers: Presentation layer
../../com.ibm.commerce.workspaces.developer.doc/concepts/cwows.html	You can use the Management Center by using Get services from BOD service modules to retrieve business objects, and along with the business objects, change control metadata included in the response. The change control metadata is returned to the Management Center, where it is used to determine whether the object can be modified by the current user. You can customize the aspects of the physical and logical layers of a BOD service module that are under change control, by enabling or disabling change control for nouns and noun parts. Use this information when you are working with BOD service modules in workspaces. The information contains important support notes such as the scope for data service layer tables, nouns and noun parts, and presenting change control information. The services in this task are typically used in the following layer: Business logic layer (Business Object Documents)
Representational State Transfer (REST) services	You can use Representational State Transfer (REST) services to provide a framework that can be used to develop RESTful applications on several platforms. These platforms can include web, mobile, kiosks, third-party and social applications. Use this information when you are developing RESTful applications on several platforms for WebSphere Commerce. WebSphere Commerce REST services are JAX-RS REST services that are built on top of Apache Wink. The implementation classes contain JAX-RS annotations such as @Path, @Produces, @Consumes, @QueryParam, and @PathParam. The WebSphere Commerce REST API is provided to assist you with this task. The services in this task are typically used in the following layer: Business logic layer
Location-based services	You can use location-based services to target customers by using Global Positioning System (GPS) enabled mobile devices. Use this information when you are working with smartphone and tablet starter stores. Mobile web starter stores and mobile applications can take advantage of location-based marketing activities. The services in this task are typically used in the following layers: Business logic layer Presentation layer

Web services tutorials

After you become familiar with the overall web services approaches in WebSphere Commerce, you can perform several scenarios by using the web services tutorial documentation.

Web services tutorials introduce the various tasks that are related to creating and customizing web services for WebSphere Commerce applications.


Tutorial	Learning objectives	Description
Tutorial: Creating a WebSphere Commerce web service module (SOI)	After you complete this tutorial, you should be able to complete the following tasks: Use the Java Emitter Template (JET) to generate a WebSphere Commerce service module Create a noun Create a client library and component facade to support operations (verbs) on that noun	In this tutorial you, you are creating a WebSphere Commerce web service module (SOI) with WebSphere Commerce Developer. This tutorial contains two parts: creating a Get TutorialStore web service, and creating a Process TutorialStore web service. You must create the Get TutorialStore web service before you create the Process TutorialStore web service to successfully complete this tutorial.
Tutorial: Creating an inbound Web service using OAGIS	After completing this tutorial, you should be familiar with the following concepts: Web services XML schema OAGIS style Web services After completing this tutorial, you should be able to complete the following tasks: Defining an OAGIS style Web service Calling existing business logic Creating a success confirmation message Creating a custom failure message	In this tutorial, you create an OAGIS style Web service. This Web service creates a customer in WebSphere Commerce with the WebSphere Commerce Web services framework. This tutorial demonstrates the steps involved with defining and registering a new service in WebSphere Commerce and creating the response JSP template for a confirmation response. Note: Creating an inbound Web services with the OAGIS style is supported in WebSphere Commerce Version 7. You are, however, recommended to create your Web services with the SOI style demonstrated in the tutorial: Tutorial: Creating a WebSphere Commerce web service module (SOI).
Tutorial: Creating an outbound web service client	After you complete this tutorial, you should be familiar with the following concepts: Web services XML schema After completed this tutorial, you should be able to complete the following tasks: Create an outbound web service client Integrate an outbound web service with a sample web service which manages users.	In this tutorial, you create the MyCompanyMember outbound web service client. This client integrates WebSphere Commerce with a sample web service which manages users. The MyCompanyMember web service client integrates with the UserRegistrationAdd and UserRegistrationUpdate commands to push new and updated user registration information to the sample system.
Tutorial: Extending an SOI service with UserData	After you complete this tutorial, you should be able to complete the following tasks: Extend nouns by using the `UserData` field to include new information. Use `UserData` to transfer information where it persists to the database. Add support for personalizing products	This tutorial shows you the steps that are involved in extending the OrderItem noun of the Web services architecture to include new information. `UserData` is used to transfer the new Order information from the example Web 2.0 store to WebSphere Commerce where it persists to the database. In this tutorial, you customize the shopping flow to allow the customer the ability to track engraving information for an Order Item. After this customization, a customer can view the options in their shopping cart for any items that can be engraved.
Tutorial: Extending an SOI service with Overlays	After completing this tutorial you should be able to complete the following tasks: Extend nouns using overlays. Use access beans to persist and retrieve data. Add support for personalizing products	In this tutorial you will extend the OrderItem Web services noun to add new information and functionality to your storefront. You will use overlays to transfer order information from your store to your WebSphere Commerce database. This support provides you the functionality of additional input fields for your customers to enter information during the ordering process which you can customize to meet your business needs. Note: Extending BOD services with Overlays is not supported. Instead, you must extend an SOI service with Overlays, as shown in this tutorial.
Tutorial: Creating an Atom feed to display information in a remote widget	After you complete this tutorial, you should be familiar with the following concepts: To understand how to customize the WebSphere Commerce framework that serves Atom feeds from Web services. To understand how your site can use Web service feeds to display store content on external sites, such as social networks.	This tutorial shows you how to customize WebSphere Commerce to use an Atom feed. You can display the information from the feed in a widget that your customers can share to social networks. The widget can contain links to drive traffic from social networks back to your store. By creating this type of Web service feed, you are no longer limited to displaying your information on store pages.
Tutorial: Creating a BOD service module	After completing this tutorial, you should be familiar with the following concepts: The WebSphere Commerce BOD command framework Extension and customization tasks. Logical model definitions. The Java Emitter Template. Service Data Objects. Eclipse Modeling Framework. The Data Service Layer Wizard. The Business Object Mediator. After completing this tutorial, you should be able to perform the following tasks: Create an extended sites store with a custom catalog. Review the Project noun. Customize the physical layer. Generate the base code for your Project service module. Generate Service Data Objects and object-relational metadata. Add language-specific exception messages to the properties files. Import mediators. Configure the data service layer for the Project service module.	In this tutorial, you develop a project service module. The services that are provided by the module are: Get, Change, and Process. As part of creating the service module, you design the logical model (noun) and physical model (database schema) based on the business requirement.
Tutorial: Creating a RESTful service and customizing the response format output	In Section 1, you customize the create and test REST services for both the Project and Project Collection nouns. In Section 2, you customize the entity providers to facilitate new custom response formats. This entity provider customization provides you the ability to specify what elements you want returned from each noun and how they appear in the client.	This tutorial demonstrates how to customize and test REST services for Project and Project Collection noun. To customize these REST services, you are also customizing entity providers to facilitate new custom response formats.
Tutorial: Configuring WebSphere Commerce for device detection and redirection to device-specific storefronts	After completing this tutorial, you should be able to perform the following tasks: Update the Struts configuration file to include new actions and new forward mappings to device-specific pages. Create and update SEO patterns. Modify the SEO patterns and parameters of `wcf:url` tags in the storefront, applying the SEO pattern file changes. Propagating SEO pattern changes to storefront customization tasks, including JSP, JSPF, and JavaScript modification.	In this tutorial, you learn how to configure WebSphere Commerce for device detection and redirection to device-specific storefronts.
Tutorial: Customizing outbound order services from WebSphere Commerce to Sterling DOM	After you complete this tutorial, you should be familiar with the following concepts and tasks: This tutorial is designed to show you the steps that are involved in extending the `orderitem` noun part of the web services architecture to include new information. UserData is used to transfer the new Order item information from WebSphere Commerce to Sterling DOM. In this tutorial, you customize the shopping flow to enable the customer to track engraving information for an Order Item, and customize the order integration flow to pass engraving information to Sterling DOM for an order item. After this customization, a customer can see the options in their shopping cart for any items that can be engraved before they check out. After inputting engraving information and submitting the order, a CSR can see the engraving information when you view the order details in Sterling DOM. For example, wine glasses can contain the options for text to be engraved with selected sizes and fonts for the text.	This tutorial demonstrates how to customize the WebSphere Commerce order component to support customization of the OrderItem noun part by using UserData information. This customization enables WebSphere Commerce to capture custom order user data and transfer it to Sterling DOM as part of the transfer order integration flow.
Tutorial: Creating and customizing REST services by using the configuration-based controller command and data bean mapping framework	After completing this tutorial, you should be able to complete the following tasks: Create a REST handler for mapping the custom data bean and controller command Customize an existing configuration-based data bean mapping to return more data The first part of this tutorial uses the sample data bean and controller command that you imported from the sample code. From the sample, create your own mapping configuration files and REST resource handler to make the rest calls to the sample data bean and controller command. The second part of the tutorial takes the default RequisitionListDataBean as an example, and shows how to customize an existing configuration-based data bean mapping to return more data. Note: This tutorial uses the Derby database.	In this tutorial, you use the configuration-based controller command and data bean mapping framework to add support for creating REST services.

Additional information about web services

The following section familiarizes you with the many websites that contain technical information for understanding and using your web services. A wealth of online information is available to complement the product documentation.

For more information about web services and related technologies, see the following websites:

For information about Apache SOAP, an implementation of the SOAP submission to W3C: http://ws.apache.org/soap/.
For in-depth information about the SOAP Specification: http://www.w3.org/TR/SOAP/.
For information about UDDI: http://www.uddi.org/.
For information about WSDL: http://www.w3.org/TR/wsdl.
For more information about OAGIS: http://www.openapplications.org.
To learn more about web services from IBM alphaWorks: http://www.alphaworks.ibm.com/webservices.
To learn more about web services from the developer perspective: .

Web services reference information

WebSphere Commerce provides many web services, which are grouped by component. Each component contains one or more nouns. In addition, WebSphere Commerce provides WSDL files that describe its web services.

For more information, see the WebSphere Commerce web services references information.

Articles of interest

Developing Web Services with EMF SDOs for complex XML on developerWorks.
IBM's SOA Foundation - An Architectural Introduction and Overview, the comprehensive architecture overview of IBM SOA.