You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2006/07/07 19:19:21 UTC
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
Re: ApacheCon EU - Tuscany related blog posts
Posted by haleh mahbod <hm...@gmail.com>.
This would be a useful excercise if we actually respond to the blogs.
On 7/10/06, Raymond Feng <en...@gmail.com> wrote:
>
> 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" <lu...@gmail.com>
> To: "tuscany-dev" <tu...@ws.apache.org>; <lu...@gmail.com>
> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: ApacheCon EU - Tuscany related blog posts
Posted by Raymond Feng <en...@gmail.com>.
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" <lu...@gmail.com>
To: "tuscany-dev" <tu...@ws.apache.org>; <lu...@gmail.com>
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org