A {@link Message} consists of the following:
The basic idea behind the {@link Message} is to hide the actualdata representation. For example, a {@link Message} might beconstructed on top of an {@link InputStream} from the accepted HTTP connection,or it might be constructed on top of a JAXB object as a result of the method invocation through {@link Proxy}. There will be a {@link Message} implementation for each of those cases.
This interface provides a lot of methods that access the payload in many different forms, and implementations can implement those methods in the best possible way.
A particular attention is paid to make sure that a {@link Message}object can be constructed on a stream that is not fully read yet. We believe this improves the turn-around time on the server side.
It is often useful to wrap a {@link Message} into another {@link Message}, for example to encrypt the body, or to verify the signature as the body is read.
This representation is also used for a REST-ful XML message. In such case we'll construct a {@link Message} with emptyattachments and headers, and when serializing all headers and attachments will be ignored.
XOP is considered as an {@link Codec}, and therefore when you are looking at {@link Message}, you'll never see <xop:Include> or any such elements (instead you'll see the base64 data inlined.) If a consumer of infoset isn't interested in handling XOP by himself, this allows him to work with XOP correctly even without noticing it.
For producers and consumers that are interested in accessing the binary data more efficiently, they can use {@link XMLStreamReaderEx} and{@link XMLStreamWriterEx}.
Often {@link Packet} include information local to a particularinvocaion (such as {@code HttpServletRequest}, from this angle, it makes sense to tie a lifespan of a message to one pipeline invocation.
On the other hand, if you think about WS-RM, it often needs to hold on to a message longer than a pipeline invocation (you might get an HTTP request, get a message X, get a second HTTP request, get another message Y, and only then you might want to process X.)
TODO: what do we do about this?
TODO: can body element have foreign attributes? maybe ID for security? Yes, when the SOAP body is signed there will be an ID attribute present But in this case any security based impl may need access to the concrete representation. TODO: HTTP headers? Yes. Abstracted as transport-based properties. TODO: who handles SOAP 1.1 and SOAP 1.2 difference? As separate channel implementations responsible for the creation of the message? TODO: session? TODO: Do we need to expose SOAPMessage explicitly? SOAPMessage could be the concrete representation but is it necessary to transform between different concrete representations? Perhaps this comes down to how use channels for creation and processing. TODO: Do we need to distinguish better between creation and processing? Do we really need the requirement that a created message can be resused for processing. Shall we bifurcate? TODO: SOAP version issue SOAP version is determined by the context, so message itself doesn't carry it around (?) TODO: wrapping message needs easier. in particular properties and attachments.@author Kohsuke Kawaguchi
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|