Tactical Guidelines, M. Pezzini Research Note 23 September 2002 Best Practices for Deploying Web Services via Integration Web services can assemble application logic into coarsegrained business services. Experience developing serviceoriented architectures suggests that an incremental approach will minimize risks and maximize ROI. Core Topics Application Integration and Middleware: Application Integration Internet Platforms and Web Services: Web Services and Dynamic Business Webs Key Issues How will enterprises meet the challenge of integrating Web-based applications with enterprise systems? What are Web services, and how is this approach different from previous approaches? Tactical Guidelines Enterprises should adopt an incremental approach to develop Web services components based on a four-step model: 1. Planning and design 2. Component construction 3. Services assembly 4. Insertion in the deployment environment Enterprises hope Web services will allow a variety of business participants partners, suppliers, customers and employees to seamlessly hook into the enterprise's business processes from within their own application systems. This is technically possible, thanks to Web services' ability to encapsulate business services. Web Services, Service-Oriented Architecture (SOA) and Pseudo-SOA Using SOA, Web services wrap pre-defined, normalized services indivisible software modules incorporating a specific business functionality (for example, "account" and all the associated functions, such as create, delete and update) and exposing a well-defined access interface that run on a single application server or transaction-processing monitor. Often, either for technical or business reasons, enterprises find it useful to wrap multiple SOA and non-soa applications into Web services interfaces. In this case, invoking a Web service for example, receiving a Simple Object Access Protocol (SOAP) message would trigger a multistep business process spanning multiple applications and systems, inside and, at times, outside the enterprise. An architecture in which services are implemented through wrapping and composition of non-soa applications can be characterized as "pseudo-soa." From a consumer perspective, a pseudo-soa Web service looks like a regular service, but from a runtime perspective, it is not a single software module but the coordinated flow of multiple software modules. Also, in a fully SOA-compliant environment, it may make sense to package multiple indivisible services and expose them through a single Web services interface as if they were actually an indivisible entity. Gartner Entire contents 2002 Gartner, Inc. All rights reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.
In SOA and pseudo-soa contexts, Web services that integrate pre-existing business logic are often defined as "composite Web services." Note that, in this context, we consider the runtime, not development time, composition of business logic. At design time, a composite Web service is represented by its interface and the description of the actions that must be executed when the service is invoked. Those actions will include calls to existing applications, interface mappings, message transformation and exception handling flows. At runtime, composite Web services manifest themselves as the execution of actions according to the specified flow. Scale of Composite Web Services Projects Nowadays, users are mostly experimenting with Web services technology and composite Web services implementation in small-scale, opportunistic projects. The number of published Web services in these cases is often fewer than 10 and, in most cases, no more than 20 or 30. Informal design and development processes can easily maintain such a limited number of Web services. However, as Web services use scales up to larger, system-oriented projects, users will have to deal with lots more composite Web services, perhaps hundreds. This will require more-rigorous processes to avoid overlapping efforts and enforce reuse of already-implemented components. It will also involve changing management and maintenance processes. Enterprises have been implementing SOA and pseudo-soa applications for many years, well before the emergence of Web services technology. However, SOA and pseudo-soa never became mainstream approaches because of their complexity, which was exacerbated by the lack of commonly agreed-on standards and poor support from development tool vendors. However, because of its popularity, widespread vendor support and the availability of tools, Web services technology is making SOA and pseudo-soa increasingly popular. Users will therefore be challenged to set up composite Web services implementation processes capable of scaling from small, opportunistic projects to large-scale, business-critical endeavors. A new discipline services-oriented development of applications (SODA; see "Service-Oriented Development of Applications: SODA Pops") is emerging to help enterprises in their efforts to address the challenge of developing new applications by leveraging services in SOA and pseudo-soa contexts. An Incremental Approach to Composite Web Services Enterprises can reuse the past experience in developing pre- Web-services composite applications and services to lay the foundation for a SODA-based incremental approach to 23 September 2002 2
composite Web services implementation. This approach is based on four main steps (see Figure 1). Figure 1 Incremental Approach to Composite Web Services 1. Planning and Design 2. Component Construction 3. Services Assembly 4. Insertion in the Deployment Environment Web Service Composite Application Mobile Application Source: Gartner Research 1. Planning and Design This step is the hardest. Application architects, possibly jointly with business analysts, have to figure out which collection of services is required, their granularity and their interface that is, the formal description of the actions each service can implement and that service's input, output and exception-handling data. Experience shows that designing a full set of enterprisewide services is a lengthy and cumbersome process. Such an effort is difficult to justify from a return on investment (ROI) standpoint and may cause resistance within the enterprise because of its overwhelming complexity. Successful service-oriented composite application projects have typically adopted a more pragmatic approach, based on the initial design and then development of the services needed to support a limited set of requirements. The 23 September 2002 3
initial set, usually from few services up to 40 or 50, is then expanded over time. These services are usually of a rather coarse granularity for example, buy stock, input purchase order, create a new customer position. Requests for new services in a specific business domain, such as front-end applications for retail banking, tend to plateau between 400 and 500 services, although some users have reached as many as 900 or 1,000. 2. Component Construction Once application architects have designed the functional characteristics of a given set of services, developers must decide how to implement those functions in terms of basic components. A basic component is the smallest meaningful unit of deployment from a technical point of view. Some of them will be already available in the form of pre-existing Customer Information Control System (CICS) or Information Management System (IMS) transactions, Tuxedo services, stored procedures, Common Object Request Broker Architecture (CORBA) objects,.net assemblies or Enterprise JavaBeans (EJB). These need only to be wrapped into a proper interface for reuse. Other components will need to be implemented from scratch, using.net, Java 2 Platform, Enterprise Edition (J2EE), CICS, Tuxedo, ABAP/4 or any other platform developers prefer. Thus, to construct the needed array of basic components, developers will use such low-level technology as communication middleware, adapters, screen scrapers, gateways, application servers and integrated developer environments, so appropriate skills are required. 3. Services Assembly After component construction, basic components are then assembled into coarser-granularity business services. Often in the past, components have been assembled by custom coding, using a third-generation programming language or a scripting language such as Java Server Pages or Active Server Pages, the so-called "orchestration" or "choreography" logic. Services assembly through custom code can be difficult and requires specific skills, although it is a less sophisticated process than those required to construct components. Therefore, enterprises are increasingly considering moreproductive tools that can be used by less technically skilled and more business-oriented developers. Enterprises will increasingly adopt rules engines, programmatic integration servers, business process managers (BPMs) and integration brokers to assemble services requiring complex orchestration of large numbers of 23 September 2002 4
basic components. Once an enterprise has assembled a service and implemented its interface, it is relatively straightforward to publish it as a Web service (or through any other interface standard) regardless of the assembly platform used. Tools are available to map EJB, CORBA, Distributed Component Object Model (DCOM) or CICS interfaces into Web Services Description Language (WSDL). Moreover, BPMs, programmatic integration servers and integration brokers usually allow users to publish entire business processes as Web services. 4. Insertion in the Deployment Environment Once assembled, a service has to be deployed on a runtime platform capable of executing the orchestration logic, invoking encapsulated business logic and running new components. Depending on the assembly and construction strategies, such a platform can be as simple as a basic application server, or it can be an integration server, or a complex infrastructure combining communication middleware, adapters, integration brokers, application servers and business process managers. Such an infrastructure is usually referred to as the enterprise nervous system (ENS). It's crucial for service developers to cooperate with the enterprise's application integration competency center throughout the development process, and not just during deployment, to ensure ENS compliance and integration, and manageability of the chosen set of runtime platforms. Once deployed, the Web service is ready to be "consumed" by any qualified Web services consumer application. Acronym Key BPM Business process manager CICS Customer Information Control System CORBA Common Object Request Broker Architecture DCOM Distributed Component Object Model EJB Enterprise JavaBeans ENS Enterprise nervous system IDE Integrated development environment IMS Information Management System J2EE Java 2 Platform, Enterprise Edition ROI Return on investment SOA Service-oriented architecture SOAP Simple Object Access Protocol WSDL Web Services Description Language Typically enterprises have so far assembled together all the development tools needed to support the process described above by selecting products for example, integrated development environments (IDEs), adapters, modeling tools and workflow from multiple vendors. In the future, most of these tools plus additional functionality for example, to support modeling, variability and rapid application maintenance will be packaged together in an emerging class of products called Web services producer platforms (see "Producer Platforms and SODA Will Shift the AD Approach"). Bottom Line: Developing composite Web services is not a new discipline: It builds on SOA and pseudo-soa development practices. Users should pragmatically adopt, and adapt to their needs, an incremental, service-oriented development approach and gradually build the appropriate software infrastructure. This will help them minimize technical risks and rapidly demonstrate business benefits. 23 September 2002 5