Distributed Applications

Applications escaped the well-controlled computer-room environment in the early 1980s with the advent of personal computers and networks. Perhaps it was the computer operators’ white lab coats, the pocket protectors, or the horn-rimmed glasses, but applications couldn’t take it anymore. They needed a break and wanted a life. Can you blame them?

While application technology developed, we saw smart terminals that had field editing capabilities (cough . . . most of you readers weren’t yet born when these terminals were prevalent) and, later on, two-tier and three-tier client-server applications in which some of the application logic ran on a server and some of it ran on a PC. Client-server technology looked really good on paper (and on those fancy new whiteboards), but it never measured up to its potential.

Then in 1990-1993, Eric Bina, Marc Andreesson, Tim Berners-Lee, and Robert Cailliau developed the hypertext transfer protocol (HTTP) and the first popular web browser called Mosaic, which sported such features as hyperlinks and web pages that contained pictures and text. Thousands of people downloaded Mosaic, which was available for PC, Mac, and UNIX-based operating systems. Distributed applications (applications made up of distinct components on networked computers) were on the rise, and the Web was cool and really fast — until the general public found out about it and ruined it. Seriously, though, a lot of neat and relevant technologies were born out of the Web, many of which we discuss in this chapter.

In effect, the Web was the death-knell for client-server applications and other legacy application technologies.

A distributed application is an application that consists of components that reside on separate, networked systems.

Security in distributed systems

Securing distributed systems is anything but easy, and it boils down to three distinct issues:

Software integrity: In a distributed system, the application may consist of software components located on various systems located in different physical locations, some of which may be owned or managed by other parties. Hundreds (or even thousands) of workstations may exist on the system, and all must have the right version of client software. Keeping track of the versions of all these separate components can be a nightmare, particularly if different parts of the organization (or even different companies!) support the various hardware platforms. Imagine the scenario if, a few days after a new release of an application is installed on all the systems, one of those systems suffers a catastrophic failure and must be rebuilt from backups — or if a new software release proves difficult to install properly on many workstations. Not our idea of a fun day.

Data integrity: The data in a distributed system may reside in many physical locations. And with advanced technologies such as data replication and cloud computing, the data often resides in many locations at the same time, introducing new problems. How, for instance, do you make sure that the data in these different locations remains accurate and in sync? Say you make a set of backup tapes before an application upgrade and you have a hardware platform that runs an older version of some part of the application. Perhaps the changes in the application upgrade were subtle, but they can be devastating. For example, now every customer’s middle name has been changed to Celine. (Royalty checks not included.)

Access control: All those distributed components need to talk with each other via the networks that connect them. Most easily, you can have the systems just talk with each other with full and complete trust. Well, Kevin Mitnick (cyber-criminal turned quasi-celebrity), Robert Morris (of the infamous 1988 Morris Worm), and scores of other infamous characters taught us that trusting everybody isn’t such a great idea, so the best approach is to make the various components in a distributed environment prove their identity to one another. This means setting up some sort of authentication, access control, or maybe even a full-blown Kerberos environment so that the various parts of a distributed application know that the other parts they’re talking to are the real deal and not hackers looking for credit card numbers to steal. It’s enough for the over-55 set to wish for green-screens and mainframes again.

Distributed systems were a great idea at the time, but the tradeoff between offloading application logic from centralized servers and the additional complexity in the distributed environment didn’t pan out very well. It was a stepping-stone on the path of progress; thankfully we didn’t stay there very long.

But wait! Distributed systems have made a huge comeback in the form of mobile apps. Now, users will install and use applications in devices such as tablet computers and smartphones. These applications communicate with other systems: application servers, database servers, and even other devices.

The rise in popularity of mobile apps once again proves that, given enough time, almost anything once rejected will be back in style.

Working with agents in distributed systems

An agent is a software component in a distributed system that performs a particular service. An example of an agent might be a system that takes a credit card number (with expiration date, customer name, purchase amount, and so on) and builds a merchant transaction to send to the bank. The agent processes the transaction and gives a yea or nay response back to the main application, which then gives the customer placing the order on the Web the good or bad news.

Today, you most often see agents in systems management software rather than in business applications. Several examples of agents include

Patch management: An agent determines what patches are installed on a server and facilitates the installation or removal of patches. A central management console controls the whole process.

Host-based intrusion detection systems (HIDSs): Agents use various means to detect signs of attempted tampering and send alarm messages to a central console, which alerts personnel about potentially serious events.

Performance and capacity monitoring: Agents periodically measure the utilization of computer resources such as CPU time, memory, and disk space.

An agent is a component in a distributed system that performs a particular function.

Adding applets to the mix

An applet is a component in a distributed environment that’s downloaded and executed by a web browser. Web browsers, which are designed to display text and graphics, and also to accept data input from users on forms, can’t process information locally on the client system very effectively, so applets were invented to solve this problem and enrich the user’s web- surfing experience.

The neat thing about applets is that they run seamlessly right in a web browser, and you can’t even tell whether an applet is running or you’re just dealing with straight HTML. Ignorance is bliss.

The two most popular environments for applets are Java and ActiveX. Java code runs in a constrained environment called a sandbox, which means the Java code can communicate only with the host from which it was downloaded. Java can also display things on the screen and accept keyboard or mouse input. However, Java applets can’t access a PC’s hard drive, memory, or any other devices. Web browsers today get a lot of practice saying to Java applets, “Go play in your sandbox and leave my hard drive alone!” And rarely do Java applets escape from their sandboxes. Personally, we think they’re surrounded by the digital equivalent of razor wire.

ActiveX, which is really just a cool name for OLE over the Internet, is Microsoft’s “not invented here” response to Java. ActiveX uses a completely different security philosophy than Java, and it goes something like this: People running web browsers get to decide whether they trust all ActiveX applets that come from a particular server. Digital certificates prove whether the ActiveX applet is genuine.

A rogue developer can write some pretty nasty ActiveX code that (say) melts your hard drive and plays old Alice Cooper songs through your PC’s speakers. ActiveX has no concept of a sandbox. If you trust the server that the ActiveX applet comes from, then you’re basically saying that you give all control of your PC over to the ActiveX applet, and it can do whatever it wants. This setup is all fine and good in an ideal world (for a 3-mile radius around Redmond, Washington) where everyone is trustworthy. In the real world, though, programmers who have an attitude — or even honest and ethical programmers who make a mistake — can permit bad things to happen to your system. Always turn down your speaker volume before running ActiveX applets — unless you’re in a closed room or you really like Alice Cooper.

Administrators can configure many proxy servers to filter out ActiveX applets (and most administrators put in extra hours to do this). You can also configure web browsers to not run Java or ActiveX applets, but the last time that we checked, users can just change this setting back so that they can see their stock tickers or the cool pictures at www.time.gov . Enterprises that are serious about protecting themselves — even at the expense of disabling some cool websites — really need to block ActiveX applets at the firewall or proxy server.

Applets are also known as mobile code because they’re downloaded from a server and run on a client.

Another interesting use of applets is the mashup, which is a web page or application that combines functionality from external applications through their published application programming interfaces (APIs). Online maps that display locations which come from a different online application implement mashups. You can see an example of a mashup application — one that shows real estate listings superimposed on an interactive map — in Figure 7-1.