OSB vs BPEL

One of the fundamental concepts of SOA is service reuse. There are significant cost benefits to reuse. This involves discipline and governance in defining the interfaces of the services to be reused. However it is not reasonable to re engineer all your existing applications to be reusable. What is required is service virtualization by a layer in front, which has the architected controlled reusable interfaces. This interface needs to be governed through an enterprise repository and discovered for reuse through a service registry.

Another problem is that application interfaces change over time as business requirements change and evolve. However in a successful SOA practice, these applications are heavily reused with lots of clients. The change to the interface has a ripple effect across all the clients who need to absorb the change. What is required is agility in the IT systems to minimize the impact of such changes so such changes can be done quickly and easily. This not only has cost benefits but also business benefits due to agility to meet new business requirements. To achieve this, we need a virtualization layer in front that the many clients talk to, which can be the point of absorption of most such changes.

Oracle Service Bus (OSB) is a high performance stateless enterprise service bus that provides this virtualization layer that facilitates reuse. OSB deals not only with XML interfaces but also binary, text, java(future) and structured binary (example SWIFT) interfaces. All these data types can be natively stored in OSB variables.

What are the types of changes OSB can absorb? OSB can largely absorb all of the following changes. As one of many examples, you do not want to constantly modify a BPEL process for all these changes but rather abstract out these changes to OSB in front of or behind the bpel process.

- Changes to the document format, say due to xml schema changes or even changes to the version of structured binary data. Transformation can be done by java code, XSLT, Xquery, or MFL to convert between structured binary and XML. OSB supports any to any bridging between formats.
- Changes to packaging say from soap 1.1 to soap 1.2 or even from REST to soap.
- Changes to where the messages need to be routed or load balanced.
- Changes to the location of a service (change in address).
- Changes to the security scheme, say from HTTP basic auth to web services security username token.
- Changes to the transport, say from HTTP to JMS. OSB supports a large number of transports and you can also seamlessly plug in new transports. OSB supports any to any bridging between transports.
- Changes to the invocation style say from one-way to request/response. OSB supports any to any bridging between supported invocation styles.
- Changes to what data the message is enriched with. OSB has a variety of ways to lookup data. You can lookup data in a databases or invoke web services or java code to do lookups.
- Split of a service or operation into multiple services or operations that need to be invoked in sequence or in parallel or a mix of the two. Alternatively merge of a set of services or operations into a single service or operation.
- Changes to the routing rules.
- As service reuse increases, the service gets overloaded and needs to be throttled.

Even if there are no difference initially between the OSB interface and the enterprise services it virtualize it is good to architect in OSB as an intermediary for more easily handle future changes.

BPEL on the other hand is focused on orchestration of long running or short running processes. The core of a process logic is implemented as a BPEL process.
The focus is very different. You would NOT put process logic in OSB.