During the past five years, application servers have emerged as a vital piece of the Web infrastructure. By providing a set of services common to all Web applications (e.g., state management, database connectivity) as well as a productive set of APIs or scripting languages, application servers have made building applications for the Web dramatically easier, not to mention more scalable and reliable.
As a result, businesses have been free to experiment with new ways of serving their customers and increasing their efficiency, resulting in turmoil and change unlike any seen since the industrial revolution.
Now, two new sets of technologies promise to have an equally powerful impact on the business and technology worlds. First, wireless standards such as WAP and i-mode are making it economical and practical to build real applications using mobile client devices such as phones and PDAs. This opens up new possibilities for applications that ensure employees, customers, or partners have access to information as well as the ability to act on it - whether they're at their desks or in their cars.
The second wave is popularly referred to as Web services, the ability to expose pieces of an application so that they can be invoked from almost anywhere on the Internet. Developers have been building network-based, distributed applications using technologies such as CORBA, DCOM, and Java RMI for years, but these have been restricted almost entirely to intracompany applications. The emergence of Internet-centric protocols such as the W3C's XML Protocol (also known as SOAP) will enable a new wave of intra- and intercompany integration as well as new business models for companies providing services that can be consumed (and hopefully paid for) by others.
As an example of how these new technologies might be used, let's look at an online travel service. Today, sites like Expedia or Travelocity allow customers to purchase tickets and look up arrival and departure times, all from within a Web browser. But much of the information they provide would be more useful if it were available away from the desk, such as from a phone. For instance, while visiting a client, many business travelers would like to be able to check the departure time of their flight or receive a page if the flight has been changed.
Similarly, an online travel site could gain additional revenue if it were able to resell its ability to book flights to others, such as a hotel site. Today, the cost and complexity of this type of integration has restricted it to a few large partnerships, but with the emergence of easily consumable Web services, it should be almost as common as syndicated content is today. This will open up new revenue streams and further change the balance of power between different types of businesses.
New Demands for Developers
From a business perspective, these changes are exciting but they also introduce a new level of complexity into the developer's life. Supporting two implementations of DHTML is difficult enough. Now, with Web services and wireless devices coming online, the development team also has to make sure the application they're building today can support the dozens of wireless devices as well as expose parts of its functionality as a Web service. For the online travel service, this means the code that checks a flight's estimated arrival time must be able to format its data so that it can be viewed in a PC browser, displayed on a mobile device, or passed to another application.
Fortunately, many of the same design principles that have served Web developers well in the past few years are also applicable to this new world - most important, a clean division between presentation logic and business logic. To a well-architected application, the addition of wireless clients or the creation of a Web service interface should involve little more than the addition of some new presentation logic specific to that client. Moreover, the investments developers have made in application servers will also carry forward, as the infrastructure services provided in the Java 2 Enterprise Edition (J2EE) specification and Microsoft's .NET architecture are vital to the successful construction of wireless applications and Web services.
That's the good news. The bad news is that application servers could still do a lot more to ease the transition to this new multiclient environment. For instance, even with a well-architected application, each new client requires additional code to handle the idiosyncrasies of managing state for a wireless browser (most of which don't support cookies) or of handling requests for Web services.
If this is really where we're headed (and I'm convinced it is), then application servers will have to add new capabilities to smooth the evolution from Web applications to wireless applications and Web services. After all, managing the kind of contextual information created by a new client technology was one of the main reasons application servers were developed in the first place.
In looking at these changes, I'll discuss wireless applications first, then move on to Web services. While both represent new types of clients, there are important differences. Finally, the last section will discuss how new capabilities of application servers should be exposed to developers in order to gain the greatest impact.
Supporting Wireless Applications
As wireless applications move into the mainstream, the first type of change we'll see in application servers is the addition of client brokering services. As the diversity of devices accessing the Web grows, application servers will need to be able to detect the type of client that's making a request and direct the request to the appropriate set of presentation services (i.e., pages that provide the formatting of data and handle things such as state management).
Thus, a browser request sent to www.mysite.com would receive the HTML home page, but a WAP phone would receive the WML home page and a Palm cHTML. This type of handler architecture is one that many Web developers have been forced to implement in order to support different browsers. Given the physical differences between a computer monitor and a PDA screen, the different home pages are unlikely to be mirrors of each other. However, forcing users to remember different URLs for each device is an unnecessary burden, especially for consumer sites.
The second type of change we'll see is more specific to the type of client being supported. In the case of wireless devices, the challenge will be to provide UI frameworks that help developers support the many different wireless devices on the market. Today, there's no standard form factor for the phone's display, not to mention multiple markup languages for displaying information. As a result, writing a wireless application often involves implementing a different set of presentation templates for each type of phone. In a world where new phones are introduced daily, this is quickly becoming unmanageable.
In response, a number of vendors have built frameworks that provide an abstraction layer above these differences. With most of these frameworks, a developer defines forms, menus, tables, and other UI components using XML or a visual layout tool. Then, at runtime, the framework uses a stylesheet, typically provided by the vendor, to map the model to the device making the request (see Figure 1).
The most advanced versions of these frameworks are available from start-ups such as AlterEgo Networks, iConverse, NetMorph, and many others. However, as wireless access becomes a common feature for many applications, these types of frameworks will likely be added to the application server as well. This way, their capabilities can be built directly into the development tools, and their services can be integrated with the others provided in the application server, such as security.
There are many other types of services that may become part of the application server as well, such as location services or support for synchronization protocols. However, the two discussed above are likely to be the most prevalent, not to mention the most fundamental.
Supporting Web Services
While the changes needed to support Web services are different from those required by wireless applications, they fall into the same two general categories: brokering services and frameworks.
Unlike with wireless devices, the benefit from a brokering service for Web services is not one of convenience. The likelihood of someone casually browsing a Web service is low. Instead, the main benefit lies in providing a clean separation between interface and implementation. Thus, a site that provides a Web service for storing data could change the back-end implementation, adding more servers or perhaps even outsourcing to another vendor, without affecting existing users (who will continue to see the same interface). Other benefits of the separation between interface and implementation include a built-in mechanism for security and load balancing, among others. These are just a few of the reasons CORBA, DCOM, and RMI all use brokering services.
In contrast to UI frameworks, which are relatively immature and completely nonstandard, the frameworks for Web services are rapidly converging on a common set of technologies built around SOAP. However, like most standards, these technologies provide only the baseline technology required for interoperability. It will be up to application server and development tool vendors to provide mappings between the popular development languages and SOAP as well as tools that can automatically generate a Web service interface from a component method or an application function.
An early example of a such a framework is Allaire's Spectra, which can expose any part of a Web site's functionality as a Web service using HTTP and WDDX (an XML protocol for exchanging data between programming languages). Another example is IBM's Web Services Toolkit, which can generate SOAP interfaces from EJB interfaces, or Microsoft's Visual Basic.NET, which enables developers to build SOAP interfaces as easily as they can build Windows forms today.
These changes are only the tip of the iceberg. The long-term effects of the move to a Web-services architecture are likely to unfold for many years to come. Let's look at one further aspect of the application server - the development model itself.
The Application Server Development Model
Today, it's rapidly becoming apparent that two primary application architectures will compete for the hearts and minds of the development community: Microsoft's .NET and the J2EE specification.
While there are important differences between these models, both conform to the same design principle - the page and component model. In the Java world, this means JSPs and EJBs, while in the Microsoft world, this means ASPs and COM/COM+ components. Both .NET and J2EE provide powerful architectures because they offer a built-in separation of business and presentation logic, which, as we've seen, is important in enabling wireless computing as well as Web services.
The only problem is there are still very few people using both components and pages. If you look at any developer survey, the percentage using ASP or JSP versus COM or EJB is overwhelmingly in favor of ASP/JSP. This doesn't even take into account the thousands of developers using other technologies such as Perl, CFML, PHP, or other server-side scripting languages.
One could argue this is only because EJB and COM are relatively new, and that they'll enjoy much broader adoption as they reach maturity. However, I believe these technologies, while very powerful and absolutely necessary, will never enjoy the same broad adoption that page-based development models enjoy.
The reason is that in most cases EJB and COM+ force developers to shoulder a lot more responsibility than they really want. If you need to write transactional components and want to take advantage of the advanced persistence services of an EJB container, that's the way to go. But for most developers, writing in the page-based model will not only be sufficient, but also a more productive way to work.
Moreover, to assume that writing applications with a clean separation between presentation and business logic requires the use of EJB is to mistake implementation for design. J2EE and .NET are a set of APIs. The separation of presentation from business logic is a way to design an application. A well-designed application can be implemented in many different ways.
In fact, many developers using page-based scripting languages follow this design principle closely, building two layers of pages that communicate with each other or encapsulating business logic in custom tags in order to keep it separate from the presentation layer. Thus, any framework that creates Web services should be able to wrap a JSP or ColdFusion page with a service interface as easily as it can generate a stub for a method on a COM object or an EJB. Given their huge base of page-based developers, it's no surprise that both Microsoft and Allaire are pursuing this strategy.
The point of this discussion is not to downplay the importance of EJB or COM+, but to point to the third major change that must come to the application server world. In the past five years, application servers have come a great distance, providing greater scalability, integration, and reliability. Now, with the infrastructure pieces falling into place, the biggest challenge will be making the full power of that infrastructure accessible to the broadest range of developers.
In other words, if we're to convert the many visions of a networked future into reality, application servers will not only have to make the Internet development infrastructure (which includes Web pages, mobile devices, Web services, and whatever is next) richer, but faster and easier as well. The vendors that figure that out will make a lot of developers very happy.
Phil Costa is the senior manager of strategic marketing at Allaire Corporation. His responsibilities include marketing for the Allaire Business Platform as well as research into the future directions of the Internet software market.