Posted by boneill42
on July 2, 2007 at 2:14 PM PDT
Often people take a look at JBI and expect to be developing new service engines and binding components, but more often than not an application developer won't need to code anything at all! (or at least thats the vision)
Many people, including myself, approached JBI as a standards-based means of achieving ESB capabilities. That was the big value proposition. In the early stages of using it, we treated JBI like JMS on steroids. It wasn't until later in the game, we realized the full potential of JBI.
And, it really boils down to knowing the Fundamentals of JBI . For developers like myself that have a tad bit of an attention deficit disorder, it is easy to overlook the implications of those fundamentals. Specifically, the JBI specification had plans within plans, and containers within containers.
The JBI run-time acts as the first level container, consuming service assemblies for deployment. Those service assemblies contain service units which get deployed to service engines and binding components. So, JBI components themselves act as a second-level containers for the artifacts within service units.
This is often misconstrued by people that believe Service Engines *implement* the business logic in an application. This is not the case. Instead, business logic gets *deployed* to Service Engines as part of a service unit (within an assembly). Service Engines contain and execute the business logic, but they by themselves do not provide it. This is tremendously important because it allows JBI to deliver, "Application Development without coding".
Lets look at an example, the BPEL Service Engine lets me wire together services mapping the results of one service to the inputs of another. So, without any coding I can deploy a bpel process to the BPEL Service Engine. Furthermore, I can connect that process to specific transports, like XMPP and SIP by simply deploying service units to the XMPP BC and SIP BC respectively.
In this situation, the BPEL SE, XMPP BC and SIP BC are acting as containers for specific business logic and "instances" of capability that could have been defined graphically in an IDE like NetBeans .
Thus in our never ending quest to make our lives easier and leave the world of semi-colons, I believe JBI has brought us one step closer.