SOA Suite 12c: The Star of the SOA Suite 12c – The Pipeline

Every new product release has a star. And of course picking that star is arbitrary. One person’s favorite feature may not be someone else’s. My pick of the 12c crop is … (drum roll) …. the Pipeline! The Pipeline is new – to some extent. In Service Bus 12c, instead of a Proxy Service that contains a Message Flow as we used to have in previous incarnations of OSB and Aqualogic Service Bus, we now have two separate components: the Proxy Service and the Pipeline (which contains the Message Flow).

Example: Service Bus project – exposing a SOAP WebService proxy service (AircraftMovementService), implemented by a Pipeline (the green component in the middle) that invokes an outbound JMS Adapter through a business service:

Compared to the 11g situation, where the message flow was encapsulated within a single proxy service, pipelines in 12c are a huge step forward. Pipelines allow for much better structured development with smaller chunks of functionality inside a single pipeline, compared to 11g message flows inside proxy services, and with much more reuse (and then I have not even mentioned pipeline templates…) For all intents and purposes: developing Service Bus projects using this concept of pipelines is very similar to the development of SOA Composite applications. Be aware that Service Bus is completely separate from SCA and that none of the SCA terminology applies to Service Bus or Pipeline. However, the notion of service components with service interfaces that can be reused, chained (wired) together, etc. clearly applies to pipelines as well.

Pipelines can be chained: a pipeline can invoke a business service (as is shown overhead) but can also invoke another pipeline – as is shown here:

Pipelines can be reused: multiple proxy services (and/or multiple pipelines) can invoke the same pipeline – directly or indirectly. A SOAP WebService proxy and a REST JSON Service proxy can leverage the same Pipeline.

A call out or publish action (not just a routing operation) from one pipeline can invoke another pipeline.

Along the same vein, a conditional branch can conditionally call out to one pipeline, selected from several pipelines (or business services), as can a split-join component. Service projects can grow into quite complex constructs, that are still fairly easy to understand and maintain, thanks to the visualization in the editor and clear meaning of the pipelines.

The next picture shows a project with two proxy service, two business services and five pipelines along with two Split/Join components. The similarity with SOA composite applications is striking, I would say.

The numbers in this screenshot indicate what the message flow is like at run time. Starting from the proxy service, the flow goes through the logging pipeline, the FightScheduleValidationPipeline, the ProcessingAndRichmentPipeline and finally the PrivateSubmitFlightScheduleService. The ProcessingAndRichmentPipeline calls out to the SlotService and the PararllelEnrichmentSplitJoin component. The latter also calls out to the SlotService and to the CheckAirlineWithFinanceDepartmentPipeline.

A pipeline can be run & debug[ged] from JDeveloper (as well as from the Service Bus console).

This means that during development, very quick change-deploy-test cycles can be run, that do not require the entire Service Bus Project to be complete. Simply test-run the Pipeline, make adjustments and test-run it again.

Creating a Pipeline

A Pipeline can be created from a WSDL service definition document:

or just by dragging and dropping the Pipeline component from the component palette:

A proxy service can also be exposed as a pipeline (which will simply create a pipeline with the same service interface as the Proxy Service and a wire from the Proxy Service to the Pipeline:

An existing proxy can be linked to a pipeline – by creating the wire in the visual editor

and from the proxy service editor:

The pipeline configuration defines the interface it implements – similarly to a proxy service. Pipeline will usually implement a SOAP Web Service interface. Additional details about message handling, operation selection and resequencing of messages can be specified on the pipeline as well.

A pipeline contains a message flow (just as in the OSB 11g and before Proxy Service) with pipeline pairs, assign and replace activities, call outs and routing actions. So you implement a pipeline in the same way as you did a proxy service prior to this 12c release.

Bonus feature: Drop Pipeline on Wire

A new pipeline can very quickly be created by dropping it on an existing wire – from Proxy to Pipeline, from Pipeline to Business Service or from Pipeline to Pipeline. A new Pipeline is created – assuming the service interface of the target of the wire that it was dropped on. For example – in the next figure, we drop a pipeline on the wire from an existing pipeline to the business service. A wizard appears to create a pipeline. This pipeline will expose the same interface that the business service exposes.

Additionally, the existing pipeline will now route to the new pipeline instead of to the business service – and the newly created pipeline will contain a routing action to the business service:

Summary

The pipeline component in Service Bus 12c will make a large and very positive impact on the development of Service Bus projects. The implementation of Service Bus services can be done in a much better organized way, with clearer units of functionality, separated responsibility, development and testing of smaller units and easy reuse. What the WITH clause (and the inline subquery) did to SQL, will the pipeline do to Service Bus development. (that observation will probably not mean a whole lot to most people). Trust me: the impact is huge.

It is interesting how conceptually the development of Service Bus projects is now similar to the creation of SOA composites – with pipelines seemingly in the role of components. Note however that Service Bus is not SCA in a technical sense!