The Role of the Application Servers in SOA

I've been using the term "service containers" to refer to the sandbox that services live in. However, in J2EE land, there isn't a 1:1 relationship between the 'software server' and the 'container'. You've got the 'servlet container', 'ejb container', etc. The Application Server is really an all-in-one - super-duper server. It slices, it dices, it does transactions, messages, web pages - you name it - it does it.

App servers can host web services. They can also host platform specific services (RMI, EJB). The services provided can be governed via the container and can leverage additional functionality via components and class libraries (most of the J2EE API's).

Just to restate - build services on top of components that are a combination of classes which sit inside of a governed container while making calls to libraries, some of which are runtime generators, perhaps being fed metadata from model-driven tooling. Agreed?

Ok. Now we need to move into "specialized servers", like identity servers, orchestration servers, etc. Many of these servers were built from the ground up as stand-alone servers, while other implementations were built to sit on top of application servers (e.g., a bpel implementation that runs in JBoss). In the J2EE world, specialized servers are really just new API's governed by the JSR process to encourage yet another container or library to be added to the J2EE server. In some ways, J2EE has become a dumping ground for 'bright ideas'. Hence the movement to 'lightweight containers'.

Now, let's ponder...
Question #1: Would you describe the application server as a "Rapid Service Development" (RSD) environment?

Question #2: To what extent should specialized services reside in generic containers?

Question #3: Should the server be 'pre-glued' together (mandate the download all 55MB of libraries) or should it be more loosely coupled and segmented?

Question #4: What are the necessary cross-cutting concerns that should be considered part of the server or container?

Question #5: What functionality is not a cross-cutting concern, but rather a specialized function?

Question #6: Would you consider the app server to be a "Contract First Container"?

The application server has evolved to meet the needs of the masses. It was designed to be an all-purpose server. Can a developer build SOA based applications in it? Sure. It is more work than it needs to be? Absolutely. And the big question... Do I believe that Rapid Service Development to Contract-First Containers is the way of the future? Yes I do.

Application servers will continue to be used when the architect chooses to use a platform specific component-based development model. Here, the focus is on 'building the application' (hence, "application server") versus building the services.

There are some real challenges that app servers will face in the SOA environment. We can be sure that BEA and IBM will be morphing their offerings to make them more acceptable to the SOA crowd. However, I fear that they will leave all of the garbage behind as well.

It's real simple - if your platform fails the loosely coupled test then so will your business applications that sit on top of them.

Remember: "Rapid Service Development to Contract-First Containers".