Making_the_Transformation_to_SOA by usvoruganti


									Making the Transformation to Service-Oriented Architecture
Capitalizing on the Next Revolution in IT January 2005

THE NEXT REVOLUTION IN INFORMATION TECHNOLOGY ................................................ 3 GROWING MOMENTUM .......................................................................................................... 3 REAL BUSINESS BENEFITS .................................................................................................... 4 THE ROLE OF WEB SERVICES ................................................................................................ 6 MAKING THE TRANSFORMATION TO SOA ........................................................................... 7 BUILDING-BLOCK SERVICES .................................................................................................. 7 SERVICE-ORIENTED ARCHITECTURE INFRASTRUCTURE .......................................................... 9 SERVICE-BASED BUSINESS SOLUTIONS ............................................................................... 10 CHOOSING A STRATEGIC SOLUTION PROVIDER.............................................................. 12

©2005 webMethods, Inc. All rights reserved.

Page 2

Businesses are looking to service-oriented architectures (SOA) as the best way to leverage their Information Technology (IT) assets and to provide their organizations with the agility needed to be competitive in today’s economy. This white paper explores why service-oriented architecture has emerged as one of the most significant developments in IT, and is followed by an overview of how businesses can make the transformation to service-orientation.

Growing Momentum
There is a remarkable consensus on the importance of SOA. Customers, vendors and analysts are united in the conviction that SOA is the dominant theme in IT today. Consider that: In an April 2003 report, Service-Oriented Architecture: Mainstream Straight Ahead, Gartner, Inc. predicted that “by 2008, SOA will be the prevailing software engineering practice, ending the 40-year domination of monolithic software architecture (0.7 probability).” An article in the October 2003 edition of CIO Magazine noted that over 50% of clients in a survey were already engaged in some form of SOA development. A report in the Wall Street Journal in November 2003 noted that 85% of large North American companies planned to use Web services in the coming year. A March 2004 survey of 100 CIOs by Smith Barney found that service-oriented architecture was their number one priority in the area of emerging technologies. Almost every software vendor on the market has claimed some association with service-oriented architecture (some more legitimately than others). But what exactly is “service-oriented architecture,” and why has it generated such interest? Quite simply, SOA is an approach to software design (“architecture”) where applications are assembled from reusable components (“services”). A service is a software building block that performs a distinct function – such as retrieving customer information from a database – through a well-defined interface (basically, an electronic description of how to call the service from other programs). SOA differs from other forms of computing in a few fundamental ways. First, software is organized into modular components. This is not a novel concept, but the difference with SOA is that the components, or services, are loosely coupled. Loose coupling is significant because it underlies the flexibility behind SOA. Loose coupling means services can be linked together dynamically at run-time, with few dependencies on how the services are actually implemented. For example, a company could create a “Customer Lookup” service to return information about a customer. With an SOA, any application needing customer information would be able to find, link to, and call the Customer Lookup service, regardless of whether the service was built using the same or different programming technologies as the calling application. Tight coupling, in contrast,

©2005 webMethods, Inc. All rights reserved.

Page 3

results when there are dependencies between software modules that are designed, coded, or compiled into application programs. Loosely coupled services can be linked together easily and quickly as business requirements demand. Tightly coupled systems are less flexible, usually involving recoding or recompilation when interdependent components are modified. Tight coupling makes it hard for applications to adapt to changing business requirements. An important consequence of loose coupling is that services can run anywhere on the network and they are not restricted to a specific hardware or software platform or programming language. In an SOA, services can (and in many cases will) originate from different technology suppliers. Tightly coupled systems, on the other hand, usually involve a commitment to a specific software environment, which creates interoperability issues when different platforms need to be integrated. The second defining feature of SOA is that services exist as two distinct elements – a well-defined service interface and the service implementation. The service interface describes how to call the service, specifying, among other things, where the service is located and the format of input/output parameters. The service interface is what provides another program with the information it needs to make a request to the service and get a response. The Customer Lookup service interface, for instance, might specify different ways of querying customer information (by customer id, by customer name, etc.), and the structure of the customer data that is returned by the service. The service implementation is the actual code that fulfills the functionality of the service. It is the logic that resides on a computer somewhere on the network and executes when called (subject, of course, to appropriate security constraints). Unlike the service interface, which is defined in a neutral format, the service implementation is inherently platform-dependent. SOA is not concerned with how services are implemented – architecturally-speaking it doesn’t matter, for example, whether the Customer Lookup service is written in Java or COBOL – only that a service fulfills the behavior specified by its interface. Finally, SOA is implicitly about business-oriented services versus lower-level technical functions (for example, of the type found in traditional application programming interfaces). Whether a service involves looking up customer information, checking inventory levels, or verifying a credit card transaction, the point is to encapsulate a logical unit of functionality that can be reused across business applications. A key aspect of SOA is that services can be comprised of other services, which makes it possible to assemble higher-level composite services that map to entire business processes (processing a purchase order, for example).

Real Business Benefits
But aside from its technical appeal, why are companies so upbeat about SOA? One explanation is that corporations are looking to bring structure to an increasingly chaotic IT environment and to better equip themselves for change. The past decade has seen unprecedented leaps in computing. Computers are applied to ever more aspects of

©2005 webMethods, Inc. All rights reserved.

Page 4

the business. Additionally, the Internet has extended system interfaces to include connections with trading partners. Not surprisingly, the combination of these factors has resulted in an unruly explosion of stovepipe applications, databases, and electronic connections. The challenge for IT today is to create and support an infrastructure that is capable of harnessing these diverse assets, and to deliver on new business requirements more effectively than with previous approaches. SOA provides the basis for this infrastructure and the promise of tangible business benefits. Ultimately, the value proposition is that SOA helps companies to be more agile and to do more with the resources that they already have.


BUSINESS BENEFITS Increases organizational agility; allows companies to easily assemble and modify business processes in response to market requirements Provides a competitive advantage by offering greater flexibility in the way computer systems can be used to support the business Lowers implementation costs by increasing reusability; services can easily be shared across multiple applications Increases IT adaptability; changes—resulting from mergers, acquisitions, package application implementations, etc.—are integrated more easily Enables incremental development, deployment, and maintenance; avoids the need to do costly and risky “big bang” software implementations

Loosely coupled

Modular approach

Decreases development effort by reducing complexity (through a “divide and conquer” approach) Over time, accelerates deployment of new application functionality; process becomes mostly assembly (of existing services) versus mostly new development Allows existing investment in IT assets to be leveraged


Lowers risk and development effort; avoids the need to rewrite and test existing applications Platform independence allows companies to use the software and hardware of their choice


Allows companies to engage in a multi-source strategy, reducing threat of vendor lock-in Reduces complexity and fragmentation resulting from use of proprietary technologies Lowers training requirements; increases available labor pool

General purpose technology

Delivers economies of scale; same technology can be applied to address a broad range of business problems

©2005 webMethods, Inc. All rights reserved.

Page 5

The Role of Web Services
The ideas behind SOA – modularization, platform independence, etc. – are not new. Prior technologies have promoted many of the same principles, but failed to achieve the status of SOA. So why has SOA gained so much traction? The answer is Web services. In theory, SOA does not require Web services, and simply implementing Web services does not necessarily result in an SOA. In reality, however, SOA and Web services are inexorably linked, and it is their synergy that is driving service-orientation into the mainstream. On the one hand, Web services – which are simply services that use specific XML-based protocols and interface descriptions to communicate – provide the standards upon which today’s SOAs are being built. Of these, the key standards are: SOAP (Simple Object Access Protocol), which deals with how an application calls a Web service to perform an operation and return an answer WSDL (Web services Description Language), which is the XML-based format used to define the interface to a Web service UDDI (Universal Description, Discovery and Integration), a directory for Web services that lets applications find out what services are available to them On the other hand, SOA principles are directing the maturation of Web services with the qualities expected of a good architecture – reliability, security, and so on. As a result, additional standards now exist, or are in the process of being developed, to enable Web services to fulfill the true promise of SOA.

Example of a Web service call within a business process flow. SOAP is used to call the “Inventory” Web service. WSDL is used to define the interface to the service

Figure 1. Example of a Web service in a business process As important as the standards, however, is the near-universal adoption of Web services by the software community and corporations. Few other technologies— perhaps only TCP/IP and HTML/HTTP— have gained the same level of support in such a short time and by such a range of enterprises. Perhaps more than anything else, this points to the impact that Web services and service-oriented architecture will have on the future of IT.

©2005 webMethods, Inc. All rights reserved.

Page 6

So how does a company make the transformation—and capitalize from the shift—to Service-Oriented Architecture? At a high level, there are three fundamental considerations: First, there is the value of either creating (from scratch) or exposing (from existing resources) the services that then become the reusable building blocks for new service-based applications and business processes. As the availability of services increases, so the benefits of reusability and quicker time-to-market compound, delivering ever-increasing business value. Second, for reasons that will be explained further, the availability of services alone does not fulfill the requirements of SOA. There is the need for an infrastructure that exists externally to the services—for example, to increase reliability, provide a layer of manageability, and address cross-service requirements such as transaction management and security. This infrastructure is critical to the success of SOA in a corporate setting. Third, the end goal of service-orientation is not about creating services or even establishing an SOA infrastructure. Rather, it is about enabling a new breed of dynamic, service-based capabilities that will provide organizations with a competitive advantage in the way they conduct business. With the right capabilities in place, corporations will be able to integrate systems more quickly, connect to trading partners more easily, increase the efficiency across all aspects of their operations, get better visibility into their business, and be more agile in their ability to respond to market pressures and opportunities.

Building-Block Services
The first and most obvious components of an SOA are the atomic business-oriented services – verify credit card, check inventory, and so on – upon which more-sophisticated capabilities can then be layered. Services can originate in several ways: Services can be written from scratch. This might be an appropriate choice for companies that are developing a brand new system or rewriting an application. Most modern programming environments and development tools offer a way to build Web services, though they vary tremendously in their ease of use. The advantage of a fresh start is that services can be designed in a way that maximizes the opportunity for reuse. Compared to the other approaches, however, doing anything from the ground up usually involves the most effort. Existing code can be made service-oriented (for example, converting a CORBAbased client/server application to use Web services standards). This is feasible with custom-developed applications that may have been designed in a modular way, but were not implemented using Web services technologies. The advantage of this approach is that if only the interface logic is changed, the

©2005 webMethods, Inc. All rights reserved.

Page 7

underlying business rules don’t have to be fully retested, lowering the conversion cost. Existing applications or processes can be “wrappered” to provide them with a Web service interface. There are several advantages to the wrappering approach. First, it is non-intrusive, which means there is no need to modify (and thus retest) the underlying system itself. Secondly, it can be done at any level of granularity, from creating a service for something as simple as a database lookup to wrappering an entire order-entry process as one service. Lower-level services can also be aggregated very easily into higher-level processes if desired. Third, in most situations this is the fastest and most robust path to bringing existing resources into the service-oriented world and, therefore, it offers the potential for the best return on investment. Finally, with package applications in which you do not have access to the source code, this may be the only feasible path to service-enabling a system. Services can be acquired. More and more package applications and systems are shipping with “out-the-box” Web services support. The major ERP and CRM vendors, for example, have either converted their Application Programming Interfaces (APIs) to Web services, or will offer a Web services-based API as another option alongside their proprietary APIs. Services may be sourced from third parties, where there is business value to having an external vendor provide the function performed by the service (for example, credit rating).

Figure 2. Web service-enabling IT resources A fundamental pillar of SOA is that services are technology neutral (i.e. it does not matter what technology a service is written in). Independent of the language used to implement a service, services are exposed and communicate in a standard manner that makes them interoperable. This is a defining difference of Web services-based SOA that makes Web services more “reusable”—and, therefore, more likely to deliver the associated benefits— of preceding technologies.

©2005 webMethods, Inc. All rights reserved.

Page 8

Service-Oriented Architecture Infrastructure
Now, as mentioned earlier, simply making a collection of Web services available on the network does not make an SOA. In fact, the unmanaged proliferation of Web services will quickly result in a chaotic mix of systems and interfaces, which is not unlike the situation that companies have faced with other technologies. To bring order to this potential chaos requires some level of SOA infrastructure. As an inherently distributed model, this SOA infrastructure must logically exist between service providers, rather than within individual service providers themselves.

Figure 3. The need for an enterprise SOA infrastructure This infrastructure exists to provide manageability and ensure consistent levels of quality of service, security, scalability, performance, and so on, for the individual service providers connected to the infrastructure. Among other things, it also provides for cross-provider metadata management (registry services, discovery services, etc.), and ensures loose coupling of the business-oriented services by allowing location transparency and dynamic binding. As the thing that binds services together, the infrastructure is also in a unique position to provide monitoring and management capabilities that span the entire service provider domain.

©2005 webMethods, Inc. All rights reserved.

Page 9

An enterprise-class SOA infrastructure should fulfill the following needs: Promote architectural consistency by ensuring that Web services are deployed in a manner that is consistent with a service-oriented model. Facilitate the assembly of large-scale, dynamic systems from Web services. Provide a central point of management and monitoring of deployed services. Deliver the performance and robustness required for business-critical systems through features such as load-balancing and automatic fail-over between services. Provide mechanisms whereby services can easily locate each other, regardless of where they are deployed in the network. Provide a framework for creating and deploying infrastructure services (services that function between business-level services, e.g. transformation, filtering). Allow services to be provisioned dynamically as business needs fluctuate. Provide security across services, addressing needs such as client authorization. Offer various levels of logging—for example, Web services requests and responses, session-related information, security events, etc.—to support trend analysis, exception handling, and problem diagnosis. Ideally, these SOA infrastructure services should be non-intrusive to the services themselves, and capable of operating either natively within supported platforms (such as an application server) and as intermediaries for non-supported platforms (such as a package application or service hosted by a third party). With this flexibility, an SOA infrastructure is able to bring all the services in a company’s environment under a single management scope.

Service-Based Business Solutions
With business processes exposed as componentized services, and an SOA infrastructure in place to manage them, companies are then positioned to capitalize on a serviceoriented approach to their business solutions and applications. Some of the biggest opportunities are described below. While some of these pre-date the shift to Web services and service-orientation, they are significantly enhanced when able to leverage the capabilities offered by an SOA. Business integration. While companies have been using business integration (EAI and B2B) solutions with great success independently of SOA, these solutions take on a much more significant and valuable role when they are plugged into the SOA infrastructure. With the right business integration solution, companies get the ability to extend their legacy (non SOA) systems into the SOA universe. With so much investment tied up in existing systems, this is the most expedient and cost-effective path to populating an SOA with the standards-based services that BPM tools, portals, and other service-based applications can leverage. The move to services also benefits downstream business integration initiatives through reusability and the reduced cost and complexity resulting from standardization.

©2005 webMethods, Inc. All rights reserved.

Page 10

Business Process Management (BPM). BPM and SOA enjoy a natural synergy. BPM is about executing well-defined tasks in an organized fashion. SOA is about exposing application and system functionality as well-defined business services. The tasks in BPM correspond to the services exposed in an SOA. When implemented in a top-down fashion (i.e. driven by BPM), the services that are developed to support one business process become available to be reused in other processes when they are deployed in an SOA. When implemented bottom up (i.e., the priority is on creating atomic services), the services in an SOA become part of the inventory that can be reused to accelerate future BPM implementations. Furthermore, flexibility arises from the fact that business process flows and the services they use are implemented separately, allowing the best tool (or set of tools) to be used for each purpose. As a result, with the underlying support of an SOA, companies can achieve the benefits of BPM more quickly. Business Activity Monitoring (BAM). BAM enables companies to become more responsive to significant events, changes and problems in their business. SOA serves the needs of BAM by providing visibility into business processes and a uniform way to access information from across the enterprise. BAM also has many obvious synergies with BPM and EAI/B2B. Like, BPM, BAM is centered around business processes. With the right infrastructure, processes that are orchestrated in an SOA automatically become candidates for BAM. EAI/B2B services provide the means to access data within existing systems, while infrastructure services within the SOA can be used to channel this data in realtime to the BAM solution. Because of these inter-dependencies, an SOA solution that combines BPM, integration, and BAM offers significant economies of scale. Composite Applications. As the inventory of business-oriented services within an SOA grows, it becomes increasingly easier to assemble custom applications to meet new business needs, or to create personalized applications for specific user requirements. Instead of building applications out of database calls and other proprietary APIs, SOA-based composite applications are able to use standard Web services. Furthermore, the abstraction provided by SOA— meaning the low-level technical details of a Web service implementation are hidden—empowers relatively non-technical staff to get involved in the construction of composite applications. While the path to service-orientation has been presented as sequential steps, the reality is that different companies will advance along the three fronts in different ways. Some companies will wet their feet with Web services before putting an enterprise SOA infrastructure in place, while others might take a more architectural approach and defer tactical Web services deployment. Other companies might look to their existing EAI or B2B capabilities as the starting point to SOA. Whatever the strategy, one of the advantages of SOA is that it can be implemented incrementally for example, on a project-by-project basis. Big bang implementations are not necessary to start reaping the rewards.

©2005 webMethods, Inc. All rights reserved.

Page 11

When choosing a solution provider to support your company’s adoption of SOA, it is helpful to consider the following points: SOA is not new, but some vendors are new to SOA. webMethods has an unparalleled track record in Service-Oriented Architecture, dating back to 1997 when we submitted a proposal to the World Wide Web Consortium (W3C) for a standard way for applications to interact across the Internet using a service-oriented architecture. This experience is reflected in our integration server, the most mature SOA-based product of its kind. SOA does not come free. The business benefits of SOA—reusability, lower cost of integration, increased ability to respond quickly to market conditions with supporting applications and processes, etc.—will not accrue without some form of SOA management infrastructure. webMethods was the first major integration vendor to incorporate SOA infrastructure capabilities – based on a Web services Enterprise Service Bus (ESB) – into the core of its product. The webMethods solution supports all the SOA infrastructure functions described in this white paper (and more). SOA is closely associated with Web services. The vendor of choice should have strong support for Web services and the related standards. webMethods is highly active on the Web services front, as evidenced by our involvement in various standards bodies, our seat as the only pure-play integration on the board of the Web Service Interoperability Group, and the recognition from firms such as Gartner for our influence in, and product support for, Web services. SOA is not the ultimate end goal. Businesses are implementing SOA because of the advantage that it provides in meeting higher-level requirements. Vendors that lack the functionality to support these needs can only offer limited value. In webMethods Fabric, webMethods offers the most comprehensive SOA-based business integration suite on the market. webMethods Fabric’s business process management and optimization and its composite application assembly capabilities allow companies to take advantage of the underlying Web services platform in building solutions that have real business value. Businesses have lost their appetite for big bang, silver-bullet solutions. An investment in SOA is hard to justify unless the implementation can be achieved incrementally, with demonstrated ROI along the way. With its strong integration origins, webMethods Fabric allows companies to “leave and layer” their existing IT assets while making them available as Web services with almost no incremental effort. This offers a quick, low risk path to SOA, with benefits accruing as a side effect at the same time that companies are addressing specific business requirements. To learn more about how webMethods allows companies to use SOA to increase Business Process Productivity, please visit

©2005 webMethods, Inc. All rights reserved.

Page 12

ABOUT WEBMETHODS, INC. webMethods is a leading provider of business integration software to the Global 2000 and large government agencies. Our technology lets our customers integrate, assemble and optimize available IT assets to drive business process productivity. Currently, more than 1,200 customers are meeting customer demands, reducing costs, creating new revenue opportunities and reclaiming ROI. Faster. webMethods is headquartered in Fairfax, Va., with offices throughout the United States, Europe, Asia Pacific and Japan. More information about the company can be found at NASDAQ: WEBM.
Copyright © 2005 webMethods, Inc. All rights reserved. Trademarks The webMethods logo, Get There Faster, Smart Services and Smart Processes are trademarks or registered trademarks of webMethods, Inc. Other product names used herein may be trademarks or registered trademarks of webMethods or other companies. Statement of Conditions webMethods, INC. PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OR CONDITIONS OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL WEBMETHODS BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF BUSINESS, LOSS OF USE OR DATA INTERRUPTION OF BUSINESS, OR FOR INDIRECT, SPECIAL, PUNITIVE, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY KIND, EVEN IF WEBMETHODS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES ARISING FROM ANY DEFECT OR ERROR IN THIS PUBLICATION OR IN THE WEBMETHODS SOFTWARE. webMethods, Inc. may revise this publication from time to time without notice. Some states or jurisdictions do not allow disclaimer of express or implied warranties in certain transactions; therefore, this statement may not apply to you. All rights reserved. No part of this work covered by copyright herein may be reproduced in any form or by any means—graphic, electronic or mechanical— including photocopying, recording, taping, or storage in an information retrieval system, without prior written permission of the copyright owner. European Headquarters Barons Court 20 The Avenue Egham, Surrey TW20 9AU United Kingdom Tel: 44 0 1784 221700 Fax: 44 0 1784 221701 Worldwide Headquarters 3877 Fairfax Ridge Road South Tower Fairfax, VA 22030 USA Tel: 703 460 2500 Fax: 703 460 2599

US West Coast 432 Lakeside Drive Sunnyvale, CA 94088 Tel: 408 962 5000 Fax: 408 962 5329

Asia-Pacific Headquarters Level 15 Philips Building 15 Blue Street North Sydney NSW 2060 Australia Tel: 61 2 8919 1111 Fax: 61 2 8920 2917

webMethods Japan KK Izumi Garden Tower 30F 1-6-1 Roppongi, Minato-ku Tokyo 106-6030 Japan Tel: 81 3 6229 3700 Fax: 81 3 6229 3701

RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the U.S. government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 (October 1988) and FAR 52.227-19 (June 1987).

©2005 webMethods, Inc. All rights reserved. The webMethods logo and Get There Faster are trademarks or registered trademarks of webMethods, Inc. All other names mentioned are trademarks, registered trademarks or service marks of their respective companies.

To top