Re. relationship with CORBA...
The CORBA component architecture required all components in an application to use the same interface definition language (OMG IDL) and the same communication protocol (IIOP). SCA is much more flexible because it embraces different interface definition languages and communication protocols. This makes it much easier for SCA components to be used together with existing components that weren't designed specifically with SCA in mind. This flexibility and interoperability means that non-SCA components can be migrated to SCA gradually over time rather than requiring a "big bang" approach where everything would need to be converted to use SCA before it could be used together.
If I understand the Tuscany idea correctly, it is a way of defining and maintaining a connections between components in a way which separates the integration code from the business logic, right?
You hit the nail on the head!
So, when I write a service I don't have to know what protocol will it use?
Yes, that's right.
Right now, the information exchange is based on SOAP WS, but it's quite possible that in next year REST WS would be the actual approach. Can this change be made? And if so, can it be made easily?
I think your talking about references here but the intention is that this is true for both references and services. Imagine that I've defined SomeService using the SCA assembly model and a Java implementation as following (Note. I just typed this in off the top of my head to sorry for any typos)
So we have the component accepting messages over SOAP web service and connecting, via a reference, to another SOAP web service.
Then If I wanted to expose this service as a Atom style REST service I could change the service declaration as follows
Or even binding.rss or binding.http. Now it's not quite as easy as that as, specifically with REST, you also need to be a bit careful about your service implementation here as you need to arrange for the infrastructure to understand how to map GET, PUT, POST etc. In our 1.x code base on which the book is based you can have you component implementation implement a simple interface to express that mapping or rely on convention.
In out latest 2.x codebase (which isn't fully released yet, we're still in beta) we've added binding.rest and JAX-RS support based on Apache Wink to provide a Java annotation approach to specifying the mapping.
If I want to change for other protocols such as RMI, CORBA, JSONRPC etc I could do that too, e.g
I've changed reference and service configurations somewhat randomly here just to point out that the same flexibility is applicable to both.
Can Tuscany give me a way to define authorization/authentication rules for all components within an application / composite?
SCA defines a policy model which allows you to attach policy at the reference/service, component or composite (effectively the application) level. We have a limited number of polices in Tuscany at the moment. For example, we support basic auth (which isn't hugely useful) and, with binding.ws, we have WS Security support. Authentication needs some work but it's pretty easy to write policy implementations to do whatever you need to.
Does Tuscany allow me to create business-logic transactionality, just like in EJB's? If so, is this transactionality flexible enough so I can use it across different protocols and programming languages?
SCA defines some transactional policies that can be applied. We have to model for this in Tuscany but we don't have the implementation just yet. We were looking at the transaction manager in Apache Geronimo to help us out here. To make it really make sense we should probably be running inside a container that provides these facilities. For example, IBM's WebSphere Application Service uses Tuscany for SCA support an I believe they have transaction support out of the box.
I should add that if you get interested in Tuscany and find things that you want to improve the Project is over at Apache (http://tuscany.apache.org/
) and it's very easy to get involved with the community and make contributions.
Hope that helps