Binildas Christudas

Hi,

I think, your query can be split up into two parts:

Can I do web service transactions

The answer is Yes and No. Yes because, specifications are there and are at different stages of adoption and maturity. Let me provide you at least one link of interest: A comparison of Web services transaction protocols. I also said No because, the Transaction Managers and the libraries (.jar files available along with vendor's package) may support WS-TX again at verying levels, and hence it depends not only on your own domain but also on the domain of the foreign Web Service providers with which you want to interact with transactionally. So all of them are to be TX aware if your composed service has to be transactional.

Whether JBI supports Transactions

JBI provides enough clarity on the support of transactions. Let me reproduce something from the specification here:

Using JBI to compose services will often require the sharing of a transaction context between JBI engines/bindings. Such transactions can facilitate reliable operation of composed services. The unit of work in the NMR is a Message Exchange. This is also the unit of work when a transaction is being used. The NMR is considered to be transaction aware. If the NMR is told that the Message Exchange is being controlled by a transaction, the NMR will internally use the transaction, if required, and will pass the transaction context along with the Message Exchange.

To learn more on ESB, JBI, ServiceMix & EIP including samples on Transactions, 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

Hi,

You can find a freely downloadable sample chapter in below link:
Bind Web Services in ESB�Web Services Gateway [1 MB]

This book talks about concepts as well as practical samples. In fact, you will find only few concepts for which there is not a sample available. For most of the scenarios, the book provides samples which you can run using Open Source Apache ServiceMix JBI container (like a server), and all samples can be run using Apache Ant tool. You don't require any IDE/Workshop, but require Tomcat and Axis along with ServiceMix for running the samples.

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

One of the benifits of SOA is the services are exposed in a technology/neutral manner to consumers.

But, as you have rightly pointed out, you cannot implement an SOA with a "technology agnostic" language or tool, since such a language or tool is difficult to imagine. In other words, you have to use some (or many) technology(ies) and then follow SOA pronciples and practices to implement an SOA.

The book uses Java (or specifically JBI API and spec) to do integration. To quote from the book:

ESB or JBI are not an end by themselves, but a means towards an end (which is SOA). An ESB is not required to build an SOA, nor is JBI required for ESB or SOA. However, all of them have something in common using JBI�we can build standard components to be deployed into ESB architectures. Thus, JBI by itself is one of the ways by which we can attain SOA.

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

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.

Hi Palla,

This book is for Java/J2EE Developers (& Architects).

This book has got simple as well as some medium-complexity code samples

As a java developer, this book will help you to identify integration aspects in your day to day code seperate from business code. Then it introduces many tools and frameworks which you can use to address integrating systems and services, using standard ways. The book assumes no previous knowledge on Integration/JBI/ESB, but will equip you with all the required skills and toolsets so that you understand Integration/JBI/ESB and also you can develop and code in Integration/JBI/ESB.

You don't require any "Workshop" or "Studio" or "Plugin" to try out the samples, nor you need a heavy RAM. You can try out the samples using Tomcat-Axis combination, using Ant build tool.

The book doesn't give you any new inventions, or any new patterns in integrations. These are already done by the great books below:

Enterprise Service Bus by David Chappel

Enterprise Integration Patterns by by Gregor Hohpe and Bobby Woolf

But the book guarantee that you understand many of the patterns and aspects described in above two books with the help of code and real world samples. You may want to look at the Table of Contents of this book to know more.

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

Hi Marc,

Hope you will have some good time with the samples.

I started using JBI products 2-2.5 years back, and at that time the ESB/JBI market was not that common. Due to multiple reasons we decided to use Open Source tools and ServiceMix especially as our integration framework. The key point here is, I was not working alone, but we were a team, people having different experience and expert level. It was true that we were having JBI spec and also ServiceMix tutorial at that time, but one frequent complaint I received from my team as well as from many others online is that, they are not able to build their solutions just using the spec and tutorial alone, since the documentations were either incomplete or the samples already provided were only code snippets in many cases.

Moreover, All people are not like Few others, and many have expressed their eagerness for someone to handhold them. Their major concerns are in the following lines:

Lot many whitepapers on ESB, but no code available

Cannot understand ESB - how is it different from other Integration Architectures?

Is there a difference between a Message Bus & a Service Bus?

Can I run an ESB sample without a heavy app server and an equally heavy IDE?

Is ESB just a hype? Does it got any real substance?

etc...

which are now at least partly answered here as you can see in the Table of Contents of the book

I understand you are going to try out the samples too - I beleive, you will gain lot many hours in your busy schedules too, which you would have been otherwise spending in R&D with code - since Myself and my team has already done a part of this R&D and now available in this format (code which you can run using simple ant scripts).

any other books or resources you would recommend to someone that wants to learn more about SOA and JBI

I assume, you are talking SOA and JBI in the context of integration (SOI) - If so I doubt whether I can point you to any other book available as of today in JBI. But at least, you may want to go through the following titles for good integration literature:

Enterprise Service Bus by David Chappel

Enterprise Integration Patterns by by Gregor Hohpe and Bobby Woolf

The above books are at the abstraction level of Architecture, Design & Patterns and you can refer to the below book for some of these literature in code.

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

A Sample chapter is available in the below link:

Bind Web Services in ESB�Web Services Gateway [1 MB]

Adding another link:
SOA + EDA = Open Source ESB:ServiceMix(*)

Other links can be found here:
Articles on SOA, ServiceMix, JBI and the Like

Hi,

The Message Broker is also called the Hub-and-spoke architecture where there is a centralized hub (broker) to which all applications are connected. Each application connects with the central hub through lightweight connectors. The lightweight connectors facilitates for application integration with minimum or no changes to the existing applications. Message transformation and routing takes place within the hub. Since applications do not connect to other applications directly, they can be removed from the integration topology by removing from the hub. There is a downside to the Message Broker topology - Due to the centralized nature of the hub, it is a single point of failure. If the hub fails, the entire integration topology fails.

By leveraging JMS, it is possible to create an enterprise message bus which provides a common communication infrastructure. Even though JMS is a java messaging API, by designing your message packets at suitable level of abstraction, you can make the message bus neutral to platform and/or language. Applications interact with each other through the message bus with the help of request-response queues.

ESB on the contrary provides a collection of middleware services which provides integration capabilities. These middleware services sit in the heart of the ESB architecture upon which applications place messages to be routed and transformed. Applications connect to the ESB through abstract, intelligent connectors which has got logic built-in along with the ESB to selectively bind to services at run time.

The article Aggregate Services in ServiceMix JBI ESB gives a small description on different Integration Architectures.

Now if we talk about JBI - SOA and SOI are the targets of JBI and hence it is built around WSDL. Integration components can be plugged into the JBI environment using a service model based on WSDL. Service composition is a major target in ESB architecture and the JBI environment aggregates multiple service definitions in the WSDL form into the message infrastructure. So you can now think of ESB, and thus JBI (because an ESB can be JBI based, even though it is not mandatory) as a workbench where you can do service orchestration and other BPM tasks.

Last but not the least - Talking on Spring and Camel - if we take the case of ServiceMix which is the reference JBI and ESB which we have used in our book, it has got good integration with these two frameworks. All beans in ServiceMix can be spring wired. The servicemix-camel component provides support for using Apache Camel to provide full set of Enterprise Integration Patterns (EIP) and flexible routing and transformation in both Java code or Spring XML.

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

Thought of posting this link here, since it can be an introduction to JBI, ESB & ServiceMix:

Aggregate Services in ServiceMix JBI ESB - Article with Code samples

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":
http://www.packtpub.com/service-oriented-java-business-integration/book
http://www.amazon.com/Service-Oriented-Business-Integration-Binildas-Christudas/dp/1847194400

We want to integrate lots of services (web services). I want to know the best practice and good design pattern on this front

Integrating services?! - You may also be interested in the below book:

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

Hi John,

Let me answer your query in the context of ServiceMix and the book in discussion:

ServiceMix is a container for JBI components. At the same time the ServiceMix JBI container by itself is a JBI component. This characteristic enables ServiceMix to be deployed as a standard JBI component into another vendor's ESB container, provided the host ESB container supports JBI components. When we say a ServiceMix container is a JBI component, it means that a host container (like OpenESB from Sun) can make use of almost every ServiceMix component, whether the component is a standard JBI component or a lightweight component (the difference between these two is explained in the text). The promise of this model is that the developer-created components can be reused across JBI containers.

To answer your query:

WAR, EAR, RAR or a standalone server?

ServiceMix supports integration with JOnAS, JBoss, Spring, Tomcat, Geronimo, etc. Moreover, ServiceMix is also available as a .war file which can be used to deploy ServiceMix inside any J2EE application server or Servlet Engine. This will aid the side-by-side deployment I talked about in this link.

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

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

Hi Walter,

I have been closely observing the Service Oriented Integration space in Java world and hence we have been dealing with the following frameworks:

[list]ServiceMix

Mule

OpenESB

Celtix

Websphere

Aqualogic

Sonic

Fiorano

etc.

Amongst them, the first three are related to Java Business Integration (JBI) in some way and open source. The extend to which these three frameworks support JBI are varied, and let me explain a bit on that.

OpenESB
http://java.sun.com/integration/openesb2_0/
https://open-esb.dev.java.net/
OpenESB is Sun's Reference Implementation (RI) for JBI. Many downloads were done for technology validations. I am not ruling out the possibility of using OpenESB for production applications, but I am yet to get references for that.

ServiceMix
http://servicemix.apache.org
Compared to Mule, the major difference for ServiceMix is its architectural design, which is fundamentally based on the Java Business Integration (JBI) standard.

Mule
http://mule.codehaus.org/display/MULE/Overview
Mule and JBI have some overlap in the problems they solve but under the covers they do it in different ways. JBI is XML and WSDL centric where as Mule makes no assumptions about the message type. JBI uses a notion of Message Exchanges and a Normalized Message to communicate between components, where as Mule use a "POJO / Endpoint" architecture. JBI is a service container whereas mule is more of a ubiquitous messaging fabric that goes beyond integration to provide a solutions for translating, monitoring, routing and orchestrating all type of information around the organization.

Let me now point to few On-Line articles/discussions. The first link is a "must read", since it narrates discussion happened between the creators of ServiceMix & Mule:
How+does+ServiceMix+compare+to+Mule
ServiceMix & Mule

As you have already noticed, the book is on JBI and an open source implementation for that. JBI as a technology and as an API is relatively new, but is very promising on SOA and integration point of view. There are no other books available on JBI at present. Moreover, we wanted to create a book for developers. This means, readers need to understand JBI API, then use an implementation and try out things at code level. Obviously we can use Mule or ServiceMix for that. Now, as we discussed above, ServiceMix is built from the ground up on JBI principles, patterns and abstractions rather than tacking JBI onto the side of a quite different model. This is the main reason why we chose ServiceMix.

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