SOA Suite 12c: The demise of the OSB and the glorious birth of the SB

Oracle has too many products. The range of acronyms is not infinite, especially when most of these acronyms start with an O and have three letters. As it turns out, OSB is Oracle-ese for Oracle Secure Backup. Well, and it used to also stand for Oracle Service Bus – but starting with SOA Suite 12c – that is no longer the case. The OSB is no more (or at least: it is no more the acronym for the Service Bus).

Does this mean the end of the Service Bus? Of course not. In fact, the Service Bus has gained in prominence. Or at least, it has moved closer to the SCA engine in the SOA Suite – the engine that runs SOA composite applications with BPEL, Mediator and Business Rule inside. The engine that may of us used to refer to as… the SOA Suite.

As of SOA Suite 12c, both Service Bus projects as well as SOA composite applications (SCA composites) are developed using JDeveloper. Both are deployed to [their respective engines] in a WebLogic managed server (can be the same managed server, can be two different ones).

Administration activities on Service Bus components and on SOA composite components – including deployment, configuration, monitoring – are done through the Enterprise Manager Fusion Middleware Control console. Both Service Bus projects and SOA Composites can make use of JCA Adapters, XQuery transformations and XSLT maps, Domain Value Maps and XRef Cross References, native-to-XMLtranslation and other facilities that make developers’ lives easy.

A single install suffices – JDeveloper with integrated WLS – to develop and test SOA Composites and Service Bus projects. And the skill set required for both is remarkably similar – quite a bit more than in the past.

So, while OSB as a product indication disappears, Service Bus [development] is on par in almost all ways with SOA composite [application construction]. It is not a loss, but a gain instead.

By the way: notice how similar the visual representation of Service Bus projects (proxy service, pipeline, business service) is to a SOA composite application (service binding, Mediator, reference binding). The visual similarity is of course no accident: the logical composition and the function of both implementations is very similar as well. The difference between these two service implementations is in the details mainly.

First figure: SOA Composite application – exposing a SOAP WebService binding, implemented by a Mediator that invokes an outbound JMS Adapter:

Second figure: Service Bus project – exposing a SOAP WebService proxy, implemented by a Pipeline that invokes an outbound JMS Adapter:

And of course both the Mediator and the Pipeline do a transformation of the request message. They both use the same XQuery document for this.