By Simon Johnston, Architect, IBM Corporation.
This paper describes the UML Profile for Software Services, a profile for UML 2.0 which allows for the modeling of services, SOA and service-oriented solutions. The aim of the profile is to provide a common language for describing services that covers a number of activities through the development lifecycle and also provides views to different stakeholders. So, for example, the profile provides capabilities for the architect to map out services early in the lifecycle using logical partitions to describe the entire enterprise-wide service portfolio. This view is further detailed by designers who develop the service specifications, both structural and behavioral that act as the contracts between the service clients and implementers. The message view provides the ability for designers to reuse information models for common service data definitions.
The profile has been implemented in Rational Software Architect and used successfully in developing models of complex customer scenarios and also in educating people to the concerns relevant to development of service-oriented solutions.
The following diagram is a model showing the concepts important in modeling services. As you can see the number of concepts is relatively small and should be reasonably familiar to anyone having worked on service-oriented solutions. Note, however that although the profile is a realization of this model a number of the concepts are not explicit stereotypes in the profile. For example there is no stereotype for operation or for protocol as these are existing notions in the UML 2.0 that the profile reuses without any ambiguity or further constraint.
The following table lists the elements of the UML 2.0 meta model that are used as meta classes for stereotypes in the UML Profile.
| UML 2.0 Meta class | Stereotypes |
|---|---|
| Class | Message, Service Partition, Service Provider |
| Classifier | Service Consumer |
| Collaboration | Service Collaboration |
| Connector | Service Channel |
| Interface | Service Specification |
| Port | Service, Service Gateway |
| Property | Message Attachment |
The following (clickable) diagram is a UML 2.0 profile diagram, it demonstrates the actual details of the profile with each stereotype, its meta class using the extension notation (filled arrow head).You can also see some of the constraints in the model, particularly those co-constraints between profile elements.
The following sections outline the elements of the UML 2.0 profile as it is currently defined. Each section outlines an individual stereotype; the details of each specify its meta class, properties and any constraints which should be applied when using the profile.
Class
A message represents the concept as defined in the
WSDL specification, i.e. a container for actual data which has meaning to the
service and the consumer. A message may not have operations, it may have properties
and associations to other classes (one assumes classes of some domain model).
A message stereotype has a property to denote its assumed encoding form (i.e.
SOAP-literal, SOAP-rpc, ASN.1, etc.).
The use of this element may be optional in a tool for two reasons. Firstly the modeler may simply wish to use elements from a domain model directly as the parameters to an operation rather than specifying a message. Secondly the modeler may wish to use the convention of specifying a set of input and output messages on an operation, in which case the modeling tool would have to construct an input and output message matching the parameters when generating service descriptions in WSDL.
| Kind | Name | Type | Description |
|---|---|---|---|
| Property | encoding | String | Denotes the platform encoding mechanism to use in generating the schema
for the message; examples might be SOAP-RPC, Doc-Literal, ASN.1, and so on.
|
Property
This stereotype is used to denote that some component of a messages is an attachment to it (as opposed to a direct part of the message itself). In general this is not likely to be used greatly in higher level design activities, but for many processes attached data is important to differentiate from embedded message data. For example, a catalog service may return general product details as a part of the structured message but images as attachments to the message; this also allows us to denote that the encoding of the images is binary (as opposed to the textual encoding of the main message).
| Kind | Name | Type | Description |
|---|---|---|---|
| Property | encoding | String | Denotes the platform encoding mechanism to use in generating the schema
for the message; examples might be SOAP-RPC, Doc-Literal, ASN.1, and so on.
|
Port
The service model element provides the end-point for
service interaction (in web service terminology) whereas the definition of these
interactions are a part of the service specification. In the model a service
not only identifies the provided interface, but may also identify required interfaces
(such as callback interfaces). A service has an additional property that denotes
the binding to be used, such as SOAP-HTTP, SOAP-JMS,
and so on.
None.
Connector
A channel represents the communication path between two services. It is important to note that interaction may occur over a channel, but the channel does not represent any particular interaction. In the web services world, each service denotes the binding(s) associated with it (so that a client may access it). In a modeling profile, you denote binding either on the communication between services or between a service and consumers. In this way, you can be flexible in understanding the binding requirements .
| Kind | Name | Type | Description |
|---|---|---|---|
| Property | binding | String | Denotes the platform binding mechanism to use in generating the service binding in WSDL; examples might be SOAP-RPC, SOAP-Doc, HTTP-Get, and so on. |
Collaboration
A service collaboration is a way of specifying the implementation of a service as a collaboration of other services. From a web services point of view this corresponds to the use of BPEL4WS in specifying service implementation. So, this means that a service collaboration is used as the behavior of a service and, if it is intended to generate to a language such as BPEL -- it may have other implementation-specific constraints.
| Kind | Name | Type | Description |
|---|---|---|---|
| Property | Binding | String | Denotes the platform binding mechanism to use in generating the collaboration as a process choreography; examples might be "BPEL", "WSFL", etc. |
Classifier
Any classifier (class, component, ...) may act as the consumer of a service, and that includes another service. While this stereotype is most definitely optional it may be useful in identifying elements of a model -- that are not services themselves -- as clients of services. On the other hand it may be overhead and not used.
None.
None.
Port
A service gateway looks like a service but is only available for use on partitions and not service providers. A gateway acts as a proxy service and can be used to mediate protocols or denote the interface available to a partition. For example, we might denote that although a number of services are implemented within a partition -- only some are available for use outside the partition, and therefore gateways are provided for these services. This disallows other services or partitions from communicating to services that are not exposed via gateways.
None.
Class
A partition represents some logical or physical boundary of the system. It is optional to model partitions but useful. For example partitions could be used to represent the web, business and data tiers of a traditional n-tier application. Partitions might also be used to denote more physical boundaries (such as my primary data center, secondary site, customer site, partners and so on), in which case the crossing of partitions may have particular constraints for security, allowed protocols, bandwidth and so on.
A partition may only have properties that represent nested parts, be they services or other partitions. Note that this is a constraint - no other elements may currently be represented in a partition.
A partition also has the notion of being "strict", if a partition denotes that all communication between it and other partitions must be directed through typed gateways then it is said to be a strict partition.
| Kind | Name | Type | Description |
|---|---|---|---|
| Property | Classifier | String | A classification name, to denote the namespace scope of this partition. |
Class
The Service Provider is a software element that provides one or more services. In modeling terms one would most usually expect to see a UML component here, however such a restriction seems arbitrary and so the metaclass is noted as Class for more flexibility. A service provider has a property that captures information about its location although the meaning of this is implementation dependent. The Class acting as the service provider may not expose any attributes or operations directly, only public ports may be provided (stereotyped as service) and these are typed by service specifications.
The location property, while implementation/platform specific is useful
in generating service endpoint names. For example with WSDL the location
may be http://svc.myco.com/ and a service might be called CustInfo, in which case the endpoint name for the service could be generated as
http://svc.myco.com/CustInfo.
| Kind | Name | Type | Description |
|---|---|---|---|
| Property | allowedBindings | String | Denotes the allowed platform binding mechanism a channel may use in connecting to the service; examples might be SOAP-RPC, SOAP-Doc, HTTP-Get, and so on. |
| Property | location | String | The location of the provider, this may be used by generators to create endpoint names. |
Interface
The use of an interface denotes a set of operations provided by a service. Note that a service may implement more than one interface. By convention it is possible to attach a protocol state machine or UML 2.0 Collaboration to such a specification to denote the order of invocation of operations on a service specification. With such a behavioral specification any implementing service can be validated against not only a static but dynamic specification of its structure and behavior. Note that the service specification may only provide public operations.
| Kind | Name | Type | Description |
|---|---|---|---|
| Property | published | Boolean | This property denotes whether the service is assumed to be published into a service repository; this is a different notion from the public/private property provided by UML. |
