• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

Difference between JBI &J2EE

 
Ranch Hand
Posts: 111
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Binildas,

How JBI is different from J2EE?

Thank You
Saritha
 
author
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Binildas Christudas
author
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
I AM MIGHTY! Especially when I hold this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic