This article looks at the junction of two leading information-technology buzzwords, SOA and OSS. It explains that users can’t really have a useful SOA implementation without thousands of services and the OSS development model is the most likely way to develop thousands of services quickly and cost effectively.

Despite the PR hyperbole that tends to drown information-technology (IT) users in buzzwords, there is really no such thing as open-source service-oriented architecture (SOA). SOA is a blueprint of one way to build IT infrastructure, one that will most likely dominate the market through about 2020 because it adds the concept of utility-like computing to the re-use and interoperability promised in earlier IT architectures such as client/server (C/S). Open source software (OSS) is a potential SOA building material—the brick and mortar, studs and nails, windows and doors—just as it has been used in C/S computing for years.

OSS is not required to implement an SOA and an SOA design does not need OSS. But they go together nicely. Although it is possible to have a more modular rather than componentized SOA design, the SOA concept really does not make much sense without hundreds or thousands of highly granular components, or services. These fine-grained services need to be decoupled from individual applications (and pieces of infrastructure software) and stored both in services repositories (see illustration). There will be two types: those behind enterprise firewalls and “community repositories” organized by supply chain or other inter-enterprise characteristic. Community repositories do not really exist yet and are expected to emerge in the 2009-2012 timeframe.

These services are the pieces—artefacts in computer-science speak—that provide the benefits users expect of SOA. Because even the largest traditional software suppliers are unlikely to build thousands of such services, due to a limited market demand for each service individually, the OSS development model is the ideal way to fill up the repositories.

The following paragraphs look at OSS in the context introduced above, exploring

• OSS options by types of “services” (as in the “S” in SOA):
  • Applications
    
  • Infrastructure
    
• OSS options by SOA integration “philosophy”:
  
• Preintegrated into stacks
  
• Mixed and matched to enable SOA in a way unique to each user