The Gartner Group foresees that by 2012, 50% of traveling workers will use mobile devices instead of notebooks; therefore a typical business scenario very likely will involve thousands of mobile devices [7].
Mobile devices are heterogeneous in terms of capabilities and operating plat- forms. Some of the more popular are as follows:
Microsoft Windows Mobile OS •
Symbian OS from Symbian Foundation •
Apple iPhone platform •
Android from the Open Handset Alliance •
Each of these platforms adopts different solutions with regards to software develop- ment, applications and OS maintenance, and data synchronization. Therefore,
Legacy applications
Middleware middlewareMobile
Database Office
automation
CAD system Organiser E-mail Mobile worker Web browser Internet Mobile phone Nomadic user
managing mobility in an enterprise environment requires that some specifi c issues be tackled by a fl exible and reliable middleware.
Transparent device management is the fi rst requirement that a mobile business application has to address, both in the case of personal productivity applications such as e-mail, calendar, and so on, and in the case of custom enterprise applications, such as Enterprise Resource Planning (ERP) or Customer Relationship Management. For this reason, IT administrators have to be provided with a unique administration panel to set up and maintain the confi guration of enterprise-related applications, regardless of the specifi c operating system, and quickly enough to promptly react to infrastruc- ture or service changes. Mobile middleware provides the underlying technologies, such as common application programming interfaces (APIs) or services, to send reconfi guration messages and to translate platform-agnostic commands, like an e-mail server address change, into a set-up operation.
Deploying and maintaining mobile applications that address enterprise needs
adds another set of requirements regarding software updates. IT administrators wish to have a quasi-real-time delivery of the updates to all the enterprise devices, without any involvement from the user side. Delays could be very expensive indeed, due to security-related issues, such as bug corrections or vulnerability and functional patches untimely delivered. Due to its proved fl exibility, the Web seems to be ade- quate to solve such issues, allowing each mobile device to directly access enterprise applications without any further superstructure. Unfortunately, the Web has some limitations relevant to the mobile business scenario, such as disconnects and data or events dissemination. For example, consider a salesman registering on his personal data assistant a purchase order: he wishes to send it immediately to his enterprise, but due to connection unavailability, he has to defer such transmission to the future. The Web itself does not permit such kind of disconnected operation, but a well- designed mobile middleware could automatically allow order data, temporarily stored on the device, to be synchronized with the enterprise server, once the connec- tion is active again. Projects like Google Gears are focused on this challenge, although they are still in their infancy. On the other hand, when the salesman places an order, the sales supervisor must receive an alert on his mobile device. Such push operations are not allowed by the currently available Web technology and mobile users have to explicitly refresh their browsers to retrieve new data. On the contrary, mobile middleware pushes data or events through message-based communications.
Security-related issues have to be adequately considered in general and specifi -
cally in a mobile environment, where data are transferred from the enterprise to the mobile device, and vice versa. Information stored on the mobile device, in fact, has to be considered as a critical corporate asset, and its loss or fraudulent access has to be promptly prevented. In order to address such issues, mobile middleware has to provide security mechanisms for data retrieving, gathering, and synchronization, powerful enough for IT managers and easy to implement for developers. Using authentication mechanisms, in conjunction with channel or message encryption techniques, the middleware layer allows developers to create intrinsically secure applications without additional efforts.
Performance-related requirements are extremely important in some business
The functional requirements described so far need to be analyzed in conjunction with the related architectural and developmental aspects of a typical enterprise system. As described in other chapters of this handbook, enterprise systems are shifting from a chaotically organized group (technology islands) of monolithic appli- cations to an ecosystem of services organized according to a service-oriented archi- tecture (SOA) and coordinated by a business process management (BPM) engine. The SOA vision of an enterprise system assumes an asynchronous interaction of loosely coupled reusable services to replace the tightly integrated monolithic archi- tecture of legacy systems. Such architecture is, in brief, constituted by
Providers and services aggregators •
Brokers, to act as services yellow pages •
Consumers •
Providers publish their services (Web service) and register their availability on the Universal Description, Discovery, and Integration (UDDI) registry. Web services are described using the Web Service Description Language (WSDL), which defi nes exposed methods and input/output data and formats. Consumers can access the services referenced by brokers through the Simple Object Access Protocol (SOAP), the Extensible Messaging and Presence Protocol (XMPP) [8], or the REpresentational State Transfer (REST) protocol [9]. XMPP is a secure, decentralized, and fl exible communication protocol based on the publish–subscribe paradigm while REST is a style of software architecture for distributed hypermedia systems such as the World Wide Web.
In order to compose services as a business process, a BPM engine executes acti- vities described through the Business Process Execution Language (BPEL). Each of the mentioned protocols and languages are open standards and can be effectively used to extend enterprise services to mobile devices.
The adopted strategy to extend enterprise applications to mobile users is to make the mobile devices part of the SOA architecture through a mobile middleware layer. The middleware resides both on the server side and on the client side and its func- tionalities can be accessed through API and/or Web service requests. The middle- ware layer has to satisfy all the previous requirements, thus allowing management, monitoring, and secure data retrieving, gathering, and synchronization. In order to integrate the enterprise, SOA architecture with heterogeneous mobile devices, open standards for protocols, and data formats should be used. All of the above- mentioned operating platforms allow the use of the Extensible Markup Language (XML) that, in conjunction with HTTP or XMPP as the communication channel, represents the foundations of each protocol and data representation method of modern applica- tions. From a software engineering point of view, we have many development frameworks that can be used to program mobile devices and the choice depends on the specifi c operating platform. Microsoft Windows Mobile OS, thanks to the .NET Framework, supports XML and Web Services. Java 2 Micro Edition (J2ME) devices, such as Symbian OS or Windows Mobile OS, can access the enterprise SOA through kSOAP, which is a J2ME-based SOAP parser, and the JSR 172, which provides a standard set of XML and SOAP APIs. The Android SDK (software development kit)
allows the development of applications based on the Java programming language. Instead of J2ME, Android devices use the Dalvik virtual machine, which relies on the Linux kernel. Nowadays, however, many Web services are REST compliant, meaning that the query is encoded in a regular HTTP request and the results come back in a simple XML format. In that way, Android devices can be part of an enter- prise SOA. The same REST compliant approach can be used for the iPhone devices, due to the lack of a specifi c SOAP API.