Network Deployment (Distributed operating systems), v8.0 > Develop and deploying applications > Develop Data access resources > Develop data access applications > Develop data access applications > Service Data Objects version 2.1.1 > Use SDO 2.1.1 in SCA applications


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

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

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 Use SDO 2.1.1 in SCA applications.

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


Procedure

  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 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.
SDO data binding for SCA applications
Use SDO 2.1.1 in SCA applications
Rational Application Developer documentation

+

Search Tips   |   Advanced Search