About Me

My Photo
Peter Yared is the CTO/CIO of CBS Interactive, a top ten Internet destination, and was previously the founder and CEO of four enterprise infrastructure companies that were acquired by Sun, VMware, Webtrends and TigerLogic. Peter's software has powered brands from Fidelity to Home Depot to Lady Gaga. At Sun, Peter was the CTO of the Application Server Division and the CTO of the Liberty federated identity consortium. Peter is the inventor of several patents on core Internet infrastructure including federated single sign on and dynamic data requests. Peter began programming games and utilities at age 10, and started his career developing systems for government agencies. Peter regularly writes about technology trends and has written for CNET, the Wall Street Journal, BusinessWeek, AdWeek, VentureBeat and TechCrunch.

Many thanks to Bob Pulgino, Dave Prue, Steve Zocchi and Jean-Louis Gassée for mentoring me over the years.

Monday, September 01, 2003

Application Servers 2004: A Big Muffin in a Donut World

After my time at JRad, NetDynamics and Sun, I have been thinking about how application servers originated, what they were meant to do, and where they are going.

Application Servers, 1995-1997

With the advent of the “Internet” age in 1995, all of a sudden corporate resources had to be available to HTML/HTTP clients. The HTML/HTTP clients were very different from previous clients in that they represented numerous intermittent connections, while in the previous client/server world there were generally a fixed number of clients with constant connections.

For example, an internal HR system that was built to support 30 HR reps and perhaps scale to 50 HR reps over the next couple of years was going to crawl if it all of a sudden had to handle 100,000 employees doing employee self-service during 401K election time, with each connection building and then tearing down a connection to the database.

Application servers were introduced to solve this problem. App servers would maintain a few open connections to the backend and queue the HTML/HTTP client requests into those connections. The back-end resources all used a variety of wacky protocols to access them, including things like dbClient, SQL*NET, CICS, SAP BAPI, PeopleSoft MessageAgent.

When enterprises took a deterministic, architectural perspective when implementing an application server, a requirement was to handle all of the wacky client protocols that were out there, like IIOP and DCOM, in addition to the variety of back-end protocols, so that the server could grow with you. The application server was nirvana for the CIO since it looked like it would solve the big corporate systems impedance mismatch as well as the pressing need to get these backend systems onto the web.

A bunch of these types of deployments were done in Java using servers like NetDynamics (acquired by Sun) and KIVA (acquired by Netscape). At this point, WebLogic only offered multi-tier JDBC drivers, had no clustering capabilities, and rudimentary application server features with their BeanT3 product.

Application Servers, 1997-2003

After Java on the client started to stall, Sun noticed that customers were deploying Java on the server and began to create new API’s to standardize this space. Initially, these API’s were simple ones like JDBC and Servlets, but then evolved into JSP, EJB, JTA, JMS, and JCA and eventually fell under the umbrella brand J2EE. In the meantime, all clients became HTML/HTTP clients and no one was trying to build fat clients that used RMI, IIOP or DCOM.

So we entered the age of the standardized yet still very profitable application server, where everyone wanted to buy a server that would do everything when in actuality 80-90% of deployments were simply Servlet/JSP to JDBC applications.

In 1999, Sun acquired Netscape’s server line, including the original KIVA server. The KIVA server was primarily a C++ server and did not support the new Java standards well, but Sun chose it and killed the NetDynamics server it had bought a year earlier. BEA had acquired WebLogic in 1998, and in early 2000 WebLogic finally had enterprise features like clustering support and went on to dominate the J2EE market.

Application Servers, 2004: The Muffin Architecture

Yet there was a problem with the J2EE architecture: it is very hard to learn, use, and deploy. And whilst originally people though they would have “a” middle tier, they ended up with numerous middle tiers, running a variety of different versions of Java and .NET technologies, and these didn’t interoperate very well.

And so the industry started to shift towards interoperability, and as well all know from past experience, interoperability means MAKE IT DUMB. So after coalescing on self-describing text files (this is about as simple as it can get), the brave new world of web services was born.

Web services are creating an environment where all of the clients are text clients, either SOAP/HTTP or HTML/HTTP, and all of the back-ends serve text via SOAP/HTTP. This includes databases, ERP systems, CICS, MQ, basically everything.

The application server has become a big text pump, and the business logic has moved off to edge nodes. The databases, ERP systems, etc. themselves process the business logic and serve out self-describing text. The application server aggregates this text into something useful for the client.

Application Servers, 2004: The Donut Architecture

Since the technology industry, like any industry, has the tendency to maintain the status quo, it is sometimes useful to step back and ask what type of solution would be created if the problems of today were suddenly foisted upon us.

So today’s problem is:

  • Everything serves or consumes self-describing text
  • Everything can talk to everything using SOAP/HTTP
  • Business logic is left up to the server or consumer of the self-describing text
  • Most applications simply transform/aggregate self-describing text from one or more sources

    So what is the solution? We must remember that the original point of the application server was to solve the big corporate impedance mismatch and arbitrate connections to overwhelmed back-end resources. Today:

  • There is no impedance mismatch, everything talks SOAP/HTTP
  • Back-end resources can now all support numerous transient connections

    So perhaps the next generation Application Server is to have NO Application Server in the middle of everything. This is the “donut”, peer-to-peer architecture where there is nothing in the middle, versus the “muffin” architecture, where the Application Server sits in the middle of everything. Anything can talk to anything, and each node has its own mini application server built in so that it can talk to the rest of the world. The interoperability standard is web services, and each of these mini application servers can be written in anything - J2EE, .NET, LAMP, anything that can speak SOAP/HTTP.

    Of course for the donut architecture to become fully realized, web services need to become transactional and offer guaranteed delivery. And yes, you can nest these servers, ie, have a portal server that calls a bunch of back-end web services. While theoretically you could call this a middle tier, it is not “the” middle tier, just another big text pump amongst many other text pumps.

    So where is the application server of the future? It is a big text pump that is embedded in the various endpoints of an enterprise. There is nothing in the middle.

  • 2 comments:

    r3mu503 said...

    I've always been of the opinion that the "middle tier" is simply wherever you're "logically" housing your business logic (be it in a physically seperate server, an edge service, or in the db engine itself). So in what you're proposing wouldn't you say that you're middle tier is now simply spread b/w the back-end and the client side (since the logic could be spread b/w the two, or perhaps including an edge service as well). I mean, logically you still do have a middle tier, it's just physically in a different location (or locations).

    WorkingAtHome said...

    What has confused me for some time, is the seeming proliferation of MSft servers, when at the same time they are making SQL Server a complete SOAP-DB engine.