WEB SERVICES STACK

This section takes a detailed look at the three levels of the Web services stack. At each level, current Web services are explained and appropriate examples are provided. Figure 2.5 again illustrates the layers of the stack but now identifies the key standards associated with each layer.

Figure 2.5: Standards of Web services stack.

Level 1: Enabling Standards

The enabling standards level contains two layers: the network transport protocols and meta-language. The layers within the enabling standards level contain well-defined and accepted standards and protocols that are widely used to support mission-critical business applications and capabilities today.

Network Transport Protocols Layer The network transport protocol layer is well defined and understood, using pervasive standards and protocols that form the foundation of today’s World Wide Web. Taking a closer look at this layer, we discover that it contains three sublayers, as illustrated in Figure 2.6.

Figure 2.6: Internet protocol stack.

The first two sublayers, Transmission Control Protocol (TCP) and Internet Protocol (IP), are typically grouped together and jointly referred to as the TCP/IP network layer. These sublayers originated from an initiative started at the Defense Advanced Research Projects Agency (DARPA). DARPA wanted to enable heterogeneous connectivity between disparate defense department computer networks. With this goal in mind, DARPA awarded Bolt, Beranek, and Newman, Inc. (BBN) a contract to develop ARPANET. From the initial four-node network implemented in 1969, ARPANET continued to grow and in 1982 adopted TCP/IP as its underlying protocol. TCP/IP later was included with Berkeley Software Distribution (BSD) UNIX and subsequently became the foundation on which the Internet and the World Wide Web (WWW) are based.

Above the TCP and IP layers is the Transport Protocol layer. While the concept of Web services is designed to be transport protocolindependent, the predominant protocol used today is the Hypertext Transport Protocol (HTTP). The ubiquity of HTTP, coupled with its innate capability to navigate firewalls, makes it the most common Web services transport protocol. Additional protocols, including Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), and even TCP can be can used, but from a practical perspective few implementations support these protocols.

When considering the implementation of Web services, it is critical to understand that HTTP is not a reliable transport protocol. To appreciate this concept, think of HTTP as providing similar functionality to a basic pager. When sending someone a page, there is no guarantee that the message will be delivered to the recipient (for example, they might have their pager turned off or be out of range). The critical point to appreciate is that a basic pager is not two-way and cannot reply with a confirmation that the message was received. Similarly, HTTP does not guarantee receipt of a message, and it is possible that a message could get lost if part of a network goes down or if other network issues occur. Right now, this lack of reliability precludes the use of Web services over HTTP for mission-critical applications unless additional logic or tools are used to ensure reliable messaging.

In considering the reliability issue of HTTP, IBM recently published a proposal for a reliable messaging protocol called Hypertext Transport Protocol Reliable (HTTPR). HTTPR builds its reliability on HTTP 1.1 and therefore includes the benefits of HTTP, while ensuring that messages are delivered to their destinations unimpeded. Reliable messaging will become an important aspect of Web services and will undoubtedly appear in some form in the near future, although it is questionable whether the network layer is the most appropriate position for its implementation.

Meta Language Layer The Meta Language layer is enabled with the eXtensible Markup Language (XML) as a means to describe structured data. A metalanguage is a language that can be used to describe other languages, enabling the creation of specific markup languages for specialized purposes. For example, XML could be used to define the grammar for HTML, the language used to display graphical pages on the Web. XML is enabling a new generation of Internet-based data manipulation applications and is undisputedly the universal language for data exchange over the Web.

XML’s key strength is its capability to significantly reduce the complexitiesassociated with the exchange of data between computer systems. It often takes a considerable amount of time, cost, and effort to enable data transfer between organizations or even between departments of the same organization. This is typically caused by a lack of standardization on how data is represented as well as the array of proprietary tools and mechanisms for extracting and transmitting data. XML provides a standard means of describing data while also providing the data context required to interpret the data if manipulation is necessary.

For example, a firm could choose to define an XML document describinga purchase order. The main element of this document might be “purchaseOrder” and would typically contain the subelements “shipTo,” “billTo,” “comment,” and “items.” Each of these subelements might themselves contain a number of subelements that enable a purchase order to be fully described. A sample XML document showing a specific instance of a purchase order is shown in Figure 2.7.

The power of XML is that information is represented as a structured document making it possible for the data to be interpreted and manipulated by a range of systems without manual intervention. As long as all parties that need to use the purchase order agree on the document structure, it is possible for the document to be shared across multiple systems or even multiple organizations. For example, the purchase order document illustrated in Figure 2.7 could be used to update order information in an order tracking system, a billing system, or an inventory management system. If these systems can not directly interpret the purchase order document in its native form, then the XML document structure makes it relatively easy to process the document and translate it into an alternative format.

Figure 2.7: XML purchase order document.

XML is a key enabling component of Web services. It is the language in which Web services communicate as well as the language used as the foundation for other layers of the Web services stack (for example, SOAP and WSDL). As is so often the case, however, a technology’s strength can also be its weaknesses. In the case of XML, the very flexibility that has been a cornerstone to its adoption can also present a very real challenge.

Need for Data Definition Standards XML and Web services simplify the complexities of system integration and system interoperability through the use of technologies and standards to transport, route, discover, and connect services together. XML and Web services do not resolve the challenges of aligning data definitions, jargon, and vocabularies within and across organizations, however. For example, if one organization refers to an inventory item as a part number represented as “partNum,” while another refers to it as a stock keeping unit, or “sku,” both organizations might mean the same thing, but a computer system typically cannot resolve this discrepancy. When this type of naming discrepancy occurs, human intervention is required to analyze the meaning or semantics of the data. As the following quotes illustrate, this situation is a real challenge and potential inhibitor to deployment of Web services.

“. . . data definitions usually vary from company to company—or even within a single company . . . that’s the bigger problem than being technically able to pass data from one system to the other.” ^[2]

“In the context of the extended enterprise, common business semantics are critical to successfully interfacing business processes.” ^[3]

Currently, the only way to deal with this challenge is to agree beforehand on naming conventions and data schemes. As organizations leverage XML and begin implementing Web services, it is absolutely critical that they develop consistent data-naming conventions within the organization. Companies should first look to leverage data definition standards that might already have been developed within their industry, and where industry standards do not exist, they should act now to start the process of defining their own standards.

In an effort to tackle these data definition issues, many industry groups have already started the process of defining the standards required to enable cross-organization data exchange. Figures 2.8a, 2.8b, and 2.8c identify a number of the most visible organizations that are actively involved in creating XML data definition standards.

Figure 2.8a: Financial services data definition standards.

Figure 2.8b: Healthcare data definition standards.

Figure 2.8c: Additional data definition standards.

In the context of this book, it is only possible to scratch the surface of XML data definition standards. For those interested in learning more about XML and XML data standards, there are several excellent sources additional information, a few of which we include here:

Oasis-Open.org —The Organization for the Advancement of Structured Information Standards (OASIS) produces worldwide standards for security, Web services, XML conformance, business transactions, electronic publishing, topic maps, and interoperability within and between marketplaces.

XML.org —XML.org’s mission is to accelerate the global utilization and adoption of XML by providing an open and nonprofit industry portal that brings together all members of the XML community, including technologists, developers, and business people.

RosettaNet.org —RosettaNet.org is a nonprofit consortium of more than 400 of the world’s leading IT, Electronic Components (EC), Semiconductor Manufacturing (SM), and Solution Provider (SP) companies working to create, implement, and promote open e-Business process standards.

In cases where consistent data definition standards are not being used, the need to translate an XML document from one format to another becomes unavoidable. This situation is where the translation capabilities of the eXtensible Stylesheet Language Transformations (XSLT) become a necessity. XSLT provides a transformation language for transmuting a XML document into an alternate format. Alternate formats could be another XML document with a different set of data definitions, a simple text document, or perhaps an HTML page.

Level 2: Evolving Standards

The evolving standards level contains slayers for SOAP, WSDL, and UDDI. Collectively, these layers form the core standards for deployment of Web services. Figure 2.9 illustrates the role that each layer plays in the execution of a Web service, and their relationship to the requestor, broker, and provider network.

Figure 2.9: Web services: publish, find, and bind.

This figure shows that the service provider preregisters their service(s) with the service broker, the service is registered in a UDDI repository, and the service is described using WSDL. Subsequently, a service requestor initiates a search for a service by contacting the service broker and searching the registry for services that meet specific search criteria. The broker returns a list of services along with details of the associated provider for each service meeting the search criteria. The requestor binds (creates a communications link) with a selected provider using the SOAP messaging standard. Also using SOAP, the requestor sends a service request and receives the result set of the executed service.

Figure 2.9 illustrates how the large industry players (such as Microsoft, IBM, Sun, and so on) envision Web services working, but this is not necessarily representative of how Web services are initially being implemented. The original vision of Web services, as illustrated in Figure 2.9, was for large public repositories of services to be published on the Internet by service brokers, to which companies would subscribe and search for services to incorporate into their own applications. In this model, the requestor, broker, and provider are all independent entities dispersed across the Internet. Today’s reality is a far more conservative environment, as illustrated in Figure 2.10.

Figure 2.10: Web services: optional publish and find.

This figure illustrates a number of key points. First, where services are being published today, they are typically published to a private UDDI repository behind a corporate firewall. Second, the repository itself is an optional element of the model. In many cases, Web services are being developed for private consumption and are not being described or published. This model significantly reduces the envisioned flexibility of the Web services model, but does provide an adequate entry point, that can later be extended to include both private service repositories and public service brokers.

The evolving standards level provides a good degree of stability and is the basis upon that which the current mix of Web services development and deployment tools are based. The current set of Web service development tools, available from the likes of IBM, BEA, and Microsoft, provide a solid framework with which companies can start to implement real-world Web services.

Services Communication Layer The services communication layer uses SOAP as a lightweight protocol for exchange of information in a decentralized, distributed computing environment. SOAP is an XML-based protocol that allows communication between multiple computer architectures, languages, and operating systems.

In the past, many attempts have been made to develop a common communications protocol that could be used for systems integration, but none of them have achieved the widespread adoption required to be truly successful. One of the most compelling considerations for the use of SOAP is that it has already been implemented on more than 70 hardware and software platforms. This widespread adoption of SOAP is primarily due to its lightweight nature and its relatively low complexity when compared to precursors such as the Distributed Computing Environment (DCE) or the Common Object Request Broker Architecture (COBRA).

The first SOAP specification was released as Version 1.0 in late 1999 as a result of collaboration between Microsoft, UserLand Software and DevelopMentor. The original specification was submitted to the Internet Engineering Task Force (IETF), at which time Microsoft made the following announcements:

“The key enabler for Microsoft’s vision of integrated, programmable Web services is XML. Through the exchange of XML messages, services can easily describe their capabilities and allow any other service, application or device on the Internet to easily invoke those capabilities. To help realize that vision, Microsoft today is submitting to the Internet Engineering Task Force (IETF) an Internet draft specification for the Simple Object Access Protocol (SOAP), an XML-based mechanism that bridges different object models over the Internet and provides an open mechanism for Web services to communicate with one another.”

“To help developers build Web services and link heterogeneous components over the Internet, Microsoft worked with industry experts to create the Simple Object Access Protocol. SOAP provides an open, extensible way for applications to communicate using XML-based messages over the Web, regardless of what operating system, object model or language particular applications may use. SOAP facilitates universal communication by defining a simple, extensible message format in standard XML and thereby providing a way to send that XML message over HTTP. Microsoft is soliciting industry feedback on version 0.9 of the SOAP specification.” ^[4]

The original SOAP specification was subsequently revised with input from IBM and Lotus and submitted to the W3C as SOAP version 1.1 on April 18, 2000. The W3C published the submitted specification as a W3C Note. The W3C has now adopted the SOAP specification and integrated ongoing work for future releases into the XML Protocol working group. The specification for SOAP version 1.2 is currently an in-progress working draft at the W3C.

To help appreciate how SOAP might be leveraged, imagine that an organization has implemented a Just-In-Time (JIT) inventory and order management initiative, and it is pondering how Web services could be used to improve the order management process, perhaps automating the process of placing orders with key suppliers:

Your firm has implemented a number of new Web services that allow your top suppliers to track your inventory levels, and you’ve provided them with documentation that details how to interface with the SOAP services. The documentation you’ve provided lets the suppliers know where your services are located, what parameters they require, and what data will be returned. Using this information, your suppliers manually implement the code to interface with your services.

This description is exactly the model outlined in Figure 2.10, where your firm is the service provider and your suppliers are the service consumers. Your suppliers (the service consumers) interface, or in Web services terms “bind,” with your inventory management service to allow them to automatically view your inventory levels.

In a nonstandards-based environment without Web services, it is very likely that this type of integration would only be accomplished through the investment of a significant amount of time and effort developing custom integration between your systems and your suppliers’ systems. Custom integration would require that all parties agree on proprietary file formats and data exchange mechanisms for which custom interfaces would be developed.

Services Description Layer The services description layer is where WSDL— often pronounced “whiz-dull”—is used as a common XML framework for describing a Web service. A WSDL document describes a set of messages in terms of what they contain and how they are exchanged. In addition to describing the message contents, WSDL defines where the Web service is available and what communication protocol is used to talk to the service. In other words, the WSDL file defines all the information required to invoke a Web service.

Over the past few years Microsoft, IBM and others have proposed service description languages for component-based Web applications including: Service Description Language (SDL), Service Contract Language (SCL), and Web Interface Definition Language (WIDL). These early proposals have been superceded by WSDL, which now has broad support and widespread industry adoption. The vast majority of Web services development toolkits and component application servers have built-in support for creating and manipulating WSDL documents.

The WSDL standard was jointly developed by Ariba, IBM, and Microsoft, debuting on September 25, 2000, with the release of WSDL version 1.0. The original specification was subsequently revised with input from a number of organizations including BEA, HP and SAP. The revised specification was submitted to W3C as WSDL version 1.1 on March 15, 2001. As with SOAP, the W3C initially published the WSDL specification as a W3C Note, and now has an in-progress working draft of WSDL version 1.2.

The real value of WSDL is in providing the potential to automate the connection to and consumption of Web services. Building on the JIT inventory management example from the prior section, it is possible to use WSDL to remove the need for suppliers to manually develop the code to bind with the inventory management Web services.

In the SOAP example from the previous section, it was necessary to document your company’s services and for the suppliers to use that document to determine how to use your services. Wouldn’t it be great if there was some way in which your suppliers could automatically determine how to communicate with your services? This is exactly how WSDL can be used. A WSDL document describes all the information that a supplier needs to use your services. In fact, with the appropriate systems in place, the suppliers could completely automate the process of interfacing with your organization’s services.

Use of WSDL documents mean that it’s no longer necessary to go through the time-consuming process of manually documenting the SOAP interface requirements, the WSDL document provides this information in a form that can be interpreted by other systems. Once the suppliers’ systems interpret the WSDL documents, they can establish a binding with the inventory management services— allowing direct system-to-system communications.

By removing the manual process of hand coding the interfaces, it is possible to significantly reduce the time and cost needed to develop a systems interface, allowing connectivity to a far larger number of suppliers than was previously feasible.

Service Publishing and Discovery Layer The UDDI specification defines a data structure standard for describing organizational entities (businesses, not for profit organizations, and so on) and the services they provide using XML. UDDI provides high-level business information that complements the information contained in a WSDL document. Information within a UDDI registry is conceptually divided into three distinct elements—white, yellow, and green pages:

• White Pages —Contains general contact information about the entity. An entry would contain a business name, address, and contact information such as phone, facsimile, and e-mail.

• Yellow Pages —Contains classification information about the types and location of the services the entity offers. Examples might be Standard Industrial Classification (SIC) codes or the North American Industry Classification System (NAICS) categories.

• Green Pages —Contains information about how to invoke the offered services and might reference a WSDL specification for the service.

Figure 2.11 illustrates the three distinct page sets represented in a UDDI registry.

Figure 2.11: Elements of the UDDI registry.

The UDDI version 1.0 specification was first published in September 2000 by Ariba, IBM, Microsoft and 33 other companies. Since September 2000, the UDDI specification has had several updates—most recently with the release of UDDI version 3.0 on July 19, 2002. With the release of

UDDI version 3.0, the UDDI standards body, UDDI.org, has now merged with OASIS.

The UDDI specification has gained significant momentum, in no small part due to the backing of Microsoft and IBM, but has not achieved the same level of acceptance enjoyed by SOAP or WSDL. This lackluster acceptance is primarily because the functionality of UDDI registries precedes the real-world need for their adoption. UDDI adoption has been inhibited by the following factors:

• UDDI was originally envisioned as the basis for public internet service registries, but the majority of Web services are being developed today for intra-enterprise consumption and do not leverage public service registries.

• Participation in public registries has been low, which undermines any compelling reason to consume services from public registries. In fact, many of the early services being registered publicly provide little more than a proof of concept for UDDI capabilities.

• Progress toward fully securing Web services is moving rapidly, but the lack of a fully implemented security model for public services will continue to impede public registry usage.

Fundamentally, the addition of dynamic discovery and integration with services from a UDDI registry adds a level of complexity to Web services for which there is not yet a compelling need. Recent revisions to the UDDI specification provide broader support for implementation of private intra- enterprise service registries, which will likely gain greater acceptance in the short-term.

Further building upon our inventory management example, let us assume that an organization places orders with a closed network of preferred suppliers. Under certain conditions, it might be desirable to leverage an open network of suppliers where a firm can dynamically determine which suppliers it wants to partner with. The company may want to place orders with suppliers based on specific requirements or parameters such as unit price, payment terms, time for delivery, and so on. These parameters may fluctuate over time based on the business pressures that an organization is experiencing, and the firm’s closed network of suppliers may not have the flexibility it is seeking.

In this case, it is necessary to search for suppliers that met the firm’s prioritized parameters. To achieve this goal, a yellow pages directory of all businesses that expose Web services is needed. Like a typical yellow pages directory, UDDI provides a database of businesses that is searchable by business name, type of business, geographical location, and so on:

Again using the inventory management example, from the previous section, a UDDI services registry could be leveraged to further extend your purchasing capabilities. In the previous examples your firm used a push model, where suppliers can determine your inventory levels and automate shipments when inventory levels get low. In this example, your firm will use a pull model, where your company uses a services UDDI registry to find suppliers that meet your purchasing needs.

You have received a special order from an important client and need to locate parts that are not available from our existing suppliers. Similar to the way in which a yellow pages directory could be used to manually locate a supplier, you will use a UDDI registry to locate suppliers that meet your specific search requirements. In this case, you are going to locate suppliers that:

• Fall within a specific Standard Industrial Classification (SIC) code.

• Are within 100 miles of our production facility.

• Publish Web services that enable us to determine product type and availability based on our specific need.

Using the search criteria, the UDDI registry will return information regarding contacts, links, technical data and specifications, allowing you to evaluate which services best meet the requirements. Once you have identified the services that you want to bind with, you will then determine the call interface and semantics for the service and automatically configure your own software to connect with the service. Having connected with the service, you can then search for the product you need, perhaps also determining the availability of on-hand stock, unit price, shipping terms, and so on.

This process could automatically be completed with a number of suppliers to determine which supplier best met your specific requirements. Once the best match has been found, an order can be placed and shipment of the product can be initiated.

UDDI is not strictly necessary to enable Web services, but as the numberof available services grows, organizations will need somewhere to register their services so they can be found easily and consumed. This will lead to the implementation of private intra-enterprise UDDI registries.

From a longer-term perspective, it is possible to envision an environment in which systems may be assembled from a collection of Web services provided over the Web—similar to way in which D&B is providing its credit-checking services. In this future, when a business changes the way in which it executes a transaction or process, the appropriate service(s) and process flow(s) will be modified and the changes will ripple throughout the organization’s IT systems.

Level 3: Emerging Standards

The emerging standards level has the least well-defined capabilities. This level represents proposed standards that are promoted by individual vendors, have not yet gained broader endorsement or acceptance in the wider Web services community, and have not been adopted as open standards for development by key standards bodies such as the W3C and OASIS.

The Web services space is moving at a tremendous pace. Therefore, it is important for companies to carefully watch the emerging standards, monitoring which gain greater acceptance and which will perhaps move from an emerging to an evolving status. As illustrated in Figure 2.12, the Web services stack has been extended from the version introduced in Figure 2.2, adding vertical layers that traverse the stack. These new layers provide capabilities that will be required as organizations continue to build out their Web services portfolio.

Figure 2.12: Extended Web service stack.

Business Process Execution Using the evolving standards of SOAP, WSDL, and UDDI, it is possible for applications to find each other and interact following a loosely coupled, platform-independent model. To realize the full potential of Web services as an integration platform, however, a standard business process integration model is required, enabling complex interactions between business processes and Web services.

A number of Business Process Management (BPM) or workflow languages have been proposed by vendors, including the Web Service Flow Language (WSFL), XLang, Web Services Choreography Interface (WSCI), Web Flow Markup Language (WFML), Business Process Markup Language (BPML), and so on. In fact, there have been so many proposed process management standards that it has been difficult to know where to look.

A key obstacle to the emergence of a clear leading standard in this area has been Microsoft and IBM’s independent offerings of XLang and WSFL, respectively. Recently this standoff was resolved with the announcement by Microsoft, IBM, and BEA Systems that they have joined forces to propose the Business Process Execution Language for Web Service (BPEL4WS).

BPEL4WS is designed to ensure that individual business processes can understand one another in a Web services environment. It is a hybrid of WSFL and XLang, combining the capabilities of both into a single cohesive BPM language. Using BPEL4WS it is possible to define a new Web service that is composed of existing services, with the resulting Web service being described by its own WSDL document. The resulting composition, or process, defines how each individual service is combined to enable the execution of an end-to-end business process.

It appears likely that BPEL4WS will be adopted as a broad industry standard for BPM with Web services, but as yet BPEL4WS has not been submitted to a standards organization for independent governance. At this time, it is clear that BPEL4WS has superseded the WSFL and XLang specifications, and possibly the BPML specification. It will be interesting to see what happens with WSCI, which was already submitted to the W3C by Sun Microsystems. Perhaps Sun will join forces with IBM, Microsoft, and BEA systems, or perhaps choose to push WSCI as an opposing standard.

Transactions Core Web services standards (specifically SOAP, WSDL, and UDDI) define protocols for Web services interoperability. Increasingly, as organizations look to use Web services for business process execution and workflow, it will be necessary to link large numbers of services into loosely coupled, distributed applications. The resulting applications will require the coordination of complex transactions between participant services.

Transactional consistency will be a fundamental requirement for building reliable service-based applications. Specifically, it will be necessary to ensure all the participants in an application or service achieve a mutually agreed upon outcome based on the success or failure of a transaction. Traditionally, transactions have held properties collectively referred to as ACID (Atomic, Consistant, Isolated, and Durable): ^[5]

• Atomic —An atomic transaction is all-or-nothing. Either everything is successfully updated or nothing is updated.

• Consistent —A consistent transaction is one that leaves data in a consistent state. The resulting data records should not contradict each other.

• Isolated —An isolated transaction is one that cannot be viewed by another transaction before it is committed. A transaction should not be able to view the transitional state of another transaction.

• Durable —Once a transaction successfully completes, the changes survive failure. Changes due to a transaction should be reliably stored and should be recoverable in case of system failure.

Web services will require the ability to coordinate transactions and implement ACID transaction processing, as well as the ability to coordinate the results from multiple services in a more flexible manner. This flexibility will require more relaxed forms of transactions—those that do not strictly abide to the ACID properties—such as collaboration, workflow, real-time processing, and so on. The emerging WS-Coordination and WSTransaction specifications, announced by IBM, Microsoft and BEA systems on August 9, 2002, provide a framework for enabling strict ACID transaction management as well as the flexibility required to support more relaxed transaction requirements.

Management As organizations build out their Web services capabilities, there will be an explosion in the volume of Web services. A rapidly increasing portfolio of services will require software to catalog, track, manage, and monitor service availability. The emerging Web services managed space will play an important role in answering the following questions:

• What Web services are available, and what do they do? Can they be reused?

• Who is authorized to use various Web services?

• What is the performance load on the servers that are running Web services? Are Web services running optimally?

• Are consumers of Web services receiving response times within acceptable Quality of Service (QoS) limits?

Web services managment tools are emerging to help organizations answer these questions and more, including performance management, quality of service, logging and auditing, and so on. Answers to all of these questions will become increasingly important as Web services are initially deployed for integration, followed by collaboration initiatives.

Web services management needs have received less exposure than other Web services requirements, such as security and business process execution As such there is currently a lack of standardization, leaving the Web services management space open to proprietary solutions. Proprietary Web services management solutions from startups such as Amberpoint, Infravio, Confluent Software, and Talking Blocks are emerging. These organizations provide a range of Web services management tools that will support Web services, management capabilities, including the following:

• Availability —Tracking which services are online or offline

• Management —Load balancing of services across multiple machines and platforms

• Visibility —Clear visibility of who is using what services and when

• Exceptions Management —Management of both business and technical exceptions

• Quality of Service (QoS) —Ensuring that both QoS and service-level agreements are being met

• Metering and Billing —In a pay-per-use environment, ensuring that services are metered and billing information is tracked

• Security —Ensuring that access to services is secure and that service usage is authenticated

As organizations continue their Web services buildout, management tools will rapidly become necessary for effective tracking and management of a growing portfolio of services.

Security It is relatively easy to secure a private network with trusted partners, suppliers, and customers using Virtual Private Network (VPN) capabilities. But as the need to use services outside of private networks increases, it will be necessary to consider emerging Web services security standards.

“. . . there is a need for securing XML documents and messages in addition to transport layer security . . . without a reliable and flexible security solution, Web services will die its own death,” said Sudhir Agarwal of Verizon. ^[6]

Web security experts identifiy three types of security threats that must be guarded against when implementing Web services outside of the corporate firewall:

1. Exposed Systems —Web services can leave open security holes, allowing hackers to gain access to private corporate information and internal corporate systems. As Web services leverage HTTP, make sure that the corporate firewall is configured to protect internal networks.

2. Exposed Information —As consumers begin to use Web services, unencrypted information transmitted over the Web can be “stolen” from internet traffic. Stolen information, for example a credit card number, could be used to complete fraudulent tractions. This type of security threat can be eliminated relatively easily using existing Webbased encryption and security standards such as Secure Socket Layer (SSL).

3. Spoofed Transactions and Services —Fake Web service transactions may be used to commit cyber theft. For example, services may be published from nontrustworthy sources, taking personal or financial information and appearing to complete a transaction, but actually capturing financial information (for example, credit card or bank account details) for later fraudulent use.

To fully secure Web services it is likely that a combination of existing security technologies will be leveraged, such as SSL, combined with emerging Web services security standards such as XML Key Management System (XKMS), Security Assertion Mark-up Language (SAML), and XML Signature.

In April 2002, IBM, Microsoft, and BEA systems submitted the WSSecurity proposed standard to OASIS. WS-Security provides a flexible framework that can be used as the basis for the construction of a wide variety of security models, including Public Key Infrastructure, Kerberos, and SSL. Specifically, WS-Security provides support for multiple security tokens, multiple trust domains, multiple signature formats, and multiple encryption technologies.

WS-Security is a building block that will likely be used in conjunction with other Web service extensions and higher-level application-specific protocols to accommodate a wide variety of security models and encryption technologies.

Additional Standards The Web services space is moving at a tremendous pace, and it seems that every day there are new emerging standards proposed by one of the key players. One such example is the Web Services Experience Language (WSXL). WSXL version 2 was announced by IBM on April 10, 2002. IBM outlined the focus and intent of WSXL standards as follows:

“. . . [WSXL] is a Web services centric component model for interactive Web applications, that is, for applications that provide a user experience across the Internet. WSXL is designed to achieve two main goals: enable businesses to deliver interactive Web applications through multiple distribution channels and enable new services or applications to be created by leveraging other interactive applications across the Web.”

“To accomplish these goals, all WSXL component services implement a set of base operations for lifecycle management, accepting user input, and producing presentation markup. More sophisticated WSXL component services may be specialized to represent data, presentation, and control. WSXL also introduces a new description language to guide the adaptation of user experience to new distribution channels.”

“User experiences that are implemented using WSXL can be delivered to end users through a diversity of distribution channels—for example, directly to a browser, indirectly through a portal, or by embedding into a third-party interactive Web application. In addition, WSXL user experiences can easily be modified, adapted, aggregated, coordinated, synchronized or integrated, often by simple declarative means. New applications can be created by seamlessly combining WSXL applications and adapting them to new uses, to ultimately leverage a worldwide pallet of WSXL component services.” ^[7]

WSXL can be thought of as putting a face to Web services. All the other technologies and standards discussed in this chapter operate behind the scenes providing the foundation for a Web services architecture, but WSXL makes it possible to integrate Web services more easily into interactive user environments such as portals.

As with all of the standards discussed in the emerging standards section, it is to early to tell if WSXL will find broad support and the required governance of a standards organization, but the ability to integrate Web services into rich interactive environments will inevitably be an essential requirement as Web services continue to gain momentum.

^[2]www.cio.com, CIO Magazine, January 15, 2002, “Costly, Painful and Worth It” by Derek Slater.

^[3]Gartner Research, February 28, 2002, “Enterprise Integration: A Key Driver for Web Services Adoption” by Debanish Sinha.

^[4]www.microsoft.com, Microsoft Press Release, September 13, 1999, “Windows DNA 2000 Provides Pervasive XML Support For Next-Generation Web Development.”

^[5]www.ibm.com, IBM, August 2002, “Transactions in the World of Web Services, Part 1” by Tom Freund and Tony Storey.

^[6]www.infoworld.com, InfoWorld, October 14, 2002, “Netegrity Minding the Web Services Security Store” by Brian Fonseca.

^[7]www.ibm.com, IBM, April 10, 2002, “(WSXL) Web Service Experience Language Version 2.”