The Gilbane Report: Volume 9, Number 5

The Application Server Cometh, II

Download a PDF version of this article

Read the news for this issue.

A little over a year ago we wrote about the increasing trend of companies who were looking for a content management solution to first, choose an Application Server, and then, pick a content management system that would meet their needs and be compatible with the Application Server. What made this trend interesting at the time was that it was emerging as an intermediate step between building a completely custom solution, and buying an "off-the-shelf" content management product. What was a developing in-between approach now seems likely to become the dominant approach for enterprise content management strategies.

Since content management is increasingly recognized as an enterprise requirement, the need to integrate with other enterprise applications, whether web-based or legacy, means that Application Servers have become a critical component of content management and information technology architectures. Whatever kind of content management requirements you have, you need to carefully consider whether, and likely how, the content management technology you choose will work with one or more Application Servers. This month Bill provides an update on this trend and some advice on how to think about it in terms of your own requirements.

The Application Server Cometh, II

In May of last year we looked at the issue of application server technology, and how it was beginning to have a significant impact on how organizations evaluated new content management technology, and also how they looked at their infrastructure and legacy systems. This trend has only accelerated, and has raised some interesting new issues that get right to the heart of content management and how it will continue to alter the enterprise. Together with the issue of open source software discussed last month, the role of application server technology in content management is central to the buying and integration decisions organizations must make in the coming months and years.

The May 2000 article focused on what was then a new and striking development. Organizations looking to acquire content management technology were looking beyond the established content management vendors (e.g., Vignette, Broadvision) for the centerpiece of their web operations. In some cases, they were looking at portal technologies, but more often they were first selecting the application serving environment as a foundation for their enterprise, and then looking for component technologies that mesh well with this foundation.

In this scenario, content management is one of those component technologies. The organizations adopting an application server first were either developing their own content management based on the core services provided with the application server technologies, or they were then acquiring content management technology that could work with their application server of choice. This technological trend led to a small volley of announcements, as many of the content management vendors announced compatibility with several of the leading application server technologies, notably IBM's WebSphere and BEA's WebLogic.

Indeed this trend has legs. Every major software vendor has an application server product, led by IBM, Microsoft, Oracle, and the Sun-Netscape alliance iPlanet. IBM and BEA clearly seem to be winning both the mindshare and marketshare war, as they have most solidly positioned themselves around conformance to Java 2 Enterprise Edition. And while Microsoft's and Oracle's offerings are solid, they seem to have run into some resistance as their solutions have been pegged as "Trojan horses" to allow the companies to sell other products into the enterprise. Interestingly, the technical wars are still being played out. Forrester and DocuLabs recently tested 11 commercial products and gave the highest ratings to iPlanet, IBM, and SilverStream, in that order.

Forrester Research, among others, seconded this same trend. They coined the term "platform orchestration" to describe an application-server-centric framework, where "best-of-breed" components supplement the core technology. The key word here though is indeed component. In this approach, component technologies surround the Application Server framework. The overriding development approach is focusing on reusable, easy to integrate components, emphasized in Java's trademarked slogan, "Write Once, Run Anywhere."

J2EE Solidifies its Position

In the May 2000 article, we stopped short of claiming Java 2 Enterprise Edition was the preferred approach for component development, and gave more or less equal weight to other component-based approaches such as CORBA and COM. However, it is clear from the success of tools such as WebSphere and WebLogic that J2EE is carrying the day, and for good reason. J2EE-based application servers offer developers these key benefits:

Support for n-tier applications. In many ways, web applications are solving old problems but in a new way. The web has ushered out the dominance of client-server applications and ushered in the dominance of multitier applications. This new kind of application is fundamentally hard to architect, as they often involve legacy systems, varying data sources, and communication needs. Environments such as J2EE mitigate these challenges by encouraging a modular approach, and then providing comprehensive services for deploying these modules. Ready services are available for such things as database connectivity (JDBC in the case of Java), security handling, and transaction monitoring - all with a minimum of complex, in the trenches programming.

Portability. Even with the relative contraction in the operating system and database markets, web developers live in a heterogeneous world. One of our clients that provides custom software to the library market has a list of more than 60 platform combinations they must deal with in each upgrade. Modular development approaches such as J2EE emphasize quick development and deployment across many platforms, and standard methods for testing and qualification.

Scalability. Working in "web time" means getting applications to market quickly, and scaling from prototypes and beta launches to 24x7 applications accessible to a growing marketplace. Component development means that the next generation application can quickly add new features and functions. The kind of component integration that comes with a J2EE Application Server means that an end user organization can quickly launch a phase 1 version of the site, and then build on virtually all of the original work to launch subsequent phases.

What This Means for Enterprise Content Management

The continued adoption and increasing importance of application server technologies has at least two kinds of impacts on content management. The first is broader, and goes to some general issues of information technology. The second is more specific to how both vendors and customers will architect their systems, and what these systems will look like in the long term.

At a broad level, the move toward component development and J2EE both mirrors and complements several other trends in enterprise content management:

• Despite the battles between Microsoft, Sun, and Oracle, J2EE is a standards-based approach, which gives both vendors and customers objective measures of conformance, and the ability to, ideally, swap in and out technologies based on added values such as price, performance, and additional features.
• Java and XML are highly compatible. Java provides many ready means to create and work with XML data, giving programmers many shortcuts for data structuring and integration.
• Shrink-wrapped applications have long since given way to tool kits, but there is a new focus on time to market and cost of integration. As with open source software, J2EE-based approaches need to be examined in terms of what core services are provided with the acquired software. Vendors are building much more into core services, which ultimately will benefit the customer.
• Organizations are increasingly focused on the "ilities" - maintainability, compatibility, and scalability - and they are looking to J2EE to provide these.

More specifically, though, the continued adoption of J2EE-based application server technologies reflects the ongoing movement in content management away from point solutions and toward systems that work in the larger enterprise. The content management solutions implemented today and in the future must work well with other systems, and at minimum must be tightly integrated with Web operations, back office systems, eCommerce platforms, personalization engines, and workflow systems, including business process automation. The orchestration and integration of these many systems becomes key, and J2EE application servers are central to solving this problem.

Beyond Dynamic Page Serving

As Web content management plays more roles in the enterprise, it must move beyond its legacy - not only the legacy of static pages but also the growing legacy of dynamically served pages. Indeed, early approaches to dynamic page serving were a difference in degree more than kind compared to static pages. Individual processes were automated - for example, a company might have hired an Active Server Page programmer to "webify" a catalog they had maintained in an SQLServer database.

Yet it was often the case that such automation was done a case-by-case basis, allowing multiple approaches to flourish even in the same organization. This would leave many organizations with a "silo problem," where each application was supported by its own database, its own programs, its own hardware, and often even its own technical staff.

Enterprise content management based on component technology and J2EE solves the silo problem by allowing developers to create discrete, reusable code. Such an approach is even more powerful when coupled with XML data. While organizations will always have heterogeneous data sources, there is clearly a movement toward having XML available at least as an abstraction layer on top of the various content sources. In this model, XML serves as the abstract data layer, and the application server and component technologies interact primarily with the XML and secondarily with the proprietary data stores. The processing and display layer then have a uniform problem to solve.

Figure 1.
XML as the interface between application servers and data/content repositories.

Some Caveats and Conclusions

A year has passed since our original article, and some of our original caveats and observations about application-server centric content management still stand and are worth repeating. As we know, even the most expensive content management technologies are not finished applications. And, more significantly, even where they do offer some off-the-shelf capabilities, they typically don't do many things precisely the way a customer needs them done. Hence, you are left with the need to be able to at least customize the applications themselves. Add to this the need to become proficient in the application server technology, and to learn how to integrate component applications.

The past several years have taught us that customization is inevitable. The key is the software buyer's need for competitive advantage. The software marketplace is too impatient to wait for the next killer app, and to gain advantage, technology buyers will adopt toolkits that support rapid prototyping and deployment. So, the thinking goes, choose the very best environment for rapid, scalable, multitier application development.

There are still risks though. Conventional wisdom holds that the Application Server you pick today may not exist tomorrow. This is of course mitigated if the Application Server you choose is indeed faithful to something like J2EE or another component model. As long as you are building your applications under the J2EE framework, for example, you can swap out, even mix and match, Application Servers.

Another piece of conventional wisdom one year ago was that J2EE, among other models, was still too new an approach. We predicted that this was a problem time would solve, as more developers developed a core competency in Java and more methods become documented and available. This has certainly proven to be true. The universe of qualified java programmers is growing, and the major application servers have many qualified adoptees and rich resources for developers.

Must You Base Your Solution on an Application Server?

This shift to an application-server-based architecture for content management may seem too complex to some, especially for the smaller or specialized organization that has a need for content management soon, and may be looking at lower-cost point solutions such as those from NCompass, Red Dot, and Ektron. If indeed your content management problem is relatively discrete, you can confidently pick from the vendors who offer the right scale solution for your needs. This is especially true if you don't see yourself tying many other applications to your content management system. The key for such a buyer would be to at least understand the technical or product roadmap this vendor has for eventually working with application server technology. We're confident that any vendor of enterprise content management software will at least ensure that their products will work with a J2EE application server at some point in the future.

Recommendations

Some of the conclusions we came to in our first article are still apropos, and we've added several more as the market has matured:

• If you have an increasing need for e-commerce, integration with back office systems, and other infrastructure changes, look at an Application-Server-centric approach.
• Look to build a Java competency, either in house or through your trusted partners.
• Understand in detail what your legacy systems are doing to make themselves more open to Application Servers. Look beyond the press releases to the specific needs you will have. Some early announcements from content management vendors that they are compatible with Application Server technologies have been little more than marketing agreements or loose bundling, and would leave most organizations short of what they would really need the technology to do.
• Look beyond choosing a single application server vendor. Yes, standardize on one where you can, but your best strategy is application server portability. The content management system you buy should work on a variety of application servers, and your application server in turn should both deliver on the J2EE standard and add value in the form of performance, price, and the "ilities."
• Implement an application server and content management successfully, and you have done a great deal to solve your portal problem. Look to your content management solution to solve content management, and look to your application server to provide core services such as personalization, presentation, data access, security, and monitoring.
• At the same time, remember that content management functionality does not belong in the application server level.
• Look for Webdav support to grow and become a key feature of collaboration and workflow tools going forward.

Indeed, solving content management and implementing a J2EE-based application server will position your organization for success in the near-term and well into the future.

Bill Trippe