Hi,
I suggest that we maintain a list of related blogs/articles commenting on
SCA/Tuscany (@wiki?). The following links together with Luciano's post can
be a starting point.
Thanks,
Raymond
SCA
http://www.davidchappell.com/blog/2006/04/why-service-component-architecture-is
http://blogs.sun.com/roller/page/rtenhove?entry=what_s_wrong_with_sca
SCA vs. JBI (Tuscany vs. ServiceMix)
http://www.infoq.com/news/JBI-Spec-Lead-Criticizes-SCA
http://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2824
http://docs.codehaus.org/display/SM/How+does+ServiceMix+compare+to+Tuscany+or+SCA
http://www.codefutures.com/weblog/corporate/archives/2006/04/forrester_on_sdo_sca_versus_jbi.html
SCA vs. Spring
<cannot find a good one>
SCA vs. Microsoft WCF
http://www.davidchappell.com/HTML_email/Opinari_No15_12_05.html
SCA vs. JAX-WS:
http://dev2dev.bea.com/blog/mrowley/archive/2006/01/sca_vs_jaxws_1.html
----- Original Message -----
From: "Luciano Resende" <[EMAIL PROTECTED]>
To: "tuscany-dev" <[email protected]>; <[EMAIL PROTECTED]>
Sent: Friday, July 07, 2006 10:19 AM
Subject: ApacheCon EU - Tuscany related blog posts
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
