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:

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 at 09:43AM Feb 11, 2008 by Tom Barrett in Personal  |  Comments[3]

Riding the Web Browser Horse a Little Further

The Pondering Began

A couple years ago, I decided that we just couldn't ride the web browser horse any further. I remembered how sexy the user interfaces were in the PowerBuilder-powered client/server days (daze?) and how HTML widgets dumbed down the interfaces with the onset of web application mania.

Wishing for the Old Client/Server UIs

The gap between the quality of user interfaces we needed and the HTML-based web pages we could create was just too big. Due mainly to browser inconsistencies, applets flopped and JavaScript was tricky. It was clear to me that the future was way cool Java Swing-based user interfaces loaded on-the-fly to the desktop by Java Web Start. The super rich APIs of Swing (and Java 2D) could allow us to do anything. Java Web Start could cache the application on the client and make it available from a desktop icon or a Start menu entry. Perfect.

Java Swing Too Difficult

That personal vision didn't last too long as I pondered just how challenging the Swing APIs were. This was before Project Matisse gave us GroupLayout and a first-class GUI builder in NetBeans. Web developers weren't necessarily hard-core programmers. Java Swing, perhaps even with tools like Matisse, was just out of reach for the masses.

Flash, the Answer?

If Java Swing and Java Web Start weren't going to get us back to the rich client/server style user interface experiences, what was? Flash? Maybe. Since it's launch in 1996, it had sure attracted a huge following. The Flash player runtime had become even more pervasive than the Java runtime on desktops around the world. Macromedia (acquired by Adobe) had developed some nifty tools targeted at web developers. There was a lot of excitement and some pretty killer web sites sporting Flash technology.

AJAX, a Better Way?

I just couldn't buy into Flash though. My open standards / no vendor lock-in DNA just wouldn't allow it. This Flash stuff struck me as a proprietary offering and a direct competitor to Java. Did we have a response in the Java community? Nope, not yet. What could I do until Java responded?

The answer came with AJAX. AJAX has provided some sanity in using JavaScript on the client. Developers don't need to be JavaScript gurus and debug their code on all browsers. AJAX provides the asynchronous capabilities that traditional HTML-based interfaces lacked. Packaged widgets from outfits like Dojo, Prototype, and Google Web Toolkit, have proliferated and I have fallen in love with jMaki as a way to wrap widgets from multiple sources to make it easy to build sophisticated applications. The jMaki plug-in and NetBeans 6.0 tooling are really sweet. I can quickly develop interactive user interfaces delivered via HTML and JSP pages.

AJAX isn't THE Answer

As great as this current AJAX excitement is, I think we will still wear out that old web browser horse. End user demands will exceed what AJAX can do for us in HTML and JSP pages. Both Adobe and Microsoft see it. The Flash / Flex (now Adobe AIR) locomotive isn't slowing down. Microsoft has entered the fray with Silverlight. However, my open standards / no vendor lock-in DNA won't let me accept Silverlight any easier than what Flash has morphed into.

JavaFX Script: Now We're Talkin'

So, what's my current best hope? It's JavaFX Script! It's a special-purpose scripting language that Sun announced at Java One 2007 that provides a declarative programming approach to generating very sophisticated user interfaces that utilize the rich Java Swing and Java 2D APIs. Although we have been demonstrating it in interpretive mode running outside the browser, we will soon have a compiled environment that can run inside the browser JVM.

I won't quit messing with AJAX, but I am closely watching the development of JavaFX Script. I hope you will too. I'll write more about JavaFX Script in future posts.

Posted at 11:26AM Jan 29, 2008 by Tom Barrett in Personal  |  Comments[1]

Role of the ESB

I have been laser-focused for well over a year on the role of the Enterprise Service Bus (ESB). That's the part of Java CAPS that interests me most and I am infatuated with the work going on under the Java Business Integration(JBI) specification in the Open ESB community.

It has seemed to me that the ESB encompassed everything, that it was the umbrella under which everything else interesting was going on. JBI's normalized message router, service engines and binding components are exciting. Building composite applications with NetBeans to deploy to Open ESB as service assemblies composed of service units is just plain fun.

However, it occurred to me a couple weeks ago that there is an architectural perspective well outside and above this ESB world and that I ought to be studying and appreciating it more. The awakening was provided by Mark Hapner, a Sun Distinguished Engineer. We are on the agenda at a developer conference this month and he will give the keynote right ahead of me on the agenda. My topic, of course, is ESB. I needed to understand where Mark will leave the audience when he sits down and I stand up. So, through several phone and email dialogs, Mark educated me a bit on the world outside my ESB.

Covering that education in full is the stuff of multiple blog postings. However, one key epiphany I had was that in contrast to what I read about ESBs as massively distributed, uber information buses, I should remember that my JBI-based ESB has a relatively small, well-scoped role. In fact, it may be far more plausible to view ESBs, in general, as localized middleware that just make it easier for developers to field composite applications. Perhaps all this "ESB as distributed, uber information bus" is just pho0ey?

The JBI 1.0 (JSR 208) spec is clear that JBI is a meta container specification for integration. JBI is to do for integration what J2EE (now Java EE) did for application development. Java EE gave us containers (web and EJB) and an assembly model (JSPs, servlets and EJBs configured declaratively via deployment descriptors and packaged into wars, ejb jars, and ears). JBI gives us containers (service engines, binding components) and an assembly model (service units and service assemblies). Both Java EE and JBI establish a standard that combat vendor lock-in by fostering open ecosystems.

So, instead of seeing the ESB vista as huge, distributed information buses spanning many hosts on many subnets, I am scaling back to realize that an ESB is just to be a local meta container (like Java EE app servers are) where programmers can more easily bring technologies together (BPEL, XSLT, rules engines, Java EE, SOAP/HTTP, JMS, AS2, ...) and field composite applications. These applications run atop a particular host housing supporting middleware. For Java EE, the supporting middleware is a Java EE-compliant application server. For JBI, the supporting middleware is a JBI-compliant infrastructure like Open ESB (and soon ... Java CAPS 5.2).

So, I'll be more realistic about ESBs in general and truer to the JBI spec and realize that my Open ESB runtime is for my composite apps what my application server is for my Java EE apps.

In the spirit of "a picture is worth a thousand words," I'll close with one that has helped me. You want a distributed JBI ESB? You know each JBI ESB runs in its own JVM, right? Just link them up somehow. How about good old message-oriented middleware? No problem, here you go:

Posted at 02:07PM Jan 19, 2008 by Tom Barrett in Personal  |  Comments[0]