Use a bottom-up approach to develop SCA components that use SDO

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).

Consider installing a Rational Application Developer product with SCA Development Tools that we 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 JEE (Java EE) component implementation type. Complete step 1 of Use SDO 2.1.1 in SCA applications.

This topic describes how to develop SCA composites that use SDO following a bottom-up approach.

1. 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);
   }

2. Write the 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 APIs 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 the files that use SDO in an SCA business-level application.

Related concepts

SDO data binding for SCA applications

Related tasks

Use SDO 2.1.1 in SCA applications

Related information: