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/
SPONSORED LINKS
| Service-oriented architecture | Computer monitoring software | Computer and internet software |
| Free computer monitoring software |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
