Contents
News Highlights
[September 29, 2000] On September 25, 2000, Ariba, IBM, and Microsoft jointly issued a specification for a 'Web Services Description Language (WSDL)' which defines an XML grammar "for describing network services as collections of communication endpoints capable of exchanging messages." Authors include Erik Christensen (Microsoft), Francisco Curbera (IBM), Greg Meredith (Microsoft), and Sanjiva Weerawarana (IBM). This published WSDL specification "represents the current thinking with regard to descriptions of services within Ariba, IBM and Microsoft, and consolidates concepts found in NASSL, SCL, and SDL (earlier proposals)." Document abstract: "WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME. This version of the WSDL language is a first step that does not include a framework for describing the composition and orchestration of endpoints. A complete framework for describing such contracts will include means for composing services and means for expressing the behavior of services, i.e., the sequencing rules for sending and receiving messages. Composition of services must be type safe but also allow for reference passing with service references being exchanged and bound at runtime. The latter being key for negotiating contracts at runtime and capturing the behavior of referral and brokering services. The authors of the WSDL specification intend to publish revised versions of WSDL and/or additional documents in a timely fashion which will include a (1) framework for composing services and a (2) framework for describing the behavior of services."
Principal URLs
W3C Web Services Description Working Group:
- Web Services Description Working Group home page
- W3C Web Services Description Working Group Charter
- W3C Web Services Description Working Group Issues List
- Mailing list archives for public list 'www-ws-desc'
- W3C Web Services Activity. The W3C Web Services Description Working Group is part of the Web Services Activity, and in the W3C Architecture Domain.
WSDL Version 2.0:
- Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. W3C Working Draft 26-March-2004.
- Web Services Description Language (WSDL) Version 2.0 Part 2: Message Exchange Patterns. W3C Working Draft 26-March-2004.
- XML Schema for WSDL 2.0
- "Handling Privacy in WSDL 2.0." W3C Team Submission. 13-February-2004. Edited by Hugo Haas and Rigo Wenning (W3C).
- WSDL 2.0 validation tools (Eclipse WSVT).
- "Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings." Editors' copy, 2004/04/01 or later
- "Web Services Description Language (WSDL) Version 2.0 Part 0: Primer." Editors' copy. 2003/11/05 or later.
- WSDL 2.0 Editor's TODO List
Earlier WSDL References:
- Web Services Description Language (WSDL) Version 1.2 Part 1: Core Language W3C Working Draft 11-June-2003.
- Web Services Description Language (WSDL) Version 1.2 Part 2: Message Patterns. W3C Working Draft. 11-June-2003.
- Web Services Description Language (WSDL) Version 1.2 Part 3: Bindings. W3C Working Draft 11-June-2003.
- Web Services Description Requirements. W3C Working Draft 28 -October-2002. Also in PDF format [cache]
- Web Service Description Usage Scenarios. W3C Working Draft 04-June-2002.
- Announcement: "World Wide Web Consortium Publishes First Public Working Draft of Web Services Description Language (WSDL) 1.2. W3C Produces Open Web Services Vocabulary with Improved XML Interoperability."
- Web Services Description Language (WSDL) 1.1. Reference: W3C Note 15-March-2001. By Erik Christensen (Microsoft), Francisco Curbera (IBM Research), Greg Meredith (Microsoft), and Sanjiva Weerawarana (IBM Research). Latest version.
Articles, Papers, Reports, News
[October 2003] "Understanding WSDL." By Aaron Skonnard. From Microsoft MSDN Library. October 2003. " The Web Services Description Language (WSDL) provides an XML grammar for describing these details. WSDL picks up where XML Schema left off by providing a way to group messages into operations and operations into interfaces. It also provides a way to define bindings for each interface and protocol combination along with the endpoint address for each one. A complete WSDL definition contains all of the information necessary to invoke a Web service. Developers that want to make it easy for others to access their services should make WSDL definitions available. WSDL plays an important role in the overall Web services architecture since it describes the complete contract for application communication (similar to the role of IDL in the DCOM architecture)... WSDL builds on XML Schema by making it possible to fully describe Web services in terms of messages, operations, interfaces (portTypes), bindings, and service endpoints. WSDL definitions make it possible to generate code that implements the given interface, on either the client or the server, making Web services accessible to the masses..."
[August 05, 2003] "UML for Web Services." By Will Provost. From O'Reilly WebServices.xml.com (August 05, 2003). ['In recent years, many software developers have used the Unified Modeling Language, UML, as an aid to designing software systems. As new software strategies such as web services emerge, it becomes important that they can be used within the strictures of formal design. In this article Will Provost shows in detail how web service applications can be designed with UML. Provost covers an implementation process that leads from UML to WDSL and W3C XML Schema to program code.'] "You've heard the hype, you've read the literature, and you're convinced that web services is the next step. You know SOAP and WSDL, and you're ready to build something. It's time to take web services to the white board. You don't want to go plunging into your first web-services project without a proper design process, right? Enter the Unified Modeling Language, which is the white board notation for object-oriented analysis and design (and much more), offering a natural fit to RPC-style service design. In a recent XML.com article I talked about the importance of working from WSDL and W3C XML Schema (WXS) as the source language for web-service development, as opposed to starting from a chosen implementation language and generating WSDL and SOAP code. This is right and good, but WSDL is neither comprehensive nor easy enough to work well as a design language. So the process we really want is not just WSDL-to-Impl, but UML-to-WSDL-to-Impl. [That is:] design in UML, express service semantics in WSDL and WXS, and implement in a supporting programming language. One big advantage of a UML design process is that UML -- through stereotypes, mostly -- can express designs over three important domains: WSDL for messaging semantics, WXS for serializable types, and the OO service or client implementation language. In an earlier article I laid out a convenient UML notation (know as a 'profile') for WXS types. This article will focus on two new capabilities: (1) Modeling WSDL components for service semantics, such as port types, ports and services; (2) Integrating WSDL, WXS, and traditional OO types for effective modeling of web services: interoperable description, service and client implementations in concise diagrams that explicitly relate these various types... Web-service designs will need to express certain WXS constructs frequently: complex types, built-in simple types, and enumerations are all most tools support so far... I'll be combining types from three different profiles I'll apply the namespace prefix xs: to the stereotypes from the WXS notation. Similarly, for the few stereotypes I'm about to introduce I'll use wsdl:... To illustrate the UML notation I'll build up a design for a simple service called 'Love Is Blind', which offers an online dating service based on simple matching queries over sex, age, and interest keywords. Members will be registered in a database with attributes for sex, age, interests, nickname, and picture; each will also have a unique member ID and a password. The service will offer a simple use case to walk-in clients: [1] Query the database for matches, receiving a result set of member profiles, [2] Send a love note to one or more members as found in the result set, passing in name, email address, and message text. Other use cases for other roles such as members and administrators will be developed along the way. Our goal will be to develop a UML design document that expresses the WSDL description, including supporting WXS types, the service implementation, and client interactions with the service..."
[July 22, 2003] "WSDL First." By Will Provost. In O'Reilly WebServices.xml.com (July 22, 2003). "Web services vendors will tell you a story if you let them. 'Web services are a cinch,' they'll say. 'Just write the same code you always do, and then press this button; presto, it's now a web service, deployed to the application server, with SOAP serializers, and a WSDL descriptor all written out.' They'll tell you a lot of things, but probably most glorious among them will be the claim that you can develop web services effectively without hand-editing SOAP or WSDL. Does this sound too good to be true? Perhaps the case can be made that in some cases SOAP has been relegated to the role of RPC encoding, that it's no more relevant to the application developer than IIOP or the DCOM transport. When it comes to WSDL, though, don't buy it. If you're serious about developing RPC-style services, you should know WSDL as well as you know WXS [W3C XML Schema]; you should be creating and editing descriptors frequently. More importantly, a WSDL descriptor should be the source document for your web service build process, for a number of reasons, including anticipating industry standardization, maintaining fidelity in transmitting service semantics, and achieving the best interoperability through strong typing and WXS. The willingness in some quarters to minimize the visibility of service description betrays a more basic and troubling bias, one which has to do with code-generation paths and development process. It assumes that service semantics are derived entirely from application source code. There are two viable development paths for RPC-style service development: from implementation language to WSDL and vice-versa. In fact, to start from the implementation language is the weaker strategy... WSDL first offers a clear advantage in interoperability of generated components. Under the WS-I Basic Profile, and in all typical practice, web services rely on WXS as the fundamental type model. This is a potent choice. WXS offers a great range of primitive types, simple-type derivation techniques such as enumerations and regular expressions, lists, unions, extension and restriction of complex types, and many other advanced features. To put it simply, WXS is by far the most powerful type model available in the XML world. It's more flexible than relational DDLs and much more precise and sophisticated than the type system of many programming languages. Why would we choose to use anything else to express service semantics? What good are WXS's advanced features if they can't be mapped to the implementation language?... For new service development, and even for most adaptations of existing enterprise code assets, the WSDL-to-Impl path is the most robust and reliable; it also fits the consensus vision for widely available services based on progressively more vertical standards. It does a better job of preserving service semantics as designed, and it offers best interoperability based on the rich type model of WXS..."
[July 14, 2003] "Using WSDL in a UDDI Registry, Version 2.0." By John Colgrave (IBM) and Karsten Januszewski (Microsoft). Edited by Anne Thomas Manes and Tony Rogers (Computer Associates). Technical Note produced by the OASIS UDDI Specification Technical Committee. Document Identifier: uddi-spec-tc-tn-wsdl-v2. 42 pages. According to a posting from Tom Bellwood Tom Bellwood (Co-Chair, OASIS UDDI Specification TC), this document was approved as a Committee Technical Note. Send comments to uddi-spec-comment@lists.oasis-open.org. Summary: "This document is an OASIS UDDI Technical Note that defines a new approach to using WSDL in a UDDI Registry." From the Introduction: " The Universal Description, Discovery & Integration (UDDI) specification provides a platform-independent way of describing and discovering Web services and Web service providers. The UDDI data structures provide a framework for the description of basic service information, and an extensible mechanism to specify detailed service access information using any standard description language. Many such languages exist in specific industry domains and at different levels of the protocol stack. The Web Services Description Language (WSDL) is a general purpose XML language for describing the interface, protocol bindings, and the deployment details of network services. WSDL complements the UDDI standard by providing a uniform way of describing the abstract interface and protocol bindings of arbitrary network services. The purpose of this document is to clarify the relationship between the two and to describe a recommended approach to mapping WSDL descriptions to the UDDI data structures. Consistent and thorough WSDL mappings are critical to the utility of UDDI... The primary goals of this mapping are: (1) To enable the automatic registration of WSDL definitions in UDDI; (2) To enable precise and flexible UDDI queries based on specific WSDL artifacts and metadata; (3) To maintain compatibility with the mapping described in the Using WSDL in a UDDI Registry, Version 1.08 Best Practice document; (4) To provide a consistent mapping for UDDI Version 2 and UDDI Version 3; (5) To support any logical and physical structure of WSDL description. This mapping prescribes a consistent methodology to map WSDL 1.1 artifacts to UDDI structures. It describes an approach that represents reusable, abstract Web service artifacts, (WSDL portTypes and WSDL bindings) and Web service implementations (WSDL services and ports). Tools can use this mapping to generate UDDI registrations automatically from WSDL descriptions. This mapping captures sufficient information from the WSDL documents to allow precise queries for Web services information without further recourse to the source WSDL documents, and to allow the appropriate WSDL documents to be retrieved once a match has been found. Given that the source WSDL documents can be distributed among the publishers using a UDDI registry, a UDDI registry provides a convenient central point where such queries can be executed... This document builds on Using WSDL in a UDDI Registry, Version 1.08, providing an expanded modeling practice that encompasses the flexibility of WSDL. The primary difference between this mapping and the one described in the existing Best Practice is that this mapping provides a methodology to represent individual Web services artifacts."
[August 05, 2003] "WDSL Tales From the Trenches, Part 3." By Johan Peeters. From O'Reilly WebServices.xml.com (August 05, 2003). ['Continuing the focus on sound design, we have the third and final installment of Johan Peeters' "WSDL Tales from the Trenches." Peeters concentrates on the importance of modeling the data elements involved in web services, and explains the best strategies for using W3C XML Schema to model this data.'] "I examine the type definitions and element declarations in the types element of a WSDL document. Such types and elements are for use in the abstract messages, the message elements in a WSD. WSDL does not constrain data definitions to W3C XML Schema (WXS). However, alternatives to WXS are not covered in this article: the goal of the series is to provide help and guidance with current real-world problems, and I have not seen any of the alternatives to WXS being used for web services on a significant scale to date. This may change in the future: while only the WXS implementation is discussed in the WSDL 1.1 spec, it was always the intention of the WSDL designers to provide several options. The WSDL 1.2 draft's appendix on Relax NG brings this closer to realization. Data modeling with WXS is not for the faint-hearted. It presents a lot of pitfalls. This article will point some of these out and helps you avoid them..." On WSDL 1.2, see the announcement "W3C Releases Three Web Services Description Language (WSDL) 1.2 Working Drafts." The non-normative Appendex E ('Examples of Specifications of Extension Elements for Alternative Schema Language Support') in the WSDL Part 1: Core WD includes a section on RELAX NG: "A RELAX NG schema may be used as the schema language for WSDL. It may be embedded or imported; import is preferred. A namespace must be specified; if an imported schema specifies one, then the [actual value] of the namespace attribute information item in the import element information item must match the specified namespace. RELAX NG provides both type and element definitions which appear in the {type definitions} and {element declarations} properties of [Section 2.1.1] 'Definitions Component' respectively..."
[June 24, 2003] "WSDL Tales From The Trenches, Part 2." By Johan Peeters. From O'Reilly WebServices.xml.com (June 24, 2003). "In Part 1 of 'WSDL Tales From the Trenches' I painted a big picture of web services design: Web Services Description Language (WSDL) only defines the syntax of how a web service may be invoked; it says nothing about its semantics. I will observe this distinction in what I say in this article about WSDL. The version of WSDL being most widely used now, 1.1, is published as a W3C Note. It is not an official standard. WSDL 1.1 offers a lot of latitude for invoking web services. Tool support tends to be patchy. WSDL gets a lot of bad press because it got the trade-off wrong between expressivity and flexibility on the one hand and verbosity and complexity on the other. Before we proceed, I will come clean and tell you that I am at a loss to tell you how to write truly clear, crisp WSDL... it helps to use an XML-aware editor when you write WSDL, preferably one with the capability to validate the WSDL document. When retrofitting WSDL to existing web services, I find it very useful to be able to generate, send, and receive messages from the editor... [As to modular web service descriptions:] Using the import keyword, you can separate a WSD into modular documents. An example in the W3C Note uses three documents, which contain, respectively, data type definitions, abstract definitions, and specific service bindings. The specific or concrete service definitions depend on the abstract service definitions, which in turn depend on the data type definitions. Apart from improving readability, this technique also improves opportunities for certain types of extension and reuse: the same data type definitions can be used across many abstract services, and the same abstract services can be offered through many different bindings, at many addresses. Initially, a set of web services may be represented as a set of three documents. As services grow, however, this may evolve into a tree of documents with the data type definitions at its root, branching into several abstract services documents, and further fanning out to concrete services... The draft available at the time of writing says that the 'targetNamespace attribute information item defines the namespace affiliation of top-level components defined in this definitions element information item. Messages, port types, bindings and services are top level components.' Whether WSDL 1.2 will support implementing several interfaces in a single service is hotly debated right now. The WSDL 1.2 draft states explicitly that the same rules against sharing namespaces with imported documents apply as in XML Schema. On the other hand, an alternative mechanism for modularizing descriptions is provided via an include element modeled on XML Schema's include element that does allow sharing of namespaces..."
[May 27, 2003] "WSDL Tales From The Trenches, Part 1." By Johan Peeters. From O'Reilly WebServices.xml.com (May 27, 2003). ['Web services are still in their infancy as a technology, and there's relatively little practical experience available to draw on. Johan Peeters describes best practices and common errors he has discovered while deploying web services in the field.'] "Recently I retrofitted WSDL to a set of existing web services. A customer had a server running and there was a client implementation. The client and server team had been working closely together and now the time had come for another client implementation by a development team on the other side of the globe. A clear specification of the services was needed, and that's what WSDL is for. So I set out to make explicit what was previously implicit. It turned out to be an instructive experience, reaffirming some good old software engineering practices and uncovering a new set of problems specific to web services, WSDL, and XML Schema. There were clearly some design flaws at the outset which were hard to pinpoint. It is likely that these mistakes would not have been made if the designers had formally written down their service definitions in WSDL. So this is the core message of the series: write WSDL up front, do not generate it as an afterthought, as is often suggested by vendors... This series will not provide an overview of WSDL; it also assumes familiarity with W3C XML Schema. This first article in the series considers what sound software engineering practice and distributed computing experience offer to web service design. I review some of the important design decisions that a web service designer must make and offer some advice to guide the process. The rest of the series is about how to represent the design. In the second article I shine a light in some of the dark corners of the WSDL 1.1 specification, leaving out data type definitions, which are the subject of the third article. I look at WXS it from the perspective of someone who uses it to specify the data which will be sent across the web service interface. ... Ideally, when designing web services, you should not have to worry about implementation issues. The whole point of design is that you look at the system at a high level of abstraction, not allowing the implementation complexities to befuddle you. But you can make all the right design choices and the design will be useless if the tool chains that are going to be used do not support the constructs in your WSDL. I strongly recommend prototyping the design specification as a reality check. This edge is still raw..."
[March 21, 2003] "Using WSDL in a UDDI Registry, Version 2.0." Edited by Anne Thomas Manes and Tony Rogers. Technical Note produced for the OASIS UDDI Specifications TC. Document identifier: uddi-spec-tc-tn-wsdl-20030319-wd. Announced in a posting by John Colgrave; comments are welcome for the next thirty days. The TN defines a new approach to using WSDL in a UDDI Registry. "The Universal Description, Discovery and Integration (UDDI) specification provides a platform-independent way of describing and discovering Web services and Web service providers. The UDDI data structures provide a framework for the description of basic service information, and an extensible mechanism to specify detailed service access information using any standard description language. Many such languages exist in specific industry domains and at different levels of the protocol stack. The Web Services Description Language (WSDL) is a general purpose XML language for describing the interface, protocol bindings, and the deployment details of network services. WSDL complements the UDDI standard by providing a uniform way of describing the abstract interface and protocol bindings of arbitrary network services. The purpose of this document is to clarify the relationship between the two and to describe a recommended approach to mapping WSDL descriptions to the UDDI data structures. Consistent and thorough WSDL mappings are critical to the utility of UDDI. The primary goals of this mapping are: (1) To enable the automatic registration of WSDL definitions in UDDI; (2) To enable precise and flexible UDDI queries based on specific WSDL artifacts and metadata (3) To maintain compatibility with the mapping described in the Using WSDL in a UDDI Registry, Version 1.08 Best Practice document; (4) To provide a consistent mapping for UDDI Version 2 and UDDI Version 3; (5) To support any logical and physical structure of WSDL description. This mapping prescribes a consistent methodology to map WSDL 1.1 artifacts to UDDI structures. It describes an approach that represents reusable, abstract Web service artifacts, (WSDL portTypes and WSDL bindings) and Web service implementations (WSDL services and ports). Tools can use this mapping to generate UDDI registrations automatically from WSDL descriptions. This mapping captures sufficient information from the WSDL documents to allow precise queries for Web services information without further recourse to the source WSDL documents, and to allow the appropriate WSDL documents to be retrieved once a match has been found. Given that the source WSDL documents can be distributed among the publishers using a UDDI registry, a UDDI registry provides a convenient central point where such queries can be executed..." Also in PDF format. [cache]
[March 07, 2003] "Web Services Description Language (WSDL) Version 1.2." Edited by Roberto Chinnici (Sun Microsystems), Martin Gudgin (Microsoft), Jean-Jacques Moreau (Canon), and Sanjiva Weerawarana (IBM Research). W3C Working Draft 3-March-2003. Version URL: http://www.w3.org/TR/2003/WD-wsdl12-20030303. Latest version URL: http://www.w3.org/TR/wsdl12. Change log. Produced by members of the Web Services Description Working Group as part of the W3C Web Services Activity. See the archives for the public comment list and discussion list. Document also available in non-normative formats PDF and XML. "Web Services Description Language (WSDL) provides a model and an XML format for describing Web services. WSDL enables one to separate the description of the abstract functionality offered by a service from concrete details of a service description such as 'how' and 'where' that functionality is offered. This specification defines a language for describing the abstract functionality of a service as well as a framework for describing the concrete details of a service description. The companion specification, WSDL Version 1.2: Bindings defines a language for describing such concrete details for SOAP 1.2 (SOAP 1.2 Part 1: Messaging Framework), HTTP (IETF RFC 2616) and MIME (IETF RFC 2045). WSDL describes Web services starting with the messages that are exchanged between the service provider and requestor. The messages themselves are described abstractly and then bound to a concrete network protocol and message format. A message consists of a collection of typed data items. An exchange of messages between the service provider and requestor are described as an operation. A collection of operations is called a port type. A service contains a collection of ports, where each port is an implementation of a portType, which includes all the concrete details needed to interact with the service..."
[February 25, 2003] "Cape Clear Software Ships New Release of Free Web Services Editor." - "Cape Clear Software has today released a new version of its free WSDL (Web Services Description Language) Editor. The WSDL Editor provides a friendly, graphical environment for creating and editing WSDL, the key building block of Web Services. The editor has been designed for both experienced and novice Web Services developers and works with existing languages such as .NET, Java, J2EE, and CORBA. This latest release makes the creation of Web Services faster and easier, while adding support for building Web Services from large XML Schema. 'Over thirty thousand programmers are using the first release of our WSDL Editor,' said John Maughan, director of engineering at Cape Clear Software. 'The overwhelming feedback from these users has provided us with a rich resource for future product development, and to illustrate our commitment to the community we've upgraded the free editor to incorporate new features and improvements that make it faster and easier to edit and create Web Services.' 'The WSDL Editor is significant because software developers are increasingly placing WSDL at the center of their Web Services development process. It facilitates good Web Service design, enables the reuse of existing data type definitions, and can be used to automatically generate service implementations without developer effort,' continued Maughan. This release of the WSDL Editor introduces a range of improvements over the previous release including: (1) Improved graphical environment, which makes creating and editing Web Services faster and easier. (2) New automated wizards that simplify the creation and editing of proprietary and industry-specific XML Schemas. (3) Support for large XML Schemas, which enables developers to create Web Services that interface to existing business processes. (4) Simplified process for creating different WSDL elements such as service definitions, port types, binding, template operations, and messages. (5) Broader support for WSDL validation against WSDL schema and WSDL profiling. (6) Advanced WSDL capabilities such as imports, faults, SOAP headers, multiple bindings, and parameter ordering, as defined in the latest WSDL specification. (7) Easier retrieval of WSDL files from across corporate networks, UDDI repositories, or the Internet..." See also the news story from 2002-09-04.
[December 18, 2002] "Publish and Find UDDI tModels with JAXR and WSDL." By Frank Sommers. In JavaWorld (December 13, 2002). ['This article presents a programming model for publishing and discovering Web services based on service interfaces. It starts by defining reusable WSDL (Web Services Description Language) interface documents and shows how to register those interfaces as UDDI (Universal Description, Discovery, and Integration) tModels using the Java API for XML Registries (JAXR). Then the article focuses on how Web service clients use well-known tModels to discover and invoke services that adhere to a set of interfaces.'] "... The pattern of finding all implementations of a Web service interface and possibly invoking those service instances proves useful in other contexts as well. Portal Websites still rely on manual -- or semi-manual -- compilation of news articles, automobile inventories, available hotel rooms, or airline seats. Even when data exchanges electronically, that automation often comes at the expense of lengthy and pricey system integration. Among the biggest motivations for building Web services is the desire to automate those tedious information-gathering tasks. This article provides a working example of how UDDI (Universal Description, Discovery, and Integration) registries, the Java API for XML Registries (JAXR), and the Web Services Description Language (WSDL) work together to initiate that automation. Currently, several industry groups are working to define Web service interface standards. Examples are the Open Travel Alliance for travel, the Star Consortium for automotive retail, and RosettaNet for supply chain management. Many of those groups employ a community-oriented process and make their specifications available to anyone for comments. Real-world interface specifications aim to be comprehensive and are rather complex. Thus, to make this article easy to follow, I use a simple interface definition for the example cruise ship destination Web service. That interface features only a single method. When invoked, that method produces a list of destinations a cruise company serves..."
[December 02, 2002] "Using WSDL in a UDDI Registry." UDDI Spec TC Best Practice document. Reference: Version 1.08, uddi-spec-tc-bp-using-wsdl-v108-20021110. 12 pages. Edited by John Colgrave (IBM) and Karsten Januszewski (Microsoft). Contributors: Francisco Curbera (IBM), David Ehnebuske (IBM), and Dan Rogers (Microsoft). A posting from Luc Clément (Co-chair, OASIS UDDI Spec TC) announced the results of a TC vote which approved version 1.08 of Using WSDL in a UDDI Registry as a Best Practice document. A Best Practice "is a non-normative document accompanying a UDDI Specification that provides guidance on how to use UDDI registries. Best Practices not only represent the UDDI Spec TC's view on some UDDI-related topic, but also represent well-established practice." Using WSDL in a UDDI Registry "describes the current Best Practice for constructing UDDI entities from, or relating to, WSDL descriptions of web services." From the Introduction: "The Universal Description Discovery and Integration (UDDI) specification provides a platformindependent way of describing services, discovering businesses, and integrating business services using the Internet. The UDDI data structures provide a framework for the description of basic business and service information, and architects an extensible mechanism to provide detailed service access information using any standard description language. Many such languages exist in specific industry domains and at different levels of the protocol stack. The Web Services Description Language (WSDL) is a general purpose XML language for describing the interface, protocol bindings and the deployment details of network services. WSDL complements the UDDI standard by providing a uniform way of describing the abstract interface and protocol bindings of arbitrary network services. The purpose of this document is to clarify the relationship between the two, describe how WSDL can be used to help create UDDI business service descriptions."
[November 27, 2002] "Explore the Web Services Bus, Part 1. Using a UDDI-Based Discovery Mechanism to Make Publishing and Discovering Web Services a Breeze." By Greg Flurry (Senior Technical Staff Member, IBM Software Group). From IBM developerWorks, Web services. November 2002. ['If you've downloaded version 3.2.2 of the Web Services Toolkit from IBM alphaWorks, you already have the Web Services Bus, a framework for constructing Web services processors. In this two-part series, Greg Flurry shows you how to get started using the Bus to get your Web services into production faster and more easily. In this first installment, you'll learn about the Bus's UDDI-based discovery mechanism, and examine an experimental practice that will help automate the process of publishing Web services.'] "The Web Services Bus, available in version 3.2.2 of the Web Services Toolkit at IBM alphaWorks, is a framework for constructing Web services processors. With the Bus, you can create Web service clients, servers, gateways, intermediaries, and more. The Bus goes beyond other Web services frameworks to offer an enhanced environment for conducting dynamic e-business with Web services. It supports service requestors with a client-side on-ramp and supports service providers with a server-side off-ramp. The Bus, through its Web Services Invocation Framework (WSIF) heritage, has WSDL at its core; Web services deployed in the bus off-ramp (called bus services) can be described with WSDL, and the off-ramp can dynamically generate WSDL for bus services. Further, the Bus off-ramp optionally publishes information about bus services in UDDI registries. In addition, the Bus supports formalized, pluggable discovery and selection mechanisms in the Bus on-ramp. Briefly, the Bus accepts requests for a particular implementation of a WSDL portType, but invokes the discovery and selection mechanisms to direct the requests to different implementations. The pluggable discovery and selection mechanisms can use any means desired to find candidate implementations and subsequently select one desired implementation from among the candidates... [You will] learn about a number of aspects of the Web Services Bus related to WSDL, UDDI, and Bus discovery. In particular, how to create a UDDI registry-based discovery mechanism, and how to leverage an experimental practice implemented by the Bus to do efficient searches in a UDDI registry for services implementing a particular portType. A more sophisticated discovery mechanism could examine other UDDI registries, WSIL registries, databases, or other sources of candidate implementations for the portType. Similarly, though the sample code selects a service at random, a more sophisticated selection mechanism could make an intelligent choice, perhaps based on cost or service level agreement terms, if such information were available. One final thought: Though the discovery implementation in this example ran in the client on-ramp, similar techniques can be used in the Bus's server on-ramp. This would allow the Bus server side to be configured to do interesting things as an intermediary, similar to the Web Services Gateway, also available on alphaWorks... In a future article, I'll examine bus filters, another feature of the Web Services Bus that enhances the Bus's abilities as a framework for Web services..."
[November 12, 2002] "Take Advantage of Existing External XML Schemas with a Custom Import Framework in ASP.NET." By Scott Short. In MSDN Magazine Volume 17, Number 12 (December 2002). ['Over the years, many industry-standard XML schemas and dialects have been developed. These industry-specific schemas embrace the original purpose of XML and are extremely valuable in promoting and supporting B2B interaction. Unfortunately, the ASP.NET Web Services runtime does not allow developers to directly reference external schemas from within their XML Web Services interface (the WSDL file). This article builds an external schema framework as an extension to the ASP.NET Web Services runtime to enable you to reference external schemas within your XML Web Service interface.'] "... Many industries have collaboratively developed XML schemas that define industry-specific concepts. Among others, the travel industry, the hospitality industry, and the education industry have published schemas. If your XML Web Service is intended for a particular industry, it makes sense to leverage targeted schemas. You can also use task-oriented XML dialects. Some examples include the Astronomical Markup Language (AIML), Robotic Markup Language (RoboML), and the Speech Application Language Tags (SALT). The more an XML Web Service adheres to recognized standards, the higher the probability that it will be consumed by others. In most cases, leveraging an industry standard involves referencing external schemas within the WSDL document of your XML Web Service. Unfortunately, the initial version of the ASP.NET Web Services platform does not provide out-of-the-box support for referencing external schemas. One way to overcome this limitation would be to write your WSDL file by hand and ensure that your XML Web Service supports the interface defined by the custom WSDL file. Doing so, however, makes development and maintenance more complex. First, it is pretty easy for the implementation and the interface to become out of sync. Second, not only does the original developer need to have a strong knowledge of WSDL, but any developer who maintains the code will have to as well. Another way to reference external schemas from your XML Web Service is to extend the ASP.NET Web Services platform, which provides a rich interception model that allows developers to add this kind of extended functionality. I used this interception model to create what I call an external schema framework (ESF)..."
[October 30, 2002] "Developing Grid Computing Applications, Part 1. Introduction of a Grid Architecture and Toolkit for Building Grid Solutions." By Liang-Jie Zhang, Jen-Yao Chung, and Qun Zhou (IBM). From IBM developerWorks, Web services. October 2002. ['According to Gartner, many businesses will be completely transformed over the next decade by using Grid-enabled Web services to integrate across the Internet to share not only applications but also computer power. In this article, Liang-Jie Zhang, Jen-Yao Chung, and Qun Zhou from IBM introduce developers to the basic idea of Grid computing and the Open Grid Services Architecture (OGSA). They describe how developers can use the latest Globus Toolkit (Open Grid Services Infrastructure technology preview) to discover a Grid service, create a Grid service interface, and invoke a Grid service instance. Some ideas to help developers integrate Web services and Grid computing are also described.'] "The driving force behind Grid technology standardization is the Global Grid Forum. The integration of Grid and Web services is technically complicated, but natural. The GGF is a community-initiated forum of individual researchers and practitioners who work on distributed computing, or 'grid' technologies. GGF is the result of a merger of the Grid Forum, the eGrid European Grid Forum, and the Grid community in the Asia Pacific. GGF efforts are also aimed at the development of a broadly based Integrated Grid Architecture that can serve to guide the research, development, and deployment activities of the emerging Grid communities. The Open Grid Service Interface Working Group of the GGF is defining the Open Grid Services Architecture (OGSA). OGSA is a distributed interaction and computing architecture based around the Grid service to assure interoperability on heterogeneous systems so that different types of systems can communicate and share information. It leverages the emerging Web services to define the Web Services Definition Language interfaces. All services adhere to specified Grid service interfaces and behaviors. The Grid can be defined at three levels: (1) Enterprise (Enterprise Grid); (2) Partner (Partner Grid); (3) Service (Service Grid). However, the following components in the OGSA specification are still in the early stages of development: Factory, Registry, Discovery, Lifecycle, Query service data, Notification, and Reliable invocation. On the other hand, OGSA is a model for system composition to perform a specific task or solve a challenging problem by using distributed resources over the network... Conclusion: Grid computing uses the Internet to connect clusters of computers or business processes into the force of one single 'supercomputer.' Eventually, the Internet will become a single, unified computing platform, providing faster access to infrastructure and other business application resources. This is the era of Service Computing. In this article, we have introduced developers to Service Computing. We have shown how to use the latest Globus Toolkit to discover a Grid service, create a Grid service interface, and invoke a Grid service instance. Some ideas to help developers integrate Web services and Grid computing have also been described... The second installment of this series will focus on the Grid solution creation process including Grid architecture design, Grid service development, and Grid service deployment."
[September 18, 2002] "Grid Computing: Electrifying Web Services." By Dirk Hamstra. In Web Services Journal Volume 2, Issue 9 (September 2002), pages 60-64. "Grid computing makes it possible to dynamically share and coordinate dispersed, heterogeneous computing resources. Flexibility and ubiquity are essential characteristics of Web services technologies such as WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol), and UDDI (Universal Description, Discovery, and Integration). The Open Grid Services Architecture (OGSA) combines technologies to unlock and exploit grid-attached resources. OGSA defines mechanisms to create, manage, and exchange information between Grid Services, a special type of Web service. The architecture uses WSDL extensively to describe the structure and behavior of a service. Service descriptions are located and discovered using Web Services Inspection Language (WSIL). By combining elements from grid computing and Web services technologies, OGSA establishes an extensible and interoperable design and development framework for Grid Services that includes details for service definition, discovery, and life-cycle management. Information systems are no longer just defined by what they can process, but also where they can connect to. For example, the growing demands for computing power in simulation and engineering design projects, is increasingly satisfied by 'on-demand' sharing of CPU cycles and disk space across distributed networks. The ultimate goal for these interconnected networks, or grids, is to make IT-power as commonplace and omnipresent as electricity... Grid computing can be described as the coordinated, transparent, and secure sharing of IT resources across geographically distributed sites based on accepted computing standards... From a technical perspective, OGSA is critical to streamlining and accelerating the creation and deployment of grid applications. The architecture unifies existing grid development approaches and is extensible from a technical perspective to incorporate future developments. However, to expand the reach of grid applications beyond the level of a single enterprise the OGSA needs to more thoroughly address issues concerning: (1) Use of WSDL extensions; (2) Definition and use of service ports; (3) Heterogeneous, end-to-end, security; (4) Grid Service manageability... The extensibility of WSDL has implications for interoperability with existing WSDL clients and servers. Full interoperability and accommodation of non-OGSA WSDL clients by grid servers will accelerate the adoption of the extensibility elements. This is important since the handling of extensions is spotty at best in most current toolkits..."
[September 04, 2002] "Tool Gives WSDL Programmers a Hand." By Darryl K. Taft. In eWEEK (September 04, 2002). "In a move to establish itself as a key provider of technology for creating and editing Web Services, Cape Clear Software Inc. Wednesday announced a free editor for the Web Services Definition Language (WSDL). The Cape Clear WSDL Editor delivers an environment for rapid WSDL development and supports both novice and experienced programmers, the company said. Cape Clear officials said the WSDL Editor includes wizards that eliminate some of WSDL's complexity; WSDL validation, which simplifies testing; and support for the rapid creation of Web Services from XML Schema. Other features include the import of any XML Schema, including industry standards; support for WSDL validation, where WSDL is tested against WSDL Schema; support for WSDL profiling, so WSDL can be validated against customized profiles for specific requirements such as compatibility with Web Services Interoperability organization profiles; support for advanced WSDL capabilities, such as imports, faults, Simple Object Access Protocol (SOAP) headers, multiple bindings and parameter ordering; and support for the latest WSDL specification. 'The WSDL Editor is to Web Services development what WYSIWYG HTML editors were to Web page development,' said John Maughan, business manager for Cape Clear's CapeStudio Web services development in a statement. 'It offers an intuitive graphical environment for the design of Web Services and, in particular, assists developers who wish to create Web Services from existing XML interfaces... Many developers are struggling with the complexities of WSDL; the WSDL Editor is designed to help them out'..."
[May 17, 2002] "Examining WSDL." By Rich Salz. From XML.com. May 15, 2002. ['Rich Salz explains some of the flaws and rough corners of WSDL.'] "Unlike today's Web, web services can be viewed as a set of programs interacting cross a network with no explicit human interaction involved during the transaction. In order for programs to exchange data, it's necessary to define strictly the communications protocol, the data transfer syntax, and the location of the endpoint. For building large, complex systems, such service definitions must be done in a rigorous manner: ideally, a machine-readable language with well-defined semantics, as opposed to parochial and imprecise natural languages. It is possible to define service definitions in English; XML-RPC and the various weblogging interfaces are a notable example. But XML-RPC is a very simple system, by design, with a relatively small set of features; it's ill-suited to the task of building large-scale or enterprise applications. For example, you can't use XML-RPC to send an arbitrary XML document from one system to another without converting it to a base64-encoded string. Almost all distributed systems have a language for describing interfaces. They were often C or Pascal-like, often named similarly: 'IDL' in DCE and Corba, MIDL, in Microsoft's COM and DCOM. The idea is that after rigorously defining the interface language, tools could be used to to parse the IDL and generate code stubs, thus automating some of grungier parts of distributed programming. The web services distributed programming model has an IDL, too; and as you can probably guess, it's the Web Services Definition Language, WSDL... WSDL derives from two earlier efforts by a number of companies; the current de facto standard is a W3C Note submitted by IBM and Microsoft. There's a web services description working group, which is creating the next version of the note for eventual delivery as a W3C standard. So far the group has published a requirements document and some usage scenarios. One reason to like the requirements document is that it renames some of WSDL's more confusing terms... I find WSDL to be a frustrating mixture of verbosity -- most messages are essentially described three times -- and curious supposedly helpful defaults, such as omitting the name of a message in an operation. I'll use the now much-discussed Google WSDL to point some of these out..."
[February 05, 2002] "WSDL Gets Close Look." By Darryl K. Taft. In eWEEK (February 04, 2002). "Major software vendors have touted WSDL as a key specification for driving the interoperable world of Web services. But some developers say its patrons are using Web Services Description Language and other standards to force enterprises into choosing one vendor's Web services initiative over another's, effectively removing the openness and interoperability that are cornerstones of the technology. WSDL, largely written by IBM and Microsoft Corp., details a machine-readable way to describe Web services. This description includes everything needed to make a Web service call. But where some developers say WSDL, which became a de facto standard after IBM and Microsoft issued the code, is unnecessary and counterproductive, others say the specification needs to be fixed. Still others say it's crucial to Web services. To clarify the matter, the World Wide Web Consortium last month created a working group to look at Web services standards, including WSDL. The group, chaired by Microsoft, has its first conference call this week. Dave Winer, a developer and CEO of UserLand Software Inc., in Millbrae, Calif., said WSDL is an unnecessary piece of standards infrastructure for Web services and exists largely as a way for big companies such as Microsoft, IBM and Sun Microsystems Inc. to set up entry barriers to smaller competitors. Winer said there is no need for WSDL "unless you are trying to lock developers into your development environment, as Microsoft and Sun and IBM surely are trying to do." Instead, developers and vendors should use normal programming techniques or Simple Object Access Protocol schemas, which he and others said are more open and less complex than WSDL. Barriers to competition occur when smaller enterprises must decide whether to bet their Web services strategy on a company such as Microsoft, IBM, Oracle Corp. or Sun, all of which offer 'some level of proprietary code that locks you into their solution,' said Britt Johnston, chief technology officer at NuSphere Corp., a Bedford, Mass., open-source technology vendor... Rich Salz, CTO of Zolera Systems Inc., in Waltham, Mass., and a member of the WSDL working group, said the specification is necessary but flawed: 'The people who say it's not necessary are those who are focusing on simple things'..."
[December 20, 2001] "All We Want For Christmas is a WSDL Working Group." By Martin Gudgin and Timothy Ewald. From XML.com. December 19, 2001. "Dear Santa Claus: We have both been very good this year. We've done our best to promote peace and understanding among web service developers around the world. We have run into some problems, however, with the Web Service Description Language (WSDL). In case you aren't familiar with WSDL, it's an XML-based language that captures the mechanical information a client needs to access a web service: definitions of message formats, SOAP details, and a destination URL. (Of course the client also needs to understand the semantics of particular messages, but that information is still imparted the old-fashioned way, i.e., documentation.) WSDL files are often interpreted by software, which uses the metadata they contain to generate client-side proxy code for accessing a service. This is appealing to developers who do not want to program in raw XML... We agree with most people in the web service community that something like WSDL is necessary. However, we have a number of issues with WSDL as it stands today, and we are hoping that you can fix them. Here is our list... Actually, Santa, forget about our list. We just realized that all we really want for Christmas is a WSDL working group. If you can get us one of those, we'd be very happy..."
[October 01, 2001] "WSDL: An Insight Out." By Sethuraman Ramasundaram. In XML Magazine Volume 2, Number 5 (October / November 2001), pages 40-44. ['Use WSDL to invoke Web services, or exploit WSDL to expose your service with the same advantages for its users.'] "Today programmers talk less about building applications from scratch; instead, they prefer to assemble applications from available third-party services through the Internet. Consider a scenario where you want to access a third-party remote service over the Internet for, say, credit card authorization. To do this, you need to know certain things such as the method signature (input/output parameters, and so forth); the protocol to be used (IIOP, SOAP, and so on); the network address; and the data format (encoding schemes). This is precisely what the Web Services Description Language (WSDL) specification defines in an XML format. The official definition of WSDL goes like this: 'WSDL is an XML format for describing network services as a set of end points operating on messages containing either document-oriented or procedure-oriented information.' By using WSDL as a standard, you can easily invoke remote services; conversely, if you have a remote service, exposing it using WSDL offers the same advantage to its requesters. Let's see how this works by looking at how WSDL fits into the Web services model, generating a WSDL document, and using it for invoking a remote service. ... Consider the position of WSDL in the big picture of Web services. In simple terms, Web services are clearly defined, third-party applications that can be invoked over the Internet. Examples of Web services might include credit card processing, shipment tracking (for example, FedEx), or even a simple time zone converter. The steps involved in creating and using a Web service are: (1) The service provider creates a service and registers it with a registry. The most common are UDDI registries. (2) The service requester [the person who wants to use a service] searches the registry and finds corresponding services. Now how does he or she know which service uses which protocol to communicate, what parameters to pass, and what result to expect? This is where WSDL springs into action. When the service providers register their services with the registry, they define the service in the form of a WSDL document. Thus by searching the registry, the service requester can retrieve corresponding WSDL documents. (3) As the WSDL document defines everything from the protocol to the service parameters, the service requester now writes the client to access the service... WSDL has support from many heavyweights in the industry. The WSDL specification was a combined effort of IBM, Microsoft, and Ariba. There is even a Java specification request present for a WSDL API, which aims at providing a Java API for constructing and manipulating service descriptions (see Resources ). For any standard to be successful, adherence by industry giants is essential. Since there is great support for WSDL, you might want to consider WSDL seriously for your Web services."
[September 20, 2001] "Understanding WSDL in a UDDI Registry. How to Publish and Find WSDL Service Descriptions." By Peter Brittenham, Francisco Cubera, Dave Ehnebuske, and Steve Graham. From IBM developerWorks [Web services articles]. September 2001. ['The Web Services Description Language has a lot of versatility in its methods of use. In particular, WSDL can work with UDDI registries in several different ways depending upon the application needs. In this first of a three-part series, we will look at these different methods of using WSDL with UDDI registries.'] The Web Services Description Language (WSDL) is an XML language for describing Web services as a set of network endpoints that operate on messages. A WSDL service description contains an abstract definition for a set of operations and messages, a concrete protocol binding for these operations and messages, and a network endpoint specification for the binding. Universal Description Discovery and Integration (UDDI) provides a method for publishing and finding service descriptions. The UDDI data entities provide support for defining both business and service information. The service description information defined in WSDL is complementary to the information found in a UDDI registry. UDDI provides support for many different types of service descriptions. As a result, UDDI has no direct support for WSDL or any other service description mechanism. The UDDI organization, UDDI.org, has published a best practices document titled Using WSDL in a UDDI Registry 1.05. This best practices document describes some of the elements on how to publish WSDL service descriptions in a UDDI registry. The purpose of this article is to augment that information. The primary focus is on how to map a complete WSDL service description into a UDDI registry, which is required by existing WSDL tools and runtime environments. The information in this article adheres to the procedures outlined in that best practices document and is consistent with the specifications for WSDL 1.1, UDDI 1.0 and UDDI 2.0..." For related articles, see the IBM developerWorks Web Services Zone. References: "Universal Description, Discovery, and Integration (UDDI)."
[November 09, 2001] "Service Registry Proxy: A higher-level API." By Alfredo da Silva (Advisory Software Engineer, IBM). From IBM developerWorks. November 2001. ['In order to provide additional tools to the Web services developer, this article discusses a new API -- the Service Registry Proxy, or SRP -- which helps to raise the abstraction level during application development and promotes seamless integration between UDDI and WSDL elements.'] "The release of the UDDI4J API enabled the creation of UDDI-aware applications, making the publish, unpublish and find operations available from an open-source API. In order to allow WSDL documents to be part of this equation, a new layer called the Service Registry Proxy API (or SRP), which sits on top of the UDDI4J, has been devised. The SRP API elements encapsulate classes present in the UDDI4J API, and some defined by the WSDL4J API, and offer a comprehensive set of methods for interfacing with a UDDI Registry. Its model simplifies the development of applications because it raises the level of abstraction, enabling the developer to concentrate on entities directly related to the Web services architecture domain. SRP supporting classes The SRP API is structured around the following main elements: Service Provider (SP), Service Definition (SD), Service Implementation (SIMP), and Service Interface (SITF)... SP (The Service Provider) represents an entity capable of providing services. It encapsulates a reference to the UDDI4J class BusinessEntity. SD (The Service Definition) describes a service by breaking it down into two pieces: implementation (SIMP) and a list of the implemented interfaces (SITF). SIMP (The Service Implementation) has a dual role. It exposes the related WSDL implementation document (see Resources) and also has a reference to the UDDI4J class BusinessService. SINT (The Service Interface) also encapsulates two entities: a WSDL interface document and a reference to the UDDI4J class TModel. The WSDL capabilities presented by SIMP and SINT are inherited from their parent class WSDLServiceInfo. This organization enables SRP to tie together UDDI and WSDL elements and, at the same time, abstract their concepts -- thereby making the creation of Web services a more productive task." Article also in PDF format.
[August 08, 2001] "Silverstream Software Introduces jBroker Web 1.0. Free Web Services Engine Provides Unmatched Performance for Java-based Web Services." - "SilverStream Software, Inc. today announced the availability of jBroker Web 1.0, a high-performance, portable Web Services engine and tools designed to build, run and invoke Web Services using Java. jBroker Web provides unmatched performance and deploys to standard J2EE application servers. jBroker Web provides a standards-compliant, Web Services runtime with a small footprint and flexible architecture. It is a complete XML Remote Procedure Call (RPC) environment for building, running and invoking Web Services using Java. Based on the Java Remote Method Invocation (RMI) programming model, jBroker Web invokes Web Services like any other remote object to speed and simplify the development of Web Services. Some of the key features of jBroker Web 1.0 include: (1) The ability to generate a Web Service from any Java class including EJBs; (2) The ability to generate a Java client to access a Web Service from a WSDL file; (3) A high performance, scalable SOAP 1.1 runtime with 4-6 times the performance of Apache SOAP; (4) Interoperability with several SOAP implementations including Apache and Microsoft; (5) The ability to leverage J2EE security features for authentication and access control; (6) Deployment into standard J2EE application servers including SilverStream, IBM's WebSphere, BEA's WebLogic, Oracle 9iAS, Apache Tomcat and others. jBroker Web is also fully integrated with the SilverStream Application Server and provides the Web Services engine for the SilverStream eXtend product line, including the SilverStream eXtend Workbench. SilverStream eXtend is the first complete and integrated services environment that enables organizations to exploit the value of existing systems and deliver business applications to any user on any device or platform..." See also (1) the previous announcement, and (2) "SilverStream Software Ships the SilverStream Application Server with Full Web Services Capabilities. Provides a High-performance Web Services Engine and Tools to Simplify J2EE and Web Services-based Application Development."
[March 26, 2001] IBM developerWorks theme on Web services. "Web services is a newly emerging technology that you need to know about, and to assist you, we are providing new articles, a forum, and other resources ... Web services is a new model for creating dynamic distributed applications across the Web with common interfaces for efficient communication. It is built around ubiquitous, open standards such as HTTP and XML, as well as newer standard technologies, including Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Discovery, Description and Integration (Cool UDDI) protocols. Using these technologies it is possible to evolve the client-server applications of today toward a service-oriented architecture and the semantic Web of the future."
[March 24, 2001] "SOAP Toolkit 2.0: New Definition Languages Expose Your COM Objects to SOAP Clients." By Carlos C. Tapang. From MSDN Online. March 20, 2001, "April 2001" issue. ['This article describes a custom tool, IDL2SDL, which takes an IDL file and produces Web Services Description Language (WSDL) and Web Services Meta Language (WSML) files without waiting for a DLL or TLB file to be generated. This article assumes you're familiar with XML, SOAP, COM, and Visual C++.'] "In SOAP Toolkit 2.0, the Services Description Language (SDL) has been replaced with the Web Services Description Language (WSDL) and the Web Services Meta Language (WSML). WSDL and WSML files describe the interfaces to a service and expose COM objects to SOAP clients. This article describes a custom tool, IDL2SDL, which takes an IDL file and produces WSDL and WSML files without waiting for a DLL or TLB file to be generated. Also shown is a customized development environment in which WSDL and WSML files automatically reflect the changes to IDL files... hen the November 2000 release of the Microsoft SOAP Toolkit 1.0 became widely available, I wrote an Interface Description Language (IDL) to Service Description Language (SDL) translator, which I named IDL2SDL. Since SDL has been replaced with Web Services Description Language (WSDL) and Web Services Meta Language (WSML) in version 2.0 of the SOAP Toolkit, I have rewritten the translator to support WSDL and WSML. In this article I will explain how to use the translator and introduce version 2.0 of the SOAP Toolkit. You will get to know IDL2SDL and learn how to incorporate it into your development environment. The tool is available at http://www.infotects.com/IDL2SDL, together with a very simple C++ sample COM object on the server side and a Visual Basic-based app on the client side. This tool is free, and I welcome questions and suggestions for improvement. The WSDL and WSML files describe the interfaces to your service and expose your COM object to SOAP clients. The SOAP Toolkit already provides the WSDLGenerator tool. The generator derives the service description from the object's TypeLib. (TypeLib is usually embedded in the DLL file in which a COM component resides.) Whereas the WSDLGenerator tool is very well-suited for situations in which you only want to reuse available components in a Web service, the IDL2SDL tool is more appropriate for situations in which you are designing your server components completely from the ground up. During development, interface specifications can change often, even during testing. The IDL2SDL utility allows you to change your IDL file and produce both WSDL and WSML files without having to wait for the DLL or TLB file to be generated. You can set up your development environment with IDL2SDL such that your WSDL and WSML files automatically reflect the changes to your IDL file. In a later section, I will describe the simple steps you need to take to make IDL2SDL part of the Visual Studio development environment. Since SOAP is designed to be universal, it is applicable to remote procedure call component architectures other than COM. Likewise, IDL can express interface contracts for component architectures other than COM. There is no standard for IDL, but IDL2SDL can be modified to easily accommodate inputs for the Microsoft MIDL and for the DCE IDL compiler... The sample Web service shown here demonstrates that version 2.0 of the SOAP Toolkit is a completely different implementation from version 1.0. However, it is just as easy to use. Like version 1.0, version 2.0 accommodates both users who just want to expose their COM object to SOAP and users who have a need to generate the SOAP messages. The IDL2SDL tool even makes it easier by automating the production of WSDL, WSML, and ASP files. The IDL2SDL tool is freely available, but it is not part of the SOAP Toolkit. This tool was built using the Flex lexical analyzer and the BISON parser generator, which are available from http://www.monmouth.com/~wstreett/lex-yacc/lex-yacc.html. The sample files and tools are also available from the Infotects Web site." [Note: the SOAP Toolkit 2.0 Beta 2 available for download has "several major enhancements, including a new ISAPI listener and support for simple arrays."]
[March 15, 2001] "Microsoft Co-Submits Another Web Services Specification to W3C. Continues Rigorous Open Standardization of XML and Web Services Technologies." - "Microsoft Corp. today announced that the World Wide Web Consortium (W3C) has acknowledged the submission of the Web Services Description Language (WSDL) specification. Microsoft joined International Business Machines Corp., Allaire Corp., Ariba Technologies Inc., BEA Systems Inc., Bowstreet Inc., Commerce One Inc., Compaq Computer Corp., DataChannel Inc., Epicentric Inc., Fujitsu Limited, Hewlett-Packard Co., Intel Corp., IONA Technologies, Jamcracker Inc., Oracle Corp., Rogue Wave Software Inc., SAP AG, TIBCO Software Inc., VeriSign Inc., Vitria Technology Inc., webMethods Inc., XML Global Technologies and XMLSolutions Corp. in submitting the specification and proposing that the W3C's XML Protocol activity take on the work of standardizing it. WSDL is a key Web Services technology, implemented in the Microsoft .NET Framework, Visual Studio.NET, SOAP Toolkit and many other technologies. It provides an XML grammar for describing the capabilities of a Web Service. . . Today's news follows a sequence of initiatives by Microsoft to enable the widespread development and implementation of Web Services. Others include the Universal Description Design and Integration (UDDI) initiative that provides a comprehensive directory of businesses operating in the online world and the Web-based services they offer. Another is the submission of the Simple Object Access Protocol (SOAP) 1.1 to the W3C last May. SOAP is a technology that enables integration of applications over the Internet irrespective of operating system or platform. WSDL augments SOAP, enabling development tools and other infrastructure to easily integrate by engaging in automated "conversations" with a Web Service. As communications standards emerge in the Web community, it becomes increasingly possible and important to be able to describe the communications in a common, structured way. WSDL addresses that need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages."
[March 20, 2001] "Datachannel Co-Submits Web Services Description Language (WSDL) To World Wide Web Consortium. DataChannel Co-Submission of New Format Demonstrates Ongoing Leadership in Advancing Web Standards." - "DataChannel, a leader in enterprise portal solutions, today announced that the World Wide Web Consortium (W3C) has acknowledged DataChannel's co-submission of the Web Services Description Language (WSDL). DataChannel co-submitted the WSDL proposal with IBM, Microsoft, Allaire, Ariba, BEA, Bowstreet, Commerce One, Compaq Computer Corporation, Epicentric, Fujitsu Limited, Hewlett-Packard, Intel, IONA Technologies, Jamcracker, Lotus Development Corporation, Oracle, Rogue Wave, SAP, TIBCO, VeriSign, Vitria, webMethods, XML Global Technologies and XMLSolutions. WSDL is an emerging XML technology that provides enterprise organizations with the ability to define the specific interface requirements needed to publish and consume Web Services. DataChannel's enterprise portal framework leverages the benefits of WSDL to deliver the new business desktop to Global 2000 enterprise customers. "As WSDL continues to gain acceptance, DataChannel's Enterprise Portal will have the flexibility to integrate specific Web Services, making them accessible directly through the corporate desktop," said Brian Eisenberg, program director for e-business technologies for DataChannel. "By providing the flexibility to interface and interact with Web Services within the Enterprise, our customers can leverage their existing technologies and avoid huge add-on software packages. In a truly integrated enterprise, companies will be able to pick and choose only those services they need to perform specific business tasks." The acceptance of WSDL is fueling the industry shift from delivering complex application logic in the form of monolithic software applications, to a distributed Web Services model that exposes similar functionality in the form of modular services. This model has the potential to reduce the amount of IT spending on software, while at the same time providing a simple and flexible mechanism for publishing, discovering, and invoking Web Services in a distributed network environment."
[September 29, 2000] "Microsoft, IBM release directory specs." By James Evans. In Network World (September 29, 2000). "IBM and Microsoft have developed a language standard for the new Universal Description, Discovery and Integration business directory, which is designed to fuel business-to-business commerce. The standard, called Web Services Description Language (WSDL), is a mixture of both IBM's Network Accessible Services Specification Language and Microsoft's Simple Object Access Protocol (SOAP) contract language. SOAP is an open standards-based interoperability protocol that uses XML to provide a common messaging format to link together applications and services anywhere on the Internet regardless of operating system, object model or programming language. The companies are evaluating the appropriate path for submitting the specification to the industry as a draft for standardization. A coalition of 36 vendors and consultants are working on the UDDI business directory, which, at its core, will be an XML-based holding tank for what businesses do, the services they offer and how they interface with their computing systems. The registry announced in early September is expected to support a number of APIs for gathering and offering information. There will be three initial versions of the registry as it gradually becomes more elaborate. It initially will provide basic information and later will offer more detailed company information, such as how to deal with a specific business unit. Ariba, along with IBM and Microsoft, launched the UDDI business directory, which will be built on TCP/IP, HTML and XML. Beta testing is expected to begin sometime in October."
[November 07, 2000] "UDDI standard: A ticket to global B2B?" By Cameron Sturdevant. In eWEEK (November 05, 2000). "Unlikely collaborators microsoft Corp. and IBM, along with Arriba Inc., have created UDDI, an ambitious core specification for business-to-business integration. After examining the new specification, eWeek Labs believes the Universal Description, Discovery and Integration standard should be on the IT agenda of any organization that wants to conduct business over the Internet. Introduced in August, UDDI is intended to be an Internet standard for creating an online business registry. At the high level, the standard defines White Pages (general information), Yellow Pages (business categories) and Green Pages (how business is conducted)... Last month, the three companies announced the WSDL (Web Services Description Language) -- the cornerstone of UDDI -- which allows businesses to describe their offerings in a standard way. Microsoft and IBM employees authored WSDL and the XML (Extensible Markup Language) format for describing network services will be developed cooperatively -- at least for the near future. WSDL is partially based on Microsoft's SOAP (Simple Object Access Protocol) Contract Language and IBM's NASSL (Network Accessible Service Specification Language). WSDL attempts to do something similar to Hewlett-Packard Co.'s eSpeak initiative, which is an open, standards-based group of tools that automates discovery and interaction among Web-based services. It's too soon to say which specification is likely to prevail. Further, our examination of the actual working products from both initiatives shows that solid guidelines are still months -- or even a year or more -- in the future. WSDL describes network services as endpoints that exchange messages telling what services are available. The language is limited to message formats or network protocols that conform to SOAP 1.1, HTTP get/post and MIME (Multipurpose Internet Mail Extensions). The specification leaves open-ended the other message formats that will be supported..." See: "Universal Description, Discovery, and Integration (UDDI)."
[September 29, 2000] "IBM, Microsoft, Ariba release WSDL Specification." By Roberta Holland. In eWEEK (September 26, 2000). "Less than a month after a coalition of 36 companies announced a wide-ranging initiative to create a directory for Web services, IBM and Microsoft Corp. have released a new language specification to describe those services. IBM, Microsoft, Ariba Inc. and other companies joined together last month on the UDDI (Universal Description, Discovery and Integration) initiative, intended to form a collection of registries and databases describing what businesses do and how to access their services electronically. What IBM and Microsoft released Monday is an XML syntax to describe those services, called the Web Services Description Language. Ariba also helped in the effort, which essentially was a merger of existing technologies from IBM and Microsoft. Officials involved say WSDL will allow for better interoperability among Web services and development tools. The language is based both on IBM's Network Accessible Services Specification Language and Microsoft's SOAP (Simple Object Access Protocol) Contract Language. WSDL was developed outside of the UDDI group and will either formally be submitted to the coalition for a specification or be submitted to a separate standards organization, said Bob Sutor, IBM's program director for e-business standards strategy in Somers, N.Y. Sutor said WSDL will not be the only choice for describing Web services, adding that Microsoft and IBM felt it made sense to combine their efforts." The WSDL specification is available for review on the IBM and Microsoft web sites.
IBM WSDL Toolkit. "The WSDL Toolkit is a set of tools that allow developers to generate client and server code from a WSDL document. A WSDL document describes the interface and deployment details of a Web service, that is, the interfaces and protocols supported by the service. Compliant server applications must support those interfaces, and client users can learn from the document how the service should be accessed." The new v1.1 [11/14/2000] generates cleaner code, and will now work with Xalan v1.2. This release of the WSDL toolkit contains two tools: (1) A client-side stub (proxy) generator that generates a stub for a service accessible via RPC over SOAP over HTTP and described by a WSDL document. The generated code will use Apache-SOAP for SOAP functionality. (2) A server-side skeleton generator that generates a skeleton for a service described by a WSDL document. The generated code is intended to be deployed using Apache-SOAP and will include the necessary deployment descriptor as well. For services that are made available using the SOAP RPC protocol, it is possible to use the WSDL Toolkit to produce a client proxy and a server skeleton that comply with the WSDL service description. A complete Java implementation of the service interface is generated for the client side. This code can be compiled and directly run against an installed SOAP service that corresponds to the WSDL description of that service. For the server side, a server skeleton class is generated which provides a compatible Java class, but no method implementations. Hence, the WSDL Toolkit can be used by service requesters to obtain all the code needed to access an existing SOAP service as described by a WSDL document, and by service providers to generate the base for their service implementation..."
[September 25, 2000] IBM's Web Services Toolkit. "Web Services Toolkit is a runtime environment as well as demo/examples to design and execute web-service applications to find one another and collaborate in business transactions without programming requirements or human intervention. The new version 1.2 [September 25, 2000] features support for Web Services Description Language (WSDL), a subset of the Universal Discovery Description & Integration (UDDI) APIs, support for Advertisement and Discovery of Services (ADS), and a new Web services creation tool. . . Web services are self-describing, self-contained, modular applications that can be mixed and matched with other Web services to creative innovative products, processes, and value chains. Web services are Internet applications that fulfill a specific task or a set of tasks that work with many other web services in an interoperable manner to carry out their part of a complex workflow or a business transaction. In essence, they enable just-in-time application integration and these web applications can be dynamically changed by the creation of new web services. Various applications that are available on the Internet can be accessed and invoked at run time without prior knowledge and programming requirements to enable business processes and decision-making at Web speeds. IBM's Web Services Toolkit provides a runtime environment as well as demo/examples to design and execute web-service applications to find one another and collaborate in business transactions without programming requirements or human intervention."
See: also "Universal Description, Discovery, and Integration (UDDI)."
