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:
Ask questions or comment on this article in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Newest First |
- Proper Use of UML
2003-08-18 11:11:44 Kirk Wilson [Reply]
I enjoyed Mr. Provost's article and consider a good contribution to the UML modeling literature. However, I am concerned about several improper representations in UML.
1. All of Mr. Provost's role names are on the wrong end of the association. This gets very confusing in UML, but:
Nouns go on the association end connected to the class that exhibits the interface.
Verbs go on the association end connected to the class that is the direct object of the verb.
(In other words, "sex" is a noun and not a verb and belongs on the end attached to the "sex" class.)
2. Mr. Provost says that portType is like an interface. Very good. He also says that port "implements" a portType. Very good, as well. However, Mr. Provost is incorrect when he says that "Specialization in UML expresses this relationship precisely." No, no, no. UML has a special dependency of "realizes" to represent the relationship between an interface and its implementation. Specialization would mean that the port is a subtype of portType, which is not what is intended. To put the point precisely, a subtype of an interface CANNOT be the implementation of an interface; it's just another interface.
3. Finally, Mr. Provost should specify the precise semantics of the dependency between WalkInImpl and Member.
- Author's response
2003-08-19 08:14:31 Will Provost [Reply]
I appreciate your thoughtful comments, and that you are clearly taking the details of UML modeling seriously. I've considered each of your points, and offer responses below:
1. Right you are. I can only plead temporary insanity on this -- they are all backwards! Worse, this makes them inconsistent with my previous article on UML for WXS. On this one and your second point, I may see about updating the article diagrams, since the error is significant and alters meaning.
2. You make an excellent point. The <<portType>> and <<port>> stereotypes I'm suggesting describe more than one artifact each: both WSDL and native-language productions are likely, and there will be various relationships between the portType-produced and port-produced entities. As such, specialization seemed a broader and more natural statement about the relationship. However, your comment reminds me that the notation should most naturally fit the abstract model of the Web service in question, and not be dragged around too much by the likely shape of the implementation. Whatever <<portType>> and <<port>> are, they are clearly not the same sort of bird, and so true specialization is off the mark, as you suggest, and realization is a more accurate choice.
3. I'm not sure what exactly you're looking for here, but generally speaking I think not much of use can be said about the dependency from the port to the domain class, beyond its existence. That is, at this level of design, and mixing WSDL, WXS and native-language concepts so tersely, I mean only to indicate that WalkIn will have to make use of Member, somehow, to do its job. It is a general tenet of UML practice that partial specification is always acceptable, as it supports an iterative process, and at this point in the hypothetical design process I feel that stating the dependency is all that's appropriate. A later pass might flesh out this dependency with additional facts, and even break it out into its own diagram with additional -- perhaps generated -- types, associations, names, etc.
Thanks for calling these out.
- Author's response
2006-04-24 03:34:42 ajw798 [Reply]
I don't quite understand the function of the domain class "Member". Could you elaborate on this please?
Many Thanks
- Author's response
- Author's response
- what maps the diagrams into code ?
2003-08-15 20:30:26 Doron Ben-Ari [Reply]
Interesting ideas.
Which tool or utility is translating the diagrams into code ?
- what maps the diagrams into code ?
2004-05-20 20:20:37 John Timm [Reply]
I created a tool that converts XMI (XML-based representation of UML models) to source code (Java) using XSLT. It would be possible to create an XSLT transform that converts XMI to WSDL. I am also considering writing a tool that converts UML to WSDL to OWL-S using XSLT.
If you would like more information on this, please send me an email.
Regards,
John T.E. Timm
- what maps the diagrams into code ?
2005-11-03 06:51:32 J.Wieland [Reply]
Hello Tim,
I'm just beginning to evaluate a transformation of xmi-model data to wsdl data. I normally build the model in Rose and export it to an xmi-file. I'm quite familiar with xslt but not with the "rules" how to build a wsdl-file out of an xmi-file. How are the "objects" (classes, attributes and so on) mapped.
I would like to get any help you can give to me (literature, links ....).
Best Regards
Juergen
- what maps the diagrams into code ?
- Author's response
2003-08-19 08:19:13 Will Provost [Reply]
Unfortunately, at this stage of the game, I don't know of any UML tools that will do code generation at this level. I think some are working well with WXS schema generation at this point, and perhaps there's very simple WSDL generation, but tying the consolidated notation into UML tool, application server, IDE, etc., is not possible yet.
For what it's worth, in my own practice I tend to rely on UML as a whiteboard language only. I've never found code generation to be very effective; it almost always breaks on reverse-engineering and thus tends to gum up the development process after an initial burst of code productivity.
- what maps the diagrams into code ?
