Listening to the architect of many IBM mobile applications, explain his reference architecture, he made some very interesting points, Now it must be said that they were made because the IBM products help fix them, and so I thought I should point that out. Of course many of the solutions can be non-IBM too!
Firstly just think about how many Java app servers, or LAMP stack type servers have been deployed, in an organisation, to support mobile applications. there will be a lot, and these will be in an environment where there are many many others.
Mobile Backend as a Service (Bluemix, or Apigee, or appcelorator) aims to fix this by collecting these into a cloud managed service that delivers them as required.
This means that you start to really remove the complexity from the environments, keeping the app servers down to those that have to be run and managed on premises and no more.
Traditional SOA platforms do not have the ability to deal with off line working, the vast majority are designed to work with computers that have a high quality and consistent long lived connection to the server. So dealing with a mobile application that has to work off line as well as on-line is not a pattern that many SOA platforms are able to cope with. This is a reason why we still need to have a dedicated mobile middleware service to allow for not just data and protocol transformation, but also to manage the orchestration required to handle off line working, and for the data flows to execute this.
Lastly, many organisations are providing their SOA services over two distinct paths. Some of the services are provided via the internet and are available for 3rd parties to use, or even are freely available to the public. Other services are locked down and only available to authenticated clients accessing over an encrypted VPN. Therefore mobile enterprise apps have to be able to deal with multiple connection paths to the back end services, even if they are all from the same organisation.
Lets also not forget that many apps have a Push Notification service and this is a third route between the app and the back end, typically a vicarious route via Apple or Google.
Posted on December 9, 2014
0