| The concept of the multitier application services was born with the advent of remote OLE automation. Using this technology, it became possible to use remote procedure calls to access instances of components executing on another computer. The technique appeared seamless on the client application. It was as if the remote component were running locally. This ability allowed traditional two-tier client/server applications to include a middle tier that could contain business rules, act as a proxy to the database server, and provide other services. The three tiers were traditionally labeled the database, business rules, and presentation layers . While this solved some problems, it created new ones. How do we manage all these components? How about version synchronization? The best envisioned implementation of this architecture used an extremely thin client, which had no logic of its own beyond that needed to manage the display. The fattest part of the application is located in the myriad middle-tier components. Unfortunately, this did not work very well with native Visual Basic because VB forms were private objects and couldn't be called remotely. This made creating a thin client difficult in Visual Basic. Anytime the business rules layer changed, it inevitably would force a revision of the UI as well, forcing another rollout to thousands of clients . It was possible to create a true thin client in VB, but because of VB's forms architecture these were invariably slow and complicated. This nullified many of the benefits of three-tier architecture. Enter the Web. Now we have a ready-made universal thin client in the web browser. However, the web browser as a thin client has its drawbacks as well. Web browsers are designed to present formatted pages of text and images to the user . They were not intended to be used as a forms engine. You are limited to the basic HTML form elements for your UI. The stateless nature of the Web forces us into a clunky programming model, where the presentation layer is disconnected from the middle tier components (ASP or ASPX Web Forms and the VB code behind them). This forces both a lowest -common-denominator approach to the UI and limits the degree of interaction possible between the server and the client. This has not changed, although it has improved some with ASP .NET. Visual Studio .NET finally offers the ability to build a robust, native Windows-based thin client that is not limited to what is supported by the web browser. XML Web Services allows us to build server-side components that are managed by the IIS and accessible to a variety of client platforms, not limited to Microsoft products. In addition, the Web Services themselves can be hosted on a variety of platforms, not just Microsoft servers. The best part is that in order to host Web Services, your server only needs the standard HTTP Port 80 open to provide these services. |
