Udooz!

Today, a technology newsletter carried with an article about SCA (Service Component Architecture) which is outshone at IBM campus along with BEA.  Is it a another SOA specification?  Is it a SOA framework? or, alternate to SOA?  Michael Rowley who is the author/architect/inventor of this said that it depends.  Confused.  Yes, it has been mentioned that SOA is hyped much and many of the things are futile.

Concept behind SCA

Following are the key aspects of SCA:

• Services – a set of operations that perform logically related tasks
• Components – contains the implementation and configuration of services
• Composites – responsible for configuring services
• Domain – A physical environment where the components will be hosted for consumption

A service contains a service contract and address.  Service contract specifies the operations available in the service, the inputs for which to operate and the promised outputs.  Service address provides where the service contract is available for consumption.  Components is nothing but C++ libraries or Java JARs.  Composites are XML file which contains the map between service contract and its implementation.  The domain enables to manage the components and apply policies for their access.  It provides common communication infrastructure and extensibility stuffs.

Technology behind SCA

Although in the specification it has been mentioned that SCA is technology and language independant, it is majorly on Java.  It has been mentioned that SCA is a concept as well as a framework but does not contains anything for presentation layer and data persistence.  However, it integrates with Java based UI and DB framworks.

So…What?

Instead of web services, SCA lets you connect and composite through web services, RPC or anyother means, unlike today protocol based SOA approach.   This is what mentioned and marketed in the SCA specification.  When you are crossing the border of “Concept behind SCA” section of this post, you have surprised that what is new in SCA for SOA, since WCF  incorporated these few years back when this specification was only on the paper.  More interesting and confusing thing is the specification team invited Microsoft for adopting this into .NET.  One more buzz is that this specification is based on WSDL.  These two make me what else have been proposed apart from what WCF has now with such the level of maturity.

For those who want clear map between above concepts and WCF:

• Services - C# interface with WCF declarations
• Components – C# classes with WCF declarations
• Composites – Service model section in app.config/web.config file.
• Domain – Service host (IIS/WAS/Windows Process)

What does it has….What doesn’t?

It provides the following:

• Service reference – dependency with other services
• Composition – way to encapsulate technical/vertical components such as validation, logging and auditing components within service and hide these to the outworld.
• Policy - a statement that controls the operations that provided by the infrastructure.
• Wire – a way for service aggregation and topologies (oneway, duplex, request and response)
• Bindings – provides the means to communicate to the consumers.

It doesn’t have the following:

• Service orchestration – but supports JSR based on BPEL
• Service extension
• Service inventory

Unfortunately, WCF has all the above with the power of .NET platform.  So, beware of SCA jargon in .NET world, where an elephant WCF has all the capabilities.  As of my understanding, SCA is WCF avatar in Java world.

Michael Rowley saluted the WCF proposals and its features, however he tried to oversight it with SCA.  Its confused.
CodeProject

Problem

WCF throws System.ExecutionEngineException when deserializing and consuming data contracts with IList based attributes.

Forces

• Collection is changed as immutable when using IList<T>
• Unable to convert it to List<T>
• Unable to send it back to service consumer if required

Solution

Let us define a data contract Dump which contains IList of InternalDump.

 
[DataContract]
public class InternalDump
{
    [DataMember]
    public string Part;
}

[DataContract]
public class Dump
{
    [DataMember]
    public string Name;
    [DataMember]
    public IList<InternalDump> Parts;
 

    public Dump()
    {
        Parts = new List<InternalDump>();
    }
}

I’ve declared a simple WCF service

[ServiceContract]
public interface IService1
{
    [OperationContract]
    Dump GetData(Dump d);
}
 

public class Service1 : IService1
{
    public Dump GetData(Dump d)
    {       
        return d;
    }
}

 You are noticed that GetData just returns the deserialized “d” as a return value to the consumer.  Being a .NET client, the consumer of this service as

Dump d = new Dump();
d.Name = "Roundtrip";
InternalDump id = new InternalDump();
id.Part = "Client";
d.Parts.Add(id);
 

ServiceReference1.Service1Client sc = new DumpConsole.ServiceReference1.Service1Client();
Dump sd = sc.GetData(d);

foreach (InternalDump id2 in sd.Parts)
{
    Console.Write(id2.Part);
}

At the consumer side, a new instance of Dump and InternalDump have been created, serialized and send it as input parameter for GetData.  At the service side, the probelm is when deserializing the IList<InternalDump>, WCF internally convert it into InternalDump[] which makes all the problem 1 and 2 mentioned in Forces section.

The problem is not in any of the above code, instead WCF itself.  The world’s so extensible ESB (enterprise service bus) framework assumed and convert IList<T> into T[] for platform neutral.

Unfortunately, do not know the root cause of problem 3 mentioned in “Forces” section.  The solution is not the technical one, but a guideline.

Don’t use IList<T> for the above mentioned probelms.  Instead use List<T>.

Hope WCF in .NET 4.0 will resolve this issue.

codeproject