*
The moose likes Web Services and the fly likes Difference between JBI &J2EE Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "Difference between JBI &J2EE" Watch "Difference between JBI &J2EE" New topic
Author

Difference between JBI &J2EE

aslika bahini
Ranch Hand

Joined: Mar 03, 2007
Posts: 111
Hi Binildas,

How JBI is different from J2EE?

Thank You
Saritha
Binildas Christudas
author
Greenhorn

Joined: Sep 02, 2002
Posts: 25
Hi Saritha,

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!

To learn more on ESB, JBI, ServiceMix & EIP, refer to the PACKT title "Service Oriented Java Business Integration":
http://www.packtpub.com/service-oriented-java-business-integration/book
http://www.amazon.com/Service-Oriented-Business-Integration-Binildas-Christudas/dp/1847194400


Binildas C. A.<br />Principal Architect, <a href="http://www.infosys.com/" target="_blank" rel="nofollow">http://www.infosys.com/</a><br />(SCJP, SCJD, SCBCD, SCEA, MCP, TOGAF, LZA)<br /><a href="http://www.packtpub.com/author_view_profile/id/180" target="_blank" rel="nofollow">http://www.packtpub.com/author_view_profile/id/180</a>
Alfred Jayaprakash
Greenhorn

Joined: Jan 11, 2008
Posts: 10
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?


-------------------------------
Alfred Jayaprakash

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
Binildas Christudas
author
Greenhorn

Joined: Sep 02, 2002
Posts: 25
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.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Difference between JBI &J2EE
 
Similar Threads
Flavors of ESB softwares
JBI and JCAPS
ServiceMix / Mule
JBI
Java EE 6