BPM, Workflow, and Case

BPM, Workflow, and Case

Come for answers. Stay for best practices. All we’re missing is you.

 View Only

Modernizing IBM BAW Advanced Mediation Flows for the cloud-native world

By Larissa Auberger posted Thu March 21, 2024 07:24 PM

  

Co-authors: Allen Chan,  Sreehari Sreedharan

Many business-critical applications in enterprises today are traditional applications that have been developed more than a decade ago and therefore weren’t designed for the cloud-native era. When enterprises decide to leverage the benefits of cloud-native, they need to take a thorough decision around traditional applications. These are too critical to be just retired. Rip and replace thousands of lines of proven code and business logic is too costly and inefficient.

Business processes built on IBM Business Automation Workflow (IBM BAW) can be operated in a traditional and a cloud-native environment. However, the advanced capabilities of IBM BAW such as BPEL processes and Mediation Flow Components (MFC) only work in a traditional non-container environment. They enable processes to use sophisticated transactions, advanced integration and connectivity as well as data transformation.

While the traditional runtime environment of IBM BAW is well known for its operational stability and reliability, enterprises start to see advantages from developing applications and operating them in a cloud-native manner. These advantages include a faster time to value because of agile development practices and automations, reduced costs through containerization, and a higher portability provided by platforms such as Red Hat OpenShift acting as a runtime and management layer across hybrid, public and private clouds. Enterprises therefore define application modernization towards cloud-native as a priority.

The challenge in context of IBM BAW advanced capabilities is that approaches for transactions, integration and connectivity fundamentally change in the cloud-native world. We need to re-think, for instance, how to align new principles such as microservices — small stand-alone components using their own databases — with the need to support business transactions while still maintaining data consistency across services.

Over the last year, we have been working with several globally operating IBM customers on how they can modernize their BAW Advanced projects that utilize Mediation Flow Components. We analyzed common challenges to develop and validate approaches for transforming these IBM BAW Advanced capabilities to a cloud-native environment.

In this article we are sharing the results from this work. Our intent is to assist enterprises on their path to modernizing advanced IBM BAW workloads to meet their goals of agility and speed in a cloud-native environment.

The building blocks of a mediation

The advanced capabilities of IBM BAW including mediation flows are developed in IBM Integration Designer. In the following example let’s review the building blocks of a mediation.

When opening the project, we can explore the mediations in the Assembly Diagram.

A mediation intercepts the interaction between a service consumer and a service provider to support loose coupling. In a traditional application, benefits of loosely coupled components included a higher reuse of components, as well as improved extensibility and scalability.

A mediation is exposed through exports which specify the interfaces that are made available to external. These interfaces are defined in a WSDL document.

A mediation invokes a service provider. Service providers are declared in the imports that define the external service to be invoked.

From the project let’s have a closer look at the mediation module called SegmentationServiceMediation. It has a service consumer which is an external client: 

  • the web service SegmentationService_WS

and a link to a service provider, which is a service outside of the module:

  • the EJB SegmentationController_EJB
Figure 1 Mediation in Assembly Diagram

Let’s drill down into the SegmentationServiceMediation.

For every operation that gets exposed via an export of the mediation module, a mediation flow is defined. Every mediation flow contains the mediation logic, declared in a graphical way. The mediation module SegmentationServiceMediation contains more than a dozen operations. All of them implement pretty much the same sequence of processing steps.

Let’s look in more detail into the mediation flow of the operation readSegmentation.

The mediation flow consists of

  • a flow to process the request (request flow) and to prepare the input data for the invocation, and
  • a flow to process the response (response flow) and to prepare the output data for the service that initiated the request

The building blocks of each flow are the mediation primitives. They are wired and configured to transform the data to meet the format expected by the target, to log messages or to lookup in databases.

Figure 2 Mediation Flow

Within the readSegmentation operation of the SegmentationServiceMediation, we can identify the following building blocks:

  • Message loggers (LogRequestMessage and LogResponseMessage) that copy the request and the response messages to a database for future use or audit.
  • Data transformations (MapWsToEJB and MapEJBToWs) that transform message formats or change message content by mapping between source and target message types.
  • Fail steps (e.g. LogRequestFail or MapToWsFail) that throw an exception and terminate the path through the mediation flow.
  • Service Invocation where the service is invoked using the transformed message and data.

Reflecting what we have investigated, the purpose of the mediation flow is to leverage the business logic by calling an EJB with the proper input data and to provide the correct response back to the caller.

In the next section, let’s explore the approach to redesign mediations for the cloud-native world.

The approach to redesign mediations for the cloud-native world

As we have decomposed the mediation in a previous part, we have identified that it consists of business logic and integration.

For a modern cloud-native application we must ensure compatibility with standards such as Open API, JSON and Kubernetes. We also need to ensure that new runtimes can take advantage of the cloud-native aspects.

One of the key benefits of the cloud-native approach is that applications are composed of various components that can be based on different runtimes, smoothly playing together by leveraging integration standards. That means we can select the most appropriate runtime for different purposes. In case of a mediation, let’s look into the runtimes that best address the requirements for

  1. business logic modernization and
  2. integration modernization

We need to take different paths for both efforts, as depicted in Figure 3.

Figure 3: Path to modernization of a mediation

Modernizing the Business Logic

Let’s have a closer look at the path to modernize the business logic, provided as Enterprise Java Beans in our mediations.

When designing the modernization path for the business logic, there is one important aspect to consider: the existing business logic is proven and mature code. To save cost and to minimize the overall risks of the modernization efforts, this code should be re-used to a high extend in the cloud-native world.

At this point, we are not talking about splitting these monolithic components into microservices, we just want them to become cloud-native ready. This can be done in several steps:

  1. To eliminate the traditional application server, we propose a move to WebSphere Liberty as the modern new home for the business logic. WebSphere Liberty, based on Open Liberty, is a proven runtime for modernizing applications without major code adjustments. It is a cloud-native runtime that provides all the benefits of a container platform with centralized logging, monitoring, scalability and high availability.
  2. WebSphere Liberty allows for a step-by-step approach on the way to cloud-native. Coming from a monolithic application with traditional infrastructure and traditional operations, WebSphere Liberty allows to enable the monolithic application to run in a container on the cloud-native runtime. Eventually, if there is a business need to further breakdown the monolith application, it can be re-factored into microservices in manageable steps, taking further advantages of the cloud-native paradigm, as outlined in Figure 4.
    Figure 4: Step-by-step approach to modernizing runtime, operations and architecture

    The modernization flow includes defining the APIs for the modernized business logic using the OpenAPI standard. The new interfaces, described as REST APIs can be discovered and used in applications and flows.

Modernizing the Integration Flow

To modernize the integration flow, we chose to leverage IBM Workflow Process Service for the following reasons:

  1. IBM Workflow Process Service is a fast lightweight runtime which runs in a container and can be started and stopped in seconds.
  2. IBM Workflow Process Service supports RESTful APIs as a primary communication protocol. Built-in tooling in IBM Workflow Process Service allows to discover data types and operations using the OpenAPI specification of the service.
    Figure 5 shows an extraction from the list of data types discovered from the OpenAPI specification of the modernized business logic.
    Figure 6 shows an extraction from the list of operations discovered from the OpenAPI specification of the modernized business logic.
    Figure 5: List of data types discovered from the OpenAPI specification of the modernized business logic


    Figure 6: List of operations discovered from the OpenAPI specification of the modernized business logic
  3. IBM Workflow Process Service provides an intuitive graphical development environment for creating service flows. It is also possible to define variables using the previously discovered data types. The service flows can consist of activities including service tasks, server script tasks and other tasks that you drag from the palette to the canvas.
    Figure 7: Calling an operation of the modernized EJB from a service flow

    The operations from the modernized business logic that have been discovered previously, can be selected for the implementation of a service task. To provide input to the service and receive back the output, data can be mapped from available variables to the expected input and output — as defined in the OpenAPI specification of the service. All these steps can be completed in a low code or even no code fashion.

    Figure 8: Mapping input and output data

Conclusion

With the described approach, we can avoid going directly from the traditional application to the microservices world, where the application needs to be re-architected and a lot of new code needs to be developed and tested, while the benefits would only be seen at the end of the tedious efforts. In addition, with the monolith application enabled for and running in a cloud-native environment, you can develop new services as microservices and use them to extend the existing monolith application features at your own pace.

In the proposed modernization approach, Red Hat OpenShift acts as the infrastructure, providing the benefits of a centralized logging, centralized monitoring, scalability and high availability. Traditional operations are replaced with DevOps for containerized applications to automated deployment and operations.

To manage new technologies around migration and the cloud-native infrastructure, expect to require a learning curve. However, frameworks and tools are available to make the modernization easier.

References

  1. The described approach has been proven in an IBM Client Engineering engagement. IBM Client Engineering provides innovative ways to co-create with IBM experts to solve complex business challenges.
  2. IBM Workflow Process Service is a lightweight, cloud-native process capability for authoring and running processes.
  3. IBM WebSphere Liberty is a cloud-native runtime that has proven itself in a variety of modernization journeys.

0 comments
13 views

Permalink

https://community.ibm.com/community/user/blogs/larissa-auberger1/2024/03/21/modernizing-ibm-baw-advanced-mediation-flows