Application servers separate systems functions from business functions, so that programmers can concentrate on the latter. The systems functions are getting more complex as systems become more component-based and distributed, while at the same time, requirements for reliability (load balancing, failover, directory services, security services and recovery) are increasing.
Developers just want to code the business problem and aren't interested in becoming systems engineers; that's a completely different skill set, so separating the functions allows skills optimization. If developers target application servers instead of operating systems or databases as the platform, interface and repository of choice for application logic, that can't be a good thing for operating system and database vendors.
If the database is relegated to serving up queries from an application server and the application server has all the logic and user connections, that seems like a shift in the balance of power.
No longer a two-horse race
For the last three years the application server market has been a two-horse race between BEA Systems--the leader on feature/function--and IBM--the low-cost product backed by a world-class service organization with a loyal customer base. There are some 14 application server companies in the market, but we believe the remaining companies face viability issues, severe product shortcomings, or serious questions about commitment to the market, or in some cases all three.
Recognizing the potential for disintermediation, Oracle has gotten pretty serious about application servers. I've been pretty skeptical about Oracle's efforts in the application server market over the years. However, things could be shifting a bit, and after three tries, Oracle may now have a serious horse in this race. The latest product looks completely different, and that's because the code was acquired outside of Oracle and it reportedly is a solid product. Techies seem excited about the product based on the e-mails we're getting.
But the key point is that I expect the market to expand to three viable players from two. Keep in mind that Oracle has 11,000 application customers who will get the Oracle application server as part of an upgrade later this year. The applications could serve as a Trojan Horse to get seeded and then attract custom application development as well.
Competition is about to intensify on the base application server, and I look for vendors to into adjacent areas quickly in an effort to redefine the checklist. So expect a giant sucking sound as the application server vendors pull in surrounding servers like portals, personalization, content management, integration, workflow, caching, provisioning and Web services. Whether they can execute well in these areas and deliver functionality on par with the best of breed products is an open question.
I suspect it will take some time, but the concept of consolidating these functions in a consistent application foundation makes sense. The integration area seems to be the most natural area for expansion since using the same platform for building and integrating applications could make life easier for developers.
The Java Connection Architecture is an attempt to standardize the link between legacy applications and application servers. The application server could become the natural convergence point for all applications in the enterprise but that's a big "if" because the application server vendors generally don't have a long track record in integration. IBM has been in the integration business for years but that's a separate product line and code base.
Another significant opportunity for Java servers is provisioning. Application provisioning and administration functions could be executed centrally and uniformly instead of each application replicating these functions.
For instance, user security, entitlement, personalization, workflow and globalization could be specified once in the application server, and all other applications leverage that administrative data.
What are the risks to this scenario? There are a lot and they are significant. It's key to remember that it's a big world out there. Most applications aren't written in Java, and so going to the trouble to architect around a Java server may not make sense for a portfolio of applications not written in Java. Development organizations seem to be slowly moving toward Java but it's a glacial pace. Getting developers retrained takes time and there are other priorities.
Second, most companies I've spoken with are just using application servers to serve up JSP (Java server pages), which is a good way to publish Web pages to a Web listener. Others are using the application server as a portal to link multiple Web-enabled applications.
No easy trick
However, that's not component-based development, nor does it take advantage of the rich features application servers offer.
The complexity could relegate application servers to high-end e-commerce applications that need the reliability and reuse. The Java server market could still use a good Visual Studio-like product but I think it's safe to say it won't be Microsoft.
Additionally, the large-packaged application vendors have turned a cold shoulder to Java application servers. The application companies have built their own application servers and don't want to become dependent on yet another infrastructure provider. Most have provided interfaces into their products but haven't opted to support a third-part application server directly to run their core application logic. Many of the smaller application companies have decided they can't invest enough to be both an infrastructure provider and an application company and have opted for BEA's WebLogic or IBM's WebSphere.
The application server companies have a significant opportunity, but they have to find a way to come down market and blend in adjacent areas to become more mainstream and get past the JSP pumping stage. If your company has built a successful complex application with a Java application server, I'd like to hear about it.