Mark Wilson I am the creator of TopXML. I am available for international and local (Australia) contracts. I am a Solution Architect/Business Analyst. I have worked in IT in several countries (NZ, Australia, South Africa, UK) building and training teams for government and very large non-governmental organizations. I am ex-Microsoft Consulting Services. I wrote the first book on Microsoft XML published in 2000 called XML Programming with VB and ASP. Most recently I have been building tools for the SEO industry. Ask me for a 37 point SEO health-checkup for your website.
First posted :
03/19/2008
Times viewed :
2622
Using the .NET SoapFormatter
One of the hot, new technologies in the .NET Framework are is
the support of the SOAP protocol. Contrary to a common perception, SOAP is not
limited to WebServices or the internet. The protocol is designed to work over a
number of different transport mechanisms, email or message queuing for example.
Building applications communicating over the SOAP protocol with the .NET
Framework is not limited to ASP.NET either. The .NET Framework offers another
solution to create and process SOAP messages independent of the whole
WebServices architecture.
In the following chapter we will learn how to generate and
parse SOAP messages with the SoapFormatter, which is rooted in the runtime
serialization framework. The .NET framework uses the SoapFormatter to
communicate between distributed objects, either to package up method calls to
transmit them to a remote server or transfer entire objects between
applications. The latter is referred to as Marshal-By-Value or short MBV
(displayed in the figure). We will only focus on Marshal-By-Value scenarios in
this chapter. .NET remoting is by far too much information to bring into this
chapter on top of the wealth of information about the SoapFormatter. There are
several books dealing exclusively with remoting.
Figure Marshalling an object graph by value will serialize all objects in the
graph into a message format that is well suited for transmission from the
sender to the receiver. The receiver reads the message and produces a full copy
of the original graph.
The first technology we need to understand is the SOAP protocol
itself. It defines an XML-based format for the exchange of messages. The .NET
Framework in release 1.0 supports version 1.1 of the protocol. At the time of
this writing version 1.2 is just around the corner, but it requires a future
release of the Framework to support SOAP 1.2 compliant messages.
SOAP messages are structured into two sections: The message body
with the payload and the header for metadata to provide context about the
payload. SOAP messages do not have to be sent directly to the receiver. The
standard allows other entities along the way to the receiver to inspect the
message and act on the information in the header section. Both sections are
embedded into an envelope element (see figure 13.2). Only the message body is
exclusively intended for the ultimate receiver messages.
Figure The anatomy of a SOAP message. A SOAP message is divided into two sections. The body section
contains the information transmitted to the ultimate receiver of the message,
such as a serialized object graph or a request
for a method call. The optional header section can provide additional
context information about message.
The standard defines four different body types: Serialized
object graphs for “document-style” messages(1), requests for remote method
invocations(2) and their responses(3) and information about failures during
transmission or processing of a message(4). More specifically, section 5 of the
protocol describes the format for transmitted objects, section 7 describes the
format for method invocations and section 4 describes the format to communicate
failures, or faults, as the standard calls them. Message based applications typically format messages. Message
based applications where messages may be broadcast to multiple receivers and do
not require an immediate response typically employ “document-style” messages.
WebServices on the other hand are based on a method invocation model and
utilize RPC-style.
