UML for Web Services
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 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:
- design in UML;
- express service semantics in WSDL and WXS;
- 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 older article, I laid out a convenient UML notation (known as a "profile") for WXS types; this article will focus on two new capabilities:
- Modeling WSDL components for service semantics, such as port types, ports and services
- 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
Use of UML for WXS
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 won't restate the notation for this here; you can refer to the original article or simply intuit the meanings of notations as I use them in the rest of this piece. One refinement is that since 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:.
Also, instances of these xs: stereotypes will be understood to encapsulate not just the WXS component, but also the corresponding application-language artifact, such as a generated class for a serializable complex type or enumeration. This is a pattern we'll see replicated for the wsdl: stereotypes as well; it is key to the integration of WSDL, WXS, and a programming language.
Just for kicks, and perhaps to develop more familiarity with the WXS notation, here's a diagram of the WXS schema for WSDL itself:
What I'm about to develop is a notation for WSDL descriptors, not just WXS schema -- that is, a high-level model that maps wsdl: stereotypes to combinations of these WSDL components, so that web-service designs don't have to spell out every individual component for a given design concept.
Case Study: The Love Is Blind Dating Service
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:
- Query the database for matches, receiving a result set of member profiles.
- 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.
Pages: 1, 2