Hi Tuscany Comunity Doing a quick google search for "apachecon tuscany" I have found couple blog posts from people that attended ApacheCon EU and had posted their impressions about Tuscnay (not necessarly in a good way). I think we should all be aware of these posts. We should also reflect around the issues raised and identify witch ones are only misunderstanding (and try to clarify these misunderstandings on next presentations or in our website/blog) or consider the other issues and thinking on what ways we can improve Tuscany and how it's viewed on the development comunity.
Fergal Somers wrote in his dinkatron blog<http://www.dinkatron.com/blog/2006/06/apachcon-europe06-apache-tuscany.html> : http://www.dinkatron.com/blog/2006/06/apachcon-europe06-apache-tuscany.html Now here are the things I don't particularly like: - It allows components to be wired together from any language - directly. Is this going to work very well? Well okay maybe for scripting languages running on a VM and for the exchange of simple structures and types it's okay. We already have an language for interchanging information between languages/platforms and systems. It's called XML. But if the components are going to be wired together then each of these components operations and parameters must be describable in each of the components languages. We have a standard for this too - it's called WSDL. But SCA doesn't define it like this. There's some sort of magic language-to-language binding to be done for wiring components together. I say magic, cos the spec doesn't say anything about it - presumably Apache Tuscany is working this out. - It has nothing to say about deployment. For a language which is being aimed at tools (see STP project in Eclipse) this is a bit weird. I may want to design a new SOA system as an assembly of connected Web Services at design time and then deploy them to one server, or multiple servers. But SCA has nothing to say about this - yet. - The SCA specification is not open. You cannot see the current draft and meeting minutes are not open. But Apache is implementing it and presumably getting some kind of priority access given that some of it's contributors companies are members of the specification body. John O'shea wrote in his Aehso's output blog <http://www.xlml.com/aehso/2006/06/30/apachecon-europe-summary/>: Apache Tuscany <http://incubator.apache.org/tuscany/> work is ongoing and I bet it will be for some time yet! I'm not certain of their claim that it will simplify the development of business solutions, if only because it is based on SCA<http://www-128.ibm.com/developerworks/library/specification/ws-sca/>which is turning into an absolute beast of a set of specifications - think "one spec to rule them all" type big, and with big specifications comes complexity, not simplification. From an implementation point of view, a huge problem is that the SCA specifications do not have either a reference implementation nor a compatibility test suite and according to Simon Nash and Jeremy Boynes (both of IBM) there are no current plans to develop either. Also it seems curious that the SCA specifications are not being developed under the auspices of an open body like OASIS, W3C or the OMG - why not? Some would say the overall approach seems incredibly vulnerable to repeat the mistakes of CORBA<http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=396>. It will also be interesting to see if any convincing response is given to Ron Ten-Hove's recent critique of SCA<http://blogs.sun.com/roller/page/rtenhove?entry=what_s_wrong_with_sca> . Also, following the link from John O'shea's blog post, here is the comments given by Ron Ten-Hove's<http://blogs.sun.com/roller/page/rtenhove?entry=what_s_wrong_with_sca> *What's wrong with SCA?* I've been examining the Service Component Architecture (SCA) Specification<http://www-128.ibm.com/developerworks/library/specification/ws-sca/>version 0.9 for a while now. The more I look at it, the less I like it. I have a couple of major reasons: it is too complicated, and it is a very poor approach to creating a service-oriented architecture. SCA is trying to fill an important hole: how do we create service-based composite applications? At first glance, SCA's model-based approach looks promising. Closer examination reveals something more akin to a pig with lipstick on. Less colourfully, most of SCA's problems lie in its muddied definition of what a *service*. In SCA a service is anything with an interface of some sort. That can be annotated POJOs, C++ code with metadata, WSDL, even COBOL (theoretically). The idea is to support multi-language composition. What SCA delivers is not the ability to MIX languages, but the ability to use separate languages within the same model. There is no support for, say, having my Java code call my C++ code. SCA provides no ability to cross language boundaries; you have to manage that yourself. Interoperability isn't supported, except within a single language/interface type. The title *Service Component Architecture* is quite misleading: this isn't about services at all. This is just yet another *software* component model, whose claim to fame is an attempt to define a *similar* component model for *disimilar* lanaguages. SCA does start to approach some level of service-orientation with its support for the WSDL interface type, but there is no bridge between WSDL and the other languages, leaving a huge disconnect. (SDO is advocated by SCA to address the data representation issues involved in interoperation, but this is a) only part of the solution, and b) optional.) Looking at this from an architectural perspective, the SCA model restricts reuse of so-called services, increases overall cost of overship, and represents an extremely poor integration strategy: - *Limits reuse.* Making a service a language-specific construct couples consumers and providers at a fundamental level: implementation language. Reuse is limited to consumers written in that language, and usually running in the same address space. Close-coupled components lead to limited reuse. - *Raises TCO.* Every time you need to bridge the gap between incompatible languages/interface types (the so-called services), you incur a cost. Support multiple languages guarantees you'll waste a lot of time & money building new bridges between them. - *Poor Integration Strategy.*With every added language/interface type in an SCA environment, you need to start building bridges between them to achieve interoperability. This is okay if you have only two or three language types, but scales badly as you add more: adding an (N+1)th language type potentially requires up to N bridges for the existing language/interface types. Worse yet, the consumers may be forced to provide such bridges, substantially raising their number & cost. The best strategy for scalable, managable integration is to standardize on a single, implementation neutral interoperation technology, such as web services. Consumers and providers are decoupled from each other; their implementation languages are irrelevant. Adding a new provider (or adapting a legacy app) simply involves adapting it to web services. You build one bridge, not N. Consumers are ready to use the service. This really comes down to how you structure your SOA. The SCA approach doesn't lead to SOA, for it doesn't even know what services are, its name not withstanding. SCA defines a jumble of tightly-coupled components (but multi-language!), and alarming gaps between components because interoperability isn't at the core of the model. SCA isn't a way to define a SOA: it is just another software component model. Give enough time, money, and consultants you could probably use SCA to realize a SOA, but SCA itself would be of little assistance along the way. Finally, SCA is a poor choice if you are vested in Java, especially Java EE. SCA collides rather badly with technologies like JSR-181 JAX-WS, and EJB 3. At best SCA creates a more confusing story for Java developers; at worst it mandates a certain amount of rip-and-replace to fit into the SCA model & metadata requirements. This really forces the question: is this necessary? Unless someone can demonstrate why such pain would be worth enduring (and paying for!), I'd say the answer is a resounding NO. Enough complaining. How do we fix SCA? For starters, throw out the multi-language/interface support. Cute idea, but very bad in practice. Instead, embrace only WSDL interfaces. This should get rid of about 80-90% of the junk in the spec. This leaves us with a much cleaner model for creating composite applications. What are left with, beyond the simple compositional model, is the concept of "smart wires", the links between consumers and providers than have non-functional policies such as security, and some functional ones such as session-based affinities, to play with. Those "smart wires" are probably more interesting as operational features than design features, for the most part. If we leave them out, we have something that looks like a simple services composition model that features a kind of fractal aggragation pattern. That could be quite useful at design time. (Update: see more about SCA in part 2, "What's right with SCA"<http://blogs.sun.com/roller/page/rtenhove?entry=what_s_right_with_sca>.) -- Regards Luciano Resende
