In a typical enterprise Mendix deployment, it’s not just one or two apps working independently. Often, we see multiple apps working together and sharing resources. Adhering to a component-based approach, in this scenario multiple Mendix apps behave as components in a larger system. Together, the components can be combined in various ways to create full applications.
Synchronization between the individual components may happen by pull services for data retrieval and push services for updates. This type of architecture is often referred to as ‘service-oriented architecture’ (SOA). Please refer to the presentation ‘Divide and Conquer‘ to learn more about the advantages of SOA and loosely coupled components.
The natural way for Mendix apps to publish and consume services among each other is by way of App Services.
Unique to Mendix, App Services let you expose data and functionality of your apps as microservices, and mix and match the services in your app ecosystem in every imaginable way. The best part: you don’t have to worry about the complexity of web services, XML mappings, and schemas. Please watch this presentation at Mendix World 2014 which is a good start if you’d like to learn more.
App Services, like traditional web services, have endpoint URLs where they can be accessed. The endpoint for accessing an app service can be overridden at design time by specifying a constant with the actual location. However, for enterprise deployments as discussed above this is not always flexible enough.
In Mendix 5.14 and below, the setting to override an app service location looked as follows.
In the Settings tab of a consumed app service, we can specify whether we want to override the app service location. If we choose Yes here, a constant (in this case
@AppServiceLoc) is required that will determine the endpoint location for all calls to this app service. In the No case, the default location, for instance
http://localhost:8080/ws/TestAppService/1/soap1, is used.
The following diagram illustrates the old situation where you have multiple providers and consumers of an app service X. Consumers of X only know about a single provider of service X at a time:
Introducing the Parameter
From Mendix 5.15 on, the Modeler gives you the choice between three options:
- Default Equivalent to the previous No option. The app service location is not overridden.
- Constant Equivalent to the previous Yes option. The app service location is overridden by a global constant.
- Parameter A special parameter,
AppServiceLocation, is introduced in every call to an action which the consumed app service makes available.
Using the third option, Parameter, adds the flexibility to determine the location of the app service at runtime. Now we can launch new instances of our Mendix apps and let them synchronize their data with others, without having to edit the model!
When you upgrade an existing project containing a consumed app service, your settings will be preserved and converted to either Default or Constant.
The following diagram shows the new possibilities: each App Service consumer can consume any number of instances of service X. A new instance of a service provider can register itself with a consumer so it knows about which providers to call.
The following example shows how an app can call the ‘Register’ action on multiple instances of the same app service on different endpoints by iterating over a list of app node locations. The endpoints are passed on as value of the AppServiceLocation parameter in the call action.
In the call action itself, you should enter the value of the
AppServiceLocation parameter as an expression. The value can be a literal String, but to benefit from the dynamic nature of the location override, you will probably want to use a variable.
We have discussed an improvement in Mendix 5.15 that allows you to specify app service locations by using a parameter with a value that is determined at runtime. This adds flexibility desired for service-oriented enterprise solutions. We hope you like it! Please leave your comments below.