File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Web Services and the fly likes Where JBI stands in Sun JCAPS suite Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "Where JBI stands in Sun JCAPS suite" Watch "Where JBI stands in Sun JCAPS suite" New topic

Where JBI stands in Sun JCAPS suite

Manish Goel

Joined: Jul 13, 2007
Posts: 5
Sun Java composite application platform suite, which was taken over from Sea beyaond, will be pacakaged in netbeans 6.X IDE replacing Sea Beyond enterprise designer.

Sun JCAPS has a number of components to support full SOA solution stack.
Like EGAte, EInsight BPM, EVision, EView etc...
EGate Integrator is primarily responsible for ESB functions.
Where JBI and SDO/SCA technologies will stand in Sun JCAPS or will it be competing with JCAPS suite?
Any other insight information where Sun is heading in this...
Manish Goel

Joined: Jul 13, 2007
Posts: 5
This question is posted for Binildas, who is doing his book promo for SOA and JBI.

Anybody else are also welcome to reply their thoughts...
Michael Ernest
High Plains Drifter

Joined: Oct 25, 2000
Posts: 7292

The architecture for JCAPS 6.x is based on the OpenESB model. In fact, if you want a sneak peek at JCAPS 6, one easy (if indirect way) to play with JCAPS 6 is by playing with OpenESB.

Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Binildas Christudas

Joined: Sep 02, 2002
Posts: 25
Where JBI and SDO/SCA technologies will stand in Sun JCAPS or will it be competing with JCAPS suite?

SCA is often described in conjunction with Service Data Objects (SDO), as you too have put in your mail. SCA allows the development of application assemblies without regard to any specific middleware APIs or language. SDO do similar things for data management, without regard to any specific persistance mechanism. So while SCA gives us a good programming model for developing composite applications, SDO allows heterogeneous data to be accessed in a uniform way. If you observe closely, the above two are concerns which are seperate from integrating services, but they are related to service definition and service integration in some way.

To quote from the book:
Even though we do enterprise integration daily knowingly or unknowingly, it takes some experience and a holistic approach to separate out the integration aspects from the routine application development aspects in a systems environment. When we understand this difference, we have taken the first step in recognizing EAI as a separate stream, in fact a specialized stream which requires specific skill sets to look at systems and services from an integration point of view.

To sum up I would say that SCA and SDO address an important, but different problem from JBI/ESB. The former is used by application assemblers and the later is used by integration architects. The interesting thing is, these two are not competing, but complementing. Middleware suites should provide tools and frameworks for doing both these tasks. Since SCA supports a pluggable middleware, JBI is an ideal back end for SCA. Hence, SDO/SCA can be options or alternative approaches in the Sun JCAPS since the promise of JCAPS is to create composite applications from existing investments as well as to deliver new business services with a lower TCO (total cost of ownership) for which the developer or architect should have options to chose from a set of tools.

To know more on ESB, JBI, ServiceMix & EIP, refer to the PACKT title "Service Oriented Java Business Integration":

Binildas C. A.<br />Principal Architect, <a href="" target="_blank" rel="nofollow"></a><br />(SCJP, SCJD, SCBCD, SCEA, MCP, TOGAF, LZA)<br /><a href="" target="_blank" rel="nofollow"></a>
I agree. Here's the link:
subject: Where JBI stands in Sun JCAPS suite
It's not a secret anymore!