OSOA Home

The Windows Communication Foundation (WCF), which was formerly known by its codename of Indigo, shares many of the goals of SCA, such as:

• A simplified service development programming model
• Support for multiple languages
• Separation of programming model from transport technology
• Interoperability through Web services technologies

The simplified programming model itself has a number of similarities that are explored in more detail below.  However, there are also a number of differences in the goals of the two technologies.

WCF Assumption of a Single Runtime

One of the main differences between SCA and WCF is that WCF is designed only for use by components running within the Common Language Runtime (CLR) and more specifically, on the .Net Framework (version 3.0 or later).  SCA can support components written in many languages such as C, C++, PHP or Cobol, without requiring that those languages run within a Java Virtual Machine or within any other designated runtime environment.  Different components running within a single SCA Domain may executing in different runtime nodes that don't share a single line of code.

SCA Assembly compared with WCF Configuration

SCA includes the concept of an assembly of components, which are defined within a composite.  A composite file is similar to a WCF configuration file, but there are key differences.  Consider the simple case of two components composed together, where the first component has a service reference ("peopleRef") that is satisfied by a service provided by the second component ("People").  The following is an example of a WCF configuration for such a composition:

<configuration>
   <system.serviceModel>
      <client>
         <endpoint configurationName="peopleRef"
                  address="http://localhost:8080/people"
                 bindingSectionName="basicProfileBinding"
                 contractType="SelfHostedService.IPeople"/>
      </client>
      <services>
         <service serviceType="SelfHostedService.People">
            <endpoint address="https://localhost:8079/people"
                     bindingSectionName="basicProfileBinding"
                     contractType="SelfHostedService.IPeople"/>
         </service>
      </services>
   </system.serviceModel>
</configuration>

Now consider a similar SCA composite:

<composite targetNamespace="http://foo.com" name="peopleComposite">
   <component name="myClient">
      <implementation.java class="myClientImpl"/>
      <reference name="peopleRef" target="people"/>
   </component>
   <component name="people">
      <implementation.java class="PeopleImpl"/>
   </component>
</composite>

Both of these files are used to resolve the target of the reference from the client to the service that provides the implementation of the People service.  In the example, we've assumed that the client and the service provider don't really care how they talk to each other.  In SCA, it is possible to simply connect a reference to a service via a wire and let the runtime decide how to communicate between components, when both components are within a single SCA domain (which does not mean that they are necessarily on the same machine).  By contrast, in WCF services and clients always must specify the binding and endpoints that will be used.  WCF has no ability to leave the choice of binding and endpoints up to the runtime.

If the SCA case wanted to make the "people" service available to the outside world (ie. outside the SCA domain), then the binding and endpoint would have to be explicitly chosen and this assembly file would also be the place to specify the binding details, similar to the way it is done within the WCF configuration file.

In SCA, it is expected that components that provide services are also frequently clients of other services. The SCA component concept allows us to recognize this.  A single component offers services, is the client of other services, and has configurable properties.  In WCF, the client (reference) configuration has to be retrieved separately from the service configuration, even if it is the same code is both a service provider and a client.  Note also that the SCA composite file points at the code that is used to implement each component - it connects the service and reference configuration data to the code that implements it.  By contrast, WCF merely holds the configuration information for the services and references and the connection to the component implementation code must be done by the implementation code itself (see the example code below for detail on this).

By contrast, the SCA assembly model provides the capability for the runtime to inject the appropriate values for references and properties into the implementation code so that the business logic does not need to be cluttered with lookup code. For example, here is some client code for WCF that accesses the "people" service.  This example shows the constructor being used to lookup the proxy that will be used for communicating with the People service.  This lookup might not be put in a constructor, but it does need to exist somewhere:

public class Client {
   private IPeople people;

   public Client()
   {
      using (ChannelFactory<IPeople> ipeopleFactory =
      new ChannelFactory<IPeople>("myClient"))
      {
         ipeopleFactory.Open();
         people = ipeopleFactory.CreateChannel();
         ipeopleFactory.Close();
      }
   }

   public void func(Person p)
   {
      people.storePerson(p);
   }
}

By contrast, in SCA the code for this client is simpler, since it does not need to do this lookup:

public class Client {
   @reference protected People people;

   void func(Person p) {
      people.storePerson(p);
   }
}

In this case, the reference people is annotated with @reference and this indicates to the SCA runtime to inject the reference to the People service into this variable when the code is instantiated - no API is used.

Programming Model Similarities

SCA configuration can be used to configure components that use existing programming models, which were created with no knowledge of SCA.  However, SCA has also defined new simplified models for that can be used with Java, C++, BPEL, and other languages in the future.  This programming model has similarities to WCF. 

Using Java Annotations and C# Attributes

Both the SCA and the WCF programming models are based on annotations (although C# calls them "attributes").   Here is an example that is used for introducing WCF service construction:

[ServiceContract]
interface IAdder
{
  [OperationContract]
  int Add(int a, int b);
}

class Adder : IAdder
{
 public int Add(int a, int b)
 {
   return a + b;
 }
}

In SCA for Java the same example would look like this:

@Remotable
public interface IAdder
{
	int Add(int a, int b);
}

public class Adder implements IAdder
{
 public int Add(int a, int b)
 {
   return a + b;
 }
}

WCF requires that operations that will be made part of the service contract need to be explicitly annotated, while SCA assumes that all of the methods on the interface that has been marked with @remotable are part of the service contract.  Other than that, the approaches are very close to one another.

Conversational Services

Both SCA and WCF allow services to be defined where the infrastructure is used to maintain session state between operation calls. In SCA an interface is marked with an @conversational annotation and an implementation class is marked with @scope("conversational").  In WCF a conversational interface is marked with an attribute of: [ServiceContract(Session=True)].

One-Way Operations

Both SCA and WCF allow service developers to define operations that may be used asynchronously.  In SCA the operation is annotated with @OneWay, while in WCF the operation gets an attribute of [OperationContract(IsOneWay=True)].  Without these annotations the client of an operation that returns "void" does not continue until the operation has successfully completed and any exceptions that are thrown will be seen by the client at the place where the call is made.  With these annotations, the client continues immediately.  The type and configuration of the binding will determine the reliability of the delivery of the request to the service provider.

Bi-directional Interfaces

Both SCA and WCF allow interfaces to be defined with a corresponding callback interface.  In SCA, an interface can be annotated with @callback(myCallbackInterface.class).  In WCF the callback is specified with [CallbackContract = typeof(IMyCallback)].

Programming Model Differences

Dependency Injection

The SCA programming model encourages the use of dependency injection.  This means that when an implementation needs access to another service, it does not call a lookup function to find the service in question.  Instead, the developer just creates a field that is marked with an @reference annotation. The runtime is responsible for filling the value of that field after the object has been created.  Similarly, property values are inserted onto fields that have been marked with a @property annotation.

WCF requires that the developer make API calls to get dependent services and property values.

Dependency injection greatly simplifies the programming model.  It also makes it easier for developers and later administrators to keep track of what code uses what.  This is especially useful when determining the potential impact of changes.

Policy

Both SCA and WCF make use of annotations to request or configure capabilities from the infrastructure.  These are the policies associated with services, and both SCA and WCF can represent policies to external clients using WS-Policy.  However, SCA's model is generalized so that users can create new policies that are represented as simple intents. The role of the Policy Administrator can define these new intents and specify how they expand into full WS-Policy assertions.

SCA with WCF

SCA does not specify any required APIs or in any other way define code that must be present in a valid SCA runtime.  It is possible to use SCA in an environment where the SCA metadata is translated into the native format of a runtime that knows nothing of SCA, but merely has concepts that correspond to the SCA concepts (implementations, components, services, wires, bindings and policies).  Because of this, it would be possible to create an SCA domain that contains some .Net runtimes.  Some composites that are deployed to that domain would contain components that are written in one of the .Net languages using WCF.  However, instead of the .Net configuration file, that information would be created in an SCA composite file, which might also contain non-Microsoft technologies. The configuration stored in the composite would then be converted into equivalent configuration files in order to be executed in a WCF container.  Nonetheless, the SCA developer still gets to see the .Net components in the context of the larger multi-technology domain.

An alternative approach is to build an SCA-aware container on the Windows platform, supporting components written in one or more of the .Net languages and using WCF as part of its implementation, but where SCA metadata from composite files is used to derive information about components and about their services and references.

It is possible that both approaches might be implemented by different vendors.