Skip to Content
Author's profile photo Matthias Steiner

Coffee Corner Talk: ESB and SOA

Thinking out loud…

Coffe cup

Those who work for or close with SAP will probably agree with me when I say that coffee culture is one of the essential pillars that the company is built on. All campuses feature several coffee corners and I know more than one colleague that would go the extra mile to get the “best” coffee. I guess it’s safe to say that some of the best ideas that came out of this company were “born” during a coffee corner talk…

I recall one particular event that underlines the importance of coffee culture at SAP: the announcement that the employees would get charged for coffee on April Fool’s Day. It caused a huge storm of protest until a clever person pointed out the date this announcement was published on… 🙂

In this tradition I labeled this blog’s title as such to emphasize that the topics discussed in this blog are to be understood as something I’d talk about with some of my respected peers during a coffee break and NOT the result of a cohesive study!


On more than one occasion I encountered being challenged with the question on the role of an ESB within a Service Oriented Architecture by customers. Typically, we (Custom Development) design composite applications as such as they do not require the presence of SAP NetWeaver Process Integration (PI) unless there’s no other way. The most important reason for this approach is the fact that we do not want to make it a mandatory component of our proposed solution in cases where the particular customer does not have PI installed on his landscape.

Yet, the SOA purists usually argue that an ESB is essential for SOA and without it the entire SOA approach does not make any sense at all. On the other hand, I can envision (valid) objections if we would make it a mandatory component in the design of a composite as well: “Common, you are not trying to tell me I need PI to run this composite application of yours, right?

Well, probably the truth is somewhere in between…

Wikipedia: “An ESB does not implement a service-oriented architecture (SOA) but provides the features with which one may be implemented.

As promising as a single point of contact in the form of an ESB may be for a SOA based IT landscape, the question whether or not it is mandatory to route all service calls through it remains valid. Depending on the number of systems, applications and users in your enterprise the system resources it would take to handle both synchronous and asynchronous communication via an ESB may be too high to justify the hardware costs – eventually resulting in a bad TCO.

Key capabilities of an ESB

So the question at hand is why people may feel like SOA dictates routing all services through an ESB? Where’s the benefit? Ultimately it would have to be a great benefit if people would accept the consequences of such an approach. In order to answer that question we should look at the feature set and the capabilities an ESB brings to the SOA table:

  • Communication infrastructure (messaging and connectivity)
  • Request routing and version resolution
  • Transformation and mapping
  • Service orchestration
  • Process and transaction management
  • Security
  • Quality of service
  • Services registry and metadata management
  • Monitoring and management
  • Support of Standards (WS RM, WS Security, SAML, BPEL, UDDI, etc.)
  • Distributed deployment and execution

(Please refer to SAP NetWeaver Process Integration 7.1 – Overview published by the Product Management of SAP NetWeaver for more details.)

So, if none of these features is actually required for a particular service call, why route it through PI? I can already hear the objections: “But what if one needs to use any of these features in the future…” Good call! If you need to leverage such functionality to route, transform, mediate, orchestrate etc. the service at a later stage in time you can transparently put a PI WebService Proxy in between – then. Voilà!

Figure 1 – Direct call

From the consumer’s point of view it does not matter whether the corresponding service provider system is called directly or through PI. From a technical point of view it’s simply a different URL endpoint that can be configured. This is exactly the rational we apply when designing composite applications…

My colleague Katharina Seiz wrote a very comprehensive walk-through about how-to create WS Proxies with PI, which can be found “Web Service –> PI –> Web Service” Scenario – A Complete Walkthrough!

Direct Connections

In cases where the decision makers or responsible IT departments defer from my point of view and insist on routing all communication through PI (for the sake of E2E monitoring, being future-proof for orchestration scenarios, etc. ), there’s a new feature of SAP NetWeaver Process Integration 7.1 that helps in doing so without most of the processing overhead: Direct Connections. In a nutshell, it allows to use all the configuration and monitoring functionalities of PI, yet the entire runtime (transformation, mapping, etc.) is by-passed.


Figure 1 – Mediated call


In order to wrap-up this coffee talk I feel obliged to emphasize that it is not my intention to downplay the central role PI (or any other ESB) plays within an SOA. I just stated that a pragmatic approach may be valid in a lot of scenarios. Direct point-to-point connections are not bad per se as they can still be replaced by plugging a WS Proxy in between to mediate the service call in a transparent way (if one needs/wants to do so at a latter point in time.) The new ‘Direct connection’ feature provided by PI is a great addition that allows to leverage central monitoring without the overhead of a fuel-fledged mediated service that requires sophisticated mapping, routing etc.

Furthermore, I focused only on the runtime aspects. For sure, the Enterprise Service Registry (ESR) hosted by either PI or CE is best-suited to keep all your design-time data of the services in your SOA in a central and well-organized place.

On a sidenote… 

There may be contradicting visions on whether or not SAP NetWeaver Process Integration qualifies as an Enterprise Service Bus or not. Well, from my point of view I’d say definitely yes as the feature set provided by it are typically attributed as the key capabilities of an ESB.

So, for the sake of this blog I won’t touch on that topic any further but instead kindly redirect anybody willing to discuss that topic to the blog of Swarup Sawant about: “A Perception – Is PI/XI as an Enterprise Service Bus (ESB)?

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Sascha Wenninger
      Sascha Wenninger

      Thanks for highlighting some truths which should be obvious, but are nevertheless often overlooked. Most (~80%) of the time, one can do without an ESB or other middleware. YAGNI applies. And if you find you need it, it's just a URL change...

      So in my books, an ESB would have to add more concrete benefits than "monitoring" and the odd bit of governance. There are definitely places for it, just not in every integration point.

      My $0.02


      Author's profile photo Matthias Steiner
      Matthias Steiner
      Blog Post Author

      Well, that was the whole point right. In some scenarios there's already an ESB in place and it makes sense to integrate a solution via this ESB.

      In other scenarios it may not (yet) be requried and you sure don't want to add one as a "side dish" as part of your project 😉



      Author's profile photo Former Member
      Former Member

      Hi Matthias,

      In my (relatively) limited experience, I think the most important point from this is "a pragmatic approach may be valid in a lot of scenarios".  I'd go so far as to change that to "a pragmatic approach may be valid in all scenarios".

      It is easy for SAP to release guidelines and best practice approaches (and this is the right thing to do) as well as wider industry standards and practices to be adopted within SAP landscapes.  However, other constraints, such as time, resource, budget, IT strategy, hardware, etc. always come into play, and that is before individuals involved with SAP systems start adding their own experiences and opinions into the mix.

      There is a very real danger of following a SOA purist approach just because it is supposedly the "right" way of doing things - it may not be the right way for a given scenario though.  The same goes for following an SAP purist approach too.

      The key is to follow a strategy and approach that works for the system, it's users and it's owners/operators/maintainers, and being open to the fact that your approach may need to change over time.  I'm not sure any type of purist approach is really possible in the real world!


      p.s. One benefit of the new SCN is re-discovering lots of really interesting content on here, such as this posting, that I may have missed first time around. 🙂

      Author's profile photo Matthias Steiner
      Matthias Steiner
      Blog Post Author

      Hi Gareth,

      indeed. It's been 3.5 years ago since I wrote that down and some of it is still being discussed these days...

      Oh, and the purist approach usually works very well in the top floor of the Ivory Tower, but being pragmatic usually helps on the street 😉



      Author's profile photo Tom Van Doorslaer
      Tom Van Doorslaer

      It's odd isn't it?

      3.5 Years since you wrote this coffee corner blog

      Yet today, I still have to explain people what the role of any ESB is and what the benefits are.

      "Yes you can do without, just like those other 17 projects. But don't you think you can reduce the TCO?"