Software Architecture
 Architects and Process |
|
Software Architecture |
||||
|
||||
| Internet Architecture | ||||
The Internet has given designers (and the general public!) the ability to access computers all over the world. The underlying network is reasonably fast and reliable, with tremendous redundancy built in to handle problems. It's a very cool playground for architects. Two factors make the Internet technologies appealing:
The first level of Internet architecture is serving up static content. Very little is needed. With free HTTP server software and an old 386 PC, nearly anyone can be in business in a matter of minutes. Application architecture tasks are limited to setting up useful directory structures and standardizing HTML templates.
Internet applications are more interesting if they can serve up dynamic data, such as weather, sports scores, price and availability of goods. An early solution still in use is the Common Gateway Interface, CGI. The browser sends a special request for CGI services. The HTTP server identifies the request and invokes a plug-in. The server pipes the request to the program's standard input and pipes the standard output back to the browser. The program can query or update databases and generate reply HTML as desired. There are CGI plug-ins for nearly every modern language. The main drawback to CGI is that each request starts a new heavy-weight process on Unix boxes, which is an expensive proposition.
Microsoft's Active Server Page technology is typical of scripting solutions. ASP mixes script with HTML. It returns the HTML parts of the page just like normal HTML and interprets the script parts. The script can access a database and loop through HTML generation. Each new request starts a light-weight thread instead of a whole process.
A Java alternative is Java Server Pages, with very similar processing for Java scripting. JSP combined with Servlets, a Java alternative to CGI, offer a flexible way to build object oriented web servers. Struts is a good open source framework for building web apps.
Other products such as ColdFusion and PHP have big followings, too.
The next step up from scripting, is N-Tiered computing with serious application servers in the back-end. This rapidly turns into a conventional N-Tiered deployment picture with CORBA or J2EE in the back-end, plus an HTTP server to connect to the client.
Internet applications have special needs around scalability. The main problem is that unlike a corporate setting where you know how many users will have access to your system, you have no ability to predict or control the number of users you might get. If your site is mentioned on the CNN Nightly Business Report, you could be buried within minutes.
One strategy is to build redundant servers, multiple machines running exactly the same code. Various hardware or software solutions will load balance these machines, dividing incoming requests among any number of servers. In dynamic configurations, operations staff can add new servers very quickly to handle surprise peaks. Some load balancers use a simple round-robin allocation, while others have sophisticated monitoring of servers to evaluate their health and send work to the server with the most capacity.
The redundant machines introduced for scalability also pay off in reliability. If one machine fails, the load balancing router pushes all the work to the remaining machines. If we design for such fail-over the user should lose nothing at all and may never realize anything happened. High availability sites sometimes duplicate their entire structure in two locations to address the risks of power outages or regional network failures.
This picture shows one possible structure for load balancing and fail-over. Each HTTP server is mated to an application server, so if either goes down, the pair is out of service. This works well when you put these two logical entities on one physical box. Other choices could put another load balancer between HTTP and app servers, so any HTTP server could talk to any app server. We might choose to have redundant databases as well, with any variety of replication techniques.
Web applications often have to hold some information about the user for the time the user is browsing the site, say a shopping cart with several items in it. Designers have many choices about where to put such data. Here are a few:
Options 1 and 2 hold data in memory on the server. This runs into trouble quickly as the server runs out of memory with only a few users. These also force us to send the user to the same machine every time. Most servers offer "sticky sessions" to do just that, but stickiness impairs our load balancing algorithms and won't fail over to another server. In almost all cases we want to reject these options and make the server "stateless". That simply means that the server holds nothing in memory on behalf of a user while the user is looking at the screen. When a request comes in, the server handles the request, sends a reply and immediately forgets everything. The memory is available for processing other requests before the user hits enter again. (Does anybody else remember pseudo-conversational CICS programming? Some of us have been doing stateless servers since the 70s!)
Choices 3 through 6 push data out to the user's browser and back. They work well if there are small amounts of data with no issues around the user being able to see the data and possibly hack it.
Choices 7 and 8 are interesting, and have many sub-options. If we do not want sticky sessions, we have to push the data off the server, probably onto a common database shared by all application servers. We must avoid creating a single point of failure here!
In the EJB world, the server can optionally automate 7 and 8. Stateful Session Beans manage temporary storage of session related data, and Entity Beans manage persisting data to a database. These options are controversial. Automation improves programmer productivity and code simplicity, but system-generated code and SQL may introduce tremendous overhead compared to what your best developers can write.
The big buzz today is Web Services. The simplest definition of a web service is a software component that one can call via HTTP. Even this minimal definition gives us a number of cool benefits. We can call from anywhere in the world. We can call services without even knowing what language, platform, object model, etc is on the other end. The text nature of HTTP messages solves all kinds of data typing problems, big end vs. little end numbers, etc.
Of course no architect could stop at such a short definition. Web Service fans specify the HTTP message should contain XML. And as long as we have XML, we might as well jump on a standard like SOAP to organize the content. Now we can communicate with new business partners using standards-based message formats just by knowing a URL.
Web Services with XML over HTTP interfaces promise unparalleled interoperability with relative ease. My only concern is that this may be a "lowest common denominator" solution. The "common" part is surely good at lowering barriers between disparate platforms, but the "lowest" part worries me. HTTP is one of the slowest protocol choices I have, and XML bloats message size and introduces complex parsers.
In a contrary camp, some of the very inventors of HTTP and the Internet believe HTTP already has all the "verbs" required to build services - get and post - and requests can be normal HTTP requests with no XML packages. The REST style architecture can make complex services available to browsers user using nothing more than a normal link.
Complementary standards include the Universal Description and Discovery Interface. One can publish a description of a service on a UDDI directory. Then someone else can search the directory, discover the interface, get all the information needed to call it from the directory, and start calling the service.
Some UDDI promoters have a fantasy of dynamically discovering services and calling them on the fly, but the realistic model is that you may discover a useful service at design time, contact the owners and negotiate an arrangement for sharing. In a closed environment, you might use UDDI to find one of several known providers within your company - maybe the closest or the one responsible for a particular product - and call it. But I doubt you'd ever call a complete stranger for service just based on his UDDI entry.
Other emerging standards to watch are EBML for Electronic Business Markup Language, being developed by the United Nations and a consortium of countries and companies, and XAML for transactions with multi-phase commit across multiple web services.
The premier vendor in full-blown web service solutions is Bowstreet. They have a fascinating internal architecture for generating rule-based customization of the output.
Once we have an n-tier architecture, it would be nice to be able to use the business and data services from other types of applications, say fat client, a voice response unit or a business partner.
The picture above shows normal browser clients and business partners coming into the system via HTTP. The browser uses HTML over HTTP, while the business partner sends and receives XML. In either event, the HTTP server is hosting the presentation layer.
Windows clients written in any Windows language can connect directly to the application server. The client does its own presentation work.
A Voice Response Unit, a.k.a. Interactive Voice Response, can use the same application server.
Other applications and other channels - E-Mail and new ones we haven't thought of yet - will use the same back-end application server.
This meets one of the application architecture goals, using the same data and business rules for all channels. We don't want our customer to get one answer from the VRU, another from the web and another from the call center!
| Architects and Process |
