No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, photocopying, recording or otherwise, without prior written consent of IONA Technologies Ltd. No patent liability is assumed with respect to the use of the information contained herein. While every precaution has been taken in the preparation of this material, IONA Technologies Ltd assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice.

Copyright © 2001 IONA Technologies Ltd. All rights reserved.

The program and information contained herein are licensed only pursuant to a license agreement that contains use, reverse engineering, disclosure and other restrictions; accordingly, it is "Unpublished -- rights reserved under the applicable copyright laws".

Orbix is a registered trademark of IONA Technologies Ltd.

CORBA, OMG IDL are trademarks of The Object Management Group, Inc.

All other products or services mentioned in this manual are covered by the trademarks, service marks, or product names as designated by the companies who market those products.

Web Services defines a new view on the paradigm of distributed programming and provision of applications, one that is firmly attached to the public Internet. Technologies such as SOAP and UDDI help provide the basis for communication and discovery of web service implementations. These technologies together enable the construction of distributed internet-based applications. Neither SOAP nor UDDI are near mature technologies, and already a requirement for a means to formally define the characteristics of a web service has emerged. This requirement has led to the creation of the WSDL 1.1 specification, a publicly available XML-based definition language for web service descriptions.

This paper is intended to illustrate the positions of IONA with respect to the requirement for a formal web service definition mechanism and our thoughts on what this definition mechanism must cover and contain.

IONA believes that there is a clear and present requirement for a standard means to describe the nature of web services in a formal manner. Today web services are essentially published, discovered, and interacted with via proprietary mechanisms.

In particular, we see a need to create a formal definition of web services that’s flexible and extensible enough to support interactions with currently deployed distributed programming technologies such as CORBA and Enterprise Java Beans as well as the new wave of B2B document flows (also called trading partner agreement flows).

Web service definitions should be abstract and independent of the underlying transport protocol, and should be easily extended to represent multiple interaction patterns such as publish and subscribe, synchronous and asynchronous messaging, multicast, and document exchange.

Figure 1, Generic Web Service implementation architecture.

Figure 1 illustrates the relationship of the proposed web services description language to the XML Protocols activity within W3C and to existing programming paradigms and document interactions. The XML Protocols activity recognizes the potential requirement for multiple transports, such as http and beep, and the service description language therefore also needs to be capable of handling them.

This paper will refer to XMLP as an intrinsic part of the web services architecture – please refer to the ongoing W3C XML Protocol working group ongoing development of this standard.

In order to accomplish the functionality represented in Figure 1, a way to describe web services in sufficient detail is required. The XMLP message itself should not have to be concerned with either the nature of its eventual target program (whether COM/COM+, CORBA, EJB, or asynchronous messaging such as JMS) or the processing of the message itself when the target is reached. XMLP does not define an executable environment, but rather a specific mapping to and from XML to achieve application level interoperability over http and potentially other transports.

A consistent approach to defining the information guiding this mapping is required to avoid the problem of private mappings, private agreement interpretations, and incompatible approaches to the mappings.

This is the goal of interoperability, at a level that does not just address the issues of API compliance and type system mapping, but predictable and coherent function for the semantics of entire interactions.

Solutions to this problem exist today in the industry, but without a common approach the goal of mapping web services in a generic way across the Internet will be difficult, if not impossible to achieve. The next generation of the Web depends on making programs in popular development environments accessible in a generic, consistent fashion that’s easy to use and easy to understand.

In addition, the case of business process document exchange (or B2B interaction) requires a mechanism for initialization or bootstrapping information among trading partners. Trading partners need a standard way to identify the business documents they wish to exchange, and the interaction patterns they wish to support within those exchanges. For example, a parts supplier might accept a RosettaNet purchase order, and agree to acknowledge receipt immediately or asynchronously via email or later invocation of another web service, allowing standard XML protocols to be used for RosettaNet, ebXML, and other electronic commerce standards. The requirements for document exchange, business interaction flow, and trading partner agreements must be represented in a standard, consistent way in order to achieve rapid, efficient growth of commerce over the Web. Manual intervention and private agreements among trading partners inhibits the take up of modern, Web-based trading mechanisms.

Figure 2, Service descriptions and registries

Figure 2 illustrates how web services can be defined for XMLP "servers" (use of that term is loose while the XMLP glossary and abstract model work completes) so that XMLP "clients" can discover their location on the web. The service descriptions represent to the Web community the description of an XML "proxy" or "wrapper" for existing and new applications, including those developed using the emerging J2EE environments (which include CORBA services for RPC, security, and transactions). The applications therefore can be integrated with other applications anywhere in the Web, allowing the same client to access all applications described this way in a uniform, simple fashion. Thus can the next generation of the web be built on top of existing and new business application infrastructure, leveraging the large http network and networks built on other transports, to facilitate the creation of new single and integrated services without regard for geographic or corporate boundaries.

The relationship of web services to J2EE, CORBA, and B2B process documents is critical to the successful integration of existing and new applications with the next generation of the Web. This is because these technologies are themselves motivated by requirements for interoperability, and resolving the backend or legacy application integration problem using a common, object-oriented methodology and standards-based, open approach. It’s important that any web services defined as part of W3C work relate seamlessly, intuitively, and easily to open J2EE and CORBA standards for back-end integration, and at the same time facilitate the easy and intuitive exchange of business process documents over the Web.

A single unifying, extensible and flexible mechanism is needed to meet these requirements. WSDL is the current candidate for providing this mechanism.

WSDL is the result of a merge of two distinct approaches to web service definition, SCL and NASSL, used by Microsoft and IBM, respectively. WSDL describes a web service as a collection of related concrete and abstract XML-described artifacts. The description elements cover the most crucial features that a contract will require to provide some level of interoperability, such as an API, a default type system and a means to represent network endpoints. WSDL also provides a means to extend the contract with proprietary decorations.

There are a number of individually released toolkits that process and use WSDL to describe services that have been implemented in various ways. These, plus use of our own toolkit has given us some idea of how WSDL relates to current implementation technologies.

We have successfully used WSDL to describe EJB remote interfaces, as well as standard Java bean interfaces for communication over SOAP. Many of the available packages and toolkits that provide some support for WSDL provide similar facilities. This implies that WSDL can successfully describe enterprise and standard Java bean implemented web services, with some caveats:

• WSDL uses the XML Schema data typeset as its intrinsic type system. To successfully generate WSDL descriptions for EJBs (and vice versa) in an interoperable manner, there is a clear requirement for a standardized mapping approach between Java types and XML Schema types.
• WSDL Extensibility Elements may be added to include information that is relevant to the quality of service decorations on an interaction. In the case of EJB this is particularly relevant in the areas of security and transactions. Because extensibility elements may be added in an ad-hoc manner, their unilateral development and use can be an interoperability issue. There is a clear requirement for a standard ‘profile’ of extensibility elements for EJB and standard bean support.

We have successfully used WSDL to describe CORBA interfaces for communication over SOAP and over IIOP. There are a number of commercially available toolkits that bridge from SOAP to CORBA objects, some of which may support WSDL. The implication here is that, similarly to the EJB instance, WSDL can successfully describe CORBA interfaces, with some caveats:

We have just begun our investigation of the relationship of WSDL to B2B standards such as Rosettanet and ebXML, following the acquisition of Netfish Technologies. Initial discussions support the ebXML transport specification mapping ebXML to SOAP with attachments, and WSDL certainly has potential to describe this type of B2B interaction mechanism. Beyond that, we see the possibility of extending WSDL with other aspects of ebXML such as trade partner agreement interaction mechanisms and quality of service decorations similar to those proposed for EJB and CORBA. We expect this picture to become much clearer in the coming months.

In this paper, we have seen that there is a clear requirement for a standard description language and method for web services. Furthermore, we have seen that WSDL 1.1 has been shown to be effective in describing simple web services implemented as standard and enterprise Java beans as well as CORBA objects. This section presents some conclusions that we have drawn from the use of WSDL with these systems and as a general approach to description.

WSDL has taken the concepts of concrete and abstract description entities and married them in the description language. This is a good start for the description of web services that allows descriptions to be reused.

Basic WSDL (without extensibility elements) implies that the web service implementation is stateless. This should be reconsidered and the case for stateful services be made.

WSDL is gaining popularity in the industry and will be used more and more. To be successful, there needs to be a standard web services description. WSDL may serve as a basis for such a standard.

In a popular approach, many toolkits that support WSDL allow the generation of WSDL descriptions from Java interfaces or some other interface description technology. This is only part of web services design – there should be an emphasis on the ‘design the service’ first, then map it to an implementation. In other words, some consideration should be given toward the possibility of generating Java interfaces from WSDL.

Generating the WSDL a starting point is a good practice, but web service developers should be aware that there may an impedance mismatch between the Java APIs that an application provides and the Web Service API that is to be public.

Description of a web service may profit from the work that is going on in the abstract model subgroup of the XML Protocol working group.

Any standard, to be useful, must be testable. There is a requirement for a test or suite of tests that will prove that a particular web service definition is conformant.

A sophisticated service definition will describe the flow of information that a particular service receives or initiates. This is required for business applications that wish to provide some interaction with business processes.