Web System Services: Building Blocks for Web Systems
Remember when writing a Web application used to mean picking the hottest Web development package you could find, peeling off the plastic, inhaling the smell of the pristine manuals and then coding some non-mission-critical -- or mission-oblivious -- system with it? Times have changed, and Web system development has turned into a serious business.
Special Report: Middleware
It had to happen sometime. Remember when writing a Web application used to mean picking the hottest Web development package you could find, peeling off the plastic, inhaling the smell of the pristine manuals and then coding some non-mission-critical -- or mission-oblivious -- system with it? Times have changed, and Web system development has turned into a serious business. Increasingly, scaling up quickly and seamlessly is important: 24X7 reliability and availability is de rigeur. When real systems and deadlines are at stake, there isn’t time for each project team to evaluate all its technology and software options before starting the task at hand, nor is it acceptable to risk picking a product that turns out to be a dud. Those once-fresh development packages are now lining shelves, incompatible with each other and out of date.
While those times were fun, there was no process for selecting technologies and software. We lacked a big picture view of the middleware and infrastructure services needed to build a Web application and determine how those packages fit together. We needed is a services-based approach instead of product- or technology-based approach. A product-based approach entails picking individual software packages based on the immediate needs of a single project team. As the project takes form and needs for additional services arise, those needs are filled by homegrown software or by stopping to evaluate more products until the project is complete. A technology-based approach focuses on selecting technologies up front -- such as Java or Microsoft DNA --and then figuring out how to use them as the project progresses.
By contrast, a services-based approach works by determining the types of services that a system -- or preferably an entire category of systems such as Web database publishing -- is going to need, and then evaluating how various technologies and products will fill those needs. Once a set of products is selected to fill the needs, a pattern can be created and applied to other systems of the same type. This type of top-down methodology helps ensure that the products and technologies selected fit the needs of the architecture, future-proofs the systems that use the services and mitigates risk. When this process is managed by a corporate architecture team or standards group, it has the added benefits of applying some consistency to the Web infrastructure that must be maintained by IT staff, guaranteeing a proper fit with architectural decisions made outside the Web domain, and eliminating the burden of product evaluation from each system developer.
Web System Services Model
So what types of services does a Web system architecture need to provide? Figure 1 shows the basic set of building blocks that need to be available to Web system developers. An architectural or Web standards group should prepare a recommendation for each of these services that states which technologies -- such as Java, LDAP, XML or DCOM -- will be used to meet each service need and which products are approved to deliver each service. It is important to use the right tool for the job. Different sets of services, or Web application patterns, should be prepared to suggest the infrastructure that will be used for various design patterns -- such as Web database publishing, n-tier transactional application, informational, collaborative or host proxy --that are prevalent in your organization. Also keep in mind that the connections between the services, IIOP from the client to the assembly engine for instance, must also be considered.
Assembly Engine: The assembly engine gets queries from the client for information, divvies up the requests, accumulates the responses and sends them back to the client over an HTML, or possibly a data stream such as IIOP. The assembly engine can consist of a number of technologies, including scripting, servlets, Active Server Pages or CGI. Often application servers fill this duty as well.
I*Net Server: I*Net Server administers a number of Web protocols, including HTML, and may be used to launch the servlets that form the assembly engine. A Web server is still used in most Web systems due to the difficulty of assuring that the client has access to anything beyond HTML.
Client: Documenting decisions or assumptions about the client interface could save system developers a lot of time. For example, will the client utilize a "logical browser," where page rendering logic is seamlessly integrated into the user interface? Will Java be allowed, or is it all just HTML? Which version of Java? Is JavaScript allowed and, if so, whose version of the Document Object Model will be used? Will there be clients connected remotely or even working disconnected? Answering these questions up front can save a headache later when a development team finishes the Web system only to realize that just half of the user population can run it.
Data Repository Access: The database itself is outside the domain of the Web architecture, but it is important to decide how to access the database --whether to allow native APIs or use stored procedures -- what protocols will be used and how you will access special databases such as directory services or your main customer database.
Business Logic Management: Once the business logic of a system grows complex enough that it is not optimal to have it reside on a single box, it becomes important to manage the business objects. This service allows business logic to be distributed and replicated across servers. It also allows monitoring and tracking of the business logic.
Content Management: Content management and distribution needs differ for each organization, requiring anything from simple access to HTML templates and the company’s logo to full content management systems. It is important to define update procedures for end user content contributors and more sophisticated authors. For some complex systems, publishing engines must interact tightly with the business logic.
Intermediary Services: To manage the scope of a Web architecture, it is important to draw a boundary. The Intermediary services allow connection to systems and data outside the boundary of the Web architecture. They include services for conversion of data streams, access to transactions, access to the interfaces of non-Web systems and access to data through taxonomy services. Examples of intermediary services are XML, portal services, common CORBA interfaces and taxonomy engines.
Underneath all these services, there is another set called the Web application foundation and administration services, which apply to more than one of the above services. For example, foundation services include load balancing. Load balancing can be applied to the Web server, load balancing for business logic, and load balancing for data repository.
Web application foundation services support more than one of the services listed above and include security, state/session management, and caching.
Web application administration services provide a monitoring and management framework that ties in to all of the other services. They provide capabilities for restarting processes, failover, and monitoring the health and performance of an application -- possibly with SNMP or site resource managers.
How Application Servers Fit In
The application server space was hot in 1998. There has been significant growth and consolidation in this market, and it is still changing. To understand the changes, one needs to note that Web application development is still in its early stages. A few years ago many organizations did not have any Web system services on which to build, and that made it convenient to acquire all the Web system services in one package. Some application servers may omit one service to focus on another, but application servers generally supply a full set of Web system services. This monolithic approach was useful in the early stages, when a project deadline forced the building of a foundation quickly. But in the long term, getting all of the services from the same source is less important. What is important is to find products that fill specific gaps and fit with existing client/server or enterprisewide technology architectures. These products are becoming less proprietary and changing to work better with other parts of the architecture.
Another change in this area is that a number of application servers that were targeted at specific patterns -- such as the Web database publishing pattern -- have been decreasing. Vendors that addressed the Rapid Application Development (RAD) pattern are moving to address the n-tier Web application pattern instead. Vendors love putting "enterprise" on products since it sounds as if there will be more money out of the sale and it will not get replaced with a larger product. These companies do not want to compete with Microsoft Corp. for low-end development sales, so they are moving out of the Web database publishing space. That is unfortunate. Most organizations have numerous quick-hit, high return on investment projects that are the Web equivalent of what FoxPro or PowerBuilder were used for. N-tier Web application servers also have a high price point, a steep learning curve and a lot of complexity. This means high-end application servers can be prohibitive for small projects unless there is a development team that implements a steady stream of them. Allaire ColdFusion, Microsoft ASP, Drumbeat, and, to a certain extent, Domino continues to play in this space, but this market segment will continue to be underserved.
A third change to the Web systems services sector is that many of the services have been subsumed by operating systems. Microsoft has been driving this trend. Redmond was late to address Web system services. Instead of competing at a product level, it built these technologies into Windows. Microsoft does not offer an application server as a shrink-wrapped package, but it does offer a set of Web system services. Combining COM, DCOM, MTS, ASP, Visual Studio, and J++ yields a complete set of Web system services. It was an accidental strategy, but one that does have some advantages. First, there is a low barrier of entry. These services are probably on developer desktops and ready to use. Second, independent software vendors (ISVs) can develop products without worrying about having to deploy an application server along with their application and the licensing and maintenance hassles that accompany that decision.
The disadvantage of the Microsoft approach is that it is platform-specific. Many developers want to develop on NT and deploy/scale to Unix. That is not possible if they use Windows-specific services. There have been some smaller vendors that are porting Microsoft technologies to Unix, but it is too early to tell if they will remain viable players, and Microsoft’s response towards them has been lukewarm at best. Another issue with the Microsoft technologies is that scalability has proven difficult to implement, especially when state and session management is required.
The application server space will continue to be volatile. The key to creating an infrastructure for Web development is to avoid piecemeal product evaluations and myopic architectural decisions. Use a top-down, service-based approach to determine what services your architecture needs how they fit into your enterprise architecture, and find products and technologies that fit those needs. With Web application servers becoming the critical link in your enterprise’s e-commerce efforts, ensuring scalability, flexibility, availability and rapid deployment are becoming your responsibility. It will separate the e-commerce winners from the also-rans.