The Next Generation in Application Architecture: Occasionally Connected

Computing

By D. Britton Johns ton, Chief Technology Officer, PeerDirect Corporation
With the notebook fast displacing the desktop as the dominant business-computing
platform, and with businesspeople becoming increasingly distributed and mobile,
applications built on the premise of persistent network connectivity are rapidly becoming
a hindrance to productivity.
Intel’s Centrino launch has added considerable momentum to the mobilization of
business computing, by making mobile and WiFi platforms far more affordable than was
previously possible. As part of this launch, Intel publicized the notion of “occasionally
connected computing” ¾ that is, applications that keep working productively even when
there is no network connection ¾ and encouraged application infrastructure vendors to
deliver products to support this new vision. After all, a mobile-enabled platform loaded
with “immobile” applications ¾ those that require persistent connectivity ¾ is not
mobile at all.
Because most business applications and databases today are centralized, they are wholly
unsuitable for occasionally connected computing. If network connections drop or become
unavailable, most applications can no longer operate. Access to the application and its
underlying data is lost, as is any user work in progress. Take for example that sales force
application, CRM system, or ERP application in your office. You can forget about using
it once you leave your office. Eve n applications in use today that claim support for
offline operations fall far short of providing true occasionally connected support.
Roaming between connected and disconnected modes cause cryptic error messages,
exposing connectivity transitions and interrupting use. Worse yet, these approaches may
require the user to re- login under a different mode of operation. Imagine instead that
same application roaming between connected and disconnected states without interfering
at all with application functionality. An application that can operate with network
transparency. That is the notion of occasionally connected computing.
So what are the choices for providing occasionally connected access to business
applications? Historically this has required the development of expensive specialpurpose
versions of the existing application — versions with stripped down functionality,
such as read-only access to information or the application requiring a manual switch to an
“offline” mode. This approach is expensive, for obvious reasons, and the resulting
applications typically are extremely limited versions of the original.
With the advent of inexpensive mobile PC’s enabled by technology such as Centrino, and
the continuous price plummet of both storage and processing power, the centralized
application architecture no longer makes sense for most organizations. Workers have
enormous power in their notebook computers, but the centralized architecture only uses a
fraction of it, because all processing and storage is centralized. At the same time, this
architecture exacts a price on end-users by forcing them to be online to use their
applications and anchored in their offices, and plaguing them with frustratingly poor
performance due to network latency and the inevitable outages that occur when
connected to the Internet. The fact is, workers today bring their laptop computers to
meetings, customer sites, and home and demand to be as productive with the applications
on the road as they are in the office. These additional hours of productivity easily
contribute added value each week. Not mention employee and customer satisfaction.
A new kind of application architecture is required to optimize the capabilities of today’s
mobile computing platforms. An architecture that enables today’s worker to use an
application at locations other than an office desk. An architecture that fully utilizes the
storage capacity and processing power on today’s notebooks, while truly mobilizing
workers by eliminating persistent connectivity as a requirement. What’s needed is
architecture to support occasionally connected use.

Requirements for an Occasionally Connected Architecture

The first requirement for creating an occasionally connected architecture is, of course, to
distribute the business logic. Anyone who understands client/server architectures also
understands that distributing business logic is nothing new. And in the context of
occasionally connected computing, it is relatively simple to do.
The second requirement of occasionally connected architectures is the hard part:
distributing data. This is a new problem and, for the most part, a problem that most
application architects have yet to completely figure out.
Distributing data may not seem like such a big deal, until one considers the realities of
occasionally connected computing. When persistent connectivity is no longer an
underlying assumption, applications must be built to rely upon local resources. But with
applications and data deployed across all of your end-users’ mobile machines, and when
those users are drifting between connected and disconnected mode ¾ and using their
applications unimpeded in both modes because connectivity becomes a “background”
concern, not a requirement ¾ how does one keep all of the data in sync? How does one
prevent a nightmare of constant conflicts as users make thousands of changes to their data
in disconnected mode during their workdays?

One approach would be to use XML caching. However, this is only suitable for
“lightweight” applications that use small data sets. This approach breaks down when you
try to deploy enterprise applications on mobile platforms. For example, you can’t move
an entire aircraft technician’s knowledgebase onto a mobile platform using XML
caching. Additionally, there is no support for structured relational data using XML
caching, which again is a barrier to deploying true enterprise applications on mobile
platforms.

Indeed, if one wants to move a knowledgebase onto a mobile device…one should simply
move the knowledgebase onto the mobile device. With the price of storage now below $1
per gigabyte, it is entirely economical to do so. The problem is, what happens to the data
once it is distributed across multiple mobile platforms and mobile workers start using it in
disconnected mode? When a technician enters a new case into the knowledge base, how
do other workers gain access to it? And how do you avoid the “nightmare” scenario
mentioned above, where everyone is working off the same application, but with radically
different data?

The answer lies in a powerful technology known as bi-directional heterogeneous data
replication.

Realizing the Potential of Occasionally Connected Computing
Initial attempts at mobile application deployment have shown that traditional one-way
data replication tools are suitable for updating a centralized database with information
gathered in the field, but little else. This relegates mobile applications to being
rudimentary information-display or capture devices, rather than true disconnected
versions of the same enterprise applications. And it certainly does not support the type of
application described earlier: occasionally connected aircraft maintenance.
The new breed of bi-directional, heterogeneous data replication technology available
today solves many of the tricky problems mentioned about distributed databases. By
providing full read-write bi-directional replication capabilities, this technology makes it
possible to deploy enterprise applications on mobile devices and to enable full access to
application data, even in disconnected mode. In the background, there is a replication
network that communicates any changes to data to all of the other databases. If a database
is not online at the moment, it will be updated when it does come online. This, in effect,
creates an application architecture in which there can be thousands of dynamically linked
databases, all communicating change to one another as needed When implemented, this
powerful capability provides “network transparency” to the user, as the application is free
to roam between connected and disconnected modes without affecting functionality.
This capability changes the role of the Internet in application architectures. It relieves the
Internet from having to do something it is not good at ¾ providing flawless high speed
connectivity to distant data centers ¾ and instead changes the role of the Internet to
something it’s quite good at: communicating occasional changes.

To illustrate the power of the occasionally connected architecture, following are two realworld
examples of occasionally connected computing in action. These are based on real
deployments:

Aircraft Maintenance: A large jet engine manufacturer wanted to make its service
technicians more efficient by freeing them to service aircraft wherever they may be
located ¾ on the runway, in remote airfields, etc. Historically they could only service
planes when they were in the hangar, because that was where the centralized maintenance
application was located. And when their work on the jet engines was done, they would
often sit idle while other workers performed maintenance on other parts of the plane.
The manufacturer wanted its highly skilled jet engine technicians to be able to service
more planes in the average working day, which meant freeing them to bring their
maintenance application with them wherever they went. They also wanted to eliminate
the connectivity problems at remote airports, where technicians often suffered from
frustratingly poor application performance.

The company achieved its mobility goals by using bi-directional replication technology
to decentralize its maintenance application. Now, instead of being tethered to a
centralized system in a hangar, technicians have their entire maintenance application,
along with the entire service knowledge base, on their notebook computers. This means
they can service more jets each day, which, obviously, means a more efficient enterprise.
Retail: occasionally connected computing architectures do not just apply to mobile
applications. They are also highly desirable for traditional desktop applications, because
they provide superior performance and availability when compared to centralized
architectures.

For example, a regional retail chain wanted to eliminate connectivity as a requirement for
its point of sale systems. Network outages and anomalies often brought systems down, or
slowed them down, which compromised customer service and per-store revenue. The
company used bi-directional replication technology to decentralize its point of sale
systems, and instead create a broad network of dynamically linked point of sale systems.

Today, the systems never go down. Even when network connectivity is out, workers can
continue to process customers, check inventory at sister stores, and do anything they
normally do with the system. Customer service can never be compromised by slow or
unresponsive systems. This means that the point of sale systems has been eliminated as a
“point of failure” in the chain’s operations ¾ no lost sales, and no lost customer goodwill
can be attributed to system problems.

These are just two examples of the power of the occasionally connected computing
architecture. One can imagine any number of business applications that would benefit
from support for occasiona lly connected computing, eliminating the application’s
requirement for persistent network connectivity.

And, as more and more applications are decentralized, end-users will develop new “pain
thresholds” for application performance and availability. It will no longer be acceptable
to have applications stop with no warning or Web pages to fail to paint. Users will expect
the same performance and availability from their enterprise applications that they get
from their desktop applications.

Furthermore, occasionally connected computing architectures will enable companies to
realize substantial productivity gains by deploying applications that are always up and
always available when workers need them, where they need them.

D. Britton Johnston, Chief Technology Officer

“Britt” brings to PeerDirect a wealth of enterprise database and open source expertise. He
has more than 18 years experience in delivering software products to enterprise
customers and most recently served as chief technology officer of NuSphere Corporation,
where he was responsible for company strategy, technical direction and strategic
marketing of products and services. Britt also led the database team at Progress Software,
where he designed the architecture for the Progress® V9 RDBMS and established that
product as the market leading embedded database.

About PeerDirect Corporation

PeerDirect Corporation is a supplier of advanced, patented technology for distributed
application deployment and management. Based in Bedford, Mass., with additional
development operations in Toronto, PeerDirect Corporation is an operating company of
Progress Software Corporation (Nasdaq: PRGS) and provides customers with a
comprehensive range of enterprise technical support, consulting and training for
PeerDirect products.

About Progress Software Corporation

Founded in 1981, Progress Software Corporation, or PSC (Nasdaq: PRGS), is the parent
organization for the Progress Company operating unit, Sonic Software Corporation,
NuSphere Corporation, and PeerDirect Corporation. PSC provides industry-leading
technologies for all aspects of e-business development, deployment, integration and
management. Progress Software Corporation is headquartered in Bedford, Mass., and can
be reached at +1-781-280- 4000 or on the Web at www.progress.com.