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
