WebSphere Principles

Beyond a set of product objectives and goals lie a set of values and principles that internally drive the WebSphere Platform. The basic principles, which drive the engineering activities around WebSphere, include:

• Treating platform as a development principle

• Leveraging core competencies

• Robustness

• Using what we sell

The engineers that work on WebSphere take the platform concept and interpret it with their own set of perspectives and contexts. To the WebSphere engineers, a platform means that they have something that is consistent, works as a single unit, and provides a user experience that is complete, rich, and robust. This is the first and most broad reaching of the WebSphere principles.

We have a platform, what does this mean? To some, it means that WebSphere Application Server is like an operating system. The WebSphere engineering team runs on and abides by many of the principles of operating system development. These are engrained in the team. Many members of the WebSphere engineering team work in development labs in places where operating systems such as OS/400, AIX, OS/2, and OS/390 were invented, delivered, and supported. Today the WebSphere engineers work in buildings alongside many of the teams that continue to be involved in operating systems development. The synergies are too many to describe.

WebSphere is effectively a layer over the top of the operating system that provides all of the programming abstractions (at least in combination with Java) that are needed to build next generation e-business applications. J2EE and application servers are effectively distributed operating systems from an API perspective. WebSphere is a distributed operating system from the perspective of performance, reliability, availability, recoverability, usability, and serviceability. This is a fundamental tenet of WebSphere.

WebSphere is based on a philosophy and value set that runs deep into the history of computing and into the history of IBM. Operating systems were the extent of software that was provided by the computer manufacturers in the beginning, or at least shortly after the beginning. IBM pioneered such concepts as transaction monitors and databases. These provided a layer that shielded, simplified, and expedited solution development. This layering idea has grown to now encompass the rich programming model that is contained within WebSphere. Within WebSphere, this platform-oriented thinking lives on and contributes in many ways to the WebSphere Application Server that exists today.

A second principle revolves around leveraging core competencies. IBM has a rich and varied set of engineering talents, spread across the globe. When specific skills are needed, the team within IBM that has those skills is found and commissioned to become contributors to the application server.

For example, when JMS became part of the J2EE, the WebSphere team went to the messaging team that provides WebSphereMQ and acquired the necessary JMS components of the application server. When object-oriented query entered the J2EE specification, the team that constructed the IBM Component Broker query service was once again called upon to deliver. In general, WebSphere takes a pragmatic approach to constructing the WebSphere Application Server, soliciting and in fact requiring contributions from the IBM Software Group at large.

Robustness is a third key principle. Being robust, WebSphere isolates the execution of customer code from the execution of system code. This is generally not the case in a world where we have no "kernel mode" to rely on for separating and isolating customer-written applications from the system. Through a series of internal components and a set of powerful reliability, availability, and serviceability capabilities, WebSphere does provide the environment of choice for application serving.

For example, our reliability, availability, and serviceability capabilities, which have been improved again in version 5.0, clearly demonstrate a commitment to robustness and reliability. In many cases, the WebSphere runtime will report a problem, point to the actual line of code (customer code and system code alike) that causes an event or failure to occur and suggest a solution. Version 5.0 actually adds an additional First Failure Data Capture (FFDC) capability that allows problems to be diagnosed without collecting additional trace data, or re-running the application to gather logs.

A knowledge base is built into the product. If a failure occurs a second time, the system will remember this and immediately gather the additional data necessary for diagnosis and providing a solution. Keeping the WebSphere JVM alive is a key part of the robustness story. Through careful programming and isolation techniques, WebSphere does everything possible to prevent a rogue piece of application code bring down the entire server.

The fourth and final principle that applies to the application server and the entire platform is that of "Use What We Sell". This principle states that the technology that WebSphere provides is the technology that we use to build some of the components of WebSphere. A good example of this in the WebSphere Application Server is the administration support provided by version 5.0. This is a J2EE application that makes heavy use of servlets and JSP pages. In WebSphere Application Server Enterprise, a number of components, including Business Rule Beans and Workflow, leverage J2EE APIs such as entity EJBs in their implementation.