Read Web Services text version


December 2001

Copyright © 2001 webMethods, Inc. All rights reserved. Trademarks The webMethods logo is a registered trademark of webMethods Inc. Other product names used herein may be trademarks or registered trademarks of webMethods or other companies. Statement of Conditions WEBMETHODS SOFTWARE CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT 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, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY KIND, EVEN IF WEBMETHODS HAS BEEN ADVISED OF THE POSSIBLITY 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. 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).


INTRODUCTION................................................................................................................. 4 WEBMETHODS: A LONG TRACK RECORD IN WEB SERVICES ................................................ 4 ABOUT THIS DOCUMENT .................................................................................................... 5 WEB SERVICES: AN OVERVIEW..................................................................................... 6 DEFINING WEB SERVICES .................................................................................................. 6 WEB SERVICES: THE PROMISE........................................................................................... 6 WEB SERVICES: THE STANDARDS ...................................................................................... 7 Simple Object Access Protocol (SOAP) ...................................................................... 8 Web Services Description Language (WSDL)............................................................. 8 Universal Description, Discovery, and Integration (UDDI) .......................................... 8 WEB SERVICES AS ARCHITECTURE .................................................................................... 9 WEB SERVICES AND INTEGRATION .................................................................................... 10 IMPLEMENTATION CONSIDERATIONS ................................................................................. 11 THE WEBMETHODS WEB SERVICES SOLUTION ....................................................... 13 CONTINUING WEB SERVICES LEADERSHIP ........................................................................ 13 COMPONENTS OF THE WEBMETHODS SOLUTION ............................................................... 13 WEB SERVICES USE PATTERNS ....................................................................................... 15 Exposing Back-End Enterprise Systems as Web Services....................................... 15 Exposing Corporate Business Processes as Web Services ..................................... 16 Integrating Web Services into Corporate Business Processes ................................. 16 MANAGING WEB SERVICES IN THE WEBMETHODS PLATFORM ............................................ 16 CUSTOMER BENEFITS ...................................................................................................... 17 CONCLUSION .................................................................................................................. 18 ABOUT WEBMETHODS, INC.......................................................................................... 19

©2001 webMethods, Inc. All rights reserved.

Page 3


Web services, with their promise to fundamentally transform the way that companies do business over the Internet and delegate computing services, have caught the attention and imagination of the entire industry. More than just a passing trend, many observers believe that Web services have the power to revolutionize distributed computing by enabling interoperability on levels never achieved before, resulting in significant cost and efficiency benefits to users. In recent months, the necessary standards to turn Web services into a technical reality have solidified, paving the way for software vendors to offer Web services capabilities in their products. Although some areas remain undefined, particularly in the areas of proper security, companies can now begin to explore the potential of Web services in their own environments. As the leading provider of integration software and a strong proponent of open standards, webMethods has taken an early lead in supporting Web services. The webMethods integration platform provides the foundation for the deployment of enterprise Web services ­ Web services that are integrated seamlessly into end-to-end business processes across the enterprise, that are supported by robust management capabilities, and that naturally leverage and extend the value of existing applications. webMethods provides true Web services value by allowing customers to: Expose existing back-end applications or higher-level business processes as Web services for internal and external application access Reuse previously developed webMethods services into Web services Link internal and 3rd party Web services into their automated business process flows Leverage new Web services-based application interfaces to accelerate implementation of integration solutions Manage Web services as part of their overall integration infrastructure webMethods' out-the-box capabilities enable organizations to fully participate in the emerging Web services technology trend.

webMethods: A Long Track Record in Web Services

webMethods' support for Web services builds on the company's pioneering initiatives in this arena, which began long before the term "Web services" came into vogue. When it launched its business-to-business server in 1996, webMethods led the way in applying Internet and XML technologies to customers' business needs, allowing them to expose back end system services as methods that could be invoked over the Web via an XML-based protocol (hence the company's name). A year later, webMethods submitted to the World Wide Web Consortium (W3C) a specification for a Web Interface Definition Language (WIDL), a meta-language for implementing service-based architectures over

©2001 webMethods, Inc. All rights reserved.

Page 4

the document-based resources of the Web. WIDL was the conceptual pre-cursor to Web services Definition Language (WSDL), now a prominent Web services standards. Today, webMethods continues to further Web services with its involvement in W3C and Java Community Process working groups and by applying its significant expertise to the standards-setting process. Recently, for example, webMethods co-submitted extensions to SOAP to deal with attachments. With its integral Web services capabilities, the webMethods integration platform enables companies to meet the full range of business integration requirements with a single globally scalable and extendable infrastructure. The platform's unified architecture leverages the open standards of the Internet to integrate disparate information resources and to connect customers and suppliers, while providing end-to-end transactional integrity, security, and reliability. By deploying the webMethods integration solution, companies are able to reduce operating costs, create new revenue opportunities, strengthen relationships with customers, substantially increase supply chain efficiencies, streamline internal business processes, and achieve a greater return on their information technology investment.

About This Document

This document is targeted at customers who want to learn more about the Web services technologies, the business potential of Web services, and how webMethods enables organizations to enable enterprise-level Web services. It also establishes why webMethods' leadership in Internet and XML standards-based computing makes the webMethods integration platform the best solution for addressing the real-world requirements of Web services deployment. For a more detailed technical overview of the Web services standards, see the webMethods white paper, Demystifying Web Services. If you have further questions about webMethods' Web services capabilities or general questions about webMethods' solutions and services, please send an email to [email protected] You can also find information on the webMethods web site at

©2001 webMethods, Inc. All rights reserved.

Page 5


Despite, or perhaps because of, the hype around Web services, making sense of it all can be a challenge. This section seeks to demystify the topic by offering working definitions of Web services, reviewing the benefits, providing an overview of the relevant standards, and exploring issues that should be considered in Web services deployment.

Defining Web Services

Not surprisingly, given how rapidly the sector is evolving, there is no universally accepted definition of "Web services". Gartner Group defines Web services as: Loosely coupled software components that interact with one another dynamically via standard Internet technologies. In contrast, Forrester Research defines Web services somewhat abstractly as: Automated connections between people, systems and applications that expose elements of business functionality as a software service and create new business value. Put into more tangible terms, Web services are building blocks for creating open distributed systems. A Web service is a collection of functions that are packaged as a single unit and published to the network for use by other software programs. Simple examples of Web services include a credit checking service or a package tracking service. Web services can aggregate other Web services to provide higher-level functionality, for instance, a complete order management service, in true business process collaboration.

Web Services: The Promise

Web services promises to revolutionize business process collaboration by enabling the next generation of composite systems. Web services' potential is driven by the following: Interoperability. Web services can be written in any language, and any Web service can interact with any other Web service. Interoperability among disparate software systems is not a new challenge, but many past attempts at solving the problem ­ including CORBA, COM ­ have met with limited success because of a lack of standardization or broad support. Industry Support. Web services address the interoperability issue by having the widest industry support from the start. Every major software vendor has endorsed Web services, the SOAP standard, and surrounding Web services technologies. Ubiquity. Just as industry support is key to interoperability, interoperability will drive the ubiquity of Web services. Furthermore, since Web services communicate using basic protocols such HTTP and XML, any platform that supports these technologies can both host and access Web services. Low entry cost. The broad support for Web services, coupled with the relative simplicity of the underlying technologies and the availability of development toolkits, has made cost-effective implementation possible.

©2001 webMethods, Inc. All rights reserved.

Page 6

Web Services: The Standards

From a technology point of view, Web services is about connecting disparate software systems using a set of standard protocols in a way that enables seamless information and process flow among the different systems. Web services define four logical protocol layers to achieve this seamless integration: Transport, Messaging, Data Definition, and Process Definition. The table below shows how these layers map to the specifications usually associated with Web services.

WEB SERVICES LAYER Process Definition (document, workflow, transactions, process flow) APPLICABLE STANDARDS Applicable standards have yet to be defined. The ultimate goal of Web services is to address all four logical layers, but thus far the technology state of the art is confined to the lower three levels. WSDL (Web Services Description Language) is an XML format for defining interface and connection information SOAP (Simple Object Access Protocol) is an XML messaging standard for information exchange in an open network environment HTTP (Hypertext Transport Protocol) is the transport protocol for the Web and one of several transports that Web services can use

Service Definition (encoding and type schema definitions) Messaging (message packaging, routing, guaranteed delivery, security) Transport (message transport)

In addition to SOAP and WSDL, the Universal Description, Discovery, and Integration specification (UDDI) is often considered a component of Web services. However, UDDI, which defines a protocol for publishing and discovering information about business services, is not a required element for implementing a Web services architecture. The following diagram shows the basic relationship among the relevant standards.

Service Registry Abstract Interface (WSDL) Concrete Binding (WSDL) Physical End Point (WSDL) Concrete Implementation Publish(UDDI)

Abstract Interface

Abstract Interface (WSDL) Concrete Binding (WSDL) Physical End Point (WSDL) Generate/ Bind Service Requesting Process Service Proxy Discover/Find(UDDI)

Connect Service SOAP/HTTP(S)

Service Request Processor

Service Consumer

Service Provider

©2001 webMethods, Inc. All rights reserved.

Page 7

Simple Object Access Protocol (SOAP)

SOAP is a lightweight, XML-based, protocol for exchanging information in an open network environment. Originally authored by Microsoft, with subsequent contributions by IBM and others, SOAP consists of three elements: 1. An envelope structure for describing what is in a message and how to process it 2. A set of encoding rules for expressing instances of application-defined data types 3. A convention for representing remote procedure calls (RPC) and responses In theory, SOAP is able to use almost any underlying transport protocol, including HTTP, SMTP, FTP, and others. The current version of SOAP, version 1.1, defines bindings for HTTP. SOAP can also be embedded into higher protocols like ebXML or RosettaNet. In fact, although both of these standards define their own messaging frameworks, work is in progress to reconcile them with SOAP. A W3C working group, of which webMethods is a member, is currently drafting the next revision of the SOAP specification.

Web Services Description Language (WSDL)

WSDL is an XML format for describing network services. WSDL consists of two parts: 1. An abstract interface describing the operations and the associated messages 2. A concrete implementation (bindings) describing the actual network protocols, wire formats, and the actual network endpoint addresses required to access the service WSDL message binding is not limited to SOAP/HTTP, although this combination accounts for the majority of Web services implementations. Other bindings that are commonly discussed are HTTP POST and GET. Still other types of bindings such as SMTP or FTP are theoretically possible, though there is no discussion on them at present. Jointly authored by Ariba, IBM and Microsoft, WSDL consolidates several other service description language concepts. The current specification, version 1.1, lacks a framework for describing the composition and orchestration of Web services, which will be addressed by a separate specification in the future.

Universal Description, Discovery, and Integration (UDDI)

The UDDI specification defines a way to publish and discover information about services. The original intent of UDDI was to enable electronic catalogues in which businesses and their services could be listed. There are two components to UDDI: the registry and the interface. The UDDI registry is the physical server that houses the business and service descriptions. The UDDI interface is SOAP/HTTP-based API that client programs use to interact with the registry server, for example, to search for a desired service. Originally designed for use with public registries on the Internet, UDDI can also be applied to an intranet environment (sometimes referred to as private registries).

©2001 webMethods, Inc. All rights reserved.

Page 8

Although UDDI is commonly associated with Web services, any type of service can be registered in a registry provided it can be described in the manner required by the UDDI specification. UDDI does not, for instance, require that a service be accessible via Internet protocols, something that would be a requirement of a Web service. Furthermore, UDDI is not necessary to implement a functional Web services architecture, which only requires SOAP for transporting message across the network and WSDL for communicating interface and connection information. Alternative ways exist for discovering Web services, with the prime example being conventional Web pages that contain descriptions of Web services and URL's pointing to the associated WSDL definitions. Existing directory products can also be used to store information about Web services. It is important to note that the usage model of UDDI is still evolving, particularly with respect to browsing/filtering of services. IBM and Microsoft recently announced an alternative to UDDI in Web Services Inspection Language (WSIL), a specification that provides yet another way for locating Web services. WSIL defines a file format for obtaining Web service information directly from service providers, bypassing UDDI. Given the newness of WSIL, its impact cannot be assessed until wider industry support emerges.

Web Services As Architecture

At a basic level, Web services can be considered a universal client/server architecture that allows disparate systems to communicate with each other without using proprietary client libraries. This simplifies the development process typically associated with client/server applications by effectively eliminating code dependencies between client and server. The server interface information is disclosed to the client via a configuration file encoded in a standard format (i.e., WSDL); the server only needs to publish a single file for all target client platforms. Provided a client supports the Web services architecture via a supported protocol such as SOAP, and is using the correct version of the WSDL file, it will be able to establish the required communications channel with the server. The value of a universal client/server architecture can be appreciated by comparing it with the World Wide Web. The Web is essentially based on a universal client, the browser, interacting with Web servers using standard protocols, i.e., HTTP and HTML. This standardization has enabled the rapid and widespread adoption of the Web. The Web, however, has several limitations for robust client/server applications: 1. The browser interface is less sophisticated than custom client interfaces. For certain classes of applications, Web browsers are inappropriate as a primary user interface. 2. The HTTP protocol is not rich enough for handling complex client/server interactions. 3. HTML is a document layout markup rather than a content/data markup language and is unsuitable for encoding data. Reliable data encoding is important if the results returned by the server require further processing or manipulation on the client side. Web services addresses the Web's limitations by: 1. Providing a standard Web service client SDK to enable custom client applications to communicate with any Web services server ©2001 webMethods, Inc. All rights reserved. Page 9

2. Adopting SOAP as the messaging protocol when a more robust communications protocol is required 3. Adopting XML as the data encoding scheme to allow reliable data parsing in both client and server applications The diagram below shows conceptually how a client connects to a server using the Web services architecture; any Web services client can connect to any Web services server and invoke its services regardless of the underlying platforms that the client and server software are running on.




Web Service Proxy

Web Service





Since Web services allows any software program to communicate with any other software program as long as both programs support the Web services client and server stacks, the client/server model can be applied bi-directionally, enabling peer-to-peer conversations and allowing systems to interact in a business process.

Web Services and Integration

Since Web services addresses the interoperability issue among disparate platforms, some may conclude that it solves the entire enterprise integration problem. This conclusion ignores the fact that integration is a multi-faceted problem involving many levels, of which Web services address only the low-level requirements of communications, messaging, and data definition compatibility. Vendors in the Java (J2EE) camp such as IBM, HP, Oracle, and Sun, as well as Microsoft (with .Net), have all announced support for Web services. While these announcements indicate that the industry heavyweights are serious about supporting Web services and providing interoperability among competing software platforms, the emphasis of these vendors is on enabling the development of Web services on their application platforms, rather than on the role of Web services in integration. webMethods goes beyond being just a Web services development platform by enabling the integration of Web services and other resources in the extended enterprise, and pro-

©2001 webMethods, Inc. All rights reserved.

Page 10

viding the higher-level capabilities that are important for integration, such as business process automation and management, support for complex processing rules and data transformations, cross-enterprise information routing, workflow, and so on. Ultimately, the vision of Web services is to facilitate and automate business process collaboration, both inside and outside the enterprise, and to eliminate inefficiencies typically caused by the unavailability of timely business information and by non-value added processing steps such as data re-keying. However, although preliminary work has begun to address process integration- and collaboration-level needs, Web services are a long ways from realizing that vision. Today, Web services is still primarily an interfacing architecture, besides which there remains the issue of the installed base of applications that is not Web services compatible. For companies who are exploring Web services ­ understanding that, before deploying for mission-critical requirements, there are limitations such as the lack of guaranteed delivery, security, and routing capabilities in the current SOAP specification ­ webMethods offers the most comprehensive solution for implementing new Web services-based capabilities while supporting existing integration needs. The webMethods integration platform allows customers to: Expose existing back-end applications or higher-level business processes as Web services for internal and external application access Reuse previously developed services and quickly turn them into Web services Link internal and 3rd party Web services into their automated business process flows Leverage new Web services-based application interfaces to accelerate implementation of integration solutions Manage Web services as part of their overall integration infrastructure By providing integral Web services support in the platform, webMethods gives customers the real-world capabilities required to implement enterprise-level Web services solutions.

Implementation Considerations

As suggested in the previous section, besides the challenges involved in getting industry agreement on standards and the challenges of building viable Web services business models, there are other issues for companies to consider as they move forward. (Many of these issues relate primarily to external Web services, and are not as relevant for internal Web services deployment). Some of the main considerations: Reliability. Before enterprise customers start using 3rd party Web services in business-critical situations, they will want assurances that the service is reliable. Mechanisms for rating reliability, as well as to locate alternative services, are required. Security. Business-related services will require encryption, authentication, access controls, user-level security, and many other forms and levels of security. HTTPS (secure HTTP) and SSL are only able to address connection-level requirements, ©2001 webMethods, Inc. All rights reserved. Page 11

though even they fall short where a higher level of granularity is required, or in a multi-step integration where a message traverses several parties, since session-level security is only applicable between adjacent points. Guaranteed delivery. Guaranteed delivery is a fundamental requirement for reliable server-to-server integration in both point-to-point and multi-party situations. HTTPR (reliable HTTP) ­ which is still only a proposal ­ has been proposed to provide guaranteed delivery over HTTP, but similar to HTTPS, HTTPR will not be adequate for guaranteeing end-to-end delivery in a multi-way integration scenario. Routing. Routing is another necessary but unaddressed capability for reliable multiparty integration scenario. Routing is required to specify the path a message needs to follow (i.e., the next recipient). Transactionality. Traditional transaction systems which rely on a two-phase commit approach cannot be applied to an open environment where there are multiple independent participants and where transactions can span hours or even days. Alternative schemes, such as compensating transactions, are required. Discovery. Web services require some way to notify clients (users of the service) if the service changes or moves after it has been subscribed to. Testing. In a system comprising multiple Web services operated by different providers and hosted in different environments, end-to-end testing and debugging will be a significant challenge. Manageability. As with testing, the manageability of a system that includes dependencies on external services and components will be a significant challenge.

©2001 webMethods, Inc. All rights reserved.

Page 12


To successfully leverage Web services, enterprises require a platform that delivers robust out-the-box support for Web services development, integration, deployment, and monitoring. Companies not only need to develop new Web services applications but also to integrate their back-end business applications in the Web services architecture. In addition to development and integration, enterprise users need to have comprehensive management capabilities to ensure reliable Web services operations.

Continuing Web Services Leadership

webMethods' support for Web services continues the company's leaderships in business integration, the application of Java and XML technologies, and support for open Internet standards. webMethods has actively contributed to standards development efforts for SOAP, WSDL, UDDI, XML (including XML Schema, XML Forms, and other standards). The company is also a major contributor in developing industry specific e-business dialects, such as EDI, RosettaNet and the chemical industries Chem eStandards. webMethods is an expert member in several W3C working groups developing the next generation Web services standards, and newly ratified specifications will be supported in the regular product update cycle. The long-term goal, as the technology matures, is to provide a broad range of Web services solutions that cover the following areas: Protocol Support Service Description and Discovery Service Development and Deployment Tools Business Process Integration and Orchestration Process Management and Analysis Trust and Authentication Through this involvement, and from working with customers on several hundred successful implementations, webMethods has accumulated the most extensive experience in deploying XML-based solutions for business integration. With the deep understanding of the underlying technologies and broad-based implementation experience in business integration, webMethods approach to Web services is to provide robust and practical solutions that yield immediate benefits to customers.

Components of the webMethods Solution

The built-in Web services features of the webMethods integration platform provide customers with a unified solution for integrating, deploying, and monitoring Web services. The platform provides customers with many powerful and easy-to-use design-time and runtime integration capabilities when integrating Web services with back-end systems and other Web services.

©2001 webMethods, Inc. All rights reserved.

Page 13

Specifically, the webMethods platform provides out-of-box supports for SOAP 1.1 and WSDL 1.1. Users can: 1. Use the integration platform as a SOAP server for receiving SOAP request messages (both document and RPC styles) from remote SOAP (Web services) clients 2. Use the integration platform as a SOAP client for sending SOAP request messages (both document and RPC styles) to remote SOAP (Web services) servers 3. Expose any integration platform service as a Web service by generating and publishing the WSDL file that describes the service. Users can choose the transport style for the service, i.e., SOAP document, SOAP RPC, HTTP POST, or HTTP GET. 4. Generate an integration platform service (called a Web service connector) from a provided WSDL file to invoke the remote Web service described by the WSDL file. The Web service connector can be used by other integration platform services as a part of the overall integration logic. The following diagram illustrates how webMethods provides bi-directional Web services support.

WSDL Web Service Proxy SOAP webMethods Service Web Service Connector SOAP HTTP HTTP

SOAP Client


SOAP Server

webMethods users are able to interact with UDDI registries using a Web browser. Most UDDI registries provide an easy-to-use browser-based interface for creating and searching business and service descriptions. As a part of the service description record, a URL can be specified that points to the location of the WSDL file for the Web service. To publish a Web service from a webMethods platform, the user generates the WSDL file for the target integration service and uploads the WSDL file to a publicly-accessible Web server. If the user chooses to list the Web service in a UDDI registry (public or private), the user creates a UDDI entry for the Web service using the Web browser interface, and ©2001 webMethods, Inc. All rights reserved. Page 14

specifies the URL that points to the WSDL file. If the user chooses to list the Web service in a Web site on a network, the user simply adds the URL to the WSDL file to the appropriate Web page. To consume a Web service from a remote server, the user can use the Web browser interface to locate the desired Web service in a UDDI registry, locate the URL for the service's WSDL file, download the WSDL file into a local server, and generate the Web service connector in the integration platform. A WSDL file can also be obtained directly from a Web site or service provider, depending on how the service is offered.

Web Services Use Patterns

Given that SOAP 1.1 lacks the concept of guaranteed delivery, Web services should initially be applied to requirements where reliability is not an issue, or where user-initiated retries are possible, such as synchronous request/reply integration between desktop applications and back-end servers. Web services can also be applied to back-end-to-backend integration where one system is making a synchronous inquiry of the other system. Currently, Web services are also not suitable for asynchronous interactions. This restriction will be removed with follow-on SOAP specifications that address guaranteed delivery and other features required for reliable asynchronous communications. Even with the limitations, enterprises can already benefit from the Web services architecture because it enables a much wider range of client and server platforms to interoperate, similar to the Web browser and server architecture. The following sections go into more detail into some of the usage patterns for the webMethods Web services solution.

Exposing Back-End Enterprise Systems as Web Services

The webMethods platform is ideally suited for exposing corporate back-end systems as Web services for corporate intranet application development. The platform not only supports the widest range of adapters for back-end application integration and best-in-class mainframe integration and human-workflow capabilities, it also offers highly productive business process modeling, service development, and data transformation tools. Combined with the platform's Web services support, exposing back-end resources as Web services is a simple point-and-click exercise. With only a small amount of configuration work, corporate information resources are unlocked for application developers, for example, providing an employee information lookup service for an HR application. Examples of back-end systems that can be exposed as Web services by the webMethods integration platform include: Commercial packaged applications such as SAP R/3, Siebel, i2, JD Edwards, Oracle Applications, and other popular enterprise packages Databases such as Oracle, SQL Server, Informix, Sybase, and DB2, as well as any ODBC- or JDBC-compliant data store Legacy CICS and IMS/TM-based applications Custom applications written C/C++, COM, Java and EJB

©2001 webMethods, Inc. All rights reserved.

Page 15

Web services-compliant application development environments are able to import WSDL files generated by the webMethods platform ­ either directly or from a UDDI registry where the services are advertised ­ generate the necessary client proxies, and invoke the Web services on the webMethods integration server. Web services can be made available to business partners over the Internet just as easily.

Exposing Corporate Business Processes as Web Services

In some cases, the back-end system services to be accessed are too low level to be used directly by Web services clients. In these situations, the webMethods integration platform provides powerful business process management capabilities to aggregate the back-end services into coherent, high-level business processes with well-defined service points for external access. These business process-level service points can then be exposed as Web services with minimum effort. To expose a business process as a Web service, the webMethods user first defines the business process model. The user then creates the underlying process implementation using the platform's automatic generation feature, resulting in the integration services that are then accessible as Web services. The user then publishes the WSDL files for the desired service points using the WSDL generation capability. Once a business process is exposed as a series of Web services, it can be easily incorporated into clients or target business systems using the Web services architecture. The ability to expose business processes as Web services adds enormous value to the enterprise by turning otherwise abstract business processes into concrete access points for end users, business systems, and other business processes.

Integrating Web Services into Corporate Business Processes

In many instances, corporate business processes require inputs from external systems or processes. The webMethods Web services solution provides a simple mechanism to incorporate Web services into a business process. The user first locates and downloads the WSDL files for the desired Web service. The user then uses the webMethods Web service connector generation wizard to generate the Web service connector. A Web service connector is a component that can be incorporated very simply into the business process models created with the webMethods integration platform. For example, a credit approval web service could be linked into an order entry business process. The webMethods platform can also act as an information aggregator, requesting and consolidating information from Web services both within and outside the enterprise to present an aggregated view to end users or requesting business systems.

Managing Web Services in the webMethods Platform

As the combination of Web services into business applications becomes more prevalent and moves out of the pilot stage, the need to successfully manage these services becomes more pressing. Operations staff must gain visibility into these services and how they interoperate, so that the tasks of fault-detection, correction and performance tuning and optimization can be performed in a timely manner. The high availability and

©2001 webMethods, Inc. All rights reserved.

Page 16

throughput requirements of critical business applications and processes must be monitored and maintained. The webMethods platform provides an ideal Web service deployment environment from a system monitoring and management perspective. In the webMethods platform, Web services and Web service connectors (for accessing remote Web services) are no different from other types of integration services supported by the platform. Web services and Web service connectors are managed and monitored using the standard webMethods GUI-based tools provided with the integration platform. Capabilities such as operational statistics, service execution logs, enabling/disabling of services, access control, etc., are all available to users. Through the Open Management Interface (OMI), jointly authored by webMethods and HP and supported by CA, IBM/Tivoli, and BMC, the webMethods integration platform makes vital Web services management and monitoring information available to existing system management products. webMethods is unique in being the only Web services vendor capable of providing true enterprise-level management functionality across all elements of the integration backbone, and is the only company to have the endorsement and product support of the four leading systems management vendors.

Customer Benefits

By utilizing webMethods as their enterprise Web services deployment platform, customers are able to realize the following benefits: Single platform solution. webMethods provides customers with a single, scalable, and manageable platform for implementing Web services and integrating them with existing disparate application resources. Reduced cost and risk. Customers can quickly turn their existing business applications and processes into Web services, enabling them to realize the benefits of Web services without incurring major development effort and risk. Faster time-to-benefit. The webMethods solution provides all the necessary out-ofbox client and server functionality for customers to quickly connect to and implement Web services. The integrated functionality results in faster implementations and a quicker return on investment. Increased competitive advantage. webMethods enables customers to quickly and easily leverage third-party business service providers. Companies benefit by being able to focus on their core business processes. Forward compatibility. The webMethods platform protects customers from the continuing evolution of Web services by providing a stable environment that is insulated from the actual underlying Web services infrastructure elements. webMethods' architecture, which separates services from protocol implementations, assures customers that any work they do today will be forward compatible with future versions of the Web services standards.

©2001 webMethods, Inc. All rights reserved.

Page 17


Web services represent a significant step in the evolution of distributed systems and promise to transform computing by providing universal interoperability between applications running on different platforms. Much energy and attention has been devoted to Web services and the development of standards such as SOAP, WSDL, and UDDI, and other areas such as security and reliability are currently being addressed by the standards bodies to ensure that Web services succeed in an enterprise setting. Although Web services are primarily an interface technology ­ and not an integration technology ­ Web services and integration platforms are highly complementary since, to be useful, any Web service will require integration with one or more back-end systems. With webMethods' long history of enabling computing over the Internet using XML and open communications standards, the webMethods integration platform offers a compelling solution for unifying a company's Web services development requirements with their integration requirements. Built into the industry's most comprehensive integration solution, the platform's Web services capabilities allow companies to provide a Web services front-end to existing application services, expose high-level composite business processes as Web services, and integrate external Web services seamlessly into integration process flows. Customers can leverage the platform's business process modeling capabilities and broad application support seamlessly in the creation of enterprise-level Web services, while relying on the platform's management capabilities for deployment. The webMethods integration platform provides customers with the most effective and low risk path for implementing true enterprise Web services.

©2001 webMethods, Inc. All rights reserved.

Page 18


webMethods, Inc. (Nasdaq:WEBM) is the leading provider of integration software. The webMethods integration platform allows customers to achieve quantifiable R.O.I. by linking business processes, enterprise and legacy applications, databases and workflows both within and across enterprises. By deploying the webMethods integration platform, customers reduce costs, create new revenue opportunities, strengthen relationships with customers, substantially increase supply chain efficiencies and streamline internal business processes. Founded in 1996, webMethods is headquartered in Fairfax, Va., with offices throughout the U.S., Europe and Asia Pacific. webMethods has more than 750 customers worldwide including Global 2000 leaders such as Citibank, Dell, Eastman Chemical, The Ford Motor Company, Grainger, and Motorola. webMethods' strategic partners include Accenture, AMS, BMC, BroadVision, Cap Gemini Ernst & Young, Deloitte Consulting, EDS, HewlettPackard, i2 Technologies, J.D. Edwards, KPMG Consulting, Microsoft, Oracle Corp., SAP AG and Siebel Systems. More information about the company can be found at

©2001 webMethods, Inc. All rights reserved.

Page 19

Contact webMethods

North American Headquarters:

3930 Pender Drive Fairfax, VA 22030 United States of America 1-703-460-2500

European Headquarters:

400 Thames Valley Park Road Reading, Berkshire RG6 1PT United Kingdom +44 (0)118 963 7455

Asia Pacific Headquarters:

Level 15, Philips Building 15 Blue St. North Sydney NSW 2060 Australia +61 2 8913 1111


Web Services

20 pages

Find more like this

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate


You might also be interested in

Understanding the webMethods Product Suite
JD Edwards EnterpriseOne Tools 8.98 Web Services Gateway: EnterpriseOne Adapter Programmer's Guide