Restricting the number of JMS / MQ connections made by the OSB
Posted by Tjeerd Kaastra at around evening time: December 2nd, 2009
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.
Guaranteed Delivery in Spring Integration
Posted by Wilfred Springer just before lunchtime: November 27th, 2009
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.
Java callout on the Oracle / AquaLogic Service Bus – Invoking static methods in any jar file
Posted by Jeroen van Wilgenburg mid-morning: October 11th, 2009
Sometimes a service bus is not sufficient for the job at hand. You can use EJB's and JMS queues, but that might be overkill. That's where a java callout might come to the rescue. This article will show you how to do a callout with 'complex' objects. On the bus you can pass around java objects or use them on the bus (this requires a small transformation step). I used the AquaLogic service bus version 10.2, but I think it should work any version that supports java callouts. The only difference can be the version of xmlbeans (AL 10.2 uses version 1.0.3)
(more...)
ESB as a political thing
Posted by Viktor Grgic mid-afternoon: October 5th, 2009
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.
Versioning SOA services
Posted by Michaël van Leeuwen around lunchtime: August 3rd, 2009
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...)
Installing Oracle Service Bus 10gR3 on Mac Os X
Posted by Jeroen van Wilgenburg mid-morning: December 24th, 2008
Last week I installed WebLogic and the AquaLogic Service Bus on a Mac. There is no Mac-download on the download page, but by using the HP-UX version everything works fine, you just have to add some command line parameters.
Top 10 SOA Pitfalls: Wrap-up
Posted by Gero Vermaas around lunchtime: June 29th, 2008
The Top 10 SOA Pitfalls countdown hit #1 last week with Rik de Groot's post on "Ignoring culture when introducing SOA", time for a wrap-up.
Putting all pitfalls together in one simple 10 item list quickly reveals a grouping of types pitfalls. Number #1 and #2 are both related to organizational aspect. If the culture, mindset and attitude are not right, these are typically the pitfalls that a SOA endeavor may run in to. The next group covers the items #3 till #7, these are all related to architectural/design skills. And the last group, numbers #8 till #10, relates to implementation issues (although proper design could help to prevent these pitfalls from manifesting themselves).
Top 10 SOA Pitfalls: #1 – Ignoring culture when introducing SOA
Posted by Rik de Groot around lunchtime: June 23rd, 2008
Last week Viktor Grgic explained Unclear ownership / Project based funding. This week we’ll continue with #1 - Ignoring culture when introducing SOA.
SOA is an approach. The culture aspect of introducing a SOA is important, but it seems that companies want to invest in tools and not in people. In order of making this SOA to work they force their employees into this new way of thinking/acting. Often this leads to resistance which undermines the SOA goals. In this part we will look into ignoring culture when introducing SOA.
(more...)
Top 10 SOA Pitfalls: #2 – Unclear ownership / Project based funding
Posted by Viktor Grgic in the late afternoon: June 16th, 2008
Last week Viktor Grgic explained the Missing skills en this week we’ll continue with #2 - Unclear ownership / Project based funding
In the world of standalone applications, there is typically a clear sponsorship and ownership of an application. There is also a single project with one project manager. The systems could be small or big, but the pattern remains the same. Funding is based on a business case and can be easily defended.
In SOA world, the story is different. There are the usual projects, each having their own objectives and often reluctant to work on generic services or enterprise components. If the ownership and funding for these components and aspects are unclear then chances are high that nothing happens on enterprise level or that it's not according to enterprise architecture or nobody feels responsible when things on enterprise level go wrong (e.g. security).
Several projects working together is not a bad situation, but there should also be a SOA steering committee and SOA competence center well funded and supported by company board.
(more...)
Top 10 SOA Pitfalls: #3 – Missing skills
Posted by Viktor Grgic in the early morning: June 9th, 2008
Last week Gero Vermaas explained the Incorrectly Applied CDM en this week we’ll continue with #3 - Missing skills
Just like any other paradigm, a level of new knowledge and experience is required. Unfortunately, SOA requires lots of new knowledge and experience. It requires a different way of thinking of more or less everyone involved. People are used to closed environments on both organisational and technical level; largely well protected from influences and unwanted dependencies with the outside world. It's all in their area of influence which makes achieving short term results relatively easy. I'm referring to silo applications where the world is complicated enough. From their view, SOA makes things even more complex. There should be awareness that there is lack of knowledge, experience and attitude and something should be done about this first. There is no real solution, except for the obvious one: educate everyone involved. Also, agile methodologies have proven to be effective in building up knowledge and experience.
(more...)
Archives
Xebia Sites
Categories
- Java (282)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Middleware (23)
- Deployment (14)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Xebia Labs (15)
- Quality Assurance (14)