Simon Laws

Congratulations folks. Great questions by the way!

Simon

Sebastien and Luciano (who both work in the Tuscany community) presented on it at Java one last year. You can get the slides via Sebastien's blog...

http://jsdelfino.blogspot.com/2010/10/javaone-2010-developing-composite.html

Regards

Simon

Hi

The idea is that SCA is complementary to other technologies rather than being a replacement for them. Take your BPEL example. If I want to orchestrate distributed services over WSDL defined interfaces then BPEL is a good solution. If you want to drive services over other communications protocols with BPEL then it becomes a bit more tricky. Create an SCA component with the BPEL process though and you have the service and reference flexibility to use a variety of bindings with that BPEL process. You can then use you BPEL process to orchestrate components over RMI, CORBA, JSONRPC etc.

You could do similar mediation with your favourite ESB also. SCA doesn't preclude this. What SCA does add though is a model of the wider connected application using an OASIS specified (not quite a stand yet but getting there) assembly model.

Simon

Hi there

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)

<composite>
<component name="SomeService">
<implementation.java class="my.package.SomeServiceImpl"/>
<service name="SomeService">
<binding.ws/>
</service>
<reference name="someReference">
<binding.ws uri="http://my.server/my/service/address"/>
</reference>
<component>
<composite>

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


<service name="SomeService">
<binding.atom/>
</service>


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

<service name="SomeService">
<binding.corba/>
</service>

<service name="SomeService">
<binding.rmi/>
</service>

<reference name="someReference">
<binding.jsonrpc uri="http://my.server/my/service/address"/>
</reference>

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

Simon

Hi

Good questions.

1. Is SCA the same as SOA? If not, what exactly the differentiating factors?

For me they are not one and the same. SOA describes architectural patterns for building distributed systems from services. SCA describes and XML based programming model for describing components, the services they provide and how can be connected to other components. It does this independently of technology by allowing you to build components using your favourite language and connected them using your favourite binding technology. It just so happens that using SCA you can build systems that exploit the same architectural patterns that SOA recommends.

2. What is the core concept behind SCA?

The core concept is the SCA assembly model. An XML model that describes components and the way that they are connected. A quick example of this XML is probably the easiest way to describe it. Take the Payment composite from the book example;

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://tuscanyscatours.com/"
name="payment">

<component name="Payment">
<implementation.java class="com.tuscanyscatours.payment.impl.PaymentImpl" />
<service name="Payment">
<binding.ws uri="http://localhost:8081/Payment" />
<binding.sca />
</service>
<reference name="customerRegistry" target="CustomerRegistry" />
<reference name="creditCardPayment">
<binding.ws uri="http://localhost:8082/CreditCardPayment" />
</reference>
<reference name="emailGateway" target="EmailGateway" />
<property name="transactionFee">0.02</property>
</component>

<component name="CustomerRegistry">
<implementation.java class="com.tuscanyscatours.customer.impl.CustomerRegistryImpl" />
</component>

<component name="EmailGateway">
<implementation.java class="com.tuscanyscatours.emailgateway.impl.EmailGatewayImpl" />
</component>

</composite>

We've defined three components "Payment", "CustomerRegistry", "EmailGateway". Note that the components are implemented with Java classes using implementation.java in this case. This can be replaced with other implementation types, for example,

<component name="Payment">
<implementation.spring location="Payment-context.xml"/>

or

<component name="Payment">
<t:implementation.script script="payment/PaymentImpl.py"/>

or

<component name="Payment">
<implementation.bpel process="pp:Payment"/>

etc.

Note that the Payment component described service and references. Services are what other components connect to. References are how you connect to other components.

We use binding.ws in the service and in the "creditCardPayment" reference. This is saying that you want web services for the service and for that reference. If you want to use other protocols instead you just change these binding elements.

The property element is a way for configuring the component.

Regardless of which implementation type you use this approach to defining services and references and properties remains constant and hence we've disconnected the way that you build the business logic of a component from the way that components are joined together.

So you take this XML and fire it into Tuscany, along with the required resources such as the Java classes being used to implement the components, and Tuscany creates the components and makes the services available for you without you having to code web services apis (in this case).

3. Looks like the definition/introduction on SCA in the manning website (on your book) is resembling Cloud Computing. Is there any relationship between these two?

We've certainly started to look at making that the case. Imagine you want to build a cloud application. E.g. multiple components that are going to interact out there on some virtual infrastructure. Wouldn't it be good if there was some abstract description of the application that you could provide to the cloud infrastructure that tells is what to run. Sounds a bit like the assembly model. We've had a go at running Tuscany apps on various cloud infrastructures. I can point you at more info it you want to look in more detail.

4. Is there any speciality or meaning in the name being chosen as Tuscany?

It was chose before my time but I'm guessing that someone liked Italy so they found a place name with "sca" in the middle of it.

Simon

Well I would probably agree that the term SOA is not used as much as it used to be but I would argue that the problems remain the same and are probably more prevalent now than when the term SOA was first coined.

From the referenced article “Service-orientation is a prerequisite for rapid integration of data and business processes; it enables situational development models, such as mashups; and it’s the foundational architecture for SaaS and cloud computing.”.

The ability to define services and connect and re-connect them remains key to building systems that are able to keep pace with the way businesses change these days. This requirement is independent of what technology is actually used to build them. You may be a web service fan and build you services using SOAP/HTTP. Alternatively you may prefer a REST based approach. In the end you're trying to get the job done.

I was attracted to SCA, and hence Tuscany, because it doesn’t describe new communication protocols or implementation languages. We probably have enough of those already. It simply exploits those that already exist and provides a model for describing services and the connections between them.

We’ve found that this simple model is surprisingly flexibly from describing how BPEL processes are connected to the services they orchestrate through to describing the connections between Javascript clients and the back end services they refer to. So while the term SOA may be used less I don’t think this will has an impact on the usefulness of SCA or Tuscany. What it will do is make at look at how we extend the project to include new approaches like cloud.

Simon

Hi Jeanne/everyone, thanks for the welcome.

Simon