The project I’m currently involved requires that business logic must be implemented in Web Service that will be consumed by the Presentation Tier Components (i.e. Web Applications).
The company has an Enterprise Service Bus, and up-to-date almost every Web Service developed is exposed through this bus. I asked some colleagues around about when to expose Service through ESB and I got this answers:
- If there’s an ESB, expose everything through it: There are several benefits like Load-Balancing and location transparency
- If the ESB will only act as a Proxy -i.e no message transformation- just don’t use it: You’ll overload the ESB and lose performance. You’ll better do a point-to-point connection.
- You should expose a component through ESB if there’s a protocol transformation (like exposing a Stored Procedure as a SOAP Service). If this isn’t present you better go Point-to-Point.
So I’m curious if there’s a general agreement or best-practice of when to expose a Web Service through it or not. Any reading/reference would be a great help.
From my point of view and after 4 years of experience with SOA technologies, using an ESB will always overload the system since you are adding a new layer and making all your communications go through it. Transformation (either messaging or protocol) and routing aren’t to hard to accomplish without an ESB and point to point communication will have a bit higher throughput. Same happens also with business process automation, there are ways to get there without the need of an ESB.
In the other hand, the use of an ESB has several benefits in the scope of a corporation but it must be within a vision and strategy. One of the best examples is a company that has been working for a long time with a wide range of tools, each of them for a specific purpose and that made the company be distributed in teams which work in silos, ones isolated from the others. After a long time that makes interaction between teams complex and slow. A well planned SOA strategy will help to integrate all those tools and start replacing them for more meaningful lightweight items.
So, IMHO, Using an ESB just to solve a couple of “issues” in a single project without a corporate strategy isn’t a good idea and, eventually, the word SOA will be banned in your company, when the problem isn’t SOA by itself by rather the lack of vision and corporate strategy.
The only rule of thumb that I found regarding the use of ESBs is: The requirement of transformation, routing, business process automation (with or without human interaction), etc. in a single project is not a symptom of going SOA (almost every project has to perform transformations, routing and business process automation), but when those needs are the ones for a whole corporation then it’s worth to think about it from a business point of view, never a technical one. If there isn’t a business perspective, then SOA will fail.
This is a really wide topic and discussion can last for ages, I will suggest you a couple of links for further reading: