We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Open for Business

Noam Tamarkin

ESB flexibility in question

Vote 0 Votes

Dear Readers:

Lately, I was challenged by an upgrade to our ESB server. That happened to be Web Methods.

From the client point of view (my application) it was easy. Just open Visual Studio, update the web reference or Service reference and keep on developing. It took less than 10 minutes including tests.

From the other side, the call from the ESB to my application suddenly stopped working. They had to do what I did but from their end. It took the Web Method expert more than 30 minutes to do what I did in seconds.

The update of the proxy took a lot of time compared to Visual Studio

The other thing that happens a lot is a need to add a field or tag to the message XML. Again, generating the client proxy is easy in Visual Studio but a lot of work in Web Methods.
I think I discovered a basic weakness. I met this in other ESB as well, so I would just summarize it.

ESB is great in the process but week at the edges. I am not sure why, but it seems that the need to support multiple technologies made it adaptable but not flexible enough.

I would like to suggest an easy way out of the problem. Each ESB is based on some technology-- e.g., Java. Why not create the client proxy in Java and reference it from the ESB?

Am I missing something? Is there a nice and easy way to handle the challenges I mentioned above?

See you all next time,



| Leave a comment

Not many details here. The name of the ESB product is also spelt incorrectly. So you're saying, you changed something and a software product didn't magically handle it? Amazing. Perhaps the person who works with your webMethods environment isn't such an expert as they say?

yes, Noam, I think you are missing the fundamental thing about ESB - nobody know what is this and it totally a vendor proprietary magic when it comes to how it work.

I have even simpler solution - forget about Java and C# all together and use XML instead, i.e. messages with XML load to be routed from requester to provider. This, BTW, is called a 'bus'. Everything else is not an Enterprise Service Bus but a proprietary product you have paid for under the cover of SOA.

Do not try to improve it but rather restrict use of it by the bus level and find solutions for your needs that You can control, not them, in the ESB.

Leave a comment

In this blog, Noam Tamarkin provides ideas for improving and better integrating your applications.

Noam Tamarkin

Senior software architect and CTO. Experience in solution design and implementation. Holds the ability to understand complex business processes and translate them to technology. Expert in Enterprise applications, integration, SOA, SaaS. Experienced in project management, technical infrastructure, procurement and manufacturing.


Recently Commented On

Monthly Archives