To realize the business and IT benefits of XML, Web services, and service-oriented architecture (SOA), organizations will inevitably have to invest in SOA infrastructure. This infrastructure – lightweight, distributed, and rolled out incrementally – performs tasks like routing messages; enforcing security, privacy, and other policies; and orchestrating multiservice solutions.

The challenge for organizations will be to: 1) realize that they need SOA infrastructure; 2) choose the best solution from two SOA infrastructure designs; and 3) decide when to start rolling out implementations.

Web services adoption leads to SOA infrastructure

XML, Web services, and service-oriented architecture (SOA) dominate the information technology (IT) industry today (see Figure 1-Tab 1). But there is rampant confusion among user companies – technology buyers – as they try and sort through the often-contradictory conceptualizations, imagery, and naming schemes from vendors, analysts, and the media. While a growing number of user companies have decided that SOA will be their technology foundation of the future, few know how to go about implementing an SOA.

The benefits of services and SOA

Why are organizations embracing XML, Web services, and the concept of SOA? Despite an environment of tight IT budgets and an industry history of overhyped initiatives that promised – but failed – to transform companies, XML, Web services, and SOA deliver what companies want and need: flexibility and efficiency (see Figure 1-Tab 2).

• Flexibility, often called “agility” within the industry, is about rapidly adapting to, and taking advantage of, change. For example, when a new opportunity arrives (e.g., a new product offering is identified) or a business condition changes (e.g., a merger), companies need technology solutions to support this changing environment. By service-enabling systems – grafting an XML and Web services interface onto existing applications – executives can access data that they need to make decisions more quickly, and firms can service their customers more effectively than before.
  
  
• Efficiency is about leveraging existing resources as much as possible. Companies don’t have the time and money to recreate existing software, whether decades-old mainframe, 10-year-old client/server, or two-year-old Internet computing applications. By service-enabling these systems, companies can keep them in place but make it easier to access them or integrate them with other applications. IT can even create new solutions by combining existing service-enabled applications into more comprehensive, multiservice solutions called composite applications (see Figure 1-Tab 3).

The debate on how to connect services

But how should IT access or integrate a variety of service-enabled applications? There are two competing views. The first is based on the idea of linking each service directly to another: point-to-point integration. The second is based on using intermediaries to connect and regulate service interactions so that policies can be applied centrally and easily reused rather than individually hard-coded to each end point of a point-to-point solution.

New Rowley believes that the second method, an intermediary-based approach, makes the most sense for companies because it will deliver a more flexible SOA. Point-to-point solutions can still be delivered if required, but companies can abstract critical policies like privacy and security and apply them to a broad range of service-based solutions and composite applications (see Figure 2).

Companies that don’t use intermediaries will have to cobble together integration efforts and composite apps by adding code and logic to the underlying apps rather than overlaying policies, resulting in an SOA that is less capable of responding to changing business conditions.

SOA infrastructure: an umbrella name for service intermediaries

For the purposes of this report, we will give these intermediaries a generic name: SOA infrastructure. Why not pick a term currently used in the industry, such as enterprise service bus (ESB), SOA fabric, or the service infrastructure layer (SIL) – New Rowley’s own term? Because these terms, and the concepts and capabilities that they represent, are defined differently by various vendors and analysts. As an example, the most common term today, ESB, unfortunately also has the most wide-ranging definitions. Some use it to describe any SOA offering, whether SOA infrastructure or not; others think of it as the same as what we call SOA infrastructure. Still, others use it to describe a specific form of SOA infrastructure originally designed for heavy-duty messaging and application integration.

However, we won’t abandon these aforementioned terms completely. Since this report is about SOA infrastructure, we need a way to examine the various offerings. To do this, we’ll attach specific meaning to the existing terms to help differentiate competing approaches (see Figure 3).

• SOA fabric or SIL solutions are built around products that were developed as SOA infrastructure from day one. That is, they are designed to interact with Web services standards like XML, SOAP, UDDI, SAML, and WS-Security. Think of them as a pure, focused Web services infrastructure solution.
  
  SOA fabric or SIL offerings are only a few years old, and the list of vendors is tiny, as only two – Blue Titan and webMethods – currently market their products as SOA infrastructure. A variety of other vendors offer some of this capability, but it is buried within another product like a Web services management solution.
  
  
• ESBs are derived from existing offerings that were developed to provide reliable messaging and application integration. Often, their core technology is based on a non-Web service technology, such as Java Message Service (JMS). Think of ESBs as messaging solutions that also do Web services.
  
  There are many vendors offering ESB solutions, and many more will soon rebrand their current messaging or integration offerings as such. We expect vendors that now sell enterprise application integration (EAI) and business process management (BPM) products, for example, to switch to the ESB term to reposition their offerings.

What SOA infrastructure delivers

No matter what the underlying architecture is, all SOA infrastructure solutions should have the same fundamental characteristics and provide a similar range of core features and benefits.

Characteristics of SOA infrastructure control points

The essence of SOA infrastructure is intermediaries that interact with services. New Rowley calls these intermediaries control points, although other vendors may call them nodes, brokers, and proxies. The control points sit between service-enabled applications, or service end points, and intercept XML and Web services traffic (see Figure 4). Then, according to predetermined policies, the control points may do a variety of tasks, such as validating a message or transforming data from one format to another. Important control point characteristics include that they:

• Are rolled out incrementally, according to need. Modular and distributed in nature, additional control points can be added when necessary – for example, to increase performance, to add redundancy to the SOA, or to meet the needs of remote facilities. An initial control point may be rolled out for a specific project, and more can be implemented as required, eventually leading to an IT environment populated by a number of interconnected control points.
  
  This distributed model is an important distinction between SOA infrastructure and traditional integration solutions that required companies to commit much more aggressively in terms of money and resources to an initial deployment. With SOA infrastructure, each control point can be cost-justified – success with one deployment will create the justification for additional investment.
  
  
• Thoroughly leverage XML and Web services standards. Not only must a control point handle XML and Web services traffic, it must also use the same technology to connect with other SOA-related plug-in tools. For example, tools specifically designed to analyze Web services performance will access control point logs using standard Web services technologies.
  
  This concept of modularity based on standards is extremely important, as it enables companies to plug in a variety of tools and solutions from various vendors and not worry about custom integration.
  
  
• Can be part of a server or an appliance. Today, most control points run on top of a Windows, Linux, or UNIX server. But a variety of companies also make XML appliances – bundled hardware and software solutions – that are essentially rudimentary hardware-based control points. Already, two vendors, appliance maker DataPower and SOA infrastructure provider Blue Titan, are collaborating on building an integrated, appliance-based control point.
  
  The issue of whether control points will eventually be server- or appliance-based is hotly contested. Server proponents claim that servers, particularly compact blade servers that aggregate server components, are powerful enough to handle control point needs. Others contend that the inherent performance-draining nature of XML processing and the historical use of appliances in the network world (e.g., routers) will lead to appliance-based solutions. We expect to see a combination of solutions in the future.

SOA infrastructure features and benefits

There are a variety of functions handled by control points. In some situations, only one capability will be required; in others, multiple capabilities will be used. As organizations become more familiar and comfortable with Web services over time, we expect Web service implementations to rely on multiple features. The following is a list of the most important SOA infrastructure features.

• Intelligent routing to improve performance and system response. Control points intercept and analyze incoming service messages and take action, routing them based on specific policies. This routing may involve simply looking at the service that the XML document is intended for and sending it on its way, or it may involve a more complex task in which the control point actually examines the data in the message to determine where to send it. For example, a policy may tell a control point to examine any customer service request for the class of customer, sending premium-class customers to a more responsive system.
  
  Control points may also end up playing the role of firewall by not routing a message – essentially stopping anything unapproved from continuing its journey through the network. This could be to keep non-authorized service messages from affecting systems, or to make sure that even well-intentioned insiders don’t degrade a system’s performance by tapping into critical services without approval.
  
  
• Security enforcement to help meet security, privacy, and regulatory needs. Control points will authenticate a message to make sure it’s from the claimed sender, validate the message to make sure it hasn’t been tampered with in transit, and encrypt or decrypt the message according to corporate security guidelines. Critically important, control points are gaining the ability to leverage standards like WS-Security and SAML to enable them to successfully broker between competing security systems. This flexibility means that a service that relies on security system A can interoperate with a system that uses security system B, all without forcing developers to go back to the original applications and modify code.
  
  This focus on security also enables organizations to meet stricter privacy or corporate compliance regulations. For example, a security policy can ensure that a patient’s record is only available to authorized systems or that corporate financial data is made available to only the proper executives.
  
  
• XML validation and transformation to ensure better data. To ensure that a service-based solution functions properly and delivers correct data, IT may require a control point to validate the XML document that forms the basis of a Web service message. Validation requires that the control point compare the XML document – its layout, acceptable terms, and possible data values – against the schema it is supposed to be using.
  
  In addition to validation, a control point may be told by a policy to perform transformation, in which the XML document is changed from one schema to another so that the receiving service-enabled application can understand the incoming data. Just as with the previous security example, this enables IT to avoid changing the underlying code of an application and will make business more flexible and able to quickly integrate both internal and external systems from partners and customers.
  
  
• Service monitoring to help IT and business managers make quicker, informed decisions. Most data generated by software designed to monitor systems is solely for IT use, helping it manage the technology as well as meet established performance goals. Because the XML documents in Web service messages contain data, control points will be able to monitor not just IT-related activities, such as transactions per second, but also business activity, such as types of products ordered per minute.
  
  A variety of IT- and business-focused management tools will tap into the data logged by control points, enabling both IT and the business to respond quicker to changes in the environment. For example, IT will proactively respond to degrading system performance by bringing additional servers online, while product managers may react to unusually high customer inquiries about a specific product by reducing the price to spur sales.
  
  
• Orchestration to enable companies to build composite apps. Companies may try to build composite apps with point-to-point services, but this strategy will quickly generate hard-to-modify, rigid solutions. But as orchestration standards, such as the business process execution language (BPEL), mature, IT will build composite apps by writing business logic in orchestration development tools that is then enforced by control points.
  
  In the Web services and SOA world, orchestration, workflow, and BPM solutions are essentially becoming the same. While various SOA infrastructure vendors may favor one term over the other, we think that orchestration will eventually be the term that wins out.

Competing approaches to SOA infrastructure

As mentioned earlier in the discussion about SOA infrastructure, there are various ways that this solution is being delivered. The two competing architectures are the SOA fabric/SIL and the ESB approach. The most dramatic difference between these two offerings is their underpinning. SOA fabric solutions were designed to work with XML and Web services; ESBs are existing middleware solutions that have been retrofitted to handle Web services and provide SOA infrastructure capabilities (see Figure 5).

When choosing between these approaches, buyers need to focus on:

• The integration features needed. Organizations that need additional capability beyond what we have outlined for SOA infrastructure – for example, connectors to non-service-enabled systems or mission-critical messaging systems – will want to invest in more traditional integration or transaction systems. In the latter case, for example, the cost of a more heavy-duty system is offset by the absolute need to have the system be 100% reliable.
  
  For the majority of Web service systems today, we expect SOA fabric/SIL solutions to be a good fit. And given that integration and messaging solutions have added service interfaces, organizations can choose to roll out a SOA fabric/SIL solution but still integrate it with existing, heavy-duty middleware.
  
  
• The amount of complexity and time required learning and rolling out a solution. Given all of the features of heavy-duty messaging and integration solutions, it will take more time and effort to roll out solutions if those features are enabled. If the more complex features are not used, it would be difficult to justify getting the more complex solution in the first place.
  
  
• The reliance on third-party tools. A properly designed SOA infrastructure offering should readily accept an expanding set of Web service tools for activities like managing service level agreements and developing service-based security and privacy policies. While vendors undoubtedly will bundle their own SOA infrastructure and plug-in tools, buyers should look for solutions that are designed to be modular. For example, proprietary orchestration development environments will limit flexibility in the long run and should be avoided.
  
  
• Price and performance of the control points. Assuming competing solutions are equal in the above criteria, buyers will look to the cost of adding additional control points as well as the performance of those nodes. EAI vendors will have a difficult time adjusting their revenue expectations from deals that generate millions of dollars to ones that bring in hundreds of thousands of dollars. And heavy-duty middleware may also show performance bottlenecks as it attempts to compete with SOA infrastructure offerings that are purposely built to quickly handle XML and Web services.

A buyer’s SOA infrastructure strategy

Given the early stage of the SOA infrastructure market, what should a company do? We suggest a series of steps to either prepare your company for thinking about SOA infrastructure or for actually rolling it out. Regardless of their state of SOA adoption, companies should:

• Understand what vendors are selling. As with any new market, vendor – and analyst – confusion makes it hard to understand what to do. The first step is to understand that many vendors are selling rudimentary SOA infrastructure, even though they do not market these offerings as such. For example, Web services management companies provide control points, but they admit that eventually they want to be out of the infrastructure space (see Figure 6).
  
  New Rowley recommends that to help understand vendors and their products, user companies should think of SOA offerings in terms of three layers, as we laid out in Figure 4. Categorize any offerings that retrofit services to existing applications as service-enablement tools (e.g., Cape Clear Software). Any product that offers SOA infrastructure capabilities in a solution not part of an app server should be thought of as an SOA infrastructure offering (e.g., Blue Titan). Finally, anything that creates the policies, rules, or contracts to be enforced by the control points, or analyzes data from control points, should be thought of as an SOA infrastructure plug-in (e.g. AmberPoint).
  
  
• Develop an SOA blueprint that includes SOA infrastructure. Many IT architects and CIOs have been thinking for some time about how to take advantage of XML and Web services. But the key ideas that must be integrated into a blueprint are: 1) composite apps, and 2) SOA infrastructure. These two concepts are the key to a more flexible and efficient enterprise, but they also bring with them a host of challenges to be dealt with, including how to develop and test composite apps that could adversely affect other services and how to tie in security and identity management systems in an evolving SOA.
  
  
• Sketch out plans for working with business users to design the most effective composite apps. Composite apps will enable companies to respond more quickly to new opportunities driven by changes in business conditions. They will also make companies more efficient – for example, delivering a unified view of all of a customer’s interactions with the company. By talking with business users, IT can start to prioritize which systems it should service-enable in order to eventually integrate them into a composite app. Obvious candidates involve anything around customer data so that sales and support personnel have a better chance to excel at their jobs.

Reasons to roll out SOA infrastructure sooner rather than later

Most organizations don’t like to be on the cutting edge; usually those out in front spend extra resources and suffer through a host of unforeseen problems to be pioneers. But in the SOA world, there are two good reasons to move forward aggressively:

1. Initial SOA infrastructure investments are digestible, even in this economic climate. For example, project-level pilots that use a single control point only run in the tens of thousands of dollars and can be used to justify future investments.
   
   
2. Services will spring up like weeds in organizations, and point-to-point implementations will eventually have to be brought into a rationalized world governed by SOA infrastructure. If you don’t think cleaning up a mass of grassroots adoption is painful, just ask IT colleagues who were charged with rationalizing the hundreds to thousands of Web sites that sprung up in companies in the mid-1990s.

For the many organizations that believe it makes business sense to move forward today due to the relatively low risk factors involved and the likely high rewards, we suggest that they:

• Evaluate and codify when to use traditional middleware and when to use SOA infrastructure. SOA infrastructure and other middleware solutions will coexist indefinitely. Business needs – how reliable and fast does the system need to be? – should be the defining criteria for choosing an appropriate SOA infrastructure or middleware solution. A team of architects can create a decision matrix spreadsheet for project managers that outlines the pros and cons and likely cost in licensing fees and developer time of the competing approach.
  
  
• Ask vendors how their current and future solutions will work with SOA infrastructure. Almost every vendor has the SOA term sprinkled liberally throughout its product literature. But in this age where one vendor’s marketing can be quickly copied but product features cannot, be sure to get information from critical software providers about how their products interact with services. Of particular interest will be the response of development tools and testing vendors. They may not have an SOA-savvy product today, but they should be able to discuss how, for example, their offerings will help you build, test, and maintain composite apps.
  
  
• Test and document initial SOA infrastructure deployments. With much lower price points than traditional middleware offerings, SOA infrastructure solutions should be easy to roll out and tie into existing services on a departmental project scale. And since SOA infrastructure will be rolled out incrementally, companies should create their own ROI studies rather than relying on generic ROI documents from vendors. These ROI results can then be used to roll out additional control points until the company buys into the concept on an enterprise level.

Conclusion

For buyers, the key takeaways from this report are that SOA infrastructure solutions are:

• Inevitable. The business and IT benefits of going down the SOA path are too great to ignore, and once organizations head down that path, they will discover that an SOA infrastructure solution is required. Aggressive adopters will have an orderly roll out of services and a head start on creating composite apps; laggards will have to jump onboard eventually but will spend precious time and energy decoupling a multitude of rigid point-to-point service solutions.
  
  
• Evolving. The capabilities required to reap the benefits of services are not fully available today; standards are still being hammered out, and software solutions are still being coded. With this in mind, look to vendors that may not have all the pieces but that understand the vision of how SOAs must evolve.
  
  
• Incremental. Unlike a massive, multimillion-dollar EAI effort that may fail or will undoubtedly disappoint, SOA infrastructure solutions require only tens of thousands of dollars to pilot and often weeks to get going, can immediately improve your ongoing service initiatives, and can be used as an ROI test bed to justify further investment.
  
  
• Efficient and flexible. In the end, the critical point to remember is that SOA infrastructure will help companies become more nimble – without breaking the bank. With an SOA infrastructure foundation in place, business and IT can work together to deliver technology solutions more quickly that improve the bottom line.