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.
