Lors de la conception des messages, il s'avère parfois que certaines structures sont
réalisées sous forme de documents ou d'autres fichiers composés et potentiellement lourds. Par exemple, les rapports ou
les informations sur les produits peuvent être distribués sous forme de fichier PDF, ou un message peut comporter des
images qui décrivent un produit ou un article. Le profil Unified Modeling Language (UML) pour les services logiciels offre un
stéréotype supplémentaire, <<Message Attachment>>, qui peut être ajouté aux propriétés dans un
modèle de message, pour indiquer que le contenu spécifié est joint au modèle par un moyen quelconque. Il permet au
concepteur de spécifier en détail un aspect très important de la conception de message. En ce qui concerne plus
particulièrement les performances et l'utilisation de la bande passante, l'envoi de pièces jointes binaires de grandes
dimensions peut être un élément important.
Pièces jointes ou liens
Dans une architecture Internet, pour transférer de gros volumes d'informations, il est possible d'envoyer une URL qui
permet au destinataire de télécharger le contenu de la pièce jointe par le biais d'un protocole plus approprié, tel que
FTP. Cette approche est très utile si les données ne changent pas souvent, car elles peuvent être situées à un
emplacement commun pour tous les clients. Ce mécanisme est également efficace si le destinataire du message peut
choisir de ne pas télécharger le contenu supplémentaire. Il présente l'avantage de laisser au client le soin de
télécharger la pièce jointe, mais l'inconvénient de constituer une charge de travail supplémentaire pour ce dernier.
Il existe une autre approche : celle de l'emplacement identifié. Par exemple, une partie de la documentation du
service indique une URL de base pour toutes les pièces jointes ; certains éléments du message indiquent ensuite un
identifiant ou un nom de fichier qui peut être ajouté à l'URL pour permettre d'obtenir la ressource à télécharger.
Codage des pièces jointes
Le stéréotype de la pièce jointe d'un message possède également une propriété qui indique sa forme de codage. Bien que
le nom de cette propriété soit identique à celui de la propriété d'un message, nous vous recommandons d'utiliser des
valeurs de type MIME pour indiquer le codage des pièces jointes. Ces types sont déjà utilisés par certaines
infrastructures Internet comme le protocole HTTP lors du transfert de données binaires, telles que des images pour les
pages Web.
Pour plus d'informations sur les types MIME, voir IETF RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
(Multipurpose Internet Mail Extensions (MIME) Deuxième partie : Types médias).
Considérons un service qui fournit un catalogue de produits. Des opérations sont bien évidemment nécessaires pour
rechercher des articles, exécuter des requêtes et renvoyer les informations complètes d'un produit. En observant un
sous-ensemble du modèle des données du produit, nous constatons que chaque entrée de produit est associée à une image,
et éventuellement à une image agrandie pour en faciliter la visualisation. Dans le modèle ci-dessous, nous constatons
également que les deux images sont marquées en tant que pièces jointes à la structure Données du catalogue de produits
(ProductCatalogData). Cependant, le diagramme ne nous indique pas que la valeur de la propriété de codage est
"image/jpeg" dans les deux cas.
Dans le cas de l'exemple illustré ci-dessus, il serait possible d'envoyer une URL pour chaque image, ce qui permettrait
au client de décider si et à quel moment télécharger l'image. L'URL indiquerait bien sûr le protocole et l'emplacement
pour le téléchargement. Dans la version suivante de la structure ProductCatalogData, les images sont envoyées sous
forme de liens.
|