Disintegrating dependent services from the ActiveMatrix BusinessWorks service

Use Case 4: A customer use case was designed such that the dependent services were integrated into the same project and multiple service calls were present in a single ActiveMatrix BusinessWorks application.

The following image shows one of the processes where there are multiple sub process calls.

Example

Each of these sub processes eventually calls the dependent services in the form of REST API or HTTP calls. For the given SLAs, the overall performance of the application was extremely low. Test results and analysis showed this was due to the way the application was designed. The dependent services were integrated with the actual ActiveMatrix BusinessWorks services in the same application and the application was deployed on a single AppNode. Hence, the AppNode resources in terms of CPU, memory and threads were shared between the dependent services and actual ActiveMatrix BusinessWorks service.

Testing and Measurement

The testing was focused on the aspects listed below:

  • Load tests were run with increasing concurrency and default thread settings.
  • To understand the scalability of the project, the ActiveMatrix BusinessWorks engine threads and HTTP connector threads were tuned and the tests were repeated.
  • The dependent services were created as separate applications. The actual ActiveMatrix BusinessWorks service and dependent services were deployed on separate AppNodes on separate machines. The test results showed improvement in performance with these design changes.
  • In order that the actual ActiveMatrix BusinessWorks services have complete resource availability, it is recommended that the dependent services are separated from the actual services and deployed on separate AppNodes. The design changes should be validated and implemented if necessary, whenever resource sharing seems to be an issue between the services.

Additionally, there are two cases that need to be considered when designing the application. One is when the dependent and actual services are part of the same application module and the second is when the dependent services are designed as a shared module.

  1. Same application module : If both the services are part of the same application module they need to be created as separate processes and both the processes should be deployed on separate AppNodes. This can be achieved in the following way:

    Consider an application module that comprises of two processes P1 and P2. P1 is the main service and P2 is the dependent service. One way of deployment is by creating two AppSpaces with one AppNode in each of the AppSpaces. The application can be deployed in both the AppSpaces. The user can then keep component P1 running in AppSpace 1 and stop P2. In AppSpace 2 the user can stop P1 and keep P2 running. P1 in AppSpace 1 and P2 in appspace 2 can communicate with each other.

    In this way the separate resources will be available for both the processes. It is also recommended to ensure that the thread pools are not shared by the activities across the processes.

    It is recommended that this approach is tested and validated before deployment.

  2. Shared module : If the dependent services are part of a shared module they get bundled into the EAR of the main service . Hence, in this case separation of services cannot be achieved.