Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.
--Putt's Law

Congratulations! You're deploying a server-centric application accessible from generic browsers on a variety of platforms. And you only had to give up server performance and a rich user experience to do it.

Or perhaps you don't want to make those minor sacrifices? Well, you'll be happy to know that you don't have to give up performance and a decent UI to get portability and server-centricity. To achieve this balance, you'll need a balanced computing delivery model. And to explain what that means, I'll need to take you through a quick detour through the history of computing.

From the networked personal computer to the server/browser model

In the beginning was the personal computer, with the emphasis on personal. Users could configure their machines however they wanted, taking advantage of their computer's interface and capabilities.

While this may have been paradise for users, it was a nightmare for administrators. The process of installing and maintaining applications on one machine at a time -- especially by floppy or CD -- did not scale. When administrators were faced with the task of managing multiple platforms, they began to think that migrating to an Internet-based scheme might make sense. At the same time, software developers and builders were looking to leverage their Internet investment, and lend a global reach to their applications in the process. Naturally, this meant rearchitecting their software. With a boatload of HTML tools at their disposal, developers and administrators moved in a big way to a server/browser model.

The trend evolved: Developers wrote applications to run on the server side, and the web browser became the de facto standard display device. At the client end, processing power not required to support the browser interface was wasted. Core execution took place on only a few central systems, and output was transported back to the browser via standard Internet protocols and transports.

There was no doubt about it: The Internet was a good way to deploy applications, giving greater control for the delivery of the overall solution to an unimaginably large audience. Yet, while this architecture somewhat mitigated installation and maintenance issues, the diversity of target platforms meant that web developers needed to write to the lowest common denominator, using the most commonly accepted standards. They started losing control over the target platforms. Deployment to the greatest number of clients won out over delivery of the best value -- and you had to say good-bye to a rich user experience.

And so it was that, to make management easier, developers sacrificed the best value for their customers -- not usually a winning strategy. Imagine if a salesperson said, "Our applications may be lousy, but they sure are easy to build and maintain!"

Some vendors and developers are convinced that developers can do better. We've learned to sustain growth by targeting a mass audience. New technologies and industry standards now make it possible to deliver better value to that mass audience.

Why go through a transition to a new compute model when everything seems to be working so well? The answer is simple; if you can offer a richer experience that your customers find valuable, you can motivate them to pay for it.

Back to top

The next phase: Balanced computing and web services

Browsers don't typically run on anemic client devices. Most enterprises have established a large base of rich client systems. Currently, there are already more than 100 million laptops and desktops deployed in the field whose processors are at least as powerful as a Pentium III. That's significant processing muscle going to waste with the current client-as-browser model. Developers can deliver software that makes it possible for end users to extract more value from their investment.

Before web services, there was no way to adequately serve and manage diverse platforms and deliver a rich user experience at the same time. But with the advent of web services, applications today can be deployed as a confederation of interacting components; components may reside on different machines, or all on the same machine. The components can be written in-house or acquired from third-party sources, with communication between components handled in a universal format like XML and by universal protocols like SOAP.

Web services make installation and maintenance of solutions and applications easier in two ways:

• First, because applications based on web services are realized by integration of components from multiple sources, developers building such apps must follow strict version management policies. Version management within components makes it possible to clearly identify dependencies and associated maintenance actions, leading to customized maintenance for every deployment of an application.
• Second, web services are described in universal formats such as XML and WSDL, and are transported using universal protocols such as SOAP over HTTP. Thus, it's trivial to accomplish initial installation and subsequent maintenance tasks using standard web servers, through HTTP tolerant firewalls, etc.

The model that takes advantage of these web services benefits is called a balanced computing model. A balanced computing model is a method of design in which a solution is designed and delivered by making optimal use of capabilities -- both computing and communication -- present in all systems. In such a model, no one system is stressed more than necessary for its role, especially not at the expense of other capable systems involved in the solution or application. In the remainder of this article, I'll discuss how balanced computing can offer a better alternative to the browser/server model.

Back to top

Predictability and the need for headroom

In a server-centric system, you must ensure that servers can handle the load imposed by the most severe demands. But how can you predict those demands? Amazon can't predict when customers will order their cookbooks. In any server-centric system that supports many users, accurately predicting when and how customers will use the system is problematic. With a diverse customer base, developers must build in headroom to accommodate a consistent user experience.

Now, it's certainly possible to design server software to support scaling and account for unpredictable behavior. You can scale up -- keeping the same servers, but packing higher-performing CPUs or more memory into them -- or out -- creating another set of servers to balance or distribute the load. But scaling has a cost and does not provide the customized user experience you want to deliver. The bottom line is that throwing server power at the problem addresses predictability but has its own limitations -- and no user upside.

Back to top

Changing the role of the server

With balanced computing, the server shoulders application processing only when it needs to. Processing is shared among any number of servers, clients, and devices on the network. The web services components of the application itself are spread across many network nodes. Instead of pushing all computing onto a few systems, it balances the load among them all. The incremental load added by each new user is insignificant; when a new user joins, the load from that new system is largely shifted back to that system.

Designing a solution based on these principles allows you to scale seamlessly as you add more users. By decoupling the server, the balanced model removes the traditional constraints on server-centric solutions, enhancing the scalability of the system as a whole. This in turn lets implementers address unpredictable customer use, and build in extra headroom to provide a consistent user experience. In this way, the balanced computing model displays a superior capacity for delivering a customized experience.

The application developer should assemble a services-based application consisting of many individual components that can run on a variety of nodes. Services may be duplicated on multiple nodes in multiple locations. This provides inherent load balancing for the application. At the same time, use of multiple nodes enhances reliability because there is no single point of failure for the application.

In this architecture, the developer can leverage the maximum computing and display capabilities of each user platform. Each individual user employs a unique constellation of physical devices to support the application components he or she uses, while the nature of the virtual application balanced across multiple nodes remains transparent.

In the balanced computing framework, distributed applications change the role of the server; instead of spending its resources in computation, now it mainly directs traffic. With capable clients, and when Internet connectivity is working well, the server is called upon less because requesters access a database server directly. Server downtime or loss of Internet connectivity doesn't necessarily mean downtime for the rich client, because it can use data and its own computational capabilities to complete tasks.

The server pushes computation to the connecting device; the amount of work that it offloads to the client depends on the device's capability, of course. The server may need to pick up the slack for less capable clients (like PDAs or mobile phones) or when Internet connectivity is not great. (Knowledge workers will typically have multiple devices: a desktop, a laptop, and a PDA, for example. Even consumers will probably have at least two devices, like a desktop and a mobile phone. Plan for it.) Still, the move to balanced computing eases the demands on the server. Server muscle is flexed only when needed, improving both client and server performance.

Back to top

Targeting the user experience

There is a significant side benefit to balanced computing solutions. Developers can look at each device -- and the user role associated with it -- and deliver a very precise, customized user experience based on job function. For example, in a manufacturing system, there may be several roles involved, including administrators and manufacturing personnel; under a distributed computing model, each role would have its own UI.

Now, you could certainly perform such per-user tailoring on the server side. However, there would be undesirable consequences. If choices for each user role were stored on the server, data would then need to be passed through the filter defined by every user. That's a lot of computation, and it's not really necessary. Server-side filtering just doesn't scale; the required processing is prohibitive.

On the other hand, when a user role profile is stored on the user's own machine -- desktop, laptop, PDA, or whatever the user employs -- that user profile can be tapped to pull very specific data from the server. Clients can even talk to the data source directly, request what they need for the user role profile, and never trigger server computation. This means less work for the web server on the output side, and eliminates the web server middleman on the request.

Back to top

Developer dreams

Integration of data on the user platform creates new development opportunities -- opportunities to build applications that can work with data drawn from a variety of sources and introduce additional context. Data warehousing and data mining have shown how powerful local manipulation of information can be and balanced computing exhibits many of the same advantages. For example, the web sites of your bank, your credit card company, and your favorite retailer store and can retrieve lots of financial information about you -- but it's all on the web server and database side. Your browser only shows the results of queries, and you can't do much more than look at the data. In a balanced computing scenario, a web service would send that same information to your system in, for example, XML format. I'm sure you can think of a desktop application that would collect those three distinct sets of data in a standard, manageable format, place them in a new context, and present them in a totally different way. Thus, using the client processor's power -- without depending on server availability -- you can analyze data, often in ways or in contexts not possible at the source. You can look at the output from multiple single applications in a uniform fashion, combining existing contexts and creating new ones.

These are not the only benefits of the balanced computing model. The decentralized nature of this approach can enhance both security and privacy. For example, off-server data repositories are harder for external attackers to locate, and less attractive for internal attackers to steal. Storing your user profile on your own machine may be more secure than storing it centrally. In addition, data is more private when scattered in multiple locations than when it is proximate.

Back to top

Balanced computing vs. P2P

You may be thinking at this point that balanced computing sounds a lot like a peer-to-peer network. There are similarities between the two, but the peer-to-peer model takes this whole distributed approach one level further -- too far, for some applications. There is no notion of separate client and server in a peer-to-peer solution, and such a solution only really works if all connected systems have high-speed connectivity on a homogeneous network with very high levels of availability. Even with intelligent rerouting, that's just not reliable on the Internet.

Back in reality, networks do tend to have high uptime and bigger bandwidth skewed physically towards giant servers. The balanced computing model suggests that developers design solutions that will take advantage of such capabilities, while still distributing computing where possible. Thus, distributed computing uses Internet connectivity and the potential of the connecting device when it can, but it does not have to depend on it to deliver consistent performance. The server detects what it's talking to and, based on the computing and communication capabilities of the device (a desktop with wired LAN/WAN, a laptop with wireless LAN/WAN, a PDA with a thin wireless WAN, a mobile phone with a thinner wireless WAN, and so forth), decides how much computing should be offloaded to various clients. In contrast, in the peer-to-peer model, no such decisions are necessary -- or possible -- since all nodes are assumed to compute at the same level.

Notice that with balanced computing, the desktop is both a client and a server, depending on its role as defined in the solution. When the user of a desktop or laptop is physically present, the experiences delivered by that machine drive its role as primarily a client, by bringing together data and contexts from multiple sources and building a unique presentation suited for the end user. When the owner of the machine is physically absent, the desktop begins to take on some of the server role.

Back to top

Balanced computing at work

Consider an example that suggests a balanced computing approach, and shows how a traditional implementation would differ. At Widgets, Inc., the supervisor of a manufacturing line is one user (and one role) of the shop floor control program. This supervisor is on site, speaking with workers at various stations of a newly configured line; he needs real-time information about defects from each station. He also wants to know how the new configuration stacks up with other lines in that same factory and across company factories, to look for additional tweaks and improvement opportunities -- as well as to point out the advantages of the new line. Using a PDA, he makes a connection to the corporate web server, which interrogates a back-end database, extracts the data requested, performs any necessary computation, and pushes back a simple display appropriate to the PDA.

The manager of the entire factory is another consumer of this shop-floor control application. She monitors production and defect levels across all lines in the factory to see how the new line is faring. From an office in another part of the factory, she uses a rich client desktop that connects with and directly interrogates back-end databases, extracts requested data, performs all necessary computations, and produces any of a number of graphical analysis displays to frame the information appropriately.

Notice that for the line supervisor, the server had to take on the tasks of back-end querying and data computation, while for the factory manager, the capable client handled that processing with minimal server involvement. In a traditional implementation, the server would have had to do all the work in both instances, probably generating the same lowest-common-denominator display for both users, as inappropriate as that would be. A peer-to-peer approach probably wouldn't have even allowed the PDA to participate, since such a device would lack the threshold horsepower.

Note that in this scenario, server downtime or network hiccups wouldn't affect the rich client user much; she would continue to have cached data and the analytical ability to manipulate it, and to schedule future synchronization of the manipulated data as well. Such scenarios are occurring as at this moment and will continue to occur in a real world. The software architecture of an application based on the distributed computing model using web services can effectively solve these productivity-losing situations your customers are bound to face. (You can find more information on these topics in the Resources section below.)

Back to top

Balanced on the edge of the future

For many software developers, the balanced computing model inspires dreams of new applications -- and ideas for improving existing apps. Certainly, under this model, the application developer begins to assemble more services and processes than ever before, and begins to face and address workflow resulting from multiple sources.

Balanced computing represents the next phase in solution design. Organizations must build independent, nimble connections and applications that can adapt and react on the fly. Loosely coupled applications can weather broken connections and sluggish network performance, protecting core business systems from the vagaries of customer demand and Internet bandwidth problems. Compound applications integrate into clients' existing business solutions by using distributed components. The result will enable businesses to distribute applications and information to constituents that are diverse -- and numerous.

Resources

• Find out how distributed computing and other virtualized models fit into e-business on demand.
  
  
• Learn more about Grid computing at the developerWorks Grid content area.
  
  
• For the IBM opinion on distributed computing, check out the Distributed Computing Environment.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• From the networked personal computer to the server/browser model
• The next phase: Balanced computing and web services
• Predictability and the need for headroom
• Changing the role of the server
• Targeting the user experience
• Developer dreams
• Balanced computing vs. P2P
• Balanced computing at work
• Balanced on the edge of the future
• Resources
• About the author
• Comments