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

2

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.

imageAs 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:

image

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

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.

About Author

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director and Oracle Developer Champion. Solution architect and developer on diverse areas including SQL, JavaScript, Kubernetes & Docker, Machine Learning, Java, SOA and microservices, events in various shapes and forms and many other things. Author of the Oracle Press book Oracle SOA Suite 12c Handbook. Frequent presenter on user groups and community events and conferences such as JavaOne, Oracle Code, CodeOne, NLJUG JFall and Oracle OpenWorld.

2 Comments

  1. good posting.. I dont get your point about why its a gain for service bus! Now it have overlapping functionality between mediator and proxy within SOA composite. can you throw some light on Mediator vs Service bus in 12c?