SOAP Protocol primary Guide (ii)

There are two problems with this expression. The first and easiest thing to understand is that the same message was sent two times, which led to a larger message than the actual message needed. A more subtle but more important problem is that because the deserialization cannot distinguish between two adjustment objects with the same value and a single Adjustment object referenced in two places, the identity relationship between the two access elements is lost. If the message receiver has performed the following test on the result object, (xfer.to = = Xfer.from) will not return true.

void Processtransfer (transfer xfer) {
if (xfer.to = = Xfer.from)
Handledoubleadjustment (xfer.to);
Else
Handleadjustments (xfer.to, Xfer.from);
}

The fact that (Xfer.to.equals (Xfer.from)) may return true is only a comparison of the values of two access elements rather than their identities.
In order to support serialization of types that must maintain an identity relationship, SOAP supports multiple reference access elements. The access element we are currently exposed to is a single reference access element, that is, the element value is embedded under the access element, and other access elements are allowed to reference that value (this is very similar to the [unique] concept in the NDR). Multi-reference access elements are always encoded as empty elements that contain only known soap:href properties. The Soap:href property always contains a code fragment identifier that corresponds to the instance that the access element refers to. If the to and from access elements have been encoded as multiple reference access elements, the serialized transfer object looks like this:

xmlns:t= ' Urn:develop-com:java:com.bofsoap.ibank '

This encoding assumes that an instance of a type compatible with the adjustment class has been serialized elsewhere in the envelope, and that the instance has been marked with the Soap:id attribute, as follows:

xmlns:t= ' Urn:develop-com:java:com.bofsoap.ibank '
3514
-100.0

For multiple reference access elements, it is the work of the deserialization program to decompose the identifier of the code snippet (for example, #id1) into the correct instance.

The preceding discussion explains how a multiple-reference access element is associated with its target instance. The following is a discussion of where the target instance is serialized. This is related to the concept of independent elements and packages.