In this interview, James Strachan discusses how Java Business Integration can help organizations integrate their siloed, vertical applications in a standard way. He describes the role of orchestration in an SOA, looks at how BPEL engines can plug into a JBI container and examines various management tools for Web services such as JMX and WS-HTTP Management. He also looks at the versatility of scripting languages, such as Groovy, inside an SOA environment.

Watch James Strachan on Java Business Integration.

Please post the interview date for this topical content.

The morning after the Tangosol party at JavaOne last year; I had a big hangover too - it was a great party :)

James
LogicBlaze

The morning after the Tangosol party at JavaOne last year; I had a big hangover too - it was a great party :)

It used to be the "TangoSolarmetric" party (joint Tangosol and Solarmetric). BEA bought Solarmetric, but (good news!) has already committed to co-hosting the party at JavaOne this year :-)

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

8. A lot of architects see JMS as being a mechanism for scaling asynchronous calls. Is this a valid use of JMS or how should JMS be used?

I think that’s an absolute valid use of JMS. I think JMS’s main aim and use is location transparency and high performance message exchange. To do high performance message exchange, normally things are done asynchronously and you have a producer and a consumer and all communication is asynchronous. So, you can get really, really high performance. Working with databases for example, remote EJBs, is kind of slow. You have lots of synchronous requests, responses and lots of latency. JMS is designed around high performance asynchronous processing. So everything is asynchronous, fire and forget. So you can get really, really high performance.

James,

     Thanks for clarifications and giving more broder view on JBI.I still have some ambiguties about JMS performance because I saw an article in dev2dev website which gives some insight into performance tests between JMS and Web services. The URL is as follows

http://dev2dev.bea.com/pub/a/2004/07/jms_webservices.html

As per those tests for sequential request processing, Web Servies seems to be faster when compared to JMS.If I have an option to implement either JMS or Web Services, should I opt for Web Services(As per those performance tests)? And one more thing is, in the article it seems they tested SOAP based web services.If I do REST based web services then,the results may be more favorable towards Web Services rahther than JMS? Please clarify.

Thanks
Kosuru

8. A lot of architects see JMS as being a mechanism for scaling asynchronous calls. Is this a valid use of JMS or how should JMS be used?I think that’s an absolute valid use of JMS. I think JMS’s main aim and use is location transparency and high performance message exchange. To do high performance message exchange, normally things are done asynchronously and you have a producer and a consumer and all communication is asynchronous. So, you can get really, really high performance. Working with databases for example, remote EJBs, is kind of slow. You have lots of synchronous requests, responses and lots of latency. JMS is designed around high performance asynchronous processing. So everything is asynchronous, fire and forget. So you can get really, really high performance.

James,     Thanks for clarifications and giving more broder view on JBI.I still have some ambiguties about JMS performance because I saw an article in dev2dev website which gives some insight into performance tests between JMS and Web services. The URL is as followshttp://dev2dev.bea.com/pub/a/2004/07/jms_webservices.htmlAs per those tests for sequential request processing, Web Servies seems to be faster when compared to JMS.If I have an option to implement either JMS or Web Services, should I opt for Web Services(As per those performance tests)? And one more thing is, in the article it seems they tested SOAP based web services.If I do REST based web services then,the results may be more favorable towards Web Services rahther than JMS? Please clarify.ThanksKosuru

I suppose you mean a synchronous web services.

In this case it is an misunderstanding.

Asynch technology is always going to have a slower response per request, because the way it must be implement it. You have a consumer, producer and infrastructure.

In the synch situation you have only server and client.

On the other side the asynch technology gives you:
- better reliability of remote calls (handles network failures)
- better scalability/clustering
- handles a peak traffic without problems (throttling)
- non blocking communication (client does not wait for server)
- better thread management (threads waiting for slow response)

Imagine you need to validate the credit card by the web service and it takes e.g. 5 seconds. And you have 1000 concurrent users, but your AP server has only 128 working threads.

There is no way, how you can implement it in the synchronous way. And in this case you do not mind that JMS is going to be 2 times slower than direct WS call.

On the other side the asynch technology gives you:
- better reliability of remote calls (handles network failures)
- better scalability/clustering- handles a peak traffic without problems (throttling)
- non blocking communication (client does not wait for server)
- better thread management (threads waiting for slow response)

I will add some more (some logically duplicate however very useful):
- Message priorities (very difficult with sync calls)
- Transaction capabilities (After commit you are sure that message will be processed)
- Routing (rerouting after failure, manual rerouting, message duplication for back office, ...) because message is like unit of work (at least try to design it this way)
- Better monitoring and auditing
- Timeout - if message don't get processed till some time it will be erased (e.g. user queries)

You can't compare direct sync call with sync call simulation via fullfeatured async service. If you decided to use async use advantages of async. All big services, at least internally, are asynchronous. I work for banking industry. All our services are async in core (sometimes not based on JMS).

On the other side the asynch technology gives you:- better reliability of remote calls (handles network failures)- better scalability/clustering- handles a peak traffic without problems (throttling)- non blocking communication (client does not wait for server)- better thread management (threads waiting for slow response)

I will add some more (some logically duplicate however very useful):- Message priorities (very difficult with sync calls)- Transaction capabilities (After commit you are sure that message will be processed)- Routing (rerouting after failure, manual rerouting, message duplication for back office, ...) because message is like unit of work (at least try to design it this way)- Better monitoring and auditing- Timeout - if message don't get processed till some time it will be erased (e.g. user queries)You can't compare direct sync call with sync call simulation via fullfeatured async service. If you decided to use async use advantages of async. All big services, at least internally, are asynchronous. I work for banking industry. All our services are async in core (sometimes not based on JMS).

Diky Pavle,

The best resource and "must read" is this book:
http://www.enterpriseintegrationpatterns.com/

Just to add more to what's already been said on this subject - you can get good performance from JMS providers that allow you to co-locate (or embed) a MessageBroker in the same JVM as the service you are running - .e.g. ServiceMix's sister project - activeMQ - see http://www.activemq.org - whilst the caller's of the service can still be remote - using tcp/ssl/http etc.

cheers,

Rob

As per JBI specification 1.0 section "4.1 WSDL-based Messaging Model" says that,JBI model services produced and consumed by components using WSDL 1.1 or 1.2.

Does it mean that if my Service is not having a WSDL interface, it is not JBI compliant? Then IMHO RESTful services are not JBI compliant,because they doesn't have WSDL?.

And in ServiceMix(2.0.2) examples, I tried to find some examples with WSDL interface, but could not able to find one.Does Servicemix 100% JBI compliant?

And I read some where that, while choosing an ESB better to go with one supports JBI, why is this?

Thanks in advance

Kosuru

As per JBI specification 1.0 section "4.1 WSDL-based Messaging Model" says that,JBI model services produced and consumed by components using WSDL 1.1 or 1.2.Does it mean that if my Service is not having a WSDL interface, it is not JBI compliant? Then IMHO RESTful services are not JBI compliant,because they doesn't have WSDL?.And in ServiceMix(2.0.2) examples, I tried to find some examples with WSDL interface, but could not able to find one.Does Servicemix 100% JBI compliant?And I read some where that, while choosing an ESB better to go with one supports JBI, why is this? Thanks in advanceKosuru

JBI standardizes a way ESBs are implemented.

So theoretically you can take the IBM's BPEL engine and plug it into the SUN's ESB if both are JBI compatible.