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 any more. They needed a break and wanted a life. Can you blame them?

As application technology developed, we’ve seen smart terminals with field editing capabilities (cough . . . most of you readers weren’t yet born when these 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 white boards), but it never measured up to its potential.

Then in 1992, Eric Bina, Marc Andresson, and Al Gore (the self-proclaimed father of the Internet) developed 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, and soon the modern World Wide Web (WWW) was born. 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.

The Web was the death knell for client-server applications.

 Instant Answer   A distributed application is an application that consists of components 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: Software integrity is a challenge because 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. Keeping track of the versions of all these separate components can be a nightmare, particularly if the various hardware platforms are supported by different parts of the organization (or even different companies!). Imagine that a few days after a new release of an application is installed on all the systems, one of the systems suffers a catastrophic failure that must be rebuilt from backups. Not our idea of a fun day.

• Data integrity: Keeping data secure is likewise a challenge in distributed systems, because the data itself may reside in many physical locations. And with advanced technologies like data replication, 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 in sync? Say you make a set of backup tapes before an application upgrade. Now you have a hardware platform running an older version of some part of the application. Perhaps the changes in the application were subtle, but they can be devastating. 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. The easy thing to do is to have the systems just talk with each other with full and complete trust. Well, Kevin Mitnick (cyber criminal turned quasi celebrity) and Robert Morris (of the infamous 1988 Morris Worm) taught us that trusting everybody isn’t such a great idea, so the best approach is for the various components in a distributed environment to 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 that 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 mainframes again.

Agents

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 gets to give the customer ordering books on the Web the good news or bad news.

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

Applets

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 accept data input on forms, aren’t very good at processing information locally on the client system, so applets were invented to solve this problem and enrich the user’s surfing experience.

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

 Tip   The two most popular environments for applets are Java and ActiveX. Java code runs in something called a sandbox, which is to say that the Java code can only communicate with the host that it was downloaded from. Java is also permitted to display things on the screen and accept keyboard or mouse input. However, Java applets aren’t permitted to 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 are used to certify whether the ActiveX applet is genuine. With ActiveX, a rogue developer can write some pretty nasty ActiveX code to melt your hard drive and play old Alice Cooper songs through your PC’s speakers.

This kind of thing is possible because 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 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 with 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.

Many proxy servers can be configured to filter out ActiveX applets. Most administrators will put in extra hours to do this. Web browsers can also be configured to not run Java or ActiveX applets, but the last time that we checked, users could still just change this back so that they can see their stock ticker or the cool picture at www.time.gov. Enterprises that are serious about protecting themselves - even at the expense of disabling some cool Web sites - really need to block applets at the firewall or proxy server.

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