This column might have been titled "on the SOAPbox," except I think I used that one already. Nevertheless, I want to discuss platforms. Politicians used to use platforms, (real ones, not some murky promises that they abandon after the election) to stand above the crowd, so as to be seen and heard better. This was back before the days of television and radio, but still, even now, everybody loves to be up on stage, to be seen. A platform gave them that opportunity to present themselves as larger than life, better, and right for the people.

In much the same fashion, a Web services platform allows you to do a better job of designing, developing, testing, deploying, and managing Web services. Picking a platform allows you to concentrate your efforts along well-defined lines, achieving efficiencies along the way.

It's easy when discussing Web services to get caught up in the higher levels of service-oriented architecture. There is a host of issues, including security and transactionality, that have to be considered and addressed in an enterprise architecture. The typical Web services person spends as much time worrying about standards such as WS-Transaction or BPEL as he or she does about the underlying implementation of the actual service itself.

This just makes the selection of a platform all the more important. A platform should enable Web services at various levels. First and foremost, it should offer an effective mechanism for creating, and exposing, services themselves. Although this sounds elementary, it isn't trivial. It's impossible for an organization to rewrite all of its software to accommodate a paradigm switch - there's too much of an investment already built into the existing technology. So while an ideal world might have all services written in Java, the real world will have them mixed with Cobol, Visual Basic, Fortran, and a host of other languages. Adding to this dilemma is the fact that most large organizations purchase packaged software to accomplish some of the business processes they employ. So in addition to organic development, Web services designers need to take into account things like SAP, PeopleSoft, and Oracle Financials, not to mention other industry-specific packages. In order to be effective, a platform must integrate into multiple environments and enable development around various APIs.

However for a platform to be truly effective it also has to manage these concepts at higher levels. Many of the tasks that used to fall to the individual programmers, such as security, transaction management, logging, and routing are now handled at higher levels. Application servers began this drive to extract common services from developer code. CORBA, DCE, J2EE, and .NET all provided the concept of an interface in some fashion, and Web services has taken it to the logical end point - a neutral, ubiquitous mechanism for defining services. It has also taken the task of defining the service away from the application server, and moved it squarely into the services arena. So now the tasks that previously fell to the developer fall to the architect or to the business process designer.

A good platform would need to provide tools and productivity enhancements to support these higher-level users. Process modeling tools that actually connect to actual services (or even drive the creation of services as a result of the modeling process) will enhance the productivity of designers and move service definition closer to the actual end users. Web services are largely about computer-to-computer interaction, but the main reason for the existence of the computers themselves is to enable some business process.

Last, a platform must be flexible. No one vendor can provide all of the pieces of a complete SOA. So, a good platform vendor will realize that the components that make up an SOA will be standards based, and the platform should be able to replace components as desired without compromising the overall usefulness of the platform.

That's a lot of work for a single vendor, or even a community, but platforms provide clear benefits over a la carte development. In this issue we bring you some more insight into platforms and effective development of Web services. Enjoy.