Application developers have always been under pressure to develop applications faster, with fewer resources. Recently, this has directed attention to service-oriented architectures (SOAs) because of their promise to provide libraries of reusable services that can be snapped together easily when needed.

While SOAs continue to evolve and gain adoption, application developers are also seeing limitations in just how far an SOA can go in delivering development speed at lower cost. SOAs are great at providing libraries of loosely coupled, reusable computing functions, but developers still need to code application infrastructures around these services in order to solve specific business scenarios. To address this problem, many infrastructure vendors have augmented SOAs with abstraction layers such as JavaServer Faces (JSF) that make it possible to write applications in fewer lines of code. Additionally, developers are increasingly sending development jobs to places like India, where labor is cheaper.

Each of these approaches to building and delivering applications faster and more cost effectively, however, is incremental in the long run. Ultimately, the goal is to deliver applications in real time, or on demand - just as fully automated, robot-empowered factories manufacture and deliver mass customized products like cars and electronic products in real time - without employing manual fabrication steps in the finished product. If you think of real-time, on-demand delivery of customized apps as the ultimate goal, then a new kind of software-based automated fabrication layer is required to augment SOAs.

SOA - A New Programming Model
The term SOA refers to the new kind of programming model that refocuses on the age-old problem of software reuse. Today's SOAs are an outgrowth of the Internet. They take advantage of XML and HTTP, and provide a new level of distribution and reuse of computing functionality that has never been seen before in software.

SOAs aren't intended to replace or "front-end" all existing back-end systems. They are intended only to replace the ones that require cross-platform access and standardized, self-describing interfaces (i.e., XML schemas). SOAs are currently evolving and are still in their early stages. As it stands, there are still many open issues with respect to how SOAs should, and can, provide basic functions around services such as security, failure, and contracts.

Today, because SOAs are so new, application developers are forced to use SOAs in conjunction with more traditional means of accessing application resources, such as tightly coupled Enterprise JavaBeans (EJBs), message queues, and language-specific, API-based connector architectures.

SOAs make it easier for business functions from different back-end systems to be seamlessly integrated into user-facing applications. This is because it is easier to transform data from one format to another when it is represented in XML, and accessed by way of independent, self-sufficient services. For example, an SOA can enable an SAP system to be linked with a Lotus Domino system at the application session layer to provide a comprehensive employee travel expense reporting system. Previously, two enterprise-level systems would have called for independent "silo" applications: SOAs enable a new breed of composite application to link services from disparate back ends into a common session running on an application server, such as J2EE-based WebSphere.

Application platforms are moving in a service-oriented direction as well. IBM, for example, is building its SOA strategy, in part, around WebSphere Application Server and integration software. The company has also established the WebSphere Business Integration Server Foundation, offering native support for the Business Process Execution Language (BPEL), as well as the IBM Assessments for Services-Oriented Architecture from IBM Global Services.

SOA - LEGO^TM Blocks for Building Applications
SOAs enable developers to 1) reuse functional software components, and 2) construct "composite applications" out of these pieces as shown in Figure 1. Just as the LEGO? block concept increased the space of what one could build with a relatively small set of off-the-shelf pieces, SOAs enable developers to provide a wider array of applications out of a small set of pre-built services. The philosophy driving an SOA is that one can standardize and lock down a relatively small set of services that don't change that often, and still achieve a needed level of application variability by virtue of the large number of ways in which these parts can be assembled. Of course, there's still a certain amount of custom fabrication that's needed to build the small set of parts that are needed for the finished product or application. This is often referred to as the "last mile" of development, which can form a bottleneck that leads to its own problems. For now, SOAs provide the first step in simultaneously enabling the seemingly diametrically opposed requirements of simple standardization and reuse, versus mass customization.

SOA - A Prerequisite to Delivering Applications on Demand
The SOA model brings about the ability to assemble applications out of piece parts - i.e., services. The similarity of this model to the manufacturing world beckons people to embrace concepts such as "make to order" and "just in time." On demand signifies delivering an application when it is needed - on demand. Without an SOA, on demand is difficult, if not impossible due to the lack of off-the-shelf, reusable piece parts - i.e., services.

The term "on demand" used in the context above pertains to the delivery of applications when they are needed - on demand. There is another use of the term "on demand" as it pertains to the runtime operation of applications and networks. In this context, on demand means the ability to adapt automatically to changes while running. One can think of operational on demand as being analogous to a car that's able to adapt to changes in terrain by stiffening the suspension and changing the braking behavior in response to changing road conditions.

While on demand application operability is important, its on demand application delivery is what really takes advantage of the power of an SOA. However, in order to realize the full benefits of on demand application delivery and an SOA, another piece is needed - automation.

Factory Automation - Enabling Real Time On Demand
Even if a development shop has an SOA, delivering custom-built applications on demand still requires people to develop application code that makes use of an SOA-provided library of reusable back-end services. The application code that forms the "structure" of the application must be developed for each business need, and this requires development cycles for each scenario. In order to make delivery of custom-generated applications be truly on demand, an SOA platform needs an automated fabrication component linked to it - akin to a factory that uses robots to perform automated sequences of fabrication steps. Without some form of automated fabrication component to assist an SOA with the creation and delivery of finished applications, on demand runs into a bottleneck that's formed by the lack of human development resources needed to build finished applications. Even with the best of SOAs, stocked with libraries of off-the-shelf services, development shops must still pour large amounts of resources into building and maintaining applications that utilize these backend services.

Many development environments today are lured into trying to solve the human bottleneck problem by using a combination of RAD tools to assist developers in the construction of software components, and less expensive offshore services. Both efforts help in some respect, but fail to solve the larger problem - to deliver on demand in a real time manner. RAD tools enable the rapid creation of single instances of software components, but they don't perform the critical role of automating the creation of families of related, but different application instances when they are needed - on demand. In other words, RAD tools are not able to automate the generation of different instances of applications, in the same manner that a robot-enabled factory is able to manufacture families of varying instances of products by varying the fabrication steps performed by individual robots. Instead, RAD tools are intended to assist and speed the manual creation of individual application instances. This makes both RAD tools and offshore services better suited for constructing the more static services that populate the warehouse library of an SOA.

In a physical world, an automated factory performs the task of fabricating the chassis and structures to hold "off-the-shelf" components that get assembled into a finished product. The analogy here to the services model is that services are analogous to off-the-shelf, reusable components, and the chassis is analogous to the application presentation, session logic, and workflow.

Enabling Many Variations from a Single Model
Today, the need for application variability and mass customization is growing stronger as developers are providing wider access to applications via the Web. Larger audiences translate to wider ranges of end-user requirements. As a result, the old Burger King slogan, "have it your way," is becoming a requirement of application services that are provided via the Web.

There are many different characteristics that can potentially cause an application to have its composition of feature and option combinations vary. These characteristics can be thought of as dimensions that drive an application's variability. Every application, even the simplest one, has at least one dimension of variability, and that is user role. Every application has users that fall into different usage roles, such as, a user role, an admin role, a developer role, and a tester role. Each of these roles causes the application to have to exhibit different functional behaviors.

In real business scenarios, the number of variability dimensions can grow into the dozens. For example, in a flight reservation booking application, there are several characteristics, such as the types of tasks that need to be performed, the level of entitlement for the end user, the end user's geographic territory, the look-and-feel requirements of the application, and the specific time in which the application is being used. Each of these dimensions creates the need for different functionality and structure to be woven into the application.

Syndication - The Force that's Driving Variability Through the Roof
In certain industries, such as travel and financial services, application delivery via the Web is becoming increasingly complex. Previously, a service provider, such as an airline or hotel, could build a Web site and expect users to visit its site. Today, a sea of intermediaries, such as travel service packagers and aggregators, and special interest sites offer their own special interest packages. As a result, airlines and hotels are being disintermediated - causing a dilution of their brands on the Web - where consumers are making buying decisions based on price over brand.

In order to fight back and gain lost market share, service providers are turning to a new application delivery solution called syndication. To overcome challenges associated with trying to get users to visit an application exclusively at a single "home" site, a service provider can syndicate its application out to thousands of other sites. Syndication means that access to the application gets embedded into partner sites in a similar manner as to the way a banner ad is embedded in a site. The difference occurs when a syndicated application is accessed by an end user visiting the partner site and the syndicated application has to be served up on demand in a manner that is similar to how a banner ad is served up in the context of another site. This is where variability and customization become important. With a system in place on top of an SOA, a service provider could potentially dynamically deliver thousands of application variants to end users, in the context of different syndication partner sites, just as easily as it could syndicate out static content in the form of ads. The difference is that the application variants are being "morphed" on the fly to represent different presentations, logical flows, and back-end interactions, whereas an ad is just a static piece of data.

Syndication is the newest application delivery mechanism that necessitates a real-time, on demand delivery capability for providing mass customization.

Summary
Service-oriented architectures lay the groundwork for enabling a new level of reuse and customization from a relatively small set of backend services. However, SOAs alone have limitations and cannot solve the problem developers face to deliver many different variations of an application to support different types of functionality and behavior. This problem is compounded by the new need to syndicate applications out into large numbers of partner sites in order for service providers to extend their reach to a broader audience.

SOAs are a first step towards realizing faster development with fewer resources. In order to realize the ultimate goal of on demand real-time delivery of finished applications, an automation component needs to be in place on top of the SOA that performs the fabrication and delivery of applications in the contexts where they are needed.