gembin

OSGi, Eclipse Equinox, ECF, Virgo, Gemini, Apache Felix, Karaf, Aires, Camel, Eclipse RCP

HBase, Hadoop, ZooKeeper, Cassandra

Flex4, AS3, Swiz framework, GraniteDS, BlazeDS etc.

There is nothing that software can't fix. Unfortunately, there is also nothing that software can't completely fuck up. That gap is called talent.

About Me

 

SCA Raining on the JBI Parade?

from http://blogs.sun.com/tombarrett/entry/sca_raining_on_the_jbi

good article for reference!


SCA Raining on the JBI Parade?

Java Business Integration (JBI) is Java's standard for providing an open integration platform.  From the outset in 2004, the main goal has been to provide an open alternative to closed, proprietary approaches that vendors like IBM, webMethods and yes, Sun/SeeBeyond, have been offering.  Without JBI, there is no easy way to rip out a BPEL engine, for example, from an Enterprise Service Bus (ESB) and replace it with a better one from a different vendor.  Sun and the Java Community Process (JCP) wanted “to do for integration what J2EE did for application development.”  The hope has been to encourage an ecosystem that supports plug-and-play for integration components in a SOA world.  This would, in turn, offer customers freedom of choice and combat vendor lock-in.

IBM and BEA Abstain
Right before Java One 2005, the JBI Java Specification Request (JSR 208) came up for final vote.  IBM and BEA, key expert group members, abstained.  IBM commented:
IBM abstains because the JBI specification doesn't represent a sufficient step forward in terms of what we believe our customers need, and above what they can already do. Many technologies and open specifications are available to the Java programmer today with more compelling interoperability and better mechanisms for component composition.
Wow.  That let some big air out of the JBI balloon set for launch at Java One 2005.  Some suspected the beginning of major schism in the JCP that moves the Java platform forward.  Can you imagine what J2EE (now Java EE) would have been like if IBM and BEA had not supported it from the outset? 

Two years have passed and the JCP is still intact.  JBI is moving along nicely without IBM and BEA.  Sun is developing the next major release of Java CAPS (6) atop the JBI specification as implemented in the Open ESB project.   However, enthusiasm for JBI has not ramped up like we saw for J2EE in its early days.  It seems that attention is diverted elsewhere.  That elsewhere is a movement called Service Component Architecture (SCA) spearheaded by IBM and BEA.

What's the SCA Movement?
As JBI is developed and promoted through the JCP, SCA is nurtured through a relatively new group called Open Service Oriented Architecture (OSOA) collaboration.  Their goal is "defining a language-neutral application model that meets the needs of enterprise developers who are developing software that exploits Service Oriented Architecture characteristics and benefits."  Sun joined the group in July of 2006.  OSOA is not a standards body, but coordinates projects like SCA to the point where they can be submitted to a standards group for ratification.  The standards body chosen for SCA is Organization for the Advancement of Structured Information Standards (OASIS ) through its new Open Composite Services Architecture (Open CSA) group.  SCA specifications have begun to be submitted to OASIS.

So, IBM and BEA  rained on the JBI parade in 2005 and have been working on something called SCA.  How important is this?  Is it really a competitor to JBI?  I've asked lots of JBI vs. SCA questions and I have heard:
  • JBI wants to build a standards-based ecosystem around integration and folks like IBM want to protect their proprietary ESB infrastructure.
  • IBM and BEA are tired of Sun controlling the Java community and are seizing SCA to exercise some independence.
  • IBM and BEA both enjoy sizable market share in integration based upon proprietary technology and an open ecosystem might erode their installed base.
  • JBI and SCA are something quite different and really aren't competing technologies. Comparing the two is like considering apples vs. oranges.
  • JBI is a container model for an Enterprise Service Bus (ESB) while SCA is a model on how to assemble composite applications.
  • JBI speaks to infrastructure vendors who will build ESBs and containers like BPEL engines that plug into them while SCA speaks to programmers and architects who want to wire components together to field an application.
  • JBI (as the "J" implies) is targeted solely on the Java platform while SCA is language-independent.
  • JBI is starting at plumbing and taking a bottom-up approach while SCA is starting at the programmer and taking a top-down journey. Hopefully, the two initiatives will meet in the middle without creating too much overlap that will need to be resolved.
  • Eventually the SCA community will see that they need the runtime environment provided by JBI and Sun will embrace the component modeling and assembly work from SCA.  As a result, the JCP rift will be patched up.
All these made sense to me.  Certainly the motivations and general approaches of JBI and SCA are quite different, but I kept wondering if there was something fundamentally different in the architectural principles that drive JBI and SCA.  So, I did what I usually do ... I pondered.  I poked around on the Web and landed on something that feeds my curiosity about architectural underpinnings.  The insight came from an SAP employee's blog post on the SAP Community Network.  The title of Jean-Jacques Dubray's post is "Comparing SCA, Java EE and JBI."

He points out that there are three popular approaches to integration: invocation, mediation and activation and illustrates them like this:

Integration Approaches

Invocation is the most well-travelled road.  JCA (Java Connector Architecture) and JAX-WS (Java API for XML Web Services) serve us well here by providing a request/response message exchange model in particular.  JCA became well-known as the standard technique to extend a Java EE application server via resource adapters to communicate with external systems.  JAX-WS is the follow-on to the popular JAX-RPC which provides a solid solution to generating web services and clients based upon Web Service Description Language (WSDL) or Java interfaces.

Mediation is all about having a message middleman acting as an intermediary between the consumer sending a message and a provider responding to it.  This is where JBI fits.  JBI's Normalized Message Router (NMR) is the mediator and acts as a backplane into which service engines (SE) (like a BPEL engine) and binding components (BC) (like SOAP/HTTP ) plug in.  JBI is a centralized architecture.  The JBI 1.0 specification was focused on providing a container definition for an integration server where the container was assumed to be running in a single JVM. 

Activation is the newest approach.  It seeks to provide an architecture where components hosted on different middleware can interact as first-class citizens.  No centralized mediator is required.  Components in a SOA based upon activation can't rely on any specific middleware features.  SCA is apparently becoming a poster child for the activation approach.

I was particularly interested in Jean-Jacque's comments on disadvantages he sees in the mediation approach.  He says that centralized approaches, like JBI, often lead to the "who is to manage the mediator?" question that has plagued B2B implementations.  In many traditional B2B scenarios,  users are loath to pay for mediation unless substantial value-add services are provided.   Perhaps because Jean-Jacque is from SAP, a SCA supporter, he fires a shot across the JBI bow as he notes that JBI doesn't address mediation beyond JBI container boundaries.  Hence, there's no distributed ESB story.  In his mind, JBI can solve only "small and local" integration challenges.  Zing, ouch.

In contrast, SCA is a shining star for Jean-Jacque.  Because of its activation roots, he touts SCA as more powerful than JCA, JAX-WS or JBI because an SCA application:
  • Has no preconceived notions of system or company boundaries.
  • Requires no centrally managed mediator.
  • Enjoys the benefits of a mediation approach, but it's a decentralized mediation that can happen at either the consumer or provider end with no intermediary in between.
  • Can handle the complex integration challenges that JBI can't because of its mediation architecture.
Well, Jean-Jacques, where does this leave JBI?  He answers:
"We can expect that Java EE and SCA will coexist offering a complementary application model while JBI will be used in traditional Enterprise Application Integration scenario."
In other words, if all you want to do is plain old, boring,  traditional integration work in a Java-focused infrastructure, JBI will serve you well.  However, if you want to tackle more complex, decentralized challenges,  SCA provides a superior basis.  Wow.  That's something more to ponder.

Bottom Line
I think that JCA, JAX-WS, JBI and SCA are all very powerful approaches.  They need to be in every architect's toolkit.  In deciding the right tool for the job, be aware of the appropriate integration approach:
  • The invocation style can server particularly well with request/response.  If the interaction can be handled by the client invoking web service endpoints, JAX-WS can serve well.  If the focus is really about extending the Java EE application server to access an external system and web services aren't necessary, JCA is great.
  • Mediation works well if you are building a composite application where an intermediary needs to be involved in order to bring the appropriate engines together to provide containers for services to execute.  JBI provides an excellent container specification for a framework propulated with service engines and binding components like J2EE did for the web container (servlets and JSPs) and EJB container (stateless, stateful, entity and message-driven EJBs).
  • Activation focuses on enabling composite applications where an intermediary is unnecessary.  SCA is a very visible implementation of the activation approach for SOA.
Of course, the JBI folks and SCA folks may be slow to come together.  Rifts take time to heal.  However, perhaps Jean-Jacques is on to something in his discussion of the three fundamental integration approaches.  As I continue to watch the SCA / JBI discussions, I'll ponder their relative contributions to invocation, mediation and activation.

The better we can make these three work together, the better it is for developers and for the JCP.  JBI enthusiasts and SCA evangelists need to start talking more.  It's OK to say good things about the other guy's technology!   Neither effort will go away.

posted on 2010-03-08 14:14 gembin 阅读(339) 评论(0)  编辑  收藏 所属分类: SOA


只有注册用户登录后才能发表评论。


网站导航:
 

导航

统计

常用链接

留言簿(6)

随笔分类(440)

随笔档案(378)

文章档案(6)

新闻档案(1)

相册

收藏夹(9)

Adobe

Android

AS3

Blog-Links

Build

Design Pattern

Eclipse

Favorite Links

Flickr

Game Dev

HBase

Identity Management

IT resources

JEE

Language

OpenID

OSGi

SOA

Version Control

最新随笔

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜

free counters