| Project LongJump — an Architecture for Low Cost, Secure Internet and Wireless Services | ||
|---|---|---|
| <<< Previous | Next >>> | |
The first step in architecting an Internet-based application is understanding the environment in which it operates. This environment (shown in the simplified network diagram of Figure 1) is certainly a demanding one. Failure to master it results in constant crashes, service outages, frequently successful attacks by hackers, and errors that anger users. Tame the Internet environment with the right architecture, however, and the full power of global communication is yours. Your servers, spread across multiple locations, work reliably with each other. Applications running on third party systems are smoothly integrated. Customers — using desktop machines or mobile wireless devices — easily access your service at any time of day or night.
Unfortunately, the impressive capabilities of the Internet come at a price. Being able to connect together a large variety of systems spread across the world creates a heterogeneous, unsecure environment. The Internet simply has to be this way — otherwise it would be of no value. After all, if someone else decided who your application can talk to, and who can talk to it, your options would be severely limited. On the Internet, these kinds of choices are largely up to you — the application's owner.
The Internet is a network of networks. Your server (or servers) reside on some Local Area Network (LAN), which is connected to the Internet. In practice, both the LAN and the Internet connection is usually supplied by an Internet Service Provider (ISP), on whose premises the application's servers are also located (collocation). Those servers are your little corner of the Internet — you get to choose who is allowed to enter there, and what they are allowed to do once inside.
There might be one server or several, working together in a group via the LAN (some demanding installations of this type use a dedicated, high speed LAN for server-to-server communication). The application may also be distributed over a wider area, with additional servers at other locations. This is typically done for reliability — if there is a failure that affects an entire site, another, geographically distant site is likely to remain operational. In contrast, multiple servers are also often deployed at a single location to increase capacity (i.e. a larger number of simultaneous requests can be processed every second).
System administrators and network engineers can take a variety of measures in order to protect the application from attack (e.g. by installing a firewall to block some intruders, running intrusion detection software, etc.). These measures, while very important, are not sufficient. The application itself — since it must remain widely accessible — has to implement its own security.
On the client side, a desktop or laptop computer is the most common type of hardware used (of course, capabilities and operating systems vary greatly). Mobile wireless devices, however, are becoming an increasingly popular alternative. These devices (typically telephones and PDAs) are connected to some wireless carrier's cellular network, which, in turn, is connected to the Internet. Internet connectivity is a requirement for cost-effective third party services to wireless clients. High bandwidth capability, however, should not be necessary for many applications — provided that the network protocol is well designed.
An Internet-based application does not have to rely solely on its own servers for all functionality. External services, for example, may be accessed (possibly subject to a license) in the course of fulfilling a user's request. The Internet is the perfect medium to integrate such disparate systems together into a single application — or even multiple applications with shared components.
Based on the operational conditions just described, several key characteristics required of an Internet-based application can be stated. These characteristics are discussed below.
Customers are used to free Internet services, as well as continually declining prices for access to both the Internet and wireless networks. An ideal solution is an inexpensive one, which leaves a wide margin with regards to pricing strategies, and even makes it possible to operate free services.
Besides the ubiquitous desktop, portable device such as PDAs and mobile telephones are becoming ever more common. These are highly personal items, so users' preferences in such devices can be expected to vary widely. An application that would serve such mobile wireless systems (either immediately or later in the future) must be adaptable to a large variety of client hardware, with a diverse range of capabilities.
Networks are central to a distributed application — especially one which operates in the dynamic (and chaotic) environment of the Internet and wireless systems. In particular, the way that data is exchanged between servers and clients is a critical determining factor in the performance, security and extensibility of the whole application.
While modern network implementations consist of multiple layers, making it impossible to have control over the entire protocol stack, a well-designed protocol even just at the application level is still very important. See Client-Server Networking for a discussion of what makes a good protocol design.
Clients can access an Internet-based application at any time of day or night. Technical support personnel may not be able to fix problems effectively in the evenings, so the system must continue to function for long periods without human intervention.
In a typical Internet-based application, anybody can send a message to the servers. The application must be able to reject badly formed messages that might come from attackers trying to break in. The system must also establish that a message is from a valid user in good standing, and that the user has the permission to carry out the operation requested in the message.
In a distributed, multi-user environment it is important that a single, coherent system state is presented to everyone. Paid services, which integrate a billing component, provide an excellent example of the consequences caused by state consistency errors.
Few things frustrate paying customers more than calling technical support in the evening, only to hear that there is a problem with billing, but, unfortunately, the billing department is closed at the moment. Somewhere inside the system, the information that this particular customer has paid the required fee has not survived the trip from the billing component to the point where the actual service is being provided.
These confusing situations often take several costly support calls to resolve, because the billing department believes that service has been authorized, but no such authorization is recorded elsewhere in the system. In the end, the customer is likely to be very unhappy. The right software design greatly reduces these kinds of errors, by making the maintenance of a consistent system state a key priority. This avoids heavy customer support costs and large losses of goodwill caused by state consistency errors.
Because server systems are hidden in the background, it not easy to keep track of their status. A good monitoring tool provides strong feedback to the operator about the internal condition of the server. It also allows a clear demonstration of the server's technology in front of a general audience.
| <<< Previous | Home | Next >>> |
| Introduction | Building Blocks |