• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Tuscany SCA - newbie questions

 
Ranch Hand
Posts: 623
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A big fat 'Howdy' to the whole Tuscany SCA in Action squad :-)

I am a real newbie in SCA and Tuscany, but after reading the introduction to your book, I must say it seems to be very interesting and somewhat sounds similar to the CORBA. Well, at least the main idea of connecting services (components) written in different languages.

In our company, we use a lot of small programs which are developed in a variety of technologies - Java, PHP, C# - and using different tools - OSGi, Spring, PHPLite, SmartGWT, etc.
The point is that the integration of these programs are based on SOAP Web Services. It is not unusual, in our case, to see a dedicated layer or even a separate software, which purpose is just to integrate few others. It's because the integration logic is just too complex...

It seems that Tuscany could help us to manage such a variety of programs/services.
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?
So, when I write a service I don't have to know what protocol will it use? 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?

What about the other way around. If I had developed a service and used a Tuscany SCA to describe it, let's say using a RMI connection, and than wanted to change it to the SOAP WS - do I have just to change the part in XML file (that right now says it's a WS binding) and that's it? Will Tuscany generate a proper WSDL for me so I can just implement the client part? If so, does it use some well known way of generating WSDL's (like Axis?)

Can Tuscany give me a way to define authorization/authentication rules for all components within an application / composite?

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?

Thanks in advance for the answers :-)

Cheers!
 
author
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

 
author
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Piotr Nowicki
Ranch Hand
Posts: 623
1
IntelliJ IDE Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you very much guys for such precise and easy-to-read answers!

I'm really shocked and eager to start some example projects with Tuscany.
It's flexibility and -- most important in my case -- separation of integration logic from business logic, is a great thing. Will totally tell about it to my colleagues :-)

Cheers!
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic