 |
| This artifact is a container which identifies a subset of an information model or domain model which is passed into or out of a service invocation. A message is always passed by value and should have no defined behavior. |
| Work Product Kinds: Model Element |
|
Purpose
|
The following people use the message :
-
Implementers, for the development of schema describing the implementation-specific message structures.
-
Designers, of other services in the understanding of how information is shared and reused among service
specifications.
-
Information/Data Architects, in understanding the relationship between the implementation-neutral domain
model and implementation-specific representations such as database or message schema.
The message is optional and used to disambiguate message structures from other elements representing the same Domain Model. For example, there may be a technology-neutral domain
model used to represent core business items such as Customer, Product, Order, and so on. This model is related to a set
of technology models that represent the same items in specific ways, message structures that take into account the
hierarchical nature of XML, database schema that normalize the object model, and so on.
Where there is no separate domain model or where separate models are used for domain and message definition, the use of
the explicit message stereotype is unnecessary.
|
Relationships
| Container Artifact |
|
| Roles | Responsible:
| Modified By:
|
Description
| Main Description |
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.
|
Tailoring
| Representation Options | UML Representation:
Class, stereotyped as <<Message>>. A Message shall not have operations or behavioral
specifications defined.
Properties:
binding : 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.
|
More Information
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|
