WebSphere.Next : WebSphere Platform for the future
The Component Puzzle
The following views represent my own, not necessarily IBMs.
The SpringSource folks have certainly made a splash in the marketplace with their announcement of the Spring Application Platform Beta. My mailbox has been filled with questions like what does this mean to JavaEE and WebSphere specifically. But what SpringSource has announced is not new, it is what we have been doing for the past couple of years. We just have customers that we are trying to bring along with us in this journey.
From my point of view let me describe what I think is going on in the industry, and what I think WebSphere is doing to fit into this environment. I would like to here if you agree or disagree with these thoughts.
SpringSource has brought forth some interesting technology and concepts in the past with the Spring Framework. It provided us the concept of Inversion of Control containers, and a programming and component model that allows for loosely coupled components to be wired together to build applications. This programming model enables more and better reuse of software components. But I would also say there are some other technologies that are available in the industry that are interesting to drive this component market for applications.
OSGi is a very interesting set of standards today that it provides the component model for packaging components and provides the runtime functions needed to knit the components together to make an application. There is starting to be an industry acceptance of OSGi as the standard for developing components. This industry acceptances so far has been more around componentizing middleware runtimes to enable customers to use just want they need of the middleware, lightening the environment up. But this is also changing, with the OSGi Enterprise Expert Group, is where the programming model concepts to enable customer applications is being standardized. Many industry players, including IBM, SpringSource, BEA, Oracle and others are working together to define this standard.
SCA (Service Component Architecture) is another very interesting technology for developing components. It was developed to be a language neutral, environment neutral model for building components. What I really like about SCA is that it abstracts away from the developer, a lot of the complexity of the middleware and allows them to focus on the business problem they are trying to solve in their application. The model allows the developer to describe their intents, for example whether the component is transactional or needs to be secured, without the business logic having to deal with these intents. I know all applications developers secretly want to write middleware, but separating these things from the application logic does enable greater reuse and allows the components to be much more valuable to the company that develops them.
Each of these technologies have advantages and disadvantages. And I view their usage in a spectrum, and it will be nice to merge some of the concepts from each to make a really good programming/component model. And that is what I would like to get the industry to do and to have WebSphere to have a quality implementation of these.
So OSGi and OASIS seem to be the place to standardize component technology. As part of the OSGi EEG, we are trying to work in that body to take the SCA technology and the OSGi technology and merge some of the concepts. This is important to enable the good features of OSGi to be exposed to true application writers in such a way that their application components are more configurable and thus more useful.
OSGi is also being actively used by middleware providers (such as WebSphere) to componentized their runtimes in to profiles. Profiles are different code loads that are tailored for a specific purpose. WebSphere has been doing this for years via the brut force techniques, we have profiles for a JavaEE application server, an ESB server, an BPEL server … . Since WAS 6.1 we have been using OSGi technology to componentized our server so that it can be thinned down for specific profiles. And there is more to come in WAS 7.0, which is in open beta now.
The Spring Framework has brought forth a lot of concepts that are being incorporated in these standards bodies. The concept of wiring applications together, and loose coupling are all things that people look to Spring to provide. We in WebSphere worked with SpringSource to help certify a level of Spring with the WebSphere Application Server, and will be doing more to ensure our customers use of the Spring Framework is a good one.
As with all technologies and products, there are things missing. What I have discussed so far is the programming and component models. What I haven’t talked about is the secret sauce. How do you manage these components, how do you resolve problems, how do you scale them up, how do you scale them down. These are all the things that differentiate one application server from the other. And it takes time and significant effort to get an implementation that fit into customer’s shops. SpringSource is just entering the market with their application server, it will take them significant time and investment to provide an application server with the depth and breath that will be needed for customers to make significant use of.
But enough about SpringSource, WAS.Next, it is a vision that we have already been implementing towards. A componentized middleware runtime, that can be tailored for specific profiles, that is standards based, that customers can scale, maintain, and bet their businesses on. This platform will be open and support several programming models, such as JavaEE, SCA, OSGi EEG, Spring, giving application developers choice, and IT the ability to run it to meet their business goals.
Its going to be a fun ride.