Java Business Integration Technology Preview is Available


News: Java Business Integration Technology Preview is Available

  1. Sun has released the Java Business Integration Technology Preview for download.

    The JBI Technology Preview is based on the 0.75 version of the JBI specification (JSR 208). JBI formalizes the notion of a Composite Services Description (Service Assembly). It provides the Service Provider Interfaces (SPIs) and message exchange mechanism for various Service Engines and Binding Components to connect and interact in a standard fashion. Business logic containers that execute BPEL, BPM, J2EE applications servers, business rules, transformation are all examples of Service Engines. Binding components could offer connectivity through JMS, SOAP, ebXML and other protocols. A SOA becomes extensible and pluggable because JBI enables the collaboration between different integration technologies.

    Sun also hosts a forum for JBI.

    In another thread on TSS ("JBI Passes Public Review"), it was noted that IBM and BEA abstained from voting on the JSR.

    Do you think JBI is something you'll be interested in using? The previous news item suggested the abstentions were not extremely important. Would you agree?

    Threaded Messages (6)

  2. Is SOA a good concept?[ Go to top ]

    Don't you think that using SOA for an internal integration is just a procedural programing style on an architecture level? What is the advantage of ESB over eg. enterprise-wide object repository?
  3. Is SOA a good concept?[ Go to top ]

    Maybe ;-). But even with internal integration, once you cross organizational boundaries, sometimes, its as tough as integrating outside the organziation. I agree if you are integrating with a buddy on a different floor (or different building, etc), and you can both agree to the integration contract, things like SOA/ESB may be overkill. Once you add other consumers, and definitely once you hop out of your datacenter, they can get complex. I think what JBI and ESB/SOA solves in particular is how to normalize the contract and semantics while simplifying the complex internals that may be necessary in order to integrate and flow data around. Take a simple example of an organization inside of a company, completely isolated initially (for political reasons, lack of line of sight, governance, whatever) that maintains a holiday calendar across countries and exchanges for validating valid trade dates and market rules. At first they may start on the path of simply exposing a SOAP over HTTP based web service for querying the holidays for a given exchange. Then some other group asks if they can receive asynchronous events when the calendar gets updated through maintenance for their own systems, so they decide to push an xml encoded event over whatever messaging system their company is using. Then another groups makes a similar request, only they can't handle the xml (don't ask, it happens ;-), and want it in a simple tagged format, but not over the messaging system used by everyone else, but via sftp (this also happens wayyyy toooo often ;-). Or maybe the request is for you to just open the gates of hell and let them remote link into your operational database directly (joy ;-). The concept of an ESB/SOA whatever, architecturally can solve such problems by implementing the patterns described very nicely by Hohpe et al ( ).
    Mule UMO is also shaping up very nicely from what I can tell ( ).

  4. Shameless plugs. :)[ Go to top ]

    While we are in the area of shameless plugs, I can add to your list. :)
    Looking at how and in what context to use JBI is among the top-priorities. It would seem like a good fit for the role of service endpoints.

    The Infonatural ESB is still quite an early version, but it already features:
    * Distributed state, registry and services
    * Pluggable and transparent (to the consumer) service-transport (plug-in whatever you like: EJB, JMS, SOAP, JVM for individual service-containers)
    * Transparent location of services
    * Synchronous or asynchronous requests for all transports
    * pluggable response-strategies (when is a request fulfilled? when does it timeout?), pluggable callbacks and serializers
    * Both standalone Java-app mode as well as embeddable into a J2EE EAR (in a J2EE environment, embedding it into an EAR is recommended).
    etc etc etc

    Still in heavy development, but maturing quickly.

    And you are right: Hohpe's website is a goldmine (as is his and Woolfs book, as well as Chappell's book "Enterprise Service Bus").
  5. Is SOA a good concept?[ Go to top ]

    Don't you think that using SOA for an internal integration is just a procedural programing style on an architecture level?
    Absolutely not. First of all, I don't think SOA is about technology first and foremost, it's about finding the practices that will allow an organization to identify, create and reuse coarse-grained, stateless business Services that are (hopefully) reusable, and perhaps most IMPORTANTLY, will shield front-end applications from the complexity of backend-systems and how the actual Services are implemented.
    SOA isn't exactly very new as such, it is a set of old best practices, succinctly bundled together with excrutiating amounts of marketing hype added. But nevertheless: best practices.
    What is the advantage of ESB over eg. enterprise-wide object repository?
    Objects tend to be very fine-grained compared to Services and come with some dependencies on other objects.
    The "Component" paradigm of EJB's tried to address this, perhaps not with great success in hindsight. Though granularity is important, it is not the primary benefit in my opinion, so don't get confused with the "well, its just objects/ejb's etc etc", because it's not the main issue at all. :)

    Also, besides the benefits of Services, an ESB gives you added advantages in the form of transparency when it comes to the Services actual physical location, preferred mode of transport (SOAP, EJB, JMS etc), implementation details, and probably even the actual interface of the Service.
    The Service-consumer just sends a request and says "do this piece of work for me, I don't care who, how or where it is done".
    Also an ESB is decentralized, which means you can deploy Services just about anywhere, but they will still appear as part of the "Bus" just as if they were centrally deployed (hence the "Bus"-analogy).
  6. Is SOA a good concept?[ Go to top ]

    Don't you think that using SOA for an internal integration is just a procedural programing style on an architecture level? What is the advantage of ESB over eg. enterprise-wide object repository?

    The advantage is that each service/application/whatever-you-like talks to the bus, not to each other. The bus acts as the broker in locating and invoking other services. This reduces the interdependencies.
  7. As a "corporate developer", I can tell you that an ESB is a very attractive option for standardizing the interactions between legacy applications, packaged applications and new efforts. JBI looks like a promising step towards somewhat standardizing ESBs.

    To "plug" a legacy or packaged application into an ESB, you have to write an adapter (think JCA). As I understand it, JBI provides the "service container" that my apps connect to. The "JBI" based ESBs will provide reliable messaging between service containers (plus management and monitoring goodies).

    So, in the context of an ESB, I do welcome JBI.