Attachment 'InsideCppM1.html'


The CPP SCA Implementation

Implementation Components

The C++ implementation has a number of major parts including:

1/ The messaging model

2/ The SCDL model, i.e. an in memory representation if the SCDL file data

3/ the tooling required to generate interface descriptions, proxies and wrappers

The following example is used to describe them.

Messaging Model

C++ SCA describes the interaction between two components using a simple model that abstracts away the difference between local and remote communications.

MyComponent -> R2 -> S3 -> MyLocalComponent:

Note that the basic mode of operation is to have a proxy translate a service request into an Operation object. This represents the service request while it is transferred across whatever communication technology might be in place (in this case none as it is a local call). At the target end a wrapper translates the operation request back into a real operation call.

There are more steps involved when a remote client is used because of the external services and entry points involved.

MyComponent -> R1 -> ES1 -> EP2 -> S4 -> MyRemoteComponent:

In both of these cases the implementer of the client code in MyComponent has to interact with the SCA runtime in order to call other component services. This process in initiated using the call:

ComponentContext myContext = ComponentContext::getCurrent();

ComponentContext provides APIs for getting hold of useful SCA artifacts such as the proxies that have been created by the runtime to represent named services.

SCDL Model

The SCA SCDL defined model is read in by the C++ SCA runtime and represented in memory. This in memory model is a collection of objects which represent components, services, references etc.

The model is consulted by the runtime when routing messages. For example, in the previous remote connectivity example the model is consulted when setting up the in memory connections between the objects that mirror the definitions in the SCDL file. Hence, based on SCDL definition of external services the ServiceSpecificWrapper is connected to a WSServiceWrapper which is, based on the bindings specified in SCDL, connected to the Axis2Client.


The service specific proxies and wrappers employed by the C++ SCA runtime are generated using the SCAGen tool.

“service.h” -> SCAGen -> serviceproxy & servicewrapper

WSDL must be used to describe service interfaces but currently WSDL must be hand generated if it doesn’t exist already.

Deployed Runtime

The two examples used to describe the messaging model above don’t show how the runtime is bootstrapped. They imply that the runtime is already up and that MyComponent has been invoked somehow.

Running a component in C++ SCA M1 using a client with a simple in-process connection to an SCA component requires that the following resources are in place.

The client code in this case is calling from outside of SCA. However a similar set of APIs are made available to it as are made available to the component developer. A call to:

  ModuleContext myContext = ModuleContext::getCurrent();

Returns a ModuleContext which provides similar APIs for locating services as the ComponentContext.

Running the same component but with a client connecting using web services requires that the following resources are in place at the server. Here the service just waits for SOAP requests to come in over the wire.

Attached Files

To refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.

You are not allowed to attach a file to this page.