 |
|
 |
 |
|
|
 
Gregg Sporar's BlogUnderstanding JBI and Open ESBPosted by gsporar on February 19, 2007 at 07:50 PM | Comments (7)Okay, so I'm kind of behind the times. This seems to happen to me quite often - I just recently upgraded from 8-track tapes to cassettes. :-) In the case of the Java Business Integration (JBI) specification, it was one of those things I kept intending to investigate more closely but other things always seemed to take up my time. The other factor is that I have never been much of an integration kind of a guy. I have worked on many different types of software during my career, but enterprise integration is not something with which I have much experience. In the applications I have worked on that exchanged data with a central system it tended to be a silo approach: pull out what you need and then in some cases write back a specific end result. So there are a whole host of problems in enterprise environments that I have read about, but have not had the responsibility for solving. But in preparation for a workshop that I attended, I decided to learn a bit more about JBI. I went out onto java.sun.com and looked around. Surprisingly, there's not much out there (but I later found some good stuff here). There are some "take 10" presentations but I was looking for a white paper type document that I could read on an airplane. I didn't see one, but it turns out the specification itself fits the bill pretty well. The first four chapters are very user friendly. I also skimmed over chapter five. From what I can tell the remainder of the document is only required reading if you plan to implement a service engine or a binding component, so I did not print them out. And that gets to the key point: the vast majority of folks will never implement a service engine or a binding component. A fitting analogy comes from the world of Java EE: most developers create servlets, JSPs, EJBs, etc. not the web and application containers that provide a runtime environment for those servlets, JSPs, EJBs, etc. But I am getting ahead of the story. I like to approach these sorts of things from the perspective of: What problem does this solve? In other words, if JBI is the answer, what was the question? To me the key to understanding all this is to focus on the 'I' in JBI: Integration. For many years now our industry has come up with solutions for integrating applications and exchanging the data that those applications process. Frequently those solutions involve custom-crafted internal code and/or reliance on a single vendor's commercial solution. A better approach would be an industry standard for integration services. The goal of JBI is to provide that industry standard for integration providers and by extension, for their users. That is a lofty goal and it leads to the question: What sorts of capabilities will these integration providers be able to deliver? In other words: why should anyone care? It turns out there are many interesting possibilities. To take just one example: the Business Process Execution Language (BPEL) provides a standard for defining business processes, which can then be run by a BPEL engine. There are a variety of BPEL engines out there - what JBI provides is a standard way for organizations to use a BPEL engine (start/stop/discovery/deployment/etc.) and to make other services available to their BPEL processes while running within a BPEL engine. For all of this to work, the BPEL engine providers have to conform to the JBI specification but from what the experts tell me, that is not too difficult to achieve. BPEL engines are just one example. There are many others: event processing, business rules engines, extract/transform/load (ETL) engines, etc. These and many other technologies are all perfect candidates to be implemented as JBI compliant service engines. A service engine is a runtime process to which a developer deploys an artifact (BPEL code, business rules, etc.). That artifact can interact with services provided by other JBI compliant service engines. For example, a BPEL process could invoke a script over in an ETL engine in order to move some data around. Contracts for these services are described using WSDL. Naturally, interaction with the world beyond the JBI container is also necessary. This is where the binding components fit in. They provide the bridge to external systems. A binding component could be written for just about any protocol: SOAP, SMTP, FTP, etc. Put it all together and you get the ability to integrate many different technologies. For example: a BPEL process that uses a file system binding component to read a file that contains a credit application. It could then pass data to an external credit-rating web service via a SOAP binding component and use the same approach to get a decision from a business rules engine. When a decision has been reached, the BPEL process can use an SMTP binding component to send an email notification. Please note: that is just one example. The possibilities are pretty much unbounded. Note that in that example, the developer who created the pieces (the BPEL process, the business rules, etc.) was not programming in Java. That point is important because I think some critics of JBI have put too much stress on the 'J' in JBI. The "Java" in JBI is all about the programming interfaces required in order to implement a service engine or a binding component. But as I wrote a few paragraphs back, that affects only a small number of people. The people who actually use JBI compliant containers to solve problems will use whichever languages are supported by the service engines they choose to use. Now for the tricky part: finding a JBI compliant container and some useful service engines and binding components. Sun has made the decision to seed the market with an open source project called Open Enterprise Service Bus (ESB). Open ESB provides both a JBI compliant container and many useful service engines and binding components. Open ESB is being developed as part of the GlassFish open source application server. So Open ESB is a container-within-a-container - it runs as a hosted application in GlassFish. A great deal of the brain power behind Open ESB comes from the folks who were part of SeeBeyond, an integration software company that Sun bought back in 2005. Last week I spent four days in a workshop that the Open ESB folks hosted. I got an overview of the SeeBeyond technology that is now being moved into Open ESB. Naturally, to make use of all this cool runtime technology, you need tools. This is where the NetBeans IDE comes into the picture. Back in October 2006 when NetBeans IDE 5.5 was released there was an add-on called the Enterprise Pack that also got released. To be frank, the name "Enterprise Pack" was not the best choice. It causes confusion because people naturally assume that it includes tools for doing development for Java EE. That's understandable, since "EE" does stand for "Enterprise Edition." But the Java EE tools are in the standard NetBeans IDE distribution - the purpose of the Enterprise Pack is to instead provide tools for developing what JBI calls composite applications. A composite application is simply a collection of the artifacts that make use of the services and bindings provided by a JBI container. In other words, it's the stuff that a developer writes and then deploys to a JBI container. So for that sample application I described above, the composite application would include the BPEL script, business rules, and WSDL files (and associated XML schema files). The NetBeans Enterprise Pack 5.5 provided a relatively small number of tools, at least in comparison to what's coming up. In April 2007 NetBeans IDE 5.5.1 will ship and there will be a significant amount of new functionality in NetBeans Enterprise Pack 5.5.1. This is in alignment with new features that are being added to Open ESB. To give you an idea of the scope of the new features in Open ESB, take a look at the two screen snapshots below. The first one is from NetBeans IDE 5.5. The second one is from a recent daily build of NetBeans IDE 5.5.1. 
The list of Open ESB service engines and binding components is listed under "JBI" (which, by the way, I am not in favor of, it seems like the label should be "Open ESB"). As you can see, there are quite a few new entries. Service engines have been added for doing ETL, intelligent event processing, SQL queries, and XSL transforms. Binding components have been added for file system access, FTP, JDBC, JMS, IBM's MQ Series, and SMTP. All of which means there is still much more to learn and explore. Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
