Introduction

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.

Attachment Encoding

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.

An Example

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.