It is very easy to create JMS consuming services in the Oracle Service Bus (previously known as BEA AquaLogic Service Bus or ALSB), but one of the things that you may want to control is the number of connections that is used to poll a JMS server. This blog describes the background to JMS listeners in OSB and how to solve problems with the JMS server being overloaded with connections. In this particular case, the JMS server is actually an IBM Websphere MQ server but most of the principles also apply to different JMS implementations.
Tags: esb, Middleware, SOA
Filed under Middleware, Oracle, SOA | No Comments »
This is not a rant against ESB. I am not saying that ESBs never have a purpose, nor suggest that it's all just a scam. If - after having read this post - you got the impression that I suspect a conspiracy behind ESB, then I want to tell you up front that this is certainly not what I intended to say.
Tags: esb, integration, messaging, SOA, spring integration
Filed under Java, SOA | 7 Comments »
Many have assumption that IT / software architecture is a thing of logic. So, there are many discussions about ESB and that we should not have those. The fact is that in large companies, we do not often do architecture - we do politecture. The politics drive the architecture. It's not the way it should be, but that's the way it is.
Let's do one more shot...why do we need ESB? This time from politecture perspective:
Preventing a mess
It allows for a greater degree of control on delivered solutions. Before you even think about creating another quick and dirty integration solution; there is that annoying ESB compliancy making sure that integration mess created with each new technology is at least visible.
Disruptive Innovation
An alternative like REST is a "disruptive innovation" and does not fit in the line of old mindsets (CORBA, RMI, EJB, SOAP, WS-*,...). ESB fits in this line. Of course, it is a matter of time before something like REST wins from ESB's.
Legacy
Quite often the cleanest solution is to change or replace the legacy in case of integration problems. So you still don't need an ESB. But the real problem is who is going to let you change that legacy that has not been changed and (barely) working in production for a long time.
Tags: Architecture, esb, SOA
Filed under Architecture, Middleware, SOA | 1 Comment »
Rik de Groot wrote a blog entry about a year ago about versioning services as part of the Top 10 SOA Pitfalls. He touched the subject on different versions in deployment and basically offered us the option of rerouting services using an ESB.
It is a common knowledge that consumers will keep on using a service hoping to only upgrade if *they* need additional or changed functionality. Services however are not meant for a single consumer but for a lot of consumers. Even if they want to upgrade they won't do it simultaneously. So you will have multiple versions of services running.
I see several options to address versions of services:
1. Minimize by using rerouting within the ESB.
2. Keep all versions running while in use.
3. Have a contractual agreement with expiry date.
4. Use content based routing.
5. Construct adapters for conversion
First I would like to look at which versions might appear. A major version increment of a service means we are no longer backward compatible. A consumer wanting to use the next major release therefore needs to start coding to make use of this service. When a minor increment occurs there is backward compatibility and additional functionality offered. This means a consumer can make use of it without much effort (changing the binding would suffice). A patch increment of a service indicates a change without breaking specifications. A new patch release can - and should - therefore replace the older version.
Clearly in all options we should limit the number of versions of a service created. This means services should not be created within projects but (re-)created in a separate track in order to have generic services and optimal reuse. This track should collect all requirements of (potential) customers, take the common denominator and bring a new version into existence. More than often a new version is created because a single customer wants certain functionality not yet offered and without looking around the new version is tailor-made.
(more...)
Tags: Architecture, SOA, versioning
Filed under Architecture, SOA | No Comments »
Today was the last day of the JavaOne Conference. We came to the point when a lot of OutOfMemoryErrors where thrown. We just managed to squeeze in the last sessions.
Today's keynote was all about toys. The guys from the Netbeans team showed some new features such as a JavaScript editor (which contains code completion), Sentilla showed there small sensor thingies, which you can program to gather information, such as acceleration, temperature etc.., LiveScribe showed there very cool pen and lots more.
Today's topic included:
Tags: Java, JavaOne, Semantic Web, SOA
Filed under Java, JavaOne, SOA, Usability | 1 Comment »
Today was the third day of the conference. Another couple of hours to go and then it is all over again. The fatigue is kicking in, and we're starting to run on reserve power. The topics of today included:
Today was the second day of the JavaOne 2008. Besides doing a lot of chatting in the JavaOne pavillion, and visiting all the cool parties this night, we also went to a number of sessions. Also today the NLJug had the James Gosling meeting we won for being the biggest JUG out here. After a long day of work, we finally had time to relax at the Adobe party and at the SDN party.
Todays topics included: