Introduction

Pervasive computing is the next stage in information technology. Industry analysts are predicting that mobile is the next paradigm shift, and vendors, including IBM, are investing heavily in producing the best tools for building applications for pervasive computing. Pervasive devices like mobile phones, PDAs, and pagers already far outnumber desktop and laptop computers, and that trend is accelerating. Add to that the fact that all sorts of equipment, such as air conditioning units, oil tanks, car surveillance systems is now being built with serious computing power and communications links, and you begin to understand the large investment in new computing environments for building applications on devices other than PCs and workstations.

In this paper, we propose a service-oriented approach to providing a common interface that is device-independent. This approach provides significant contributions to the pervasive computing environment. Our goal is to point out unique services used for various application types. We’ll use a financial scenario to illustrate the extension of a Service-Oriented Architecture (SOA) in the pervasive environment. The paper first gives a brief introduction about Web services and the pervasive computing environment. Following the overview sections, it describes how you can extended Web services to the pervasive environment through key Web services application types, including transaction, messaging, location-based services, synchronization, device management, data management, and media application.

SOA overview

SOA is a conceptual architecture for implementing dynamic e-business. It is a way of designing a software system to provide services to end-user applications or other services through published and discoverable interfaces. Services provide a better way to expose discrete business functions and, therefore, an excellent way to develop applications that support business processes.
Figure 1. General SOA environment

Web services components

Several essential activities need to happen in any service-oriented environment:

• A Web service needs to be created, and its interfaces and invocation methods must be defined.
• A Web service needs to be published to one or more intranet or Internet repositories for potential users to locate.
• A Web service needs to be located to be invoked by potential users.
• A Web service needs to be invoked to be of any benefit.
• A Web service may need to be unpublished when it is no longer available or needed.

Figure 2. SOA Model

A service is a logical entity, whose contract is defined by one or more published interfaces.

A service provider is a network node that provides a service interface for a software asset that manages a specific set of tasks. A service provider node can represent the services of a business entity or it can simply represent the service interface for a reusable subsystem. (A software entity that implements a service specification)

A service requester is a network node that discovers and invokes other software services to provide a business solution. Service requester nodes often represent business application components that perform remote procedure calls to distributed objects, or service providers. Provider nodes may reside locally within an intranet or remotely over the internet. The conceptual nature of SOA leaves the networking, transport protocol, and security details to the specific implementation. Traditionally, this is termed a client; however, a service requester can also be an end-user application or another service.

A service locator is a specific kind of service provider that acts as a registry and allows for the lookup of service provider interfaces and service locations.

A service broker is a network node that acts as a repository, yellow pages, or clearing house for software interfaces that are published by service providers. A business entity or an independent operator can represent a service broker.

The three SOA participants, service providers, service brokers, and service requesters, interact using three basic operations: publish, find, and bind. Service providers publish services to a service broker. Service requesters find required services using a service broker and bind to them.

SOA enabling technologies

The enabling technologies for SOA are:

• XML: The Extensible Markup Language 1.0 standard is a text-based markup language specification from the World Wide Web Consortium (W3C). Unlike HTML, which uses tags for describing presentation and data, XML is strictly for the definition of portable structured data. It can be used as a language for defining data descriptive languages, such as markup grammars or vocabularies and interchange formats and messaging protocols.
• SOAP: Simple Object Access Protocol is a lightweight XML-based protocol for the exchange of information in a distributed environment. SOAP defines a messaging protocol between requester and provider objects, such that the requesting objects can perform a remote method invocation on the providing objects in an object-oriented programming fashion. The SOAP specification was co-authored by Microsoft, IBM, Lotus, UserLand, and DevelopMentor. The specification subsequently spawned the creation of the W3C XML Protocol Workgroup, which is comprised of over 30 participating companies. SOAP forms the basis for distributed object communication in most vendor implementations of SOA. Although SOA does not define a messaging protocol, SOAP has recently been referred to as the Services-Oriented Architecture Protocol due to its common use in SOA implementations. The beauty of SOAP is that it is completely vendor-neutral, allowing for independent implementations relative to platform, operating system, object model, and programming language. Additionally, transport and language bindings as well as data-encoding preferences are all implementation dependent.
• WSDL: The Web Services Description Language is an XML vocabulary that provides a standard way of describing service IDLs. WSDL is the result of a convergence of activity between NASSL (IBM) and SDL (Microsoft). It provides a simple way for service providers to describe the format of requests and response messages for remote method invocations (RMI). WSDL addresses this topic of service IDLs independent of the underlying protocol and encoding requirements. In general, WSDL provides an abstract language for defining the published operations of a service with their respective parameters and data types. The language also addresses the definition of the location and binding details of the service.
• UDDI: The Universal Description, Discovery, and Integration specification provides a common set of SOAP APIs that enable the implementation of a service broker. The UDDI specification was outlined by IBM, Microsoft, and Ariba to help facilitate the creation, description, discovery, and integration of Web-based services. The motivation behind UDDI.org is to define a standard for B2B interoperability.

Web services application design
Figure 3. Web services standards

Web service messaging can use XML, but it might transport binary data; it generally uses SOAP headers, but it is not required to use SOAP encoding for message bodies. It may use HTTP as a transport, but it could also use SMTP or other means. There are two well-defined standards for the description and discovery of Web services: WSDL and UDDI.

Background and related work

The service-oriented approach to computing has gained the widespread attention of researchers and the industry. Major initiatives include service-oriented programming (SOP) for constructing software components and service-oriented architectures (SOA) for distributed applications.

SOP draws on and enforces object-oriented programming, but is geared toward the development of software components that are enabled for intra- and inter-process communication. Software programs developed using SOP can be thought of as multi-threaded programs, where the various threads can exchange messages through clearly defined interfaces. Component design for programs concentrates on defining interfaces for the service provided by the component. Proposed features of SOP include contracts, components, connections, containers, and contexts. SOP software should provide for conjunction, ease of deployment, mobility, security, and availability.

SOA builds on SOP to construct systems and applications to achieve maximum re-use of the services provided by software components, while ensuring loose coupling in their interactions. The foundation element is a service, and SOA specifies a set of entities (service provider, service consumer, service registry, service contract, service proxy, and service lease) that elaborate on the details regarding the provision and consumption of a service. Systems that follow SOA concepts must have services, which are interoperable, self-contained, modular, location transparent, loosely coupled, and addressable through a network.

Web services technology is based on SOA concepts. This technology is directed toward integrating enterprise applications, and for providing a common data-exchange platform to semi-automate inter- and intra-organization business processes. Some of the integral technologies that make up the Web services are XML, UDDI, HTTP, SOAP, and WSDL. XML is used for defining the structure of messages between Web services. UDDI are Web service repositories that can be searched. HTTP is the underlying communication medium. SOAP is the container for the messages exchanged. WSDL is used to provide descriptions of Web services. Research has been progressing to address interactions and coordination issues, while not referencing or integrating research aimed at composition of Web services, and vice versa.

Jini, the other major SOA initiative, has been directed toward constructing local computing environments based on services. Devices are assumed to provide services, and Jini specifies certain features such as discovery, join, lookup, federation, leases, and others that enable network deployment. Jini is closely tied to the Java^TM programming language. For example, communication is achieved through Java RMI and service interface specifications are Java Object interfaces.

Using SOA in a pervasive environment

The following sections provide an overview of SOA and Web services in a pervasive environment.

Introduction to the pervasive environment

Pervasive computing projects can be viewed as specific solutions to particular problems, where the problem is often in the form of a scenario. In this respect, they tend to resemble traditional embedded system design, albeit on a larger scale, and with networking added. As with embedded system design, various projects tend to create customized solutions that are proprietary and lack extensibility. What seems to be lacking is a suitable abstraction for programming pervasive computing environments. Instead, the various pervasive-computing scenarios seem to envision a seamless system of software that acts according to the user’s desires and intentions. We believe that such a view does not match the reality of incremental adoption that is likely to occur, nor the diversity of pervasive-computing device vendors that will doubtless proliferate. Thus, we propose that a standardized service-based programming environment be adopted for pervasive computing.

Pervasive computing is defined by NIST as shorthand for the strongly emerging trend toward:

• Numerous, casually accessible, often invisible computing devices
• Frequently mobile or embedded in the environment
• Connected to an increasingly ubiquitous network structure

The aim is to make easier computing available everywhere it’s needed. Various researchers have identified that a networking and middleware infrastructure will be needed to enable such a vision. The salient features of this pervasive infrastructure include scale, mobility, and ubiquity. The scale will dwarf anything currently extant. Given this, we can infer various additional issues that must be addressed by the infrastructure. Failure and/or disconnection will be a critical issue since, as the number of components increases, the probability of some component failing also increases. If the system is not to fail, it must be fault-tolerant. The infrastructure is likely to be peer-to-peer in nature, rather than client/server or multi-tier, as is currently the case in middleware, and as is typically assumed in the building of data networks. As with the internet, it is doubtful that such a large system would have a single domain of authority. Given multiple domains of authority, combined with mobility, some notion of visitor status is required, both for mobile devices connecting to foreign networks and for mobile applications that are following their owner. Such a visitor status must both protect the integrity of the foreign network and preserve the security of the mobile data. Ubiquity and mobility imply that devices will expect always to be connected to the infrastructure. Finally, it is doubtful that such a system could be other than heterogeneous.

Pervasive-computing projects, on the other hand, frequently take the approach of providing a single-integrated solution, usually to a specific scenario or collection of scenarios. Therefore, pervasive computing requires a common abstraction that can be used as a programming within which the various problems can be resolved. Such an abstraction must be powerful enough to capture existing projects, and flexible enough to enable the development of solutions to the various outstanding problems within pervasive computing. We propose that the service-based approach provides such an abstraction. This approach can provide significant contributions to the pervasive computing environment.

First, it provides a way of viewing pervasive computing systems. Currently a significant amount of research effort in pervasive computing revolves around scenarios. It is, therefore, unclear what pervasive computing is. The service-based approach defines pervasive computing as a ubiquitously available service environment.

Second, it gives us a framework within which to view existing pervasive-computing projects. As a result, we are able to identify features in those projects that are lacking. We are also able to compare the various projects based on the way in which they implement aspects of our service view.

Third, our approach allows for the incremental development of pervasive computing within a ubiquitously available service environment.

Pervasive computing security

The pervasive computing environment relies on the exchange of information between various clients and servers over various networks. In such a setup, as the information travels from the source to the destination, there is always the risk of the data being intercepted. The same security risks are applicable to Web services transactions. In Web services transactions using SOAP, the data is passed between the service invoker and service provider as plain XML, so anyone who intercepts the messages can read the data that is exchanged. In the Web services scenario, the security aspect is more complicated because of the following:

• Soap messages can be sent using different applications or transport protocols like HTTP, SMTP, and so on, which might have any security model, from very high to none at all. Hence, there is a need for a comprehensive security framework for Web services applications, which is common to all types of transport protocols.
• There may be legitimate intermediaries that need to access, as even modify, some or all of the SOAP message. The security model must be comprehensive enough to allow such intermediaries.

The following sections define the various aspects of Web services security that can be applied to the application types described in Using SOA in pervasive applications

Web services security guidelines

The W3C Web Services Architecture Requirements outlines six important security considerations for a comprehensive security framework:

• Authentication guarantees that the service is accessible for anyone with a verified identity.
• Authorization guarantees that the authenticated person has the right to access the service or data.
• Confidentiality guarantees that the data passed between the requester and provider is protected from eavesdroppers.
• Integrity offers that the message was not modified in its path from requester to provider.
• Non-repudiation guarantees that the sender of the message cannot deny that he/she sent it at a later point in time.
• Accessibility ensures that the service is always accessible and is not impaired by attacks, like denial-of-service (DoS), from outside or inside the system hosting the service.

Web services security today

Web services security is still in its infancy stage. New standards and applications are continually being developed and deployed. Today, Web services security can be achieved at two levels:

1. Transport level: Security at the transport level uses the inbuilt security features of transport technologies like HTTP, IBM WebSphere MQSeries, IBM Websphere Everyplace Connection Manager, and so on
2. SOAP or messaging level: This level is currently being extensively researched and specifications being developed by security groups such as OASIS. Security at this level involves using digital signatures, certificates, and so on, at the XML document level.

Securing Web services with HTTP

You can secure Web services transactions over HTTP by using the following:

• HTTP basic authorization
• HTTP with secure socket layer (SSL)
• HTTP basic authorization + HTTPS

However, HTTP security does not address all of the Web services security guidelines described earlier. The best possible configuration is to use HTTPS with HTTP basic authorization, which addresses all aspects of Web services security except non-repudiation and accessibility.

HTTP basic authorization: HTTP basic authorization (BASIC-AUTH) is a simple mechanism used in HTTP. Using this mechanism, we can protect Web resources from unauthorized access. To access resources protected using HTTP BASIC-AUTH, a user has to provide a username and password. The Web site administrator configures the Web server with a list of valid users and resources that a user can access. Since Web services invocation over HTTP is the same as accessing an endpoint URL, we can make use of BASIC-AUTH to restrict Web services access.

HTTP secure (HTTPS): Secure socket layer (SSL) is a technology that allows Web browsers and Web servers to communicate over a secured connection. This means that the data being sent is encrypted by one side, transmitted, and decrypted by the other side before processing. This is a two-way process, meaning that both the server and the browser encrypt all traffic before sending out data.

HTTP basic authorization + HTTP secure: HTTPS provides excellent security to Web services transactions. It also provides an authorization mechanism for a user by means of signed certificates. However, if a duplicate of the certificate is available, anyone can impersonate the participating agent. Therefore, the best form of security can be derived by a hybrid of HTTP BASIC-AUTH and HTTPS. This satisfies the first four aspects of Web services security, as well as providing a better degree of protection from repudiation. In the following sections, we will explain how to configure your Web services application to take advantage of this security method.

Using SOA in pervasive applications

The remainder of this article describes how SOA and Web services can be used to provide common interfaces for key pervasive application types. The key pervasive applications we will focus on are: messaging, transaction, device management, synchronization, location-based services, data management, and multimedia services. In order to help define how we can use SOA and Web services in these applications, we’ll use a financial services scenario. This scenario is based on the following architecture:
Figure 4. General financial portal architecture

Financial services scenario overview

The following diagrams illustrate the financial services scenario described here:

1. New bank customer signs up for online banking through laptop, including such services as fraud detection alert, new offerings, and online bill payments
2. Customer decides to check status of account balance (using laptop or smart devices)
3. Customer then decides to make online payments (using laptop or smart devices)
4. Customer receives an alert stating that a large amount has been taken from account. Alert gives the customer the ability to respond and talk with a bank service agent via messaging or voice
5. Customer makes an online transaction using the bank’s Web services client on their pervasive device.

Figure 5. Scenario 1

Figure 6. Scenarios 2 and 3

Figure 7. Scenario 4

Figure 8. Scenario 5

SOA for messaging

The notion of messaging involves dispersing messages to an array of pervasive devices over a broad spectrum of wireless networks and protocols. Examples of messaging operations range from broadcast types such as news, stock quotes, and event notifications, to personal communication types such as pager messages and instant messaging (IM). More recent developments in such wireless technologies as Short Message Service (SMS) and Session Initiation Protocol (SIP) have provided for innovative solutions that leverage the capabilities of Web services.

Application Requirements

• Seamless Integration of IM Applications: There currently exists a fairly fragmented group of IM service providers, including AIM, MSN, and Yahoo, among other proprietary providers. There is a need to consolidate these services in order to improve usability and management. Trillian Pro has addressed this issue in the desktop realm by allowing users to configure and use these services from a single client. The same principle by which IM service providers can be consolidated by adhering to a common interface would also serve well in the pervasive environment.
• Session Management: The recent completion of the SIP specification facilitates the development of IM applications on mobile devices, representing a convergence of popular desktop IM applications and wireless SMS systems. SIP provides session management support, allowing users to store and retrieve data from conventional request and response objects that potentially span multiple SIP requests. Refer to JSR 180 for further details.
• Guaranteed Delivery: Many IM applications today do not guarantee message delivery; they are “fire-and-forget” types. Messages sent to a user who becomes unavailable during an IM session are typically lost. While this may be acceptable in most situations, there may be a requirement for guaranteed delivery of high-priority messages. This would undoubtedly introduce further complexity, including the need for acknowledgement of messages and the queuing or caching of unacknowledged messages until the user returns online.
• Enhanced Communication: SMS, EMS, MMS
• Security: See Pervasive computing security.

How Web services can be used

Web services serves as a common, device-independent interface from which providers can publish their services to be subscribed to by clients. They may be invoked directly by clients or by other services. This feature allows for the aforementioned notion of an IM hub, in which various proprietary IM service providers could be consolidated to form a single client application. As with the desktop realm, this would improve usability and ease of management. Equally important, Web services effectively serve to abstract the backend processing from the client by fulfilling its needs through the invocation of discoverable interfaces.

A fairly rudimentary solution consists of a thick, custom-written Web service client ported to a device. This approach, while requiring more development time and effort, allows for greater flexibility because the client is given full responsibility over application control and presentation details. Furthermore, aspects normally handled by the container, including security and session management, do not need to be addressed.

You should note that while Web service technology has matured for desktop and enterprise applications, many extraordinary considerations must be taken to accommodate the constraints of limited-capability, pervasive devices. For one thing, parsing XML/SOAP messages is fairly intensive and requires a considerable amount of processing power. To mitigate this, the JSR 172 specification will provide a leaner version of its J2SE/J2EE counterparts. Refer to J2ME and Web services for further details.
Figure 9. Thick client environment

The abstraction of backend processing from the client increases the potential number of serviceable devices by allowing for those with less processing power or memory. If the assumption is that the client supports access to a Web interface, that is, communication via TCP/IP, a solution that incorporates portlet aggregation and WebSphere Portal Server (Portal) may be an ideal fit, as described below. Custom-written portlets, special reusable Java servlets that, conventionally, compose defined regions on a portal page, provide access to many different applications, services, and Web content. Portal provides support to deploy Web service-backed portlets. This frees the developer from administrative concerns handled by Portal and allows the developer to focus on implementing specific business logic. Refer to Create your own portlet and Web service and Develop portlets that use Web services to obtain data from remote systems for implementation specifics.
Figure 10. WebSphere EveryPlace Connection Manager and Portal Server environment

WebSphere EveryPlace Connection Manager (Connection Manager) serves as an optional transport gateway between client devices and the WebSphere EveryPlace Access server. Connection Manager allows for abstraction of such low-level details as wireless protocols from the backend application, thus inducing reuse and separation of concerns.

The messaging services arm of Connection Manager enables a Web application server to interact with pervasive devices such as those mentioned previously. While messaging services supports the more prevalent SMS and unconfirmed WAP push delivery, it also enables a number of other message modes, including short message delivery over proprietary networks, e-mail via SMTP, and SNPP. For more information, please see IBM WebSphere Everyplace Connection Manager Version 5 Handbook for further details.

Everyplace Access serves as the connection between the mobile client and enterprise environment. Everyplace Client, one of Everyplace Access’s core offerings, serves as a complementary software package, which provides a variety of PDAs with more robust device environments. It provides out-of-the-box IM service; however, it is currently limited to Lotus Sametime.

Another advanced feature of Everyplace Access is Intelligent Notification Services (INS). This service enables the enterprise to autonomously notify mobile users based on subscription of notification applications and triggers. This is accomplished via Everyplace Access administration, where the user specifies information source, notification criteria, and any preference and subscription settings. Refer to WebSphere Everyplace Access Version 4.3 Handbook for Developers for further details.
Figure 11. Portal environment

Because Portal touts a highly configurable and proven framework, many of its built-in functionalities can be leveraged to reduce development time and cost. Portal, integrated with Everyplace Access, supports mobile devices by generating pages in any markup language, including officially-supported WML for WAP. When a page is requested, Portal handles backend processing to automatically detect the device type and return portlets that render their contents in the appropriate markup language.

Messaging in the financial services scenario

In the case of a financial services scenario, messaging provides the user with added features and conveniences. For instance, the system infrastructure can be set up so that the user is alerted when suspicious account activity is detected, such as a large withdrawal of funds. As mentioned above, Everyplace Access’s INS supports subscription-based notifications, where messages are triggered by specific events to which users subscribe.

Users can then choose to connect and correspond with an agent via an IM application to resolve the issue. Due to the nature and importance of the session, messages could be treated for guaranteed delivery and retained until acknowledged by the client.

SOA for transaction services

When thinking about transactions in a pervasive environment, one must take into account the limitations that pervasive environments impose on the transactions that can be performed. Furthermore, since a pervasive environment can contain any number of different devices with different capabilities, it is important to account for ways to use the same transaction to service different devices and their capabilities.

The most obvious answer to this problem is to abstract the mundane details of a transaction from the client. This can be done in two ways. One method is to make the abstraction layer completely unaware of the clients that access it. This requires that the client be intelligent enough to handle the capturing and displaying of appropriate data. Obviously, this is referring to a thick client, which would open up the service to a wide variety of clients, but could potentially demand higher CPU and memory requirements from each.

Another method is to make the abstraction layer intelligent enough to distinguish between the different capabilities of the clients that request its services. In this case, all of the details of the different capabilities of each device must be accounted for by the service provider. The client would be considered a thin client offering low CPU and memory requirements, but requiring that a finite number of devices be supported by the service provider.

Web services and SOA can address these issues of providing either a simple abstraction layer or an intelligent one. The following section demonstrates how this Web service can provide this functionality.

Application requirements

Transaction services in a pervasive environment need to take into account the same issues as transactions in a traditional application, as well as the fact that the client can be running on several different kinds of hardware and software with different capabilities. Also, the location of the device can be virtually anywhere and care must be taken as to the type of information that is displayed in a given environment. The following list is not intended as an exhaustive list of potential areas of consideration, but a reasonable start when considering the implementation of a transaction in a pervasive environment:

1. Because a device can only show certain number of results, you may need to cache on server side with some sort of session.
2. Consolidate transactions into a few aggregate calls on the server side to reduce network calls over precious and low wireless bandwidth.
3. Let the server side perform any complex sorting or other CPU-intensive operations.
4. Difference between synchronous and asynchronous transactions. How would one implement both types of transactions?
5. Online and offline transactions.
6. Crucial to make maximum use of limited online time. Minimize time device has to wait for results. Reduces cost of being online.
7. Fire-and-forget transactions. Queue up jobs on behalf of a device. Then when device checks back, it can pick up results.
8. Security can be more easily compromised. Need to take special care as to the kind of information that is displayed on these devices. Bank-type transactions, for example, may allow a home user to make changes to their account information, but same transaction on a cell phone may not want to allow edit functions, only view functions.

How Web services can be used

Web services can be used at two levels in a pervasive environment. One is by implementing a Web service client on the remote device, which will invoke the Web services directly. This method is illustrated below:
Figure 12. Pervasive transaction using Web services thick client model

The benefit in this scenario is that the remote device has complete control as to how to display the data. The device will know its own limitations and display the returned data in a way that is appropriate for that device.

This method also has the added benefit of allowing the embedded program to perform transaction optimization. This is done by allowing the device to store multiple transactions until such time as it is deemed appropriate to send or request data. The appropriate time can be determined by the total number of queued up transactions or, perhaps in an environment where the network has intermittent availability, the transactions can be stored until the network is available. This would allow for offline functionality.

The added benefit that SOA brings here is that the client doesn’t need to worry about any of the details of invoking the transactions. The client doesn’t need to worry about database connections, special protocols, proprietary data formats, or changing back end systems. All it needs to do is construct XML and send the data using the Web services client. Because these are all open standards, it is possible to create a single transaction that varying types of devices can support. No special code needs to be written by the Web services provider to support the different devices. This essentially makes the transaction itself pervasive, which facilitates data consistency amongst different devices by allowing the sharing of the centralized logic in the service provider amongst all sorts of different devices.

Transaction services in the financial services scenario

To continue the banking example, let’s say that a user wants to purchase an item online using a handheld PDA device. The device could have a client built-in that launches a Web service transaction requesting a temporary credit card number from the bank. The client can then use this information to fill in the purchase information for buying the item. Similarly a smart phone could be used to run the same Web service transaction, but this time the information could be transmitted to a vending machine to buy a can of soda. Because there are Web service clients that can run on practically any device one transaction can be used by many devices.

SOA for device management

Device management is becoming increasingly difficult as the number of wireless devices is set to increase to 11.1 million by 2006. In addition, the complexity of the applications run by these devices will certainly increase as multimedia capabilities and bandwidth surge forward. All of these devices will have to be managed in order to maintain control over applications that are deployed.

The rush to cram new features and functionality into mobile devices is happening at an astonishing pace. As a result, device recalls and firmware updates are becoming increasingly common in the latest, advanced mobile devices, much to the dismay of network operators.

Application requirements

Unlike PCs and servers that are consistently tethered to a LAN and protected behind a firewall, wireless devices such as smart phones, PDAs, and even many mainstream mobile phones are by nature far more difficult to manage. They often serve both as work tools and personal productivity devices and are more easily lost or broken and more frequently replaced. As a result, CIOs and network operators must recognize that mobile devices are subject to a different set of rules in the context of device management. The following lists some of the desirable capabilities of device management applications applications:

1. Generation of upgrade packages that are sent OTA (Over The Air) to the device
2. Storage, management, and provision of software images
3. Client residing on the mobile device
4. Software deployment
5. Asset and configuration management
6. Fault management
7. Device control and data security
8. Back-up and restore

Key differentiators are the ability to enable self-diagnostic and self-healing capabilities on mobile devices; a centrally managed, Web-based console that works over the air with client software; and intelligent delivery of updates based on bandwidth and network connectivity.

How Web services can be used

In this scenario, the device administrator invokes an update process to all devices through a Web service interface. The Web services interface allows the administration to occur from any client that can hit the device administration server with a web browser. More importantly, it adds a level of abstraction between the proprietary administration interfaces of all of the different devices allowing for one unified interface to administer all devices. The following diagram illustrates this idea:
Figure 13. Device administration through Web services and proprietary interface

Another benefit to providing the device administration through a Web service is the ability to administer devices that are contained within secured environments from a single centralized location. All that is necessary is for each isolated location to contain a Web services enabled Web application server like WebSphere Portal Server 5.1 and access to port 80 and 443 through the firewall. This scenario would be specially suited for situations where there are remote offices that may not be accessible within a company intranet or that may reside within secured subnets within an intranet. The following diagram depicts this situation:
Figure 14. Device administration architecture

Another device management scenario to consider is the case in which a device is aware that it requires an update. One could allow the proprietary device interface to be invoked directly by remote devices. However, this could have serious implications, considering that many different device types each with their own proprietary device interface may need to be exposed. Each of these device interfaces would have to be secured in a way consistent with the requirements of the enterprise. It would be much easier to have just one Web service available for devices to invoke. Each device would transmit the request offering the appropriate security credentials required by the enterprise. After verification and authentication, the Web service would invoke the appropriate proprietary device interface to send out the necessary update.

Device management in the financial services scenario

Going back to our banking example, consider a PDA that contains a banking application. When the PDA runs the banking application, it first invokes a Web service the retrieves the latest software version list. The device matches this list with the list of currently installed software and notices that the account balance application requires an update. The device then invokes the software update Web service passing along security credentials and all of the information necessary to identify itself and the software it needs to download. The Web service in turn launches the PDA-specific software update device interface with the appropriate parameter to identify the device and the location of the software that needs to be deployed to that device. In this case, the Web service offers an abstraction layer to the security between the devices and the proprietary device update software as well as abstraction to how and where the deployable software is managed. The same Web service is invoked for every type of device, so that the enterprise isn’t hindered by the security or software versioning, and management schemes are offered by the proprietary device interfaces.

SOA for location-based services

Location-based services (LBS) is the gateway to providing customized content for the user. A Global Positioning Satellite (GPS) system is one mechanism to provide accurate triangulation of the users location. Such a system requires more functionality from a pervasive component device. Not all devices may have such a functionality, thus LBS must be provided through user profiles and user input. An initial check can be conducted through IP routing and discovering the user’s possible location.

Client applications are necessary to provide the ability to send information to servers via Web services to provide the client with content, which can be used by the user. With the server knowing the location of the user, it has the ability to send data to the client such as local information based on the users current GPS position.

Application Requirements

• Client application to run on the device.
• Optional GPS hardware to allow for device locating
• Optional user input or configuration settings for device locating

How Web services can be used

Using Web services at a client level would allow for discovery and content delivery on demand based on a user’s specified location. Everyplace Access Server allows for additional functionality, such as internal UDDI discovery. Although development and functionality can be provided without a pre-packaged product, using Everyplace Access would save time.

Given the nature of pervasive computing, LBS must be used concurrently with other services to determine specific content to be delivered to the user based on their device. Transcoding will be necessary to transform content to designated pervasive devices. Pre-packaged products such as Everyplace Access Server have pre-defined transcoding templates for various devices. All pieces can be developed from scratch, but as mentioned before would require more time and effort. SOA allows for common API and functionality to assist during the design and development processes.

Everyplace Access Server provides many tools for implementation of LBS. Location Aware Services in Everyplace Access enable rapid development and deployment of applications that are location aware. APIs provided by Everyplace Access to support Location Aware Services enable developers to add location aware portlets in standard manner. Service adapters must be written by each service provider to allow for services to be provided in a location aware environment. A service adapter can have many roles, such as interface translation, service invocation and error handling, and authentication with service providers. A service written according to the Location Aware Services API provided by Everyplace Access, would be able to handle the general authentication and other features without having a developer rewrite those common pieces.

A vending machine scenario for LBS

In a snack area vending machine example, a pervasive device, based on its location, may have the ability to connect to a nearby service provider through Web services and obtain a list of available vending machines and their contents. The nearby service provider can be provided through a content browsing application, which accepted user input for the user’s location, or a client application, which is smart enough to be able to discover a nearby service provider and query for available services. The user is then able to browse through the available items and proceed to the vending machine with the items they desire. A purchase transaction could also be made on the device, if that feature is available. The service provider may show other services that are available around the area, such as local maps, stores and more. There are many unique client devices and with the assistance of the Location Aware Services provided by Everyplace Access Server, a common service can be defined. The Everyplace Access Server would be able to handle many of the common steps such as authentication and transaction handling. If not, it could forward the request to a service that would be able to handle the request.

LBS in the financial services scenario

In our financial scenario, a user would be able to sign in based on their current location as determined by user input or LBS. The client application and device may already be installed and as a result could communicate seamlessly with the service provider. The information may be sent through Web services and immediately provide the user with necessary information based on their location. Web services can be used for transferring data between the client and service provider, but not all services may be offered because of the user’s current location. For instance, if a user were at a gas station, they may only be able to select option 2 of the financial services scenario, which is to check one’s account balance. This determination can be made by a combination of user location, user’s preconfigured settings for the application, or a variety of other possible scenarios. It could also be because of the location’s lack of services or a security risk. In another location a few blocks away, the same user may be able to perform all scenarios mentioned earlier. See Figure 15 for an example:
Figure 15. Location-based scenario

Everyplace Access, in conjunction with Portal Server, would be able to provide functionality such as authentication; however, it can still be implemented separately if desired.

SOA for synchronization services

Synchronization services provide a user the ability to synchronize email, PIM data, and general data. Clients are required on the device to provide the ability to synchronize data. Using SOA can allow for data to be transferred in a generic fashion via Web services between client and server. From the perspective of pervasive computing, data transfer must take into consideration client capabilities, such as processing, storage, and bandwidth.

Devices will vary in size and as a result synchronized data must be catered to each type of device, which involves transcoding to provide content to client devices. Everyplace Access Server provides functionality to synchronize e-mail and PIM data with major mail servers. With SOA and standards, you could extend such a Web service to provide synchronization services for any type of client that would be able to parse such data.

Application Requirements

• Client application to be able to provide synchronization services and provide the user with useful information
• Data storage mechanism with various types of storage mediums
• Data integrity (CRC) mechanisms to ensure validity of data

How Web services can be used

LBS would also assist in data synchronization by enabling applications to determine a user’s location and synchronize specific data based on that location. Web services discovery can also be used to assist in finding a synchronization service provider to provide necessary data. Intra-company usage of synchronization services would be very important to allow users to synchronize necessary data depending on the user’s location within the company. Advantages of using a SOA and the generic aspect of Web services are that they allow for an endless amount of data synchronization possibilities. Disadvantages of being generic can be longer development times because not much is defined. See Figure 16 for an example:
Figure 16. Intra-company data synchronization

If a user started out in the warehouse department and wanted to synchronize data, the inventory information would be synced. If the user walked to the finance department and decided to synchronize, the financial data would be synchronized.

In a warehouse shopping center example, currently the warehouse checkout procedures allow for prescanning of items while members are waiting in line. The items are prescanned on a wireless pervasive device. When the member reaches the register, the cash register attendant scans the member’s membership card. Once the card is scanned, the system is able to pull up all the prescanned items and the transaction is completed in a timely fashion. This speeds up the checkout process because items don’t have to be transferred between carts. SOA would provide a common interface for both the wireless device and checkout register. If the warehouse at any point in time decides to upgrade or change devices, the interface would be the same and implementation costs could be reduced.

Synchronization services in the financial services scenario

A user’s device may have a personal money manager application that the user wants to synchronization with their banking provider. A Web service implementation would provide a common method of synchronizing the user’s bank information, regardless of the type of information that needs to be sent. If a user checks their balance, they may be given an option to download the data to the device. Based on the client device, the service provider can determine the amount of data to synchronize. A user may also prepare offline payments on the client device and have it synchronized with the service provider at a later time, ultimately completing the transaction when the data has been synchronized. The client application may also be able to connect to other financial service providers that implement the same architecture and data transmission/communication methods.

SOA for media applications

Media applications are specific to audio/video streaming and or playback. These types of applications can be used for employee training and certification purposes or even news and information-based services. The major concerns for media applications is the fact that client devices need to be capable of decoding and playing back the media formats given to them. There are more than a handful of wireless devices with various hardware specifications. In order to support all these devices for media applications, we have to know what types of media formats can be streamed or even played back. A perfect example of Web service re-use would be to use a device management service to handle the vast majority of devices. We also have to take into consideration what protocol can be used to support the transport of the media formats. For instance, if a business case requires video/audio playback, we can safely assume that SMS messages will not be supported as a means of transport on a client device.

Application Requirements

• High processing power on client devices
• Client devices that support streaming capabilities
• Support for media format playback

How Web services can be used

The figure below illustrates how Web services can be used in a thin client design:
Figure 17. Thin client design

In a thin client design (also known as a client/server design), practitioners can assume that they are supporting client devices that have access to a web interface such as a browser, thus allowing them to view http requests and have the capability to playback Real Network, Quicktime, Media Player, or even Macromedia Flash media formats. With this solution, practitioners do not have to worry about what protocols the client device supports, just so long as the service provider allows internet access.

For the thin client design, the bulk of the implementation is handled in code on the server side to detect the client device capabilities and determine what format to stream or even download to the device for playback. As you can see, this solution is no different from the client/server approach for architecting Web applications for desktops, since practitioners still have to consider client capabilities. The only difference is that we now include additional checks for smaller memory footprint devices.

These server side applications from the thin client design can be home-grown and run on any application server. Keep in mind that custom applications will drive develop time and maintenance costs up in the long run. IBM provides alternate solutions as part of Portal Server. Portal Server already has an industry-proven framework that can easily be extended to support additional devices and capabilities, along with the ones that are already supported out of the box. Portal Server allows custom rendering of portlets to be written depending on the client making the request. Home-grown solutions will have to provide this function along with authentication, authorization, reporting, and so forth.

Both custom implementation and Portal Server can make use of Web services in an SOA to expose media applications and to make use of existing Web services. This can then be used to implement a push-model design, where the Web service itself invokes commands on the client device to stream a company broadcast from executives or managers who wish to send a broadcast or targeted message. Again, we can use subscription and location-based services to the track devices.

The figure below illustrates a sample thick client design:
Figure 18. Thick client design

Thick client design adds more complexities, as with any other thick client architecture. With thick clients, the devices would have to be able to parse and assemble Web service messages. The thick client design limits the number of devices that can be supported due to the limited device capabilities currently in the North American market. Like any of the other application types, a thick client design can use the device proprietary interface. The drawback is that a gateway of some sort is needed to sit between the device and the application server.

Unlike the thin client design, implementation is required on both the client device and on the server side (WebSphere Application Server or Portal Server). Architecting client side implementations leaves the practitioner the option of either using device proprietary interface or invoking Web services to benefit from non-proprietary device coding. In the case of media applications, both solutions are feasible because the first option can use SMS to request media to be sent via MMS.

As mentioned above, solutions such as SMS or MMS require that a gateway like Connection Manager sit in between the client devices and the application server. With Web services, Connection Manager and the proprietary calls to SMS and MMS are eliminated and replaced with a generic interface that can be ported to other devices that support Web service messages.

Media applications in the financial services scenario

In the financial services scenario, media applications can be leveraged to support clients that want to provide their users and customers with disability services. A thick client implementation can be used to wrap VoiceXML over a transaction-based service via Web services to handle banking transactions.

SOA for data management applications

Data management applications control, protect, and facilitate access to data in order to provide timely information to consumers. The functions are provided by a database management system.

Application Requirements

• Web interface on client device for thin client solution
• SQL client for thick client solution
• Generic data acquisition, validation, processing, storage, retrieval, and display interface

How Web services can be used

In a thin client model, data management services would be facilitated on the server side through a web interface. This design is again not much different from typical web applications today, although with the use of Web services the design can leverage transaction-based services to perform commits and rollbacks along with synchronization-based services to keep the data accurate and up to date. With the thin client design, the implementation is all done on the server side.

A thick client design for data management services has two possible solutions. Like any other thick client solution, Web services is the simplest solution because of its portability and reuse. The second solution requires a product to sit between the client device and the application server to transcode the instructions from the device to the service on the application server.

The Web services design still allows the architecture to be flexible in that the data management implementation can reside on the client device, accessing other services as mentioned above to help facilitate transactions and synchronization as part of the data management package. Another possible solution could be to implement data management services as a Web service itself, so that it can be used by other services that require data management.

The second design calls for DB2® Everyplace to sit between the client device and the application server to facilitate data management. With DB2 Everyplace, you can build a PDA application that makes data management available anywhere. Your application can reach common PDAs, such as Palm^TM, Handspring^TM, HP® Jornada, Cassiopiea^TM, and Compaq iPAQ^TM devices. DB2 Everyplace also supports EPOC-based PDAs and devices with embedded Linux.

Data management in the financial services scenario

Data management services can be instrumental in the development of financial services. Data management exposed as a Web service is beneficial to both thin and thick client design by allowing flexibility for financial institutions to implement on either the client or server side depending on security, accuracy of data, and other requirements. Analysis and reporting of data is more accurate if the use of date management services is centralized in application design.

Conclusion

This article described how you can use SOA to provide a clear and concise solution using Web services in a pervasive environment. The article described the various application types you can use in designing the solution. We used the financial services sample to illustrate how unique services could be implemented in a specific scenario. Finally, we described tools you can use to help facilitate Web services, such as gateway or proxy devices for infrastructure security and scalability of the applications.

Appendix: J2ME and Web services

As it currently stands, there is no standardized and efficient mechanism for J2ME-enabled devices to leverage Web services technology in the SOA environment. While the Web services specification has been defined in detail for J2SE and J2EE domains, it does not address the extraordinary constraints placed on J2ME domains. Such constraints include the requirement that Web services technologies meet the platform performance and size requirements. More specifically, it is necessary that the API be implemented within the runtime memory and processing requirements and that it fit within the memory footprint of target devices. Furthermore, it must take into account the limitations of the deployed environment, including low bandwidth and high latency.

JSR 172 from the Java Community Process Program attempts to address these issues by introducing the addition of two optional packages, which will enable Web services technologies on J2ME-enabled devices. Because XML serves as the de facto standard for message format, the optional packages to be introduced focus heavily on optimizing JAXP and JAX-RPC.

JAXP provides the basic APIs required for manipulation of structured XML data. The J2ME version will include a strict subset of that defined for the J2SE and J2EE platforms. It will accomplish this by supporting only crucial functionality, including SAX parsing, as well as support for XML namespaces and UTF-8 and UTF-16 encodings. Functionality that will be excluded includes support for XSLT and the other XML parsing variant, DOM. DOM was excluded due to its implementation size and runtime memory footprint.

JAX-RPC provides the APIs and conventions for enabling XML-based RPC communication from J2ME. Again, in contrast to its corresponding versions in J2SE and J2EE, the JAX-RPC will be optimized by excluding support for SOAP 1.1 encoding, extensible type mapping, and service endpoint.

What does this JSR specification, coupled along with best-practice design patterns for such limited-capability devices, ultimately translate into?This section is primarily focused at the conceptual level, so implementation details will be omitted. Refer to Small Memory Software: Patterns for Systems with Limited Memory by James Noble, Charles Weir, and Duane Bibby for further description and implementation details for the following patterns.

Web service client scenarios

SAAJ

A client that communicates with a Web service via SAAJ is involved in several procedures. First, it must programmatically create a message and add content according to a pre-determined format enforced by a DTD. Thereafter, it obtains a SOAPConnection object, sends the message, and blocks until receiving a response message.

• Process: Packages: Split the program into packages, and load each package only when needed.
• DTD: Resource files: Keep configuration data, on secondary storage, and load and discard each item as necessary.
• Connection utility: Read-Only memory: Store read-only code and data in read-only memory.
• ResponseMessage: Data files: Process the data a little at a time and keep the rest in secondary storage. Packed data: Pack data items within the structure so that they occupy minimum space.

JAXR

In contrast to a predetermined arrangement, as in SAAJ, the client may choose to dynamically send a query to the Java WSDP Registry Server searching for Web services that support JAX-RPC via JAXR. It must first establish a connection by looking up a connection factory, setting connection properties, and obtaining a RegistryServiceObject. With the RegistryServiceObject, the client can then query with the corresponding BusinessQueryManager’s methods, i.e. findOrganizations, findServices, findServiceBindings. These methods return BulkResponse, a collection of objects. For optimization reasons, the client can choose to cache and create a local database of distributors.

• Process: Packages: Split the program into packages, and load each package only when it’s needed.
• Connection utility: Read-Only memory: Store read-only code and data in read-only memory.
• BulkResponse: Data files: Process the data a little at a time and keep the rest in secondary storage. Packed data: Pack data items within the structure so that they occupy minimum space.
• Cache: Sharing: Store information once, and share it everywhere it’s needed.

JAX-RPC

Upon constructing a repository of relevant Web services via JAXR, the client can execute business logic via JAX-RPC. One way to accomplish this is the creation of a static stub or dynamic proxy. More commonly, results are returned as a collection of Java Beans. In the former, the client first creates the stub object, sets the stub’s endpoint address to access that particular service, and casts the stub to the service endpoint interface.

When creating a dynamic proxy, the client creates a service object with a ServiceFactory and two parameters: the URL of the WSDL file and Qname, the XML-qualified name. It then creates a proxy with a type of the service endpoint interface.

• Process: Packages: Split the program into packages, and load each package only when it’s needed.
• Stub/Proxy Utility: Read-Only memory: Store read-only code and data in read-only memory.
• Parameters/Result Collection: Data files: Process the data a little at a time and keep the rest in secondary storage. Packed data: Pack data items within the structure so that they occupy minimum space.

Common J2ME application design patterns

• JavaBeans:
  • Packed data: Pack data items within the structure so that they occupy minimum space.
• Interfaces:
  • Small interfaces: Design interfaces so that client controls data transfer.
• Properties files:
  • Resource files: Keep configuration data on secondary storage, and load and discard each item as necessary.
• Memory usage:
  • Application switching: Split your system into independent executables, and run only one at a time.
  • Memory limit: Set limits for each component and fail allocations that exceed the limits.
  • Captain Oates: Sacrifice memory used by less vital components rather than fail more important tasks.
  • Partial failure: Ensure that running out of memory always leaves the system in a safe state.
  • Pooled allocation: For similar objects, pre-allocate a pool of objects, and recycle unused objects.
• Storage:
  • Packed data: Pack data items within the structure so that they occupy minimum space.
  • Compaction: Move objects in memory to remove unused space between them.
  • Adaptive compression algorithm
• Article Source

Popularity: 17%

Hear
this post