Flying in Formation: Helidon and WebLogic Integration in Oracle Communications Order and Service Management
Success comes in unrecognized ways: for example, integrating newer computing paradigms and technologies with established paradigms and technologies, to meet new market needs while preserving core application value.
Consider the case of Oracle Communications Order and Service Management (OSM). A proven and widely adopted solution in the communications industry for managing the fulfillment of orders and activation of services within communications service providers, OSM handles much of the world’s incoming business of that kind. When you buy the latest new mobile phone and accompanying service plan from your chosen cellular provider, chances are the fulfillment of your order and activation of your service (as well as orchestration of backend processes like inventory management and billing) is managed by OSM.
As an established product, OSM has long used the paradigms and technologies of its time: a Java enterprise application powered by Oracle WebLogic Server (WLS), deployed on bare metal or virtual machines on the premises of its users. But times have changed, and OSM is changing with them, in response to customer demand.
OSM is now on two different journeys simultaneously: a cloud-native journey, and a microservices journey. Much of the cloud-native journey has already been completed in OSM 7.4.1, with containerized deployment orchestrated by Kubernetes already available, leveraging WebLogic Operator. The microservices journey is in progress in OSM 7.4.2, and that’s where Helidon comes in. OSM’s core process engine remains in WLS, while ancillary functionality is migrated to microservices. As OSM introduces new capabilities, those too will be implemented as Helidon-based microservices — and that evolution is very important and mission-critical to OSM. Figure 1 below depicts both journeys.
“It’s not just a beauty contest [adding microservices to OSM]. We need the components to be separate from the main WLS application so that they can be distributed in other data centers, because customers need deployments to be multi- data center with geo-distribution, but the central orchestration function is mission-critical to them. So the ability to distribute these light components is of great importance to our architecture.” — Francois Truchon, Senior Director, Product Development, Oracle Communications Applications Global Business Unit
An architecture featuring Helidon microservices flying in formation with WebLogic-hosted functionality necessitates integration between Helidon and WLS, as OSM has implemented. Its development team has incorporated integration at multiple points, including:
- Consumption and production, within Helidon Release 2.5 components, of messages on WLS 12.2.1.4 -hosted Java Message Service (JMS) destinations, with CloudEvents envelopes (soon to be upgraded to Helidon 3.0 and WLS 14.1.1)
- Invocation of WLS-hosted web services from Helidon components
OSM’s original architecture depends heavily on WebLogic’s JMS capabilities. Customers integrate external systems to OSM using JMS to deliver correlated events in long-running business processes. But now customers want to move to REST-based integration. So OSM is introducing a new Ordering microservice, built on Helidon, with a REST interface aligned to OpenAPI-based industry API specifications from TM Forum. Inbound orders to OSM will be received via the REST interface, and outbound orchestration interactions will occur over REST calls and messages on JMS. Kafka support will appear in a subsequent release, and the architecture will support additional message brokers like Pulsar. These OSM architecture aspects are depicted in Figure 2.
The observant reader will notice that both Helidon API flavors, Helidon SE and Helidon MP, are used in the design and implementation of the OSM REST Ordering Microservice, and in fact in the same JVMs running that microservice. That is possible because Helidon has a layered architecture, with the Helidon MP API layering on top of Helidon SE capabilities. Leveraging both API flavors within the same microservice allows an application to select and use the API flavor that best fits a given context: in this case, Helidon MP for integrating with WLS JMS and web services, and Helidon SE for integrating with external systems via JMS, Kafka, or REST.
OSM’s evolving architecture has shined a light on additional natural integration points between Helidon and WebLogic which work easily today using existing capabilities:
- REST calls in both directions between Helidon and WLS components
- Transaction coordination enlisting resources in Helidon and WLS, using Oracle MicroTx Free
- Security integration facilitating single sign-on across services built with Helidon and WLS
All such integration points are likely to be used widely going forward, because it is natural for such hybrid Helidon/WebLogic architectures to become commonplace as additional established application owners embark on their own cloud and microservices journeys.
As time goes on there is no doubt that Oracle Communications Order and Service Management will continue to be a shining success story, like Oracle Hospitality Integration Platform and Oracle CX Industry Framework, in recognized ways. It will eventually enjoy widespread cloud-based deployments of the new hybrid architecture featuring integrated Helidon and WebLogic components flying in formation. And OSM will not be the only story with this theme. Watch this space for future success stories of other applications on the same journeys.
