Tuesday Sep 23, 2008

OpenESB about to hit a major milestone

Any parent will tell you there are major milestones that you, as a parent, mark in your child's life, like when she gets her first tooth, or first goes off to kindergarten (or college!). These moments can fill you with pride, and excited anticipation for what's next.

It is with similar parental feelings that I can announce that Project OpenESB is about to hit a major milestone in the life of an open-source enterprise software project: a commercially supported version is to be introduced. This indicates the the project is both mature enough and stable enough to be widely "used in anger." After about three years of development, project OpenESB has "grown up" enough to mark this important occasion.

Sun will be introducing a branded version of OpenESB, to be called GlassFish ESB (running atop the GlassFish v2 application server, so the name is quite descriptive). GlassFish ESB is essentially Open ESB (including most of its components), fully supported by Sun, with the 24/7, one-throat-to-choke type of support a lot of enterprises require for key production systems.

I know some OpenESB users have, in the past, requested this kind of support, and some have even gone into production without it, so I've known for quite a while OpenESB was ready for milestone. Congratulations to the whole OpenESB community! You make me proud. And I know this is only the beginning.

Monday Jun 30, 2008

Is JBI an ESB?

Does the JBI standard define an enterprise service bus? In a word, no.

In his book, Enterprise Service Bus, JBI expert group member Dave Chappell presents a very useful model of what an ESB is, and what it does. One of the major features of his model is the service container, a node on the bus where services are provided and consumed. The service container includes integrated applications, of course, presenting them to the bus as services invoked by XML message exchange. In Dave's model JBI is a technology for creating such service containers from standardized pieces (namely the NMR and the plug-in components).

JBI was deliberately crafted to support multiple approaches to building an ESB. This has resulted in some quite different approaches. Some ESBs use multiple JBI instances linked by JMS message queues. Others use multiple replicated JBI instances running together in a cluster, providing in essence a large, highly available and scalable virtual JBI instance. Still others approaches exploit more elaborate ESBs, using JBI to create highly flexible, componentized service containers.

Okay, this is all stuff that was published three years ago, so why am I bothering to write about it today? I have seen recent reports of certain ESB vendors running around claiming that JBI is a terrible ESB, saying things like "the NMR is a single point of failure," and "it is a hub-and-spoke architecture, not a bus". This either reflects a genuine misunderstanding of what JBI is (which seems unlikely after three years), or an attempt to spread self-serving lies and old-fashioned FUD.

So if you are contemplating buying an ESB that supports JBI, please look closely, and educate yourself about the benefits of using open standards, especially in avoiding vendor lock-in. And please, don't take too seriously any "technical advice" about JBI coming from a company that doesn't support JBI. The chances are, they just want to lock you in to their proprietary ESB, and they won't let the truth stand in their way.

Wednesday Apr 11, 2007

Relationship of SCA and JBI

There is an interesting white paper at the OSOA web site entitled "Relationship of SCA and JBI". Given the confusion about this subject in the recent past (which I have commented on), I'm glad to see something that is more informative on this subject, published by the Open SOA collaboration, which includes Sun, IBM, Oracle, SAP, BEA, and others. (Check out the Open SOA site for details.

Some interesting bits:

"Both SCA and JBI are focused on helping developers construct and compose services so it is natural to assume that they are competitors; however, this is not the case. While both can be used separately, they are also effective to use together because they focus on different aspects of the larger service composition problem.

"The reason this is possible is that SCA and JBI target different audiences. The SCA specifications target end users. They describe how to implement, assemble and deploy applications composed from services. As such, the target audience for these specifications is people working in the roles of developer, assembler and deployer respectively."

That pretty well summarizes the situation, as it exists with JBI 1.0. One of the possible outcomes of JSR 312 (JBI 2.0) is an improvement in the alignment between the two technologies. Such an improvement would allow the technologies not only to co-exist (as is the case today), but also would eliminate what small "impedance mismatches" exist in the areas of deployment and metadata.

Tuesday Mar 13, 2007

Open ESB 2.0

It is with considerable pride that I can announce that the open-source JBI project Open ESB 2.0 beta is now available. This release includes a bunch of JBI plug-in components that provide a lot of interesting functionality. This also includes extensive design-time tool support in the form of NetBeans 5.5 modules (including the NetBeans Enterprise Pack).

The list of components that come with this release is impressive:

  • Intelligent Event Processing (IEP) service engine. Very sophisticated business activity monitoring.
  • WS-BPEL 2.0 service engine. Stateful business process automation. Very cool interactive debugging capabilities.
  • Java EE 5 service engine. Two-way integration of Java EE technologies, by means of JAX-WS. Your Java EE assets can provide services to other JBI components, as well as consume services they provide.
  • XSLT service engine. XML transformation.
  • JDBC service engine. Database access via service wrappers. Good for resource-layer services.
  • HTTP binding component. SOAP and REST protocols using a very high throughput HTTP implementation.
  • JMS binding component.
  • File binding component.
  • FTP binding component.
  • MQSeries binding component.
  • SMTP binding component.
In addition there are tools for creating composite applications and administering the ESB; everything you need to create, deploy, monitor and control your SOA.

This release represents a huge contribution to the open-source integration & SOA communities.

Thursday May 11, 2006

JBI takes over Java EE 5!

The Java EE 5 SDK has been released, along with some NetBeans-based tooling. This is the first industrial-strength release of Java EE 5, so this will be of great interest to the EE crowd.

What makes the SDK release really interesting (at least to me) is the integration of Open ESB (Sun's open-source JBI-based Enterprise Service Bus) into the SDK. This really points to the future of Java EE application servers: interoperation between the various EE technologies, using the web services model, enabled by the JBI infrastructure.

Even more interesting is the NetBeans tooling that accompanies this release. This leverages a JBI service engine that executes composite applications using WS-BPEL 2.0, a SOAP-over-HTTP binding component, and the AS9 "Java EE Service Engine", which ties the various Java EE technologies to JBI transparently. Visual editors aid creation of BPEL, WSDL, and XSD documents; tight integration with Open ESB allows you to easily create JBI service assemblies and deploy them to the app server. Multi-language debugging is another great feature. This stuff is a pleasure to play with; check it out!

Wednesday May 10, 2006

JavaOne JBI and Open ESB sessions

It's back.... and a month early, this year. JavaOne in San Francisco starts next week. There are several sessions of note to the JBI and Open ESB communities:
  • TS-2002 Tuesday 3:15 PM. What Is Happening With SOA in Open Source? There are a lot of open-source ESB projects out there, delivering SOA infrastructure. A lot of them support JBI. This should be an interesting discussion of the directions open source and SOA are taking.
  • BOF-0089 Wednesday 9:30 PM. What's Next for JBI? A birds-of-a-feather session on what we should put into JBI 2.0. This one is supposedly booked full, but promises to be very interesting: a true BOF.
  • TS-3175 Thursday 1:30 PM. Building a Service With BPEL and the Java™ EE Platform: How Composite Applications and JBI Simplify SOA Development. Marrying Java EE with SOA painlessly. This includes a really cool demonstration of how JBI integrates Java EE technologies. It features Project GlassFish (AppServer 9), with its built-in JBI support.
  • TS-1076 Thursday 4:00 PM. Practical SOA Business Integration Using OpenESB: A Distributed Java™ Business Integration Composed Services Application How-to and Demo. A "cooking show" showing how you can use Open ESB.
I'm presenting at the Wednesday and Thursday sessions. Stop by and say hi!

Thursday May 04, 2006

Ask The Experts Session on JBI May 10th (10 - 11 AM PDT)

I get to participate in a live web chat, along with other JBI experts and an audience loaded with good questions. Please join us! Sign up here.

It will be held May 10th, 2006, from 10:00 AM - 11:00 AM Pacific daylight time. A transcript will be posted afterwards, for those of you who can't make it.

As they say, good seats are going fast! :-)

Tuesday Apr 25, 2006

Java EE 5 integrated into JBI (or is that the other way around?)

Manisha Umbarje has recently blogged on Java.net about using SOAP over JMS. The really interesting part (to me) was how she did this: by using the built-in JBI service engine in the GlassFish app server.

What's so cool about this? The Java EE technologies involved (from the web container in this case, but others can be used similarly) weren't altered at all (down to the binary level!) to make this happen. That's right: no changes!

Manisha's article has a nice detailed picture of all the moving parts involved in this end-to-end demo (she implements both the consumer and provider sides), but the key takeaway is this: the servlet developer didn't have to do anything different to get SOAP over JMS to work properly. She uses standard web service technologies (JAX-WS et alia) in the normal fashion, without doing anything special to get JBI support. The real work of associating a logical service with a different binding type (in this case, the JMS binding) is accomplished at two levels, beneath the covers:

  • The GlassFish service engine. This bit of internal magic the GlassFish team came up with turns GlassFish web service I/O into JBI normalized messages and message exchanges.
  • The composite application (service assembly in JBI-speak). This is the package that "wires" the services together. In this case, it wires the servlets to the JMS binding components.
The GlassFish service engine works so well because of the pioneering work of Harold Carr, creating the PEPt communications architecture that sits inside GlassFish. Combined with the strong alignment of JBI (and Open ESB) to web services, and you get cool things like the GF SE.

Friday Apr 14, 2006

JBI 2.0

It has been almost a year since we completed JBI 1.0. What do we do for an encore? Do JBI 2.0, of course!

If you are attending JavaOne 2006 in San Francisco, please bring your JBI "wish list" to the following BoF (Birds of a Feather) session:

Session Id: BOF-0089
Session Title: What's Next for Java™ Business Integration (JBI)?
Track: Core Enterprise
Room: Franciscan I
Date: 17-MAY-06
Start Time: 21:30 
If you've been living with JBI 1.0 for the last year, as an implementor, component developer, or application developer, we want to hear from you. We want to make sure that we take JBI 2.0 in directions that are important to the current users of the technology. So bring that wish list, and the beverage of your choice (it will be 9:30 PM, after all!).

Tuesday Feb 07, 2006

Technical: JBI Component Implementation: Using ExchangeStatus

It seems that there is some confusion in the world of JBI component implementors about how the ExchangeStatus of a MessageExchange instance should be used. This usually arises when looking at the ExchangeStatus.ERROR state.

The following code and comments give a basic outline of how a typical JBI component should use the exchange status when accepting a message exchange from its delivery channel, and what the component can assume about the state of the exchange instance. Note that the the component's role (as either consumer or provider) is important in determining what conditions hold, especially in when the instance's status is ERROR.

/\*\*
 \* Process an accepted message exchange instance. An instance received by this
 \* component can be sent by a component that is consuming a service that this
 \* component is offering, or send by a service provider component that this component
 \* is consuming.
 \*
 \* @param me the MessageExchange instance sent to this component by the NMR
 \* 
 \*/
void processAcceptedMessageExchange(MessageExchange me)
{
    if (me.getStatus() == ExchangeStatus.ACTIVE)
    {
        // next step in the ping-pong game
    }
    else if (me.getStatus() == ExchangeStatus.DONE)
    {
        // The game is over; the partner component
        // is closing the MEP, and so should I.
        // For the following MEPs the following are true:
        //
        // Pattern  me.getRole() me Invariant
        // -------  ------       ------------
        // In       CONSUMER     getInMessage() != null && getError() == null
        // In-out   PROVIDER     getInMessage() != null && 
        //                       (getOutMessage() != null xor getFaultMessage() != null) &&
        //                       getError() == null
        //
        // (the patterns with optional responses are
        // more complex.)
    }
    else if (me.getStatus() == ExchangeStatus.ERROR)
    {
        // The game is over; the partner component 
        // is abruptly closing the MEP, and so should I.
        // The only ME property I can count on is 
        // me.getError(). Other ME properties will reflect
        // the on-going state of the exchange before it
        // was ending by the partner abruptly.
        //
        // Pattern  me.getRole() me Invariant
        // -------  ------------ ------------
        // In       CONSUMER     getError() != null && getInMessage() != null
        // In-out   PROVIDER     getInMessage() != null && getError != null &&
        //                       (getOutMessage() != null xor getFaultMessage() != null )
        // In-out   CONSUMER     getInMessage() != null && getError() != null &&
        //                       (getOutMessage() == null || getFaultMessage() == null)
    }
}
Notice that the invariants change in the ERROR case for the In-out exchange, depending on the role of the receiving component.

This gets more complex looking when we add in the robust-in-only and in-optional-out message exchange patterns, but the basic processing pattern remains the same.

This information isn't new: it's all in the JBI specification, but is scattered in several places, so it is understandable that the role of MessageExchange.getStatus() gets overlooked. This actually works well in the so-called "happy path" for In-only and In-Out MEPs, but becomes problematic in the ERROR case or when dealing with the MEPs that have optional exchanges in their patterns.

Thursday Jul 14, 2005

Clues for Don Box?

Judging from some recent blogs, some folks are getting lost in the details of the JBI specification, and not seeing "the forest for the trees." This is understandable -- we are used to most JSRs being focussed on very narrow technical domains. However, this isn't true of JBI.

When I explain JBI to people, I usually start a statement like "JBI is a meta-container" or "JBI is a container of containers." This is an extremely important architectural point that must not be ignored in the urge to get the "meat" of the API's and SPI's that are defined. Why is this so important?

A JBI plug-in is typically a container of some sort. A familiar example is a EJB container. Others include BPEL engines, transformation engines, and, of course, bindings to various protocols. The point of the meta-container concept is to allow these various specialized (concrete, if you will) containers to interoperate. Let me say that again: JBI allows plug-in containers to interoperate.

Pause and think about that for a moment. The JCP has been very good at defining many Java-based technologies, including several very important container types. Getting those containers to interoperate has required "hard coded" provisions within the container specifications, and appserver implementations are usually very messy as a consequence of this. As a thought experiment, try imagining adding one more container type to the J2EE suite. Adding it as a standalone container would be easy; getting it to interoperate with existing containers would be no mean feat. Getting the N plus 1th container type to interoperate with the previously defined N container types would likely require N separate "connections" to achieve interoperation. Ugly, not scalable, and very brittle.

This type of interoperation problem isn't unique to Java EE, or Java at all. We in the integration community know this problem intimately. The solution is to be found in architecture. A service-oriented approach (with a distinct WS flavour) is the architecture that JBI defines to achieve interoperability between plug-in containers.

That takes me to the second point I usually make when explaining JBI: don't look on the JBI API's and SPI's as something you will use in your application. For the vast majority of users, JBI will simply be a framework that will be used to host a set of containers that will provide the functions needed by the user. The user will be using things like BPEL, XSLT, and SOAP, and will deal only with BPEL processes, XSLT style sheets, and WSDL definitions. The only points where JBI will become visible are a) knowing that you need to assemble the right JBI components to provide the types of functions you need, and b) having a centralized administrative capability, allowing you to administer these separate containers together.

So let's conduct that thought experiment again, where we added a new container type, but this time let's use JBI. What are the effects of adding a new (plug-in) container to a system with pre-existing containers? None. Nothing. The plug-ins are loosely coupled, meaning that we don't have to change the existing container components to accommodate a new container type. Much better!

This inter-container interoperability is more than a technically meritorious achievement. This has many implications for the marketplace, but that is a separate topic.

JBI 1.0 is Final!

After over two years of great effort, I am pleased to announce that Java(TM) Business Integration 1.0 is final! This means that the specification, along with the reference implementation (RI) and technology compatibility kit (TCK), have been accepted by the JBI expert group and the Java Community Process executive committee for Java SE/EE. You can find the final spec and RI at Sun. (The TCK, as usual in the Java world, must be licensed separately.)

We timed the completion of JBI 1.0 to occur just before JavaOne, which is always the best time to introduce a new technology to the Java community. Peter (my co-spec lead) and I gave a talk about JBI at JavaOne. In addition, there were several other talks related to service-oriented architecture (SOA) and JBI.

Interestingly, our session on JBI (subtitled "A Foundation for SOA") was the best attended technical session of the entire JavaOne 2005 conference. We even did a repeat session to accommodate the overflow from our original talk. Obviously the attendees felt that JBI was something important.

Personally, I'm gratified at the huge reception JBI got at JavaOne. The open-source community is also embracing JBI wholeheartedly. See servicemix.org, celtix.org, and Java.net for examples.

Judging from some of the blog traffic related to JBI, I'm sure that not everyone yet \*gets\* what JBI is all about; certainly the implications of such a standard are just starting to be understood by the community outside of the JBI expert group. I will attempt to answer some of the questions being raised in future blogs.

Tuesday Mar 08, 2005

JBI's new messaging model

The new public review draft of the JBI 1.0 specification is now available. This version introduces an important change to the JBI messaging model.

The previous Early Draft Review (EDR) version of the specification placed bindings (protocol handlers) and engines (internal service providers) into distinct roles. This has been significantly revised, to the better.

Rather than architecturally distinct bindings and engines, we now have JBI components, which serve as service providers, service consumers, or both. For example, an XSLT engine provides XML transformation services, while an inbound-only binding component serves as a (proxy) service consumer. A BPEL engine serves as a service provider (through its receive nodes), and consumer (invoke nodes).

These changes simplify the JBI APIs, eliminate the local binding component, and enable direct engine-to-engine and binding-to-binding service invocation.

I invite you to read the new draft of the Java(TM) Business Integration, available at the JCP. The major change I've outlined above, but there are numerous improvements, plus JavaDocs for all of the defined APIs. Please send your comments to jsr-208-comments@jcp.org.

Friday Oct 29, 2004

JBI and BPEL in competition? Nonsense!

It has been recently reported in various news stories that some folks in the community regard JBI and WS-BPEL to be competing standards. This is pure nonsense!

I'm co-spec lead on JBI, and have been a member of the WS-BPEL technical committee at OASIS since the TC was formed in 2003. JBI has been carefully designed to support BPEL, so any claims of "overlap" are either false, or indicate that the JBI expert group isn't achieving its goals.

JBI is centred on abstract WSDL message exchange patterns. Normalized messages, exchanged via WSDL-defined operations, provide the mechanism for interoperation of components. Service engines provide and consume services at the abstract, portType level, to use WSDL 1.1 terminology. Guess what? This exactly fits the definition of WS-BPEL -- it too provides and consumes services using the abstract, portType level of WSDL. No coincidence here: this is by design.

Of course, WS-BPEL doesn't provide a complete solution to business process execution. It defines the process in terms of abstract messaging, but implementations must provide the "plumbing" to add real communication protocols (like SOAP over HTTP) into the mix. This is readily accomplished using JBI's binding components, but of course proprietary approaches are also possible.

JBI is all about breaking vendor lock-in. By using a standards-based infrastructure, end users can mix and match components to provide the needed services and bindings to create solutions that match their unique needs. Some vendors apparently object to this -- they much prefer current practice, which locks the user in to the vendor, due to the proprietary nature of their solutions. In this sense, JBI is in competition with BPEL -- closed implementations of BPEL designed to perpetuate vendor lock-in in business integration.

Monday Jul 12, 2004

Enterprise Service Bus (ESB)

At JavaOne last month, I was fortunate to receive an invitation to Dave (Sonic) Chappell's launch party for his latest book, entitled Enterprise Service Bus. I spent last week at the beach, recovering from JavaOne, and took time out from digging in the sand to read ESB. This book should be required reading for anyone involved with EAI, especially integration architects.

For those of you who may not have heard about ESB, it is a rather new approach to structuring a SOA (service-oriented architecture), using a distributed MOM infrastructure, XML messages, intelligent message routing, automatic transformation of messages, and centralized administration. The SOA approach to EAI solutions is compelling, and the alignment with JBI is clear, but it is still too early in the game to tell if ESB will take the world by storm. It has a lot of promise, and many EAI vendors are jumping onto the bandwagon that Sonic, including Dave Chappell, helped to build.

The books offers the first comprehensive definition of an ESB that I have seen, almost entirely stripped bare of vendor-specific information and sales info. I say almost, for some issues (such as app-servers vs. ESB service containers) are presented in a less vendor neutral fashion than I would like.[1] Overall, the book stays high on useful content, and low on vendor product positioning.

The books combines nicely described technical descriptions of ESB features with some high-level case studies culled from Dave's experiences in industry, or based on interviews of IT leaders that he conducted while researching the book.

The technical descriptions avoid becoming too detailed, but are sufficient to capture the essential issues encountered in integration. The diagrams, resembling Gregor-grams, are very useful, although I was a bit mystified to find a reference card for the glyphs used, tucked away in the back of the book. The diagrams are self-explanatory, IMHO.

The case studies are similarly abstract, avoiding introducing a level of detail that would cause the forest to be lost amongst the trees. At times I wished to a little more detail here, but I suspect I'm something of a glutton for punishment that way.

ESB is threatening to become something of a buzz word these days, what with IBM weighing into the ESB market. This book should help secure a rational, useful definition of Enterprise Service Bus before the marketing machines of the various integration vendors obliterate it in a storm of white papers and glossy brochures.


[1] Of course, I work for a major appserver vendor, so I may be exhibiting extra sensitivity in this arena.
About

rtenhove

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today