Pervasive computing, or PvC, untangles this knot of protocols and operating systems to allow access to information anywhere, anytime in a secure manner. It allows data to be delivered efficiently, effectively, and economically to any device, no matter what the hour or how distant the user's location.
We are not only speaking about largely distributed systems and applications, but about highly dynamic and mobile sets -- clusters of participants, who can interact with each other and store data individually on mobile devices, as well as in remote facilities. The major goal of PvC is to render computing devices and their technology invisible so the user remains focused on the matter at hand: receiving updates and tasks.
PvC architecture must take into account two fundamental conflicts: the level of mobility within the system, and concurrency and level of resource conflict. In essence, the higher the mobility, the lower the concurrency.
In light of these conflicts and requirements, the PvC system supports peer-to-peer, multiplexed, fragmented, and point-to-point connections (similarly, FTP provides peer-to-peer, but a failed connection is usually reconnected in the same place. In PvC, however, a failed connection may have to be reconnected from another location). PvC should also support the bridge between broadband content, distributed systems, and mobile systems with limited capacity and bandwidth. Support for multiple protocols and devices should also be built in.
PvC architecture needs to be kept simple so that it can be deployed easily across multiple devices. It has to support persistent storage and mobile computations so that devices can work even under limited connectivity.
Preserving local autonomy while allowing for a higher level of security and application management is another source of conflict for PvC. This conflict usually arises in global organizations spanning several locations while at the same time trying to preserve local autonomy.
Bandwidth consistency in mobile networks has gotten a bad rap, and for good reason: Large fluctuations in mobile bandwidth are a given. Even so, any two points on the planet can be directly connected in 0.13 seconds. This is an important consideration as the PvC solution will relay not only on broadband, but also on vastly diverse mobile networks. Furthermore, network and protocol failures are indistinguishable from lost connectivity.
Figure 1
The commonly used approach for client-server and multitier computing relying on a distributed state among nodes and statically partitioned logic among nodes would not work well in a multiple-network environment, nor with multiple and heterogeneous devices, limited connectivity, or autonomous administration.
This "classic" approach (suitable for static computing) would render PvC computing highly ineffective due to scalability, connectivity, and interoperability issues.
That means PvC architecture should compensate for or have the following components:
- An increased level of interoperability
- Mobility (mobile IP, migrate)
- Compensation for lost connectivity (writing into temporary storage like RMS, enabling persistency)
- Mobile code systems (J2ME, DB2 Everyplace)
- Adherence to standards (especially OGSi, JXTA, etc.)
- Support application data routing even if resources are intermittently connected
- Make data stream redirection transparent
- Make resources available on a discovery basis (discovery services) through well-defined interfaces (INS, or Intentional Naming System, in which an application is described by use of an intentional name that specifies what it is, what it does, and where it is located; discovering resources by their physical location; and JINI).
JINI (Sun Microsystems) was developed to support and handle "communities" of distributed services across networks. The services are defined by pieces of code, which perform only specific functions. Once on the network, clients are allowed to discover services without previous knowledge of the network's topology or minimal configuration. The services are accessed through "proxy objects" -- Java-written classes allow standard access to these services. The pieces of code are transferred to the client and can perform local calls and access remote objects. All of the services on the network will respond to a discovery request with their own "proxy object" specification. After a client performs lookup on the "lookup service" and finds a matching service, it will then register and access the proxy object directly.
JINI's lack of service mobility can be compensated for by an approach based on location, in which the user's identity and location are encoded in an XML message over HTTP. This is somewhat similar to the JXTA P2P specification mentioned earlier.
PvC architecture will have to compensate for and prevent spam on the browser side, server side, kiosk, and wireless and mobile devices (with an eye to data persistence) at either the component level, PvC peer or PvC Relay, or Proxy. PvC synchronization at relay or proxy may be a particularly vulnerable target for spam or session hijacking.
PvC architecture as optimized will extend the reach of enterprise computing and allow workers, clients, suppliers, buyers, etc., to capitalize on the value of enterprise data. The explosion of short-range ad hoc networking (e.g. Bluetooth, HomePNA, 802.11, etc.) is commensurate with the PvC device boom itself. This connectivity capability has implications for device architecture requiring seamless support for transparent, appliance-like, ad hoc collaboration among devices.
The PvC device market is extremely diverse and includes PDAs, set-top boxes, screen phones, in-vehicle computing platforms, smart phones, and home gateways. For that reason, the future architecture of PvC is one of components dispersed throughout networks. It will be device independent. Its components will be available on relays providing for authorization, authentication services, peer-to-peer communication, data exchange between broadband and wireless band networks, and various mobile devices.
When such architectures are in place, not only will you have access to specific subscriptions through your provider -- in addition to peer-to-peer communication, but you will also be able to take advantage of local services that may not be available at your access point.
In short, PvC is the architecture of the future. It will enable workers traveling in Asia to print a document on their boss's desk in the U.S. ... before leaving their hotel to catch a plane to their next destination... about which they just downloaded a local map ... and updated information about their client. And on and on.
For more information on Pervasive computing initiatives...and fallbacks, see the sidefile to this article.
- See the Web site for the MIT Project Oxygen.
- Read up on Project Aura -- distraction-free ubiquitous computing.
- See the site for The Open Gateway Systems Initiative.
- Visit the site for Project JXTA.
- Read up on Location-based services.
- Design P2P systems that extend beyond traditional network boundaries with this developerWorks article "Making P2P interoperable -- Creating JXTA systems."
- Develop device-enabling applications with WebSphere Studio Device Developer.
- Read about PvC and the IBM Management Framework.
- Brush up on LAN technology, including Bluetooth, HomePNA, 802.11, etc.
- From FreeNet: Open Source P2P.
- Read "IBM Everyplace Wireless Gateway -- short message
support."
- Take this free developerWorks tutorial on J2ME.
Roman Vichr is Senior Architect at Etensity, an e-commerce and EAI consulting company. His latest interest includes expanding databases into wireless technology, after focusing on database management for client/server and Web applications development over the past nine years. His background is in fiberoptics, culminating in a Ph.D. in the field from Prague's Institute of Chemical Technology in 1992. He can be reached at rvichr@etensity.com.
Vivek Malhotra is a wireless technology expert based in the Washington D.C. area. Vivek has several years of experience developing and implementing wireless applications and has spoken on expert panels focusing on the wireless industry. You can contact Vivek with any questions you might have about this article.
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
