Episode #1: “BPEL vs. OSB”

This episode is a special edition of SOA MythBusters, produced specifically for the IV edition of SOA Magazine (http://soacommunity.com/images/pdf/SOA%20Magazine%20IV%2001.2015.pdf)

Introduction

So, do you work with Oracle SOA Suite?, that’s great because we also do, every single day since a long time ago. As Oracle professionals, we’ve seen the SOA stack grow, change, incorporating new products and technology with each version, from 10g to 12c.

We’re Rolando Carrasco (Oracle ACE) and Arturo Viveros (Oracle ACE Associate), the SOA Myth Busters from Mexico, and as we go with this series we will put to the test a number of questions, myths and urban legends regarding both SOA & the Oracle SOA Platform in seek of finding out which myths are true and which are not.

BPEL vs OSB

In this episode, we will dive into one of the hottest arguments Oracle SOA Practitioners have been sustaining over the years: BPEL against Service Bus.Can and should they work together? Is one of them better than the other? Are there any well-founded guidelines that I can rely on in order to decide between them? And what about SOA Suite 12c? Around this subject there seem to be plenty of myths, misunderstandings and misconceptions, so let’s get it on and uncover as much of the truth as possible.

Let’s get started

First and foremost, the two things we are comparing are pretty much standards before products.

BPEL – Business Process Execution Language. It’s a standard for services orchestration, delivered and maintained by OASIS. It became popular in the early 2000s. Many software companies, like IBM, Oracle, have been actively working on the improvement of the standard. Many software companies offer products that support this standard. For example: Oracle BPEL PM.

Service Bus (a.k.a. Enterprise Service Bus). Since the old days of integration and EAI, the concept of having something in the middle to be able to intercommunicate heterogeneous systems and services has been present. This ESB as a standard, should support: Dynamic Routing, Mediation, Virtualization, Content Enrichment, Service Invocation, etc. A good way to start learning about the standard of a Service Bus, is the book of David Chappell “Enterprise Service Bus” (http://shop.oreilly.com/product/9780596006754.do). This book has already 10 years, but David represented quite well what a Service Bus is, and all the concepts are current to our days.

Now, it happens that Oracle has a product by the name Oracle BPEL Process Manager and another named Oracle Service Bus. That’s what can add a little bit more of confusion to the comparison. And this question: should I use BPEL or Service Bus? It is a common one within the Oracle SOA professionals and we think to any other software company that supports these two standards.

A little bit of history

So let’s start looking into this from a historic perspective. We’ll need to go back in time a few years, so we can attempt to locate the source of the aforementioned controversy and identify some myths.

We remember our first years with this technologies, it was back in 2003-2004, when Oracle first released Oracle BPEL PM. In those days, Oracle did have something to offer in the integration space: Oracle Interconnect. But it was not that popular. When Oracle released BPEL PM, it changed everything. It changed many professional careers, as well as it changed the market.

Oracle didn’t yet had a product quite resembling an ESB, but it did have Oracle BPEL PM. With that product it was able to compete in the Orchestration stage against players like BEA Weblogic Integration, TIBCO, and Web Methods.

Ever since those days, Oracle BPEL PM (we’re referring to the tool, not the standard) was capable of: routing calls, enrichment of messages, virtualizing the access to other services, data model/format transformation through adapters to EIS systems like SAP, Oracle EBS, PeopleSoft, Siebel, Mainframe, etc. Oracle hadn’t started the rampage of buying PeopleSoft, Siebel, etc. so there was no tight integration with them. It was just adapters and this tool which was able to easily communicate with them.

As time went by, a combination of market pressure and industry trends, caused Oracle to include in the 10g release of SOA Suite (year 2007) something called: Oracle Enterprise Service Bus (OESB). Then Oracle could finally say: we do have as part of our stack an Enterprise Service Bus.

As fancy as it sounded, this former version of Oracle’s ESB was somehow limited and never really qualified as a best-of-breed product. Furthermore, it never boded well with architects, developers and administrators who found it a tad complicated and unfriendly.

So, it seems like we’ve identified a first milestone in this BPEL vs OSB discussion. An early version of the SOA Suite we’ve come to know (10g), which included:

• An already robust and highly-liked product based on an up and coming industry standard (BPEL)
• A below average ESB as an optional component of the suite

At the time, Oracle ESB (OESB) wound up not being heavily used in most integration projects outside of AIA implementations. For the time being and the state of industry requirements, BPEL could exist and function mostly by its own.

Then in 2008, Oracle buys BEA Systems, and with this acquisition we come into a second relevant milestone: The release of Oracle SOA Suite 11g in mid-2009. This new and revamped stack introduced some very relevant changes:

1. Oracle WebLogic Server as the runtime platform for all of the tools included in the Suite.
2. Oracle Service Bus (based on the former BEA AquaLogic Service Bus) comes along, as a true ESB capable of positioning itself as one of the market-leading players.
3. 10g’s ESB (OESB), is rebranded as “Mediator” and stays as an optional component of the Suite.

This proved to be a great move by Oracle, and from the technology/architecture standpoint it gave to the components its specific weight. Now the Enterprise Service Bus standards/capabilities were very well identified inside Oracle Service Bus. But if your SOA initiative included orchestration, business activity monitoring, business rules, the Oracle SOA Suite with the rest of the components, was an excellent option.

With this new stack, OSB could even be licensed on its own for clients that wanted to have the ESB alone as a cornerstone for their SOA implementation, though the most usual scenario is for the customers to have both the SOA Suite and the OSB as part of a multifaceted and well complimented SOA Toolkit.

On the other hand, OESB’s rebranding stirred some confusion and otherwise felt a little like a demotion for an incumbent product that didn’t quite stick and was replaced by a more powerful tool.

Finally, coming back to the present we find ourselves months removed from a third big milestone: SOA Suite 12c. In this new major release, the stack itself has been realigned according to the current industry trends (Industrial SOA, Developer Productivity, Cloud and Mobile). The tools are now more integrated than ever and Oracle’s intention is clearly to revolutionize the way we approach and implement SOA.

In SOA Suite 12c it has become much more evident where and when to use BPEL or Service Bus, or when to use them together. According to Oracle, there should be less confusion around this. And in the way the IDEs, engines and monitoring are integrated in this release, the architecture definitions should be clearer than ever.

So let’s summarize everything that we just mentioned:

Year	BPEL	ESB
2003-2007	-Acquisition of Collaxa by Oracle leads to Oracle BPEL PM-BPEL PM provides integration, web-services and BPM capabilities -It quickly becomes the product of choice for Oracle SOA Practitioners	-Oracle doesn’t have a traditional ESB offering throughout this period of time
2007-2009	-BPEL PM continues to evolve and features in Oracle SOA Suite 10g with some new capabilities-The JDeveloper BPEL designer is vastly improved facilitating the SOA developer’s work	-Oracle ESB debuts as a component in SOA Suite 10g-Its main purpose is to “move data among multiple endpoints, both within and outside of an enterprise” -OESB includes a design-time modeler in JDev as well as a web-based runtime console (Oracle ESB Control)
2009-2013	-Oracle BPEL PM continues to headline SOA Suite 11g-Both the runtime and the design time for BPEL are vastly improved -The adoption of WLS as the flagship application server by Oracle, makes BPEL a lot more powerful than it was before, especially performance-wise.	-OESB is rebranded as Oracle Mediator and remains as a component in SOA Suite-Oracle Service Bus (OSB) leverages the former ALSB and is positioned immediately as a full-fledged ESB with lots of capabilities. -The design-time tool for OSB is Eclipse-based (OEPE)
2014 +	-Oracle BPEL PM and OSB have finally converged into an integrated developer environment (JDev) with the release of SOA Suite 12c-The concepts of Industrial SOA, Developer Productivity, Mobility and Cloud Integration drive the improvements in the products, and have been equally applied to both tools, making them more compatible and complimentary than ever.

Looking at this timeline, one can easily see where a lot of confusion could have arisen despite Oracle’s best efforts, especially before 12c:

• BPEL Developers that have been working with the tool for a long time just love it, and have seen the product grow and evolve in an orderly and standardized fashion, with a constant IDE. This as opposed to an ESB that has suffered many changes so far and has not been as easy to get familiarized with. This can lead to radical opinions that are not at all uncommon like: “BPEL is unquestionably better than the Service Bus”, where a sound product like OSB ends up being disqualified for all the wrong reasons.
• SOA Professionals that were already used to work with BEA WebLogic Server, WLS Workbench, Aqua Logic, Fuego etc., are much more prone to like OSB and understand its potential and capabilities. They may even find it easier and more dynamic than BPEL PM due to familiarity with the IDE and web-console. “OSB is just friendlier than BPEL and Eclipse is a much better IDE than JDev”. It wouldn’t be strange to hear an assessment like this one from an accomplished developer with a background in BEA technology.
• People that are newer to Oracle FMW’s stack, always seem to be wondering which one of the products is the best alternative, if they are making the right choice and even if they are over-utilizing or sub-utilizing one of them. In this case, rather than understanding the products as complimentary to each other, we would be unnecessarily stressing out and questioning ourselves over which one to choose.
• Architects and programmers that used to work with the tools from a different vendor (IBM, Software AG, TIBCO, etc.) and are now working with Oracle FMW, usually have trouble identifying the stack at first glance, so they tend to gravitate towards the product which seems to be more familiar and less problematic to them and stay away from the rest based on their past good / bad experiences. This kind of scenario often leads to the most disparate opinions such as: “BPEL just doesn’t work at all and its use implies a terrible danger for the client, we’ll be better off by using exclusively a Service Bus”. Just imagine the turmoil an statement like this can produce, especially when pronounced by an “expert” with a long track record in integration projects.

But is this controversy really just a matter of perception, past-experience, or even post-traumatic stress disorder? We’ve already dived enough into the history, so let’s have a look now at some other kind of facts.

SOA Design Patterns

We saw in the past section how much the products have matured over time. At the same time, SOA as a methodology has also been evolving and maturing through a series of contributions from industry leaders, standards organizations, academics, professionals, architects and technology enthusiasts.

As a result of this contributions, we have a well identified set of SOA Design Patterns: proven solutions to common problems.

NOTE:

*If you want to know more about SOA Design Patterns, make sure to visit the following site for a thorough explanation:

http://www.soapatterns.org/

Here we’ll have a look at some of these patterns and whether they are more suitable to be applied by the utilization of BPEL and/or Service Bus:

SOA Design Pattern	BPEL	OSB
Data Model Transformation	X	x
Data Format Transformation		x
State Repository	X
Rules Centralization	X	x
Process Abstraction	X
Process Centralization	X
Asynchronous Queuing	X	x
Intermediate Routing		x
Event-Driven Messaging	X	x
Protocol Bridging		x
Atomic Service Transaction	X
Compensating Service Transaction	X
Reliable Messaging		x
Policy Centralization		x

As we can see in the table, each tool has its own set of relevant capabilities, some of them shared by both. JCA Adapters can also help us extend the native functionality of the products, especially in the case of BPEL.

Based on the information we’ve just analyzed, we can definitely come up with a collection of pretty accurate guidelines regarding the use of one product or the other for certain scenarios:

• For service virtualization and brokering activities use OSB
• For long running and stateful orchestrated tasks, use Oracle BPEL
• For automatizing business activities based on a process definition use Oracle BPEL
• For incorporating Human Workflow and/or Oracle Business Rules, use Oracle BPEL PM
• For applying policy-centralization and reliable-messaging techniques on web-services, use OSB
• For stateless and short-lived web-service orchestrations use OSB
• For synchronous entity-based services or pass-through operations use OSB

This gives us more clarity, providing appropriate separation of concerns without meaning that we cannot use OSB and BPEL in conjunction for solving sophisticated integration scenarios:

BPEL Service virtualization using OSB

OSB performing mediation duties in a Service Composition

Asynchronous queuing scenario with one-way invocation of a BPEL process through OSB

And how does this look in Oracle SOA Suite 12c?

After looking at the historic perspective, some of the great advantages of SOA Suite 12c have to do with:

• Stability
• Continuity
• Maturity

Unlike past releases, there’s not a major change in the runtime engine, nor in the set of products that conform the suite. This has allowed Oracle to focus on substantially improving each one of the tools, taking in account customer / developer feedback as well as industry trends and requirements.

Oracle SOA Suite 12c, if anything, encourages SOA Practitioners to use BPEL and OSB together in order to design and implement robust solutions with the ability to provide the required flexibility, SLA compliance and transactional capacity the industry looks for.

The following improvements (among many others) seem to be the most relevant in this regard:

• Unified IDE for BPEL and OSB (JDeveloper)
• Unified Monitoring Console with end-to-end tracing capabilities (EM)
• Quick start SOA Suite installer bundle for developers including OSB
• Integrated Debugger for BPEL / OSB
• Error Hospital
• MDS tighter integration
• Continuous Integration through Maven artifacts
• Modularity profiles

 

Conclusion

• While there indeed was a time when one product was more robust and mature than the other in the Oracle FMW Stack (BPEL > Service Bus), this is not true anymore. Even in 11g this point was arguable to some degree, but in 12c both tools have been equally upgraded and aligned with the industry tendencies mentioned beforehand.
• Some of the controversy between these tools, especially among developers, had to do with the presence of different IDEs for BPEL PM and OSB. This proved to be a very impractical situation that has already been taken care of in 12c. JDev is now the IDE of choice for developing Oracle SOA Suite components, whether it is with BPEL or Service Bus.
• Even though BPEL + Service Bus have always been able to work together, in the past there was no pressing need to design solutions based on such a combination. Moreover, the separation of concerns between the tools was not as clear as it is now, thanks to the maturation of SOA Methodology. Nowadays, especially with SOA Suite 12c, BPEL & OSB comprise a terrific and necessary combination. A dynamic duo whose combined capabilities will let us face and successfully figure out the multiple challenges of Industrial SOA, as well as reap its significant benefits.

We certainly hope that this body of work has been interesting, useful and enjoyable for you appreciated reader. Let’s meet again in our next episode!!

The SOA Myth Busters