Tuscany of Service

Goal

This paper will further understand the design idea of Tuscany from the angle of SCA Web Service binding. At the same time, further understanding of Osoa SCA 1.0.

Terminology and abbreviations

Component: This article translates the component in SCA into components. Component: This article translates the composite in SCA into components.

Background information

SCA first wants to solve the compatibility problem between SOA platforms, but the road is long. Tuscany has now done a service environment where he first provided a local widget runtime environment, which is the same as what spring does. The local system can run on top of the IOC environment/container provided by Tuscany. But the environment is much easier to integrate the services provided by heterogeneous systems through WS into the local system than spring. This article is going to explore another very important SCA implementation provided by Tuscany, which is to develop any local Java artifacts as a service to other systems.

Analyze content

Implementing local artifacts

When Tuscany plays the local IOC, the Java object provides an instance of the local widget and its methods. The job developers face is to load the widget description file (see SCA1.0)

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="http://mycomp" name="mycomposite">
<component name="Component">
<implementation.java class="mycomp.ComponentImpl"/>
</component>
</composite>

Tuscany will parse the file and load the implementation classes specified in the widget. Currently, the classes loaded by Tuscany are multiple examples. There is no relevant provision in the SCA1.0 standard.