 | ||
|
| ||
| ||
|
| ||
Robert Hess
Developer Relations Group
Microsoft Corporation
November 16, 1998
The following article, which was originally published in the Site Builder Magazine (now known as MSDN Online Voices) "More or Hess" column, continues a series in which MSDN Online columnist-at-large Robert Hess investigates application development.
So far in our investigation of "Web applications," we've looked at things from a very high conceptual level. We've considered The Right Tool for the App (October 20), Application Development in the Internet Age (September 21), and Applying the Web (August 17). This time, let's dive in a little closer and focus on some actual implementation issues. While a true "application" will have a lot going on in both the "business logic" and "data services" layers, the presentation of this information is still what can often get the most attention, which is probably foremost on your minds.
Remember that every solution brings with it a unique set of expectations, limitations, requirements, and approaches that affect how the solution's presentation should be dealt with. The possibilities range from a broad-reach approach (going after compatibility with the largest number of client systems) to a rich-interface approach (taking maximum advantage of specific capabilities of the operating system or hardware platform). The method you choose for your solution will almost certainly involve trade-offs, depending on how you prioritize your client-side objectives and capabilities.
The Web has traditionally been one place where "reach" is an underlying objective. HTML standards and browser compatibility, as well as the availability of browsers on different platforms, all allow services to be exposed in a manner that pays little attention to the specifics of the user's operating system or browser technology. It is common for Web sites to keep their site designs slightly behind the times in order to remain compatible with as many different browsers as possible.
Let's pretend for a moment that your situation is as follows: You have a service that you want to expose to a broad audience, and you think the Web is the best way to go. Where do you focus your energies? How do you provide the best possible experience for your users, while addressing compatibility issues in a way that keeps your implementation as straightforward as possible? For discussion purposes, lets say you are a leading architectural firm, and you want to provide a method to allow a robust, interactive, visual walk-through of many of your firm's past projects.
To address a "reach" model for your service, you need to focus on the components that you "own." Or perhaps "control" would be a better term. In a full-reach model, you have almost zero control over the operating system and browser technology your users employ. However, you should have a certain level of control over, or at least clear knowledge of, the server that is hosting your site. (Either you actually choose the operating system and installed services for your server, or at least your hosting service gives you a clear description of what is, and is not, possible.) So the more functionality you can place on the server, the better. For our example project, your site would most likely want to rely on JPG or GIF images for the visual tour your site was presenting. While ActiveX® controls, Java applets, or plug-ins might provide more functionality, they also would be tightly tied to the specific capabilities of the client browser -- and in this particular scenario, we are trying to avoid those limitations.
You also need to identify the source of any data on which your solution depends . Is it coming from systems and resources you control? Are you getting it from an external source? Is it "new" data that you are constructing specifically for this project, or are you utilizing existing data that already has a defined structure and implementation model? Again, the more you "own," the better. And the fewer your expectations of the parts you don't own, the better. For our example architecture site, this data is probably something that describes the construction diagrams for the structure you are presenting. An example of "not owning" that data would be using the file format of the architectural application used to design the structure. Such information might not only be far more than you need to provide the walk-through experience, but it might also be more time consuming to process constantly. If you chose to "own" the data, this would probably be in the form of pre-processing the drafting information to create a minimal subset that was specifically designed for fast retrieval and computation.
All of this points to the importance of placing implementation resources on your Web server. This is the part of the Windows DNA design model that we call the "business logic" section. You can also view this as the "processing" component of your solution. It doesn't necessarily represent a single server. Using a distributed programming model, you can leverage the processing capabilities or specialties of multiple connected servers. Referring back to our architecture example, we would in the "business logic" part of the site read the architectural information from whatever storage mechanism we chose to use -- processing the model internally, creating a graphical rendering based on the user-requested position and orientation, generating a JPEG or GIF image on the fly, and then passing that image back to the user.
Together, the various parts of this Web application provide a clean and flexible method for creating a highly functional Web site that is also compatible with a broad range of browsers. It would probably require more work and server functionality than simply leveraging the abilities of a specific client browser -- but if your goal is for "broad reach," this is a trade-off you might need to make. Here are some more tips and approaches that might be appropriate for your situation:
If you really want the greatest possible reach, avoid paying too much attention to the advances coming out in the latest versions of browsers. Yes, they might be cool. Yes, they might directly address a problem you are having. But if you've identified one of your priorities as a broad-reaching compatibility, then you'll just cause yourself trouble by designing in some of these advanced features, all the while hoping to find a workaround eventually for down-level browsers.
Server-side scripting is a fairly exciting way to enhance your pages. It allows you to easily provide in-page logic that decides what HTML code is sent down the pipe to the client browser. However, there are two important things to keep in mind as you implement this:
First and foremost -- and the issue that generates the most questions to me -- is that server-side scripting must happen on the server, before the resulting HTML code gets sent to the client system. A function defined with a server-side script block can't call a function defined in a client-side script block, and vice versa.
Second, adding ASP scripting to a page does incur overhead. This means that an ASP file will take longer to process and send down to the client than a raw HTML file. Granted, taking standard lag time of data-transfer rates into account against high-speed processors on the server, the difference in total rendering speed between an ASP file and an HTML page might be extremely slight. However, there will be a difference. A well-designed ASP site will leverage the server-side scripting selectively, within specific pages where it provides the greatest benefit. An example of using ASP technology incorrectly might be to make all of the pages on your site use server-side scripting simply in order to add a random background sound to them.
If you rely on an external data source, I highly recommend that you use ActiveX Data Objects (ADO)
to connect to these databases to retrieve data. The thing to avoid is any tightly coupled proprietary interface to a specific database. Going down that route ties you too closely to that specific technology, and if you later need to switch your data-storage model, it can often be difficult to revamp your connectivity logic to deal with such a change. ADO is designed to provide an extremely flexible interface that can connect you to virtually any of the common database engines. And as new or updated databases come out, interfaces can easily be provided to make them accessible via ADO.
As exciting and flexible as server-side scripting might be, you should be aware of the benefits of server-side components, and how and when to use them on your site. A server-side component is a compiled executable that runs on the server, and can be easily invoked and communicated with via ASP code on your page. When you use ADO to connect to a database, you are using a server-side component. It might even be appropriate to write your own server-side component if you want to expose some form of processing that is unique or otherwise strategically targeted to your specific solution. Examples of this might be providing an interface to a piece of proprietary hardware, or implementing application logic that represents the specific features of your solution offering.
To properly take advantage of developing your own server-side components, you must also understand the abilities of the development resources at your disposal. If your staff is entirely comprised of HTML authors, then you can't expect them to write properly optimized components. In that case, you would either want to find third-party components that perform the functionality you seek, or outsource the development for that specific situation.
Just because you want broad reach doesn't mean that you can't add any advanced features to your pages. You just need to be careful about how you do it. As I suggested earlier, start with a relatively generic HTML 3.2 page; after you've gotten that pretty well defined, you can look at the possibility of leveraging some of the advanced features of Internet Explorer 4.0 or even 5. Several advanced features that can easily be added to a page are simply ignored by down-level browsers. For example, you can add a TITLE property to any tag, and, in Internet Explorer 4.0 and higher, the string associated with that property will be displayed as a ToolTip when the mouse is over it. Down-level browsers simply ignore this. You can also carefully add client-side script code that attempts to identify which client browser it is running in and performs certain actions only when it has determined that the browser supports them. Using this approach for "rollover" effects can add a certain flair to your pages without diminishing the page on browsers that don't support them.
There are many more things to consider as you develop a "broadest-reach" Web application. Each of you will have unique and interesting requirements as you head down that path. The best way to focus on the most leverageable directions is to evaluate all of the processes your solution needs to go through, and prioritize based on those parts over which you have the most control.
Robert Hess is an evangelist in Microsoft's Developer Relations Group. Fortunately for all of us, his opinions are his own.
The Windows DNA design model breaks things down into three fairly distinct tiers:
Business logic: This is where the processing logic of your solution lies. The code you write that sorts, filters, calculates, and forms the foundation of the unique capabilities that you are providing to your customers.
Data services: This is your information storage and retrieval component. Databases, file systems, information services, and anything that provides the raw data resources that your solution will utilize in preparing information for the user of your service.
Presentation: This is where you communicate with the user -- both in displaying the results of your processing, as well as getting information from the user as to how to proceed further.The Windows DNA design model
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top