Service Data Objects (SDO)

SDO (Service Data Objects) is a framework for data application development, which includes an architecture and API. WebSphere Commerce utilizes the SDO capabilities for XML marshalling and unmarshalling, and code generation from XSD to static Java objects. The SDOs themselves are Java object representations of your nouns, and can be easily traversed by using getters.

SDO provides the following benefits:

• Simplifies the J2EE data programming model

• Abstracts data in a service-oriented architecture (SOA)

• Unifies data application development

• Supports and integrates XML

• Incorporates J2EE patterns and best practices

In Java, the data objects of the service module (contained in the data object project) are represented as service data objects (SDOs). This module contains the XSDs of the data objects along with the WSDL of the services and the generated SDO code to be used by the component facade implementation and the Java client.

An example of a SDO is com.ibm.commerce.member.facade.datatypes.impl.PersonTypeImpl, which implements the com.ibm.commerce.member.facade.datatypes.PersonType interface. To get information from the SDO, you need to know its XPath. For example, the XPath of a person's logon ID is as follows: /Person/Credential/LogonID

To get this information from the Person SDO, you would write the following Java code:

personType.getCredential().getLogonID();

When an SDO getter returns a List, refer to the Javadoc to determine the type of the List elements. For example, the list of contacts in a person's address book is of type com.ibm.commerce.foundation.common.datatypes.ContactInfoType:

List contacts = person.getAddressBook().getContact();
for (int i=0; i < contacts.size(); i++) {
	ContactInfoType contactInfo = (ContactInfoType) contacts.get(i);
	TelephoneType telephone1 = contactInfo.getTelephone1();
}

See

Introduction to Service Data Objects on the IBM DeveloperWorks for a good introduction to SDO.

SDO annotations

SDO annotations are Eclipse Modeling Framework (EMF) annotations for generating Java code based on XSDs. SDO annotations can be added to the XSD to assist the EMF tooling to specify the package name and XML namespace prefix when creating the .genmodel as a basis to generate SDOs. This extension is to add the following namespace and package declaration to every schema defined. The namespace element is the EMF syntax definition to allow the package attribute to be specified. This package attribute is used by the tools to generate the package name of the generated objects. In the example below, the generated SDO is com.ibm.commerce.catalog.facade.datatypes.

<schema xmlns="http://www.w3.org/2001/XMLSchema" 
 xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
 xmlns:oa="http://www.openapplications.org/oagis/9" 
 xmlns:_cat="http://www.ibm.com/xmlns/prod/commerce/9/catalog"
 attributeFormDefault="unqualified" 
 elementFormDefault="qualified"
 targetNamespace="http://www.ibm.com/xmlns/prod/commerce/9/catalog" 
 ecore:nsPrefix="_cat"
 ecore:package="com.ibm.commerce.catalog.facade.datatypes">

See the article on the dev.eclipse.org Web site.

Note: The word class is reserved by SDO. If you use class as a property name, an underscore _ is added to provide a unique name when EMF generates the SDOs. However, it does not update the configuration files, and manual updates are necessary. For example:In the wc-business-object-mediator.xml file:

<_config:userDataProperty logicalPropertyName="class_" 
physicalPropertyName="class_"/>

In the wc-object-relational-metadata.xml file:

<_config:column name="CLASS" nullable="true" primaryKey="false" 
propertyName="class_" type="INTEGER"/>

Programming guidelines for WebSphere Commerce Business Objects

The following programming guidelines can help us create business objects that conform to the expected default structure implemented in WebSphere Commerce.

• Every business object defined in the WebSphere Commerce logical model should have a Java interface defined to describe the object.

• Although the business objects do implement the commonj.sdo.DataObject interface, IBM recommends to use the static Java interface when possible, and only use the commonj.sdo.DataObject interface when needed.

• The business objects are typically defined in the com.ibm.commerce.component.facade.datatypes Java package for the business component. For example, the Catalog Java interfaces for business objects are located in com.ibm.commerce.catalog.facade.datatypes.

• Since the business objects are represented by Java interfaces, a Factory class is required to instantiate an implementation of the interface. The factory for creating and instantiating the business objects should be found in the same Java package and business object interface. It should use the following naming convention: ComponentFactory. For example the factory for instantiating Catalog objects is called CatalogFactory.

• The Java technology used to implement the Java interfaces is based on EMF, where the programming pattern to instantiate the objects follow a consistent model with EMF. That is, the factory interface that is used to create the Java implementations of the business object Java interface have an eINSTANCE field, with links to the implementation of the factory to create the object.

  The following is an example of instantiating a CatalogDescription business object:

  CatalogDescriptionType descType = CatalogFactory.eINSTANCE.createCatalogDescriptionType();
  descType.setLanguage("-1");
  descType.setName("CatalogEntry Name");
  descType.setThumbnail("CatalogEntry Thumbnail Relative URI");
  descType.setShortDescription("CatalogEntry Short Description");

Related concepts
WebSphere Commerce use of Open Applications Group (OAGIS) messaging
Client library for WebSphere Commerce services

Related tasks
Creating and updating Service Data Objects (SDO)
Generating code from an SDO genmodel file
Updating Service Data Objects