JBI is different from J2EE in the sense that JBI extends J2EE and J2SE with business integration SPIs. These SPIs enable the creation of a Java business integration environment. Similar to J2EE, JBI also employs concepts like application packaging and deployment functionality to include JBI Components. Currently, Java does not currently adequately support service-oriented integration (SOI) technologies, hence the new JSR (JSR-208) is proposed which talks about JBI. A JBI Application can be composed of one or more JBI Components, which may or may not include J2EE modules as defined by the J2EE Platform. This means, there will be perfect harmony between J2EE and JBI components, the former mostly dealing with Application, component and service definition and development whereas the latter deals mostly with integrating them (in a standard way). And this should be the reason - today, the borderline is very thin between J2EE and JBI, and in fact they should co-exist in suites like Weblogic, Websphere, JBoss, etc. I mean, such stacks should provide means to develop business components (using J2EE) as well as means to integrate components & Services (using JBI). So, we are talking here about two seperate concerns, service development and service integration, and we need to understand that these are two different problems and we should use seperate toolsets and frameworks to address them. so that, business code is not mixed with service (or component) wiring code!
Binildas, I am unclear of the role of JBI specification itself (Possibly i am too lazy to read up the JSR spec ). If Service Integration in a SOA itself is based on the Webservices standards what is the role played by JBI? Is JBI trying to sum up Webservices standards and SOA Service integration principles and trys to extend it to Java/J2EE containers? Per my understanding, Webservices standards support in J2EE container plus ESB support added is a rough equivalent of JBI?
Sun Certified Enterprise Architect
IBM Certified Solution Designer - RUP 7.0
Call it 'Component' when others understand what you have coded
Call it 'Framework' when you don't understand what you have coded
posted 12 years ago
Web Services talks about web services, but not about "integrating" services. Integration is a different task which we can do it in many ways, ranging from the "traditional Spaghetti" way to more formal, standard, ordered ways using best of the breed integration architectures like ESB.
JSR 208 Quotes:
Java Business Integration JSR (JBI) extends J2EE with business integration SPIs. These SPIs enable the creation of a Java business integration environment for specifications such as WSCI, BPEL4WS and the W3C Choreography Working Group.
When we say "Java business integration environment", we mainly refer to vendor tools and frameworks, including App servers. These environments has to provide "plugs" and "adaptors" for specifications like BPEL, etc. Good, that is the vendor's headache and let us now come to our developer's headache...
We have been using multiple Java/J2EE components, ranging from POJO, JMS, EJB, RMI-IIOP, etc., etc. We now know how to service enable (web-service wrap or some other way) them too. When the Java business integration environment provides plugs and adaptors, we as developers should know how to plug-in our traditional components (like POJO, etc.) to this integration environment. This concern I would visualize as the other side of the JBI coin (the first side is the one seen by tool vendors). So, Integration Architects and developers using Java tools has now got a reason to look into JBI - to wire services in the standard way. So your query (and understanding):
Is JBI trying to sum up Webservices standards and SOA Service integration principles and trys to extend it to Java/J2EE containers? Per my understanding, Webservices standards support in J2EE container plus ESB support added is a rough equivalent of JBI?
is in the right direction. with the addition of the "second face of the coin" which we described above, and it is this second face of the coin which we are addressing in our book - so, the target of this book is developers/architects doing integration using Java tools, not Tool vendors.