Page History

Introduction

This page details the Design Specifications for the Tuscany SCA Native M4 Release.

The release contents can be found here: SCA Native Next Release Contents

Design Specifications

The design specifications for each topic are detailed below.

SCA Artifact Schemas

Currently, when the TuscanySCA runtime starts, it loads the following schemas:

• <install_root>/xsd/sca.xsd
• <install_root>/xsd/tuscany.xsd
• <install_root>/extensions/<every extension>/xsd/*.xsd

The schema file sca.xsd simply includes the following:

• <install_root>/xsd/sca-core.xsd
• <install_root>/xsd/sca-interface-java.xsd
• <install_root>/xsd/sca-interface-wsdl.xsd
• <install_root>/xsd/sca-implementation-java.xsd
• <install_root>/xsd/sca-implementation-composite.xsd

For the Tuscany M4 release, this will change so that any xsd file in the following directories will be loaded:

• <install_root>/xsd/*.xsd
• <install_root>/extensions/<extension directories>/xsd/*.xsd

The following TuscanySCA XML Schemas are what will be loaded for the M4 release.
They will need to be modified to reflect the SCA Assembly model and Client and Implementation version 1.0 specifications.
Those schemas that are loaded but ignored will be loaded for compatibility with TuscanySCA Java and other implementations.
The runtime will start without failure with relevant logging message will be generated, but the services will not be
available at runtime.

• runtime/core/xsd/ (deployed to <install_root>/xsd)
  • sca-implementation-composite.xsd
  • sca-interface-wsdl.xsd
  • tuscany.xsd
  • sca-core.xsd
  • sca.xsd (to be removed)
  • sca-implementation-java.xsd (loaded but ignored)
  • sca-interface-java.xsd (loaded but ignored)

• runtime/extensions/cpp/xsd/ (deployed to <install_root>/extensions/cpp/xsd)
  • sca-implementation-cpp.xsd
  • sca-interface-cpp.xsd

• runtime/extensions/php/xsd/ (deployed to <install_root>/extensions/php/xsd)
  • sca-implementation-cpp.xsd

• runtime/extensions/python/xsd/ (deployed to <install_root>/extensions/python/xsd)
  • sca-implementation-python.xsd
  • sca-interface-python.xsd

• runtime/extensions/rest/xsd/ (deployed to <install_root>/extensions/rest/xsd)
  • sca-binding-rest.xsd
  • sca-interface-rest.xsd

• runtime/extensions/ruby/xsd/ (deployed to <install_root>/extensions/ruby/xsd)
  • sca-implementation-ruby.xsd

• runtime/extensions/sca/xsd/ (deployed to <install_root>/extensions/sca/xsd)
  • sca-binding-sca.xsd

• runtime/extensions/ws/xsd/ (deployed to <install_root>/extensions/ws/xsd)
  • sca-binding-webservice.xsd

SCA Data Model

Currently, when an SCA project is loaded, the composites, componentTypes, WSDLs, and extension
files are parsed into SDOs based on schemas loaded at startup. The SDOs are then traversed and
an SCA artifact hierarchy is created, typically with a composite being the root level artifact.
Then when a runtime service request is processed, the runtime extension (cpp, ws, sca, etc)
gets the SCARuntime pointer and then traverses the SCA hierarchy and ultimately retrieves the
ServiceProxy or ServiceWrapper to invoke the service. The problem with this approach is that
the runtime extensions are very closely coupled with the internal data model. Any minor change
to the model requires modifying just about every other part of the codebase that uses the data
model.

To decouple the internal data model, from its consumers, an SCAServiceFactory will be created
which will effectively be a map from of String Service Identifiers to SCAProjectData objects.
The SCA project will still be loaded as it is now, but when each project is loaded into SDOs
and the internal data model is created, the service data will be loaded in the SCAServiceFactory.

SCAServiceFactory Service Identifier String

The Service Identifier String will be a unique identifier for a particular SCA service. In the
case of an SCA service exposed by a <binding.ws/> and <interface.wsdl/> element, the Service
Identifier String will be the HTTP URL specified in the WSDL service/port/soap:address. The
Service Identifier will vary depending on how the SCA service is exposed.

SCAServiceFactory SCAProjectData class

The SCAProjectData class will be a type of SCA Service metadata object. It will contain all
necessary information to be able to query and invoke an SCA service. The SCAProjectData will
serve to decouple the internal SCA data model hierarchy from the runtime service execution
extensions. Following is a brief preliminary summary of its structure:

class SCAProjectData
{
public:
    get/setCompositeName();
    get/setComponentName();
    get/setServiceName();
    get/setBindingName();
    get/setNamespaceURI();
    get/setInterfaceType();
    get/setImplementationType();
    get/setServiceWrapper();
    get/setServiceProxy();

private:
    std::string compositeName_;
    std::string componentName_;
    std::string serviceName_;
    std::string bindingName_;
    std::string namespaceURI_;
    std::string interfaceType_;
    std::string implementationType_;
    ServiceWrapper *serviceWrapper_;
    ServiceProxy *serviceProxy_;
};

Both the SCAServiceFactory and the SCAProjectData will be thread safe and will internally use Mutex
appropriately.