I view SCA as hooey. I read the overview
document over the weekend and I could not differentiate anything in there from
generic SOA + BPM. The concept of the assembly is a concept that is leaning
toward something that would lead to greater componentization of service groups
if done right, but it’s nowhere now. I had a talk with John Evdemon yesterday (co-Chair of BPEL TC) and
V2.0 of BPEL isn’t due until May and not all participants are buying into
IBM’s proprietary extensions for human workflow and executable linking. Additionally,
BPEL won’t support sub-processes, so if Tuscany is based on BPEL as the glue, this
things a long way from reality.
Dave Linthicum and I addressed our views
on SCA in his Podcast yesterday. Check it out www.soaexpertpodcast.com
Raising component models
to a new language- and platform-independent level is extreme goodness. Previous
component models have been tied either to a programming language (e.g.,
Java/J2EE) or to a platform (e.g., COM, .NET). The only exception to this rule
is the CORBA component model (CCM), but I think CORBA's complexity and its
market timing ensured its still-birth experience. (CCM didn't get defined until
after J2EE has taken over the app server market.)
But in reality, SCA is not a component model. The granularity of the
"components" is different from any previous component model. They are
services -- not components. SCA is a services assembly model.
I view SCA as much more competitive with JBI than it is with J2EE. SCA doesn't
define a new model for creating services. The service creation model is outside
its scope. (And you can be sure that IBM and BEA will build their
implementations of SCA so that they fully exploit their J2EE-compatible app
servers for building services.) SCA just requires that services meet some
simple basic requirements, and then it focuses on how you assemble services
into applications and/or business processes. It exploits some of the core
capabilities of the web services framework: standard languages for describe
service interfaces (e.g., WSDL) and the use of intermediaries and interceptors
to enforce policies. This model removes the need for a central hub to manage
and coordinate a distributed application. The "smarts" can be
deployed anywhere along the message path -- including at the endpoints. If the
service has been implemented using a proprietary protocol, then the mapping
between the standard environment and the proprietary environment should be
hidden behind the interface rather than central to the model.
On the other hand, JBI promotes a model in which all messages must be
translated into a canonical form before transformation and routing to its final
destination -- and most JBI-compatible products implement this canonicalization
in a central hub. The transformation and routing is at the center of the model.
My concern with SCA is that it is still very Java-centric. Yes -- a service can
be implemented in any language (e.g., Java, .NET, Ruby, etc.), and the Tuscany project plans to
build an SCA implementation in C++ as well as Java. But the spec defines two
types of interfaces: WSDL and Java. If this model were truly
language-independent, it would not include only one language-specific
interface. IBM explained to me that they needed to provide a Java interface for
performance reasons, so that it could be used from within the portal server to
invoke J2EE components using the same model as it would use to invoke a web
service. Fine -- then provide the same optimized capability to invoke a .NET
component. Or don't pretend that this is really a language-independent
specification.
Anne
ps -- J2EE isn't dead, but the value proposition for the J2EE component models
(JSP, servlets, EJB, MDB, JCA, etc.) has been greatly diminished. I strongly
recommend using Spring/Hibernate (POJO component model) over the J2EE component
models. But that doesn't necessarily diminish the value of JBoss, WebLogic, or
WebSphere. These application servers provide plenty of value-add to the POJO
programming model.
pps -- Ruby rocks! But Ruby is not the right language for all applications.
(The same is true for Python.) Sometimes Java is a better choice. And sometimes
C or Assembler is. Project requirements should always dictate language
selection.
On 12/18/05, jeffrschneider
<[EMAIL PROTECTED]>
wrote:
> JBoss is toast.
> Nope. Still the most prevalent open
source app server.
>
> J2EE is dead.
> For me it was still birth.
If J2EE was still birth, that makes JBoss what? The best instance of
the still births?
> Java is moot.
> That's just crazy talk.
JP - Java hit alpha2 in november of 1995. I know because I quit
my "stable" job to do full time Java consulting that month. Java had
a nice life - and will continue to have a nice life. As languages
mature so does their ability to innovate due to legacy customer
constraints. No big deal - just how things go.
> Long live SCA.
> Why?
SCA cleans up J2EE API mistakes, it binds components and services,
introduces encapsulation for DSL's and provides a uniform data
model. Nothing is perfect, but SCA represents the innovation that
we've seen at the open source level (Spring/IoC/etc.) taken to the
next level and packaged by major vendors, enabling Very Large
customers an easy buy/support model.
> Long live Ruby.
> Now you sound like a zealous
programmer that has no sense of
> reality.
Like I didnt' hear that about Java in 1996 :-)
You can continue to tell your customers to NOT use SCA or Ruby and
to find innovation in JBoss and Java 5.0. Your call.
I will tell my customers to leverage coarse grained services that
are loosely wired together, leveraging a component model containing
domain specific languages. And that they should use the most dynamic
and participative presentation and collaboration framework available
to them, regardless of the language. IMHO, failure to acknowledge
the Ruby advantage and associated movement is a mistake.
Now, many of my customers will not be able to make the
WOA/SOA/SCA/DSL transition anytime soon. That's cool.
JBoss/WebSphere/WebLogic and are just fine for stabilized
environments. More agressive shops will likely look at
Spring/Hybernate/etc. And even more aggressive shops will do
WOA/SOA/SCA/DSL. I.T. shops that do not seek advantage or innovation
will likely not seek change.
I'm glad we agreed on 'peace on earth' and 'good will to men' ;-)
------------------------ Yahoo! Groups Sponsor --------------------~-->
Most low income homes are not online. Make a difference this holiday season!
http://us.click.yahoo.com/5UeCyC/BWHMAA/TtwFAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
YAHOO! GROUPS LINKS
