When designing Messages, there are occasionally structures that we find are
actually realized as documents or other compound and potentially large files. For example, reports or product
information may be distributed as PDF files or a message may have attached images describing a product or item. The
Unified Modeling Language (UML) Profile for Software Services provides an
additional stereotype <<Message Attachment>> which can be attached to properties in a message model
noting that the specified content is attached to the model in some way. This allows the designer to provide a detailed
specification of a very important aspect of message design. In particular, in respect to performance and bandwidth
usage, the passing of large binary attachments may be a significant factor.
Attachments or Links
In an Internet architecture, there is an approach to the transfer of large amounts of information, the passing of a URL
that allows the recipient to download the content via a more appropriate protocol such as FTP. This is also very useful
if the data does not change often because it can be placed in a common location for all clients to retrieve; it is also
an efficient mechanism if the message recipient may chose not to download the additional content. This has the
advantage of putting the requirement for attachment download on the client. This may more of a disadvantage and
additional work for the client.
Another possible approach for attachments is the well known location. For example, a part of the documentation
of the service denotes a base URL for attachments and some element of the message denotes an identifier or file name
that can be appended to the URL to get the actual resource to download.
The message attachment stereotype also has a property that denotes the encoding form of the attachment. Although the
name is the same as the property on a Message, it is recommended that the values used to denote the encoding for
attachments be MIME types. These types are already used by certain Internet infrastructure such as the HTTP protocol in
transferring binary data such as images for Web pages.
For more information on MIME Types see the IETF RFC 2046 - Multipurpose
Internet Mail Extensions (MIME) Part Two: Media Types.
Let us consider a service that provides a product catalog. Obviously there are operations to find items, execute
queries, and return complete product information. If we look at a subset of the model of the product data, we can see
that each product entry has an associated image and possibly a zoomed-in image for easier viewing. In the model below,
we can also see that the two images are marked as attachments to the product catalog data structure. What we cannot see
in this diagram is that the value for the encoding property is "image/jpeg" in both cases.
As for the example shown above, it would be possible to send a URL for each image, allowing the client to decide if and
when to download the actual image. The URL of course would denote the protocol and location for the download operation.
The following is a version of the ProductCatalogData structure with the images as links.