中国原位芯片出口 “厦门芯”迈出第一步

If you plan on building mobile apps, you probably want a pluggable framework that allows you to easily use and reuse mobile services. You can then effortlessly access back-end systems, rapidly assemble new apps, and easily update individual services.

Déjà vu I hear you cry – isn’t that what my service-oriented architecture (SOA) gives me?  Yes and no. A SOA gives you much – but not all – of what you need, and understanding the line of demarcation can prevent you from making expensive mistakes.

- Your SOA does much of the heavy lifting: But SOA is not quite enough to support mobile apps.  Mobile devices add a layer of technical challenges to implementations that are not met by the SOA designed to meet the needs of web applications.  

- Don’t build infrastructure into an app – When development teams begin to create mobile apps, they can quickly run into the limitations of their SOA and often begin building mobile services – including security, authentication, and data services to name a few – directly into the app.  

- Let IT manage, secure and govern all infrastructure: When development teams build infrastructure into an app, it results in ad hoc code that is hard to update and even harder to govern.  Let development teams focus on the user experience and leave IT to IT.

What is an IT department to do?  Luckily, your existing SOA infrastructure provides most of what you need, and the additional services you need can be added without much difficulty. 

Chris Marsh, a principal analyst for enterprise mobility at 451 Research said, “Enterprises need an open and extensible platform that, rather than just sitting as another silo, can work with existing IT infrastructure and scale policy, security, and compliance across mobile assets.” 

SOA is not enough because mobile devices are not like the platforms of yore. They bring unforeseen complication into the world of IT, and when you couple that with the potential power of mobile apps and ubiquity of devices you have a set of needs that requires a thoughtful and strategic approach.

Mobile devices – whether a cell phone, tablet, or mini laptop – are amazingly powerful, but are constrained by bandwidth and battery life. Apps have to be architected to conserve both or the user experience suffers.  Mobile devices require apps that are architected to:

- Conserve bandwidth: You cannot send large, metadata-encrusted SOAP objects to a phone the way you can with larger platforms.  Likewise, you also should not send unfiltered data sets filled with unnecessary data and have the device to extract the one field it needs. Doing so consumes unacceptable amounts of bandwidth and ultimately leads to frustrated users.

- Conserve battery: When a mobile app performs significant amounts of computation, the device chews through a significant amount of battery power. As much business logic as is possible must be done service-side to keep the mobile devices functioning at their peak.

  

Most apps written for a larger platform are intolerable on a mobile device, and more than just the UI has to be re-engineered.

One significant inconvenience of mobile devices is that connectivity is not always available. It is a mild annoyance when you are not able to play your favorite game on the subway, but it cuts into productivity if you cannot conduct business in basements, remote regions, or other areas with no cell service or Wi-Fi.

Mobile workers need to be able to continue work off-line because the work does not stop when connectivity stops. Working off-line is not difficult to implement if the app provides read-only access to background information, but if the app is designed to provide near real-time support for transactions, the app needs to store and sync data, which is a nontrivial task.

One of the most difficult challenges of working with mobile devices is that they are mobile, making it very difficult for IT departments to secure the data used by the device and govern the activities taking place on the device. They move beyond firewalls, travel across international borders and get lost in cabs.

The prevailing bring-your-own-device (BYOD) policy makes it even more difficult, as corporations have less control. And, phones and tablets typically are used for both personal and business purposes. IT has to secure employees from:

- Non-business apps: A user can inadvertently download an app with spyware, which could compromise corporate data.

- Non-employee users: Phones are often picked up by friends or children who are not authorized to use corporate apps.

- Lost devices:  If a phone is left behind, IT has to be able to wipe sensitive corporate data without harming personal data such as pictures or music. 

Security is always a challenge, but mobility adds a new dimension to the problem.

 

Because of the complications that mobile devices bring to the table, additional technology – on top of exiting SOA infrastructure – is needed to support mobile apps.  In much the same way that the shift to web-based apps required an app server, the shift to mobility requires a mobile app server. The purpose of a mobile app server is to bridge the gap from SOA to mobile.

 

Consider what a mobile app server can do:

- Authentication: It is not practical for a mobile device to authenticate against multiple back-end systems, multiple times. These are tasks that can be managed by the mobile app server. It can manage all authentication – including governance rules about who is authorized to do what – and the mobile device only has to authenticate once with the server.

- Working Off-Line: Mobile devices often lose connectivity, and being able to continue working off-line is beneficial for most apps and usually critical for enterprise apps.  Storing data locally on the device is part of the solution, but the majority of the solution is synching transactions made while off-line back-end system and with transactions made by other devices. Again, the mobile app server can and should provide this service.

- Device Actions: Another service that a mobile app server can provide is the ability to push actions to devices. If a device is lost, an employee’s access rights change, or a corporate business process is altered, it needs the ability to execute actions on the device.  These actions can include wiping data, forcing a log out, or uploading a newer version of an app among others. When to issue these actions, and who to push them to, is managed by the mobile app server.

- Data Services: Mobile devices are small. They need data to be in small packages and prepared for easy consumption. A mobile app server can host data services that not only pre-process (collect, integrate and filter) the data to lighten the load on the device, but convert it to the efficient rest format as well.

- Business Logic: In an effort to lighten the load on the device as much as possible, and to create reusable services that are shared by multiple apps, the mobile app server should also host mobile services that are specific to the organization. In addition to making it easier for development teams to build apps, centrally hosting services makes it easier to update apps. Instead of having to modify multiple apps and then force all users to upload the new version, changes only have to be made in one location.

In conclusion, the enterprise mobile application developer needs to supplement his or her SOA with a mobile app server that provides comprehensive security, enterprise data integration and proactive app management.