WS-I Attachments Profile Locate
WSO2 SOA Enablement Server for Java provides full support for WS-I Attachments Profile 1.0, which describes how to send interoperable SOAP messsages with attachments using MIME. There are two ways MIME attachments can be described in WSDL in a WS-I compliant fashion:
By using mime:content. Such attachments are recognized in messages by the special format of the Content-Id value, as described in section 3.8 of the profile, Value-space of Content-Id Header. The domain can be set in configuration file.
By including the special type swaRef in the XML schema of the message, as described in section 4.4 of the profile, Referencing Attachments from the SOAP Envelope.
![[Note]](images/note.gif) | Note |
|---|---|
Attachments compliant with WS-I are not compatible with other attachments specifications such as SOAP Messages with Attachments, DIME or MTOM/XOP. WSO2 SOA Enablement Server for Java supports all of these, but you must choose exactly one (for one service). | |
Attachment with Serialization of XML Infoset Locate
Rule R2943 of the WS-I Attachments Profile 1.0 reads, "In a MESSAGE, a message part bound to a mime:content that refers to global element declaration (via the element attribute of the wsdl:part element) MUST be serialized within the MIME part as a serialization of an XML infoset whose root element is described by the referenced element." In other words, it specifies that some attachment part should contain XML valid according to some XML Schema that is specified as a part of WSDL.
WSO2 SOA Enablement Server for Java never generates such WSDL, is always uses type attribute in wsdl:part for attachment part (rule R2943 applies in this case).
It is possible to correctly implement requirement of rule R2943 with WSO2 SOA Enablement Server for Java, since all attachments are available on Java level as binary stream via getData in MessageAttachment but it is up to user to handle this correctly. WSO2 SOA Enablement Server for Java runtime does not enforce this rule.
Faults with Attachments Locate
Rules R2920 and R2930 of the profile allow the sending of SOAP faults inside the MIME root part if the normal response message is MIME. The message can contain attachment parts. However, rule R2930 prohibits the fault to reference the attachments.
WSO2 SOA Enablement Server for Java will never send a fault in MIME message but it is able to receive such messages. The attachments are ignored by WSO2 SOA Enablement Server for Java consistent with the paragraph above. It shouldn't be needed but it is possible to access these attachments in a handler, for example by extending UnreferencedAttachmentsHandler.
What to Avoid in Code Locate
In addition to obvious conditions like setting WSO2 SOA Enablement Server for Java to use WS-I compliant mode, there are some guidelines the application code should follow:
mime:content attachments (as described in Section 3.8) are mandatory; they must be always present in the message. WSO2 SOA Enablement Server for Java enforces this by requiring these attachments. If an attachment should be optional, use a swaRef attachment in the WSDL.
MessageAttachment has the methods setContentId(), setContentLocation() and setContentType(). Using these methods turns off normal WSO2 SOA Enablement Server for Java processing of the MIME headers values. This implies the user becomes reponsible to follow all rules concerning these headers. Therefore you normally should not use these methods.
Each MIME part should have a Content-Transfer-Encoding header (unless it contains 7bit data but this is very rare for binary data). The default setting is in persistent server configuration. The user code can override the setting with CallContext.DEFAULT_MIME_CONTENT_TRANSFER_ENCODING context property. When using 7bit or 8bit values (both mean identity transformation, i.e. no change), the programmer should be sure the real data really match the description. Refer to RFC2045 for details.