You can use a bottom-up approach that starts from Java
files to develop Service Component Architecture (SCA) component implementations
that use Service Data Objects (SDO) 2.1.1 (JSR 235).
Before you begin
Install the product and enable SDO. Instructions on enabling
the SDO feature are in the installation topics for your operating
system.
Consider installing a Rational® Application
Developer product with SCA Development Tools that you can use to assemble
service-oriented application components based on open SCA specifications.
See the Rational Application Developer documentation.
Access
the default HelperContext programmatically in a Java or Java Platform, Enterprise Edition (Java
EE) component implementation type. Complete step 1 of Using SDO 2.1.1 in SCA applications.
About this task
This topic describes how to develop SCA composites that
use SDO following a bottom-up approach.
Procedure
- Start from a Java interface or implementation using type
commonj.sdo.DataObject for one or more parameters or return types.
The following example Java file provides an interface.
Logger.java
(interface):
package logger;
import commonj.sdo.DataObject;
public interface Logger {
public String logDataObjectProperties (DataObject input);
}
- Write your SCA Java client or component implementation
using the dynamic SDO programming model.
The following
example Java file provides a component implementation.
LoggerImpl.java
(component implementation):
package logger.impl;
import logger.Logger;
import org.osoa.sca.annotations.Service;
import commonj.sdo.DataObject;
import commonj.sdo.helper.DataFactory;
import commonj.sdo.helper.HelperContext;
@Service(Logger.class)
public class LoggerImpl implements Logger {
public String logDataObjectProperties (DataObject input) {
String logMsg = "==========\n";
List props = input.getInstanceProperties();
for (int i=0; i < props.size(); i++){
Property prop = (Property)props.get(i);
logMsg += " prop[" + i + "], name = " + prop.getName() + ", val = " +
input.get(prop).toString() + "\n";
}
logMsg += "==========\n";
return logMsg;
}
}
The SDO application programming interfaces
used are generic in that they do not depend on any particular schema
definitions. This behavior fits the bottom-up approach because, without
a WSDL interface describing this service, the runtime environment
cannot associate the input object that is built during deserialization
with a specific XSD or SDO type.
Results
You have developed an SCA composite that uses SDO following
a bottom-up approach.
What to do next
Optionally, implement shared scopes. See the topic on
using SDO 2.1.1 in SCA applications.
Deploy your files that
use SDO in an SCA business-level application.