Simon Nash

author
+ Follow
since Jan 12, 2011
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Simon Nash

Hi Pedro,

Thanks for your interest in SCA and Tuscany.

SCA and CORBA both enable integration between different languages and platforms, but they do it in very different ways.

CORBA defines its own interface definition language (OMG IDL) and its own wire protocol (IIOP). All CORBA implementations need to define their interfaces in OMG IDL and use IIOP on the wire. In human language terms, it's like inventing a new artificial language (Esperanto) and translating all the other languages to and from Esperanto. If an English speaker wants to talk to a French speaker, the CORBA approach means that the English speaker would translate from English into Esperanto and the French speaker would translate from Esperanto into French. Similarly, a Spanish speaker talking to a Japanese speaker would translate Spanish into Esperanto and the Japanese speaker would translate Esperanto into Japanese. This gets really crazy when one English person is talking to another English person, because they would have to communicate via Esperanto instead of just speaking English.

SCA doesn't mandate a single interface definition language, so it's fine to describe interfaces using WSDL, Java interfaces, C++ header files, etc. SCA also doesn't define its own wire protocol, so it's fine for components to communicate using SOAP/HTTP, JMS, RMI, REST, JSON-RPC, Atom, RSS, IIOP, etc. In human language terms, the SCA approach means that two English speakers can chat in English if they want. A French speaker and a Japanese speaker might decide to talk in French, but if they prefer to use Japanese that would be fine as well.

As you say, SCA and Tuscany separate the business logic from the integration code so that business component implementations don't have any knowledge of or dependencies on the integration technology that's used to connect them. The integration technology knowledge is contained in XML component definitions that are separate from the business implementations and can be changed easily without needing to modify implementations.

In the example you gave of an SCA service originally implemented using RMI, this could be changed to Web Services by just updating the XML component definitions. The Tuscany runtime would generate the WSDL using its own generator which follows the JAX-WS specification. We originally used Axis2 for WSDL generation but we ran into some problems with the Axis2 WSDL generator and so we created our own WSDL generator.

SCA has a policy framework and Tuscany uses this to enable authentication and authorization to be added to components declaratively. The SCA policy framework also supports transactionality but Tuscany's support for this is rather limited at present.

In a perfect world, everything would work perfectly in combination with everything else (for example, transactions would work across all protocols and implementation types). The SCA architecture does enable this, but there's a lot of tricky implementation code needed in the SCA runtime to make this work for all possible combinations. Tuscany adopts an 80/20 approach to this kind of thing, which means that we put a lot of effort into making sure the important combinations work and we improve the more obscure cases as and when people need them and are willing to help with the work involved.

I hope this helps. Let us know if you have any more questions.
It's definitely possible to implement SCA for other languages and platforms, such as C# and .NET. There's no official SCA specification for this, so someone who wanted to do it would have to adapt the current SCA specs to the C# and .NET environment.

Building the equivalent of Tuscany for C# and .NET would be quite a bit of work, and so far no-one's been willing to invest the time and effort to make it happen.

The good news is that it's easy to integrate C#/.NET code into an SCA/Tuscany application by using WSDL/Web Services as the interoperability protocol. You just need to build a web service using C#/.NET, generate WSDL for this web service, import the WSDL into an SCA component definition, and invoke the C#/.NET web service from the SCA component. We've tested this scenario in Tuscany, and there's a Tuscany demo showing how to do it.