What I have learned about IBM Worklight mobile application integration
Christian Karasiewicz 270005XS4E Comment (1) Visits (5050)
In my recent discussions with customers, I have found people asking how the IBM Worklight adapter can be used to integrate back-end systems. I’ve heard questions like “What if we have enterprise service bus (ESB) providing the business services?” and “How does mobile integration work in the absence of ESB?”
In this post I will go through three possible scenarios for mobile back-end integration using Worklight. But before we go deeper, here are some short definitions of important terms:
Here is an example use case to explain this topic:
Use Case: A banking mobile app provides the account balance service to the user. The app takes the user’s customer ID. In the back-end system, all the account information is stored at the account level and thus requires an account number as an input. Here are the two interfaces given by the system:
1) getAccountNum: This returns the account number for a given customer ID.
2) getAccountBal: This provides the account balance for a given account number.
Let’s take up the above use case with three different integration styles, considering both ESB and non-ESB scenarios.
Scenario 1: Back-end integration through ESB through a coarse-grained business service.
In this case, we assume that ESB provides a coarse-grained service that can be directly consumed by the Worklight server. Here the Worklight adapter has the role of hooking up the business service. While writing the Worklight adapter, a procedure should be written that invokes the coarse-grained service exposed by ESB. ESB should further call one or many back-end interfaces to fulfill the use case.
In the example, ESB exposes a coarse-grained service called getAccBalService, which in turn invokes multiple interfaces exposed by the back-end system and finally returns the account balance to the mobile app client.
Scenario 2: Back-end integration through ESB with multiple fine-grained services rather than a single coarse-grained service.
In this case, we assume that ESB exists in the enterprise, but it provides multiple fine-grained services rather than a single coarse-grained one. At the Worklight adapter end, a procedure should be written that invokes multiple fine-grained services, forming the aggregated output to be sent back to the client application.
In this example, ESB exposes fine-grained services: (i) getAccNumService and (ii) getAccBalService. These services are mapped to the back-end interfaces. The adapter makes multiple service calls and returns the account balance to the mobile app.
Scenario 3: Direct Integration through Worklight adapter where no ESB exists.
This is a case where ESB does not exist for back-end integration. The back-end application provides one or multiple interfaces, which are directly consumed by the Worklight adapter. The Worklight server provides a variety of pre-built technology adapters, which can be configured easily without doing any additional development.
In this example, the back-end system exposes the interfaces: (i) getAccNum and (ii) getAccBal. The adapter makes multiple direct calls to the back-end system and returns the account balance to the mobile app.
Another case could be integration through IBM WebSphere Cast Iron, but to me that looks like another flavor of ESB. In this case, Worklight provides a ready-made Cast Iron adapter for quicker integration.
In conclusion, it doesn’t matter if the back-end services are available through ESB or non-ESB. I recommend building the back-end integration through the Worklight adapter(s), as it provides the following advantages:
As the IBM Worklight server positions itself as a leader in mobile enterprise application platforms (MEAP), the adapter component will have a decisive role in delivering enterprise mobile applications.
Do you have any other integration styles for mobile back-end integration? Leave a comment below.