Anyone who has been around the computer world for a while knows that application servers are not a new idea.
Today’s definitions (and there are pages of them accessible through Google) boil down to “”an application server is a computer that serves applications to users””. Redundant, yes; sometimes
the definition extends to specifying that it acts as the front end to a database server, or that it is the inter-mediary between the front-end graphical user interface (GUI) and back-end products.
Looking back, using the simple definition the first multi-user systems were application servers. They were known as mainframes. They held the data, ran the software, and provided output in the form of printouts or punched cards. They accepted input from extremely thin clients – first punched cards, then dumb terminals.
Granted, they weren’t interactive, so calling them servers in our modern sense is a stretch, but they do fulfill the basic function of an application server to this day.
When we segue to the application server of the current century we see that it, too, performs those three functions. The differences are in the input and output; now, most often, input comes from keyboards or disk files, and output goes to a file or to a screen via a Web browser. It’s a far cry from the green screens and punched cards of yore.
Once the kid in the middle in the multi-tier client/server architecture, the application server has grown to be much more than simply the engine that ran the business logic and handed the answers to its sexier front-end components. And every vendor who plays in this market has been working to put its own twist on the concept to lure customers into its fold.
However, all of these products have price tags attached that may give some would-be users pause. Thanks to the Open Source movement, even companies of more modest means can still acquire quite usable application servers.
All of these products are busily extending the definition of the application server for one reason. A basic application server is, well, a basic application server: Not sexy at all, and certainly not unique. Vendors need to differentiate themselves and their products to make them enticing to customers.
The danger, however, is that a hodge-podge of features can take away from the primary functionality of the product. Like the multi-tools clipped to many belts that have a lot of mediocre functions instead of a couple of really good ones, software plagued with feature-itis may not do all things equally well. In fact, it may do some very badly, necessitating expensive additional components. That has always been a major argument against software suites of any kind, and it fits well here. Customers also have the valid complaint that they may be paying for functions they do not, and will never use.
Vendors, on the other hand, argue that a suite provides tight integration that cannot be achieved by individual products, at a discounted price.
Probably both sides are right. If a good application server is coupled with suitable companion software, it can build a robust solution with the added benefit that users need only make one call for support. But it is incumbent on the customer to do its homework and ensure that the functions it needs work as claimed, and satisfy its requirements.
On the other hand, an application server crammed with poorly-conceived or badly implemented features will be an albatross around both its users’ and its vendor’s necks.
Selecting a platform
These days, when you buy yourself an application server, you’re often buying into a development environment as well.
That’s not to say that you can’t use a different product if you want to. The big question is, is it worth the trouble when you can get a nicely integrated system with all of the tools you need to deploy to the vendor’s application server in a tidy package?
Conspiracy theorists would say it’s an evil plot to lock you into the vendor’s platform. Less suspicious types would counter it’s simply a way to help you get up and running more quickly. They would also add this explains the integrated Web servers and other conveniences we are increasingly seeing in these products.
It’s likely a bit of both.
Consider, for example, IBM WebSphere. Attached to the brand are not only naked application servers, but business integration products (using application servers, among other technologies), e-commerce products, and a myriad of other items to help run all facets of a business. WebSphere Studio is the development component, and while nowhere in its promotional material does it say it’s required for WebSphere development, its branding and toolset make it a great candidate for the task.
Oracle takes things a step farther, including five Oracle JDeveloper 10g licenses for each processor licensed for its application server. JDeveloper happens to be its integrated Java, XML and Web services environment for developing, debugging and deploying Web services. That, plus the fact that Oracle’s development training uses JDeveloper, is a powerful incentive for application server customers to stay in the fold.
Sun says upfront that its application server is a development platform as well. It describes it thus: “”The Sun Java System Application Server provides a Java 2 Platform, Enterprise Edition compatible platform for developing and delivering Web services. It integrates a powerful application development environment with the Sun Java Studio Enterprise.””
You will notice that, unless you’re looking at Microsoft, which touts Visual Studio .NET as the development platform of choice for its application server, one common factor that emerges is the almost universal acceptance of Java as the development language for application servers.
In fact, ‘platform’ is the term du jour for application servers these days. They’ve grown beyond their original function and now are loaded with features, and perform tasks that would probably startle the folks who conceived the concept.
Forrester Research has seen the writing on the wall, and is now specifically measuring application server platforms. In its description of its application server platforms, Forrester says, “”Application servers have evolved into broad-based platforms that encompass not only application development, but also portals and application integration. These application server platforms will be the foundation of the new generation of enterprise applications based on service-oriented architectures, Web services, and business process automation.””
In other words, application software will evolve to take advantage of the new twists on an old idea. And to ease the transition, development environments will have to follow. It means re-education of developers, and revamping of methodologies because as things stand today, some components, such as Web services, are not fulfilling their original vision.
If developers have to get new tools anyhow, and those tools just happen to be built in to the application server platform and neatly integrated with it, well, that makes life much easier all round.
Are the conspiracy theorists right? Well, sort of. Faced with the options of spending a lot of money on separate development tools, or using the set already attached to their application server, companies will often take the financially more attractive route and use the server vendor’s product.
It’s convenient, the tools usually integrate nicely with the server, and, yes, as a side effect it can wed the customer to the vendor and its platform.
