Build a Better Enterprise Application

With plans for Web services still in their early stages, most organizations are cautiously enhancing their IT infrastructure to accommodate the move. At least, that's the philosophy behind Service-Oriented Architecture (SOA), the hottest idea being pushed by Web services vendors, analysts, and visionaries. It might just be a good one, too--if implemented properly.

Strictly speaking, SOA isn't a new concept. It's simply a way of making application functionality available through shared services discoverable on a network. The theory is that by abstracting applications away from the underlying hardware, resources can be used more efficiently. Having reusable software components can also simplify the development of custom applications, allowing IT to more closely match the needs of end users than it could with services that depend on specific servers.

Until now, that theory has been difficult to put into practice, mainly because SOAs have traditionally depended on proprietary middleware that often erased any efficiency gains made. The advent of Web services changes this. Thanks to industry-wide standardization on XML, Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI), services can be published, discovered, and invoked using interfaces that are supported by all competing vendors.

An SOA is more than a collection of Web services. It's also the technical architecture required to publish, discover, operate, and manage services in support of enterprise applications. And while Web services do make SOA rollout simpler than it used to be, it still involves critical decisions that impact network performance and IT security.

Designing an SOA is further complicated by the immaturity of Web services. Enterprises still grappling with XML are bombarded by continued standards volatility. Vendors from previously separate markets are jockeying to provide SOA solutions, each claiming to offer the architecture's most important component, whether that be management, security, development tools, or the Enterprise Service Bus (ESB), the middleware that distinguishes an SOA from standalone Web services. Some of these solutions are critical in an SOA, while others will depend on the existing IT architecture and the organization's goals.It's important to note that an SOA isn't a packaged software application, and it can't be purchased from a single vendor. In fact, an SOA may not require any additional software or technology at all.

SOARING SOAs

SOA's key advantage is flexibility. Unlike previous paradigms such as client-server and mainframe environments, it offers IT functionality as cross-platform shared services. This offers a number of benefits, but the most immediate is a clear ROI arising from asset reuse.

Once a portfolio of Web services is available in an SOA, these reuse benefits multiply exponentially in an "SOA network effect." The value of SOA increases with the number of available services, and the number of different applications or users that access those services. This value compounds over time and becomes even greater if SOA is leveraged both internally and externally.An enterprise could start out with an SOA used for internal services, for example, then expand it to customer-facing applications. This entails XML data exchange with trading partners, a practice that's becoming more common in the telecommunications and travel industries. An SOA can also benefit customer-facing B2B applications, where the user is unaware of the underlying infrastructure.

For example, a bank might use a client portal to support customer inquiry and self-service functions that require access to multiple legacy back-end systems. An SOA approach would offer these functions as Web services to both the customer-facing portal and the bank's own employees. This reduces the amount of internal integration required to provide full access to the legacy systems, as the same SOA interface is used by all applications.

SOA's flexibility also benefits an organization through faster application development and lowered costs by allowing hardware and software components to be reused. Applications developed this way can even be of higher quality than those developed independently because the components are pretested and the Web services interfaces have already been proven.

These benefits aren't just speculative. Motorcycle vendor Harley-Davidson was able to develop and roll out IP telephony to its resellers in just three days, thanks to its use of Web services for application integration. The company runs BEA Systems' WebLogic application, enhanced with its own in-house Java framework to build reusable SOAP services. The VoIP links reused a dealership contact service originally intended for a CRM application.

The speed, ease, and quality of SOA-developed applications has led many analysts to see the architecture as a means of aligning an enterprise's goals with its IT services and capabilities. If implemented properly, its flexibility will filter through to the entire network and to the organization as a whole: An IT department can modify technology without making changes to the services available, while an enterprise can change its applications or business processes with minimal effect on the IT architecture.SOA's flexibility is particularly important when trying to integrate several different systems, such as those that result from mergers. After organic growth and multiple acquisitions, for example, office supply retailer Staples found itself with five duplicate systems for credit card authorizations. Rather than transition to just one authorization system or create multiple interfaces to each back-end application, Staples implemented a Web service for use by all five. An SOA provides the run-time, management, and security functionality, allowing Staples to route each of its 100 million annual credit card transactions through whichever one of the five banks and clearinghouses provides the best value for that particular payment.

SOA SO FAR

It's possible to implement an SOA without Web services. The concept has been around since the rise of object-oriented technology, taking the form of Remote Procedure Call (RPC) middleware solutions such as Microsoft RPC and Java Remote Method Invocation (RMI). Based on the Common Object Request Broker Architecture (CORBA), Distributed Computing Environment (DCE), and COM/DCOM, these solutions implement a synchronous client-server communications model, in which one application acts as client and another as a server.

Compared to Web services, this model has two major disadvantages. First, synchronous operations can slow applications down because the client remains idle until the server has completed its request. Second, RPC-style solutions are typically proprietary and won't interoperate across platforms. The biggest challenge is finding a single RPC solution that works with all the required programming tools and computing platforms at an affordable price.For example, while CORBA has the broadest platform and language support, it's complex and expensive. Java has built-in CORBA and RMI support. Microsoft Windows supports DCOM and Microsoft RPC. Most Linux and Unix platforms support Open Network Computing (ONC) RPC. This makes implementing a single RPC solution across heterogeneous computing environments a challenge.

Message-Oriented Middleware (MOM) goes some way toward solving both RPCs' problems, but introduces new ones of its own. MOM solutions such as IBM's WebSphere MQ, Sonic Software's SonicMQ, Microsoft's MSMQ, and TIBCO Software's Rendezvous implement asynchronous peer-to-peer communications, allowing an application to continue its normal processing while waiting for a response from another. This approach is typically associated with loosely coupled connections, which allow greater independence regarding exactly how a message is processed.

The downside of MOM solutions is that they're often more complex to implement than basic RPC. They're also expensive and proprietary. Although the Java platform provides a Java Message Service (JMS) API that can connect to almost any MOM product, SonicMQ won't interoperate with WebSphere MQ, and WebSphere MQ won't communicate with Rendezvous. For two applications to communicate, they must use the same middleware layer.

An SOA that uses Web services is similar to one using MOM, but it replaces the proprietary middleware with open standards that can support both synchronous RPCs and asynchronous messaging. Whether running on Sun Microsystems' J2EE, Microsoft's .NET, or a legacy platform, SOA exposes services using the same industry-standard XML.

CORE COMPONENTSAn SOA must have a number of core architectural elements in order to function (see Fact File). The first thing most SOA users see is the services registry, usually based on UDDI, an XML standard for Web services directories.

Underneath that is the ESB, also called a Web services broker, which processes messages and routes traffic to the most appropriate application or service. Increasingly, the ESB is combined with a Web Services Management (WSM) platform, which monitors an SOA's performance.

Finally, a Web services security or identity management solution is usually required.

Registration Required

The services registry acts as a repository of information about the Web services available in an SOA. The registry itself is published using UDDI, while WSDL documents are required when clients invoke services. Thus, a client or user can browse the UDDI registry, then request the WSDL document for a specific service. UDDI registries are available as standalone products from vendors such as Systinet, Cape Clear Software, IBM, Microsoft, and Novell. But when building an SOA, a registry bundled with a WSM platform from a company such as Digital Evolution may be more attractive, as it allows tight integration between the two.The WSM itself provides a run-time environment for invoking Web services, as well as managing their operations and enforcing SLAs. This segment of the SOA market is replete with solutions, including those from firms such as Actional, AmberPoint, Infravio, and Service Integrity.

Some WSM vendors emphasize different capabilities within this broad category, though they generally offer similar functionality.

For example, Digital Evolution emphasizes security and reliable message delivery. Infravio emphasizes management of SLAs. Service Integrity emphasizes monitoring and visibility. Others emphasize operations such as load balancing and failover. WSM vendors are also beginning to aggregate functionality from other product categories, including the security and ESB sectors, gradually building toward a complete SOA solution.

MIX AND MATCHToday, no vendor can provide a single comprehensive solution. An SOA also requires an ESB to parse the XML in SOAP or other Web services messages, then route or transform those messages appropriately. Meant to augment existing IT architectures, ESBs also offer a robust set of capabilities for organizations beginning the migration to an SOA. Standalone ESBs are available from vendors such as Sonic, Fiorano Software, Cape Clear, and Blue Titan.

Some analysts forecast WSM systems and ESBs merging over time because their functions overlap. In fact, one ESB white paper claims that ESBs are "a pre-packaged SOA implementation, already consisting of the necessary functional components to achieve SOA aims." This is an aggressive claim that ignores many core SOA functions such as management and services discovery. ESB functionality is a critical aspect of any SOA, but it's not enough on its own.

SERVICE SECURITY

Like everything else on a network, Web services must be kept secure. The standards for Web services security have been a concentration point for all vendors, and tend to fall into two broad categories: Web services security itself, and federated identity management.

Both categories offer multiple implementation alternatives. WSM solutions such as Digital Evolution's often include support for basic Web services security standards, while vendors such as Forum Systems and Reactivity offer dedicated security appliances. Federated identity management is usually included in Single Sign-On (SSO) solutions from vendors such as Netegrity, Tivoli, RSA Security, and Novell.Web services security addresses requirements for authentication, authorization, confidentiality, and data integrity through emerging standards such as Web Services Security (WS-Security) and the Security Assertion Markup Language (SAML). Both build on existing security standards, from basic SSL and X.509 certificates to XML Signature and XML Encryption.

The Liberty Alliance is responsible for most of the work on standards-based federated identity (see "Making the Case For Liberty"). Based on SAML, federated identity associates privileges with identities. In an SOA, identities must be applied to both users and applications.

Federated identity is becoming increasingly important as Web services expand beyond internal integration efforts and into externally facing services for customers and trading partners. This will lead to close collaboration between WSM vendors, which have proven solutions for securing Web services, and identity management vendors, which have expanded their SSO solutions to support Web services applications and SOAs.

OUTSIDE THE BOX

The registry, ESB, and WSM functions represent the SOA core. Most SOAs will also include other components that depend on an organization's individual requirements. If an enterprise is producing its own tools, it will need Web services development and programming tools, such as Integrated Development Environment (IDE) and WSDL compilers.As an SOA reaches critical mass, the core architecture may also be supplemented with other emerging solutions. Some of these are very compelling. For example, SOA policy and governance solutions can help network architects define and enforce rules for accessing Web services. Metadata management is also important because XML is infinitely extensible, and WSM solutions must be able to process and manage all the elements within a Web services document.

Even without an SOA, Web services can mandate additional products. XML acceleration or security appliances can provide important incremental performance improvements as Web services proliferate within an organization.

SOA STRUGGLE

The vendor battle for SOA control is a multifaceted one. SOA start-ups are offering leading-edge tools to help enterprises build and operate SOAs and other Web services, challenging the large incumbent vendors and their installed base. The incumbents, such as IBM, Microsoft, SAP, and Oracle, won't easily cede control to WSM and ESB vendors.

The real issue for network architects is identifying a primary SOA driver. This is usually based on a variety of business as well as technical issues arising from SOA's flexibility. For instance, SOA and Web services initiatives are often triggered by some overarching business imperative such as revenue generation, customer loyalty, internal IT and business efficiencies, or cost reductions. Understanding this will help clarify what SOA core solutions are required and the sequence they should be implemented in.For example, if an SOA's main function is to deliver externally facing Web services, its most important features will be robust security and a WSM solution. If an organization's initial goals are integration-focused, an ROI can be achieved by replacing or augmenting an EAI strategy with Web services. In this case, SOA may call for an ESB-based solution that builds upon existing messaging and integration skills.

The installed base can also influence the move to an SOA. An organization with a J2EE architecture may base an SOA strategy on an application server solution such as BEA's WebLogic or IBM's WebSphere. In a similar vein, SAP users will feel strongly about positioning NetWeaver as the centerpiece of their SOA. However, these debates miss two key points. First, these technology solutions are not SOAs in and of themselves. Second, an SOA is not about a single vendor or a single product. Rather, it's about enabling IT to be more responsive to the needs of the organization.

An ideal SOA would initially be developed from a business perspective, independent of any vendor influence. This assures a focus on the services that an SOA will deliver, not on products or technology. Once this overall context has been established, the incumbent IT architecture and application portfolio should be evaluated for SOA inclusion and support, and new SOA solutions should be investigated to build a robust SOA core.

Each vendor naturally claims that its own piece of the SOA puzzle is the most important. ESB, WSM, UDDI, and security vendors all feel that their solution alone is enough to transform an existing IT architecture into an SOA, but the reality is that all of these functions are required. A network can start with whichever of the core SOA elements is most important to its users' requirements, but this is only the first step. Over time, a full SOA solution may be required.

Ultimately, SOA solutions must always support an organization's objectives. Perhaps the real battle for control of SOA is in maintaining this focus. Implementing an SOA must be a business decision first, followed by the technology choices described above. Maintaining this unrelenting focus will allow IT executives to rise above the vendor fray and match SOA requirements to business goals and objectives. Eric A. Marks is president and CEO of AgilePath and co-author of the Executive's Guide to Web Services (Wiley, 2003).Send comments to [email protected].

Fact File

UDDI Services Registry

Makes Web services visible to applications. Encouraging developers to publish all services to a UDDI registry will provide a platform for code reuse and application sharing. Often the first step in migrating to an SOA.

Enterprise Service BusProvides a reliable messaging and data integration backbone. Parses XML messages for content-based routing and transformation.

Web Services Management

Provides visibility and management for Web services. Monitors service availability to ensure quality and enforces SLAs. Also handles load balancing, failover, and reliable Web services messaging.

Web Services Security

Provides a secure environment for Web services accessed by external users or applications. Includes encryption, digital signatures, authentication, authorization, confidentiality, data integrity, and nonrepudiation. May be combined with federated identity management solutions.

Risk Assessment: Service-oriented Architecture

As a concept, SOA is mature. The Web services technologies that enable it are not. Core standards such as XML, SOAP, WSDL, and UDDI are accepted industrywide, while other standards such as those needed for security are still emerging. An explicit connection to business performance must develop further for many organizations to invest in an SOA.

The fact that SOAs can be and have been implemented without Web services is reassuring. This means that with Web services' lower entry costs and ability to reuse existing IT assets, SOAs will have an even better chance of success. SOAs can be implemented in a variety of ways using a variety of approaches, though their benefits aren't yet clear for every organization.

SOAs and Web services will have a tremendous impact if user requirements are paramount in their design and buildout. Metrics for success must be tied to an organization's goals and performance. Even without business and IT interlock, SOAs have internal IT benefits that will result in greater internal customer satisfaction.There are two risks with SOAs. One is the risk of moving toward an SOA too soon or too late and leaving potential cost savings on the table. The other is implementing SOA incorrectly (that is, without Web services), which may tie an organization to obsolete proprietary technology.

The SOA Sweet Spot

Not every enterprise needs an SOA--at least, not yet. The incumbent IT architecture has a big influence on deciding when and how to migrate to an SOA. For example, if an organization is mainly an SAP shop, how should it begin using Web services and building an SOA?

SAP is headed in a services direction with its NetWeaver solution, which can affect how it fits into and supports an SOA. NetWeaver enables SAP's Enterprise Services Architecture, which is a combination of a standards-based application server, an integration server, and a Web services stack. Organizations implementing NetWeaver are ideal candidates for a move to an SOA, with NetWeaver at the SOA's center.Another common scenario is an organization with a mixed J2EE and .NET architecture dominated by custom-developed software and legacy mainframe applications. In this case, SOA can be implemented as a single unifying architecture, abstracting Web services from the specific platforms that the original applications were developed in.

In general, the sweet spot for an SOA is typified by the following incumbent architectures:

* A mixed architecture consisting of a roughly equal ratio of J2EE and .NET platforms, with a need to unite these environments.

* A heterogeneous architecture with a diverse application portfolio (for example, multiple ERP applications or a variety of legacy systems) and a need to aggregate customer and supplier information into a self-service portal.

* A diverse application portfolio with significant investments in EAI solutions driven by portal initiatives, customer or employee self-service initiatives, or business intelligence requirements.* A legacy architecture dominated by several mainframe applications, whose useful life must be extended.

* An ERP-dominant architecture with requirements for supplier, partner, and customer collaboration.

In all of these scenarios, an SOA is a way to unify heterogeneous architectures, integrate diverse applications, leverage existing IT and software assets, and enable IT flexibility. Creating a services overlay will generate rapid and ongoing cost savings.