Coffee Corner Talk: ESB and SOA

[matt_steiner]

Thinking out loud...

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!

ESB in SOA

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...

 Note:
My colleague katharina.seiz/blog 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

Conclusion

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/blog about: "A Perception – Is PI/XI as an Enterprise Service Bus (ESB)?"