UML for Web Services
by Will Provost
|
Pages: 1, 2
Expressing Service Interfaces
As a description of a service interface, the WSDL portType component is naturally similar to the UML interface: it is a collection of operations, which are just UML methods; each method signature must be spelled out as SOAP messages (input, output, and faults) rather than parameter lists, a return type and exceptions.
The exact mappings of portType, operation, message, part, and WXS types to programming languages are spelled out in language-specific standards such as JAX-RPC. We'll float above the gory details here and simply treat WSDL port types as realized interfaces.
|
So our first wsdl: stereotype is shown at right and a simple example follows. Note that I've conjured the supporting WXS complex types and an enumerated type as part of the design process for WalkIn.
Just a snippet of the total WSDL production from this design is shown below. (If there were any doubts about the possible choice of WSDL as a design language, they should be dispelled with one look at the complete listing, which is already unwieldy while the UML whence it came is elegant.)
...
<simpleType name="Sex" >
<restriction base="string" >
<enumeration value="Male" />
<enumeration value="Female" />
</restriction>
</simpleType>
<complexType name="Characteristics" >
<all>
<element name="sex" type="LIB:Sex" />
<element name="age" type="positiveInteger" />
<element name="interests" type="LIB:StringArray" />
</all>
</complexType>
...
<message name="findTrueLoveRequest" >
<part name="desires" type="LIB:Characteristics" />
</message>
...
<portType name="WalkIn" >
<operation name="findTrueLove" >
<input message="LIB:findTrueLoveRequest" />
<output message="LIB:findTrueLoveResponse" />
</operation>
<operation name="sendLoveNote"
parameterOrder="memberID note" >
<input message="LIB:sendLoveNoteRequest" />
<output message="LIB:sendLoveNoteResponse" />
</operation>
</portType>The message and operation names are implicit and would be handled by a UML or other code-generating tool. Not shown is the use of exception signatures to express WSDL faults.
The case study thus far shows only the production of WSDL and WXS from UML designs, which is the first of our goals. How does the «wsdl:portType» integrate with ordinary OO types? First, client interaction with the service will be through the port type, so we'll see dependencies like those shown below. (Note that an implicit rule of interoperability can be stated for this notation: client dependencies should only flow to wsdl: and xs: types.)
The «wsdl:portType» stereotype is now seen to express more than just the literal WSDL portType component. It does double duty in encapsulating the (probably generated) application code for the interface. Thus the client dependency to the port type uses the native programming language on the client side, and a generated stub is understood to be translating this to SOAP messages. This integrated notation, then, assumes the interoperability inherent in web services.
To understand the other interesting integration point we'll need a mapping for the concrete service model --- ports, bindings, services --- where thus far we've been dealing only with the abstract model.
Expressing Services and Ports
|
A WSDL port "implements" a port type. Realization in UML expresses this relationship perfectly, though clearly the implementing type is more than just a class. Thus our second wsdl: stereotype, shown at right, and an expanded UML diagram for Love Is Blind, now including a port and drawing on additional implementation types from the implementation language. Thus the second point of integration, and a similar, implicit translation from SOAP to the native language:
The corresponding WSDL production is small and, in fact, invalid till we deal with WSDL service and binding components. «wsdl:port»s will also produce platform-specific artifacts to dispatch SOAP messages to application code: XML deployment descriptors, a skeleton implementation class, perhaps even tie classes.
But, indeed, what about the WSDL binding? This is an interesting question: should the SOAP binding of port to port type be expressed in UML at all? It's arguable that everything expressed there comes into play only in code generation -- that none of it, in other words, is really design information. As much for the sake of brevity as anything else, this is the road I'm taking. (By the same rationale, note that the URI value tagged to the «wsdl:port» is relative to the service; I assume that absolute location is external to the design.) If details such as use and style are considered important to design and documentation, one could certainly define a «wsdl-soap:binding» stereotype -- probably a stereotype of UML realization itself, as binding informs the realization of portType by port.
|
As shown at right, services are primarily collections of ports. They add URI context information, but not much else at the interoperable level.
The next step up from service is the WSDL descriptor itself, and the important implication this has on model content is the XML namespace in which all of the information we've discussed so far is contained. What more natural mapping is there to an XML namespace but from a UML package? Now a complete design for the WalkIn use case is feasible:
The complete WSDL descriptor is, again, only part of the production from this design. See also this expanded design for additional behaviors in the Love Is Blind service -- such as member login and administration -- and the corresponding, expanded WSDL descriptor.
Odds and Ends
This basic notation turns the interesting trick, which is to enable a visually-oriented design process that seamlessly expresses WSDL components, WXS types, and implementation types in integrated diagrams. The resulting UML can provide the clearest and cleanest pictures of a designed web service, for implementation as well as for documentation and communication outside the development team.
The framework can be expanded in a number of ways: stateful ports might express session-aware web services; behavior on serializable types might imply server-side-only validation or other logic. WSDL messaging scenarios other than request/response might be indicated in any number of ways.
Finally, an interesting complement to the class/component notation is the dynamic analysis it implies. UML interaction diagrams will work smoothly with this notation: method calls versus messages is actually a fine distinction in the UML sense. Different messaging scenarios (request/response, one-way, etc.) also imply different synchronization in the UML. Here's a simple example for the primary Love Is Blind use case:
- Proper Use of UML
2003-08-18 11:11:44 Kirk Wilson - Author's response
2003-08-19 08:14:31 Will Provost - Author's response
2006-04-24 03:34:42 ajw798 - what maps the diagrams into code ?
2003-08-15 20:30:26 Doron Ben-Ari - what maps the diagrams into code ?
2004-05-20 20:20:37 John Timm - what maps the diagrams into code ?
2005-11-03 06:51:32 J.Wieland - Author's response
2003-08-19 08:19:13 Will Provost
