指南:消息附件
本指南提供了通过引用或包含将大元素或复杂元素作为消息的附件传输的方法,使设计人员能满足性能或带宽约束。
关系
相关元素
主要描述

简介

设计消息时,有时存在我们发现实际已作为文档实现的结构或其他合成且可能很大的文件。例如,报告或产品信息可能作为 PDF 文件分发,或者消息可能有附加的描述产品或项目的图像。用于软件服务的统一建模语言(UML)概要文件提供了其他构造型 <<消息附加>>,它可以被附加到消息模型中的属性,指示指定的内容以某种方法被附加到模型。这允许设计人员提供消息设计的重要方面的详细规范。特别是对于性能和带宽使用,传递二进制的大附件可能成为重要因素。

附件或链接

在因特网体系结构中,有一种方法可以传输大量信息、传递允许接收方通过更合适的协议(如 FTP)下载内容的 URL。如果数据不经常更改,这也是很有用的,因为可以将它放到所有客户机都能检索的公共位置;如果消息接收方选择不下载附加内容,它也是一种有效的机制。这样做的优点是将附件下载的需求放在了客户机上。这样做的缺点是给客户机带来了更多工作。

处理附件的另一种可能的方法是著名的位置。例如,服务文档的一部分表示附件的基本 URL,消息的某些元素表示可附加到 URL 以获得要下载的实际资源的标识或文件名称。

附件编码

消息附件构造型还有表示附件的编码形式的属性。尽管该名称与消息上的属性相同,还是建议用于表示附件编码的值应该是 MIME 类型。这些类型已经被特定的因特网基础结构使用,如传输二进制数据(如 Web 页面的图像)中的 HTTP 协议。

关于 MIME 类型的更多信息,请参阅 IETF RFC 2046 - 多用途因特网邮件扩充协议(MIME)第二部分:介质类型

示例

让我们考虑提供产品目录的服务。很明细,有查找项目、执行查询和返回完整的产品信息的操作。如果我们查看产品数据的模型的子集,我们会看到每个产品条目都有一个相关联的图像,并且可能有一个放大的图像以便于查看。在以下的模型中,我们能看到两个图像被标记为产品目录数据结构的附件。在此图中,我们看不到的是在这两种情况下编码属性的值都是“image/jpeg”。

文本内容中所述的图。

对于以上显示的示例,可以发送每个图像的 URL,允许客户机决定是否以及何时下载实际的图像。URL 当然将表示下载操作的协议和位置。 以下是 ProductCatalogData 结构的一个版本,且有图像作为链接。

文本内容中所述的图。