|
An Insecure Present :
As we have already said, the Kerberos-based interchange is naturally still a while off. Therefore, the
initial release of HailStorm in a Box skirts entirely over the issue of security, replacing the Kerberos
ticket with a simple ID number generated when a first provisioning a HailStorm service for the user. If
you've already installed the SDK, you can discover your identity and your temporary ID using the
hspost executable in the Bin directory of the installation:
C:\HailStorm\Bin>hspost -p
Your username is danm - PUID = 7525
Similarly, the bodies of the SOAP packets sent between endpoint and service are not currently
encrypted either. We'll see when we construct an example query inside a SOAP packet where this
current shortcut fits in and the final solution that will replace it.
The Simple Object Access Protocol is described in its specification as "a lightweight protocol for the
exchange of [structured and typed] information [between peers] in a decentralized, distributed
environment". As this is the sort of environment we be using when programming against HailStorm
SOAP is ideal. Intended as a simple alternative to other over-the-wire protocols (like DCOM,
CORBA/IIOP and RMI) that could work within the generic Internet infrastructure with no other
assistance, its sole function is to define the format of the message sent between clients and servers.
Other internet protocols ? in this case, HTTP, TCP, and SMTP ? define the (synchronous and
asynchronous) transport mechanisms used to send the messages.
Each SOAP message is an XML document with three main elements: the SOAP envelope, the SOAP
header, and the SOAP body.
Fig - SOAP Envelope
- The <Envelope> element is the mandatory top-level element of a SOAP message,
wrapping up both the message itself and any information about the message that might be
necessary for its successful delivery and processing.
- The optional <Header> element lets you specify extra information about the message that is
not the message itself. For example, authentication, transaction management, and delivery
routes.
- The mandatory element contains the actual payload of the SOAP message, be it a
request from an endpoint or a response from a server. The latter might contain a <Fault>
element indicating an error or glitch occurred in the processing of the request.
SOAP also defines a namespace for the envelope at http://schemas.xmlsoap.org/soap/envelope/.
This takes the attribute encodingStyle that allows you to set the serialization rules used in the
SOAP message.
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Header>
some additional info about the message here
</s:Header>
<s:Body>
actual message payload in XML here
</s:Body>
</s:Envelope>
This schema is actually stricter than XML in an effort to keep things simple (which is the aim of SOAP
after all), preventing the use of DTDs and processing instructions in a message for example.
For further information on SOAP, check out the W3C specification at
http://www.w3c.org/TR/SOAP/.
SOAP :
The choice of SOAP as the communication protocol between HailStorm endpoints and servers is not a
surprise. Microsoft's open access strategy and HailStorm's web service-centric nature matches SOAP's
language and platform neutrality. However, SOAP never figures in HailStorm as an RPC medium (its
original function), carrying objects and serialized structured data across the web. Instead, it uses
SOAP's ability to route XML messages over the web to a server ? via zero or more intermediaries,
synchronously or asynchronously ? and receive them back the same way. Indeed, a lot more
information goes into the header of a SOAP envelope than in its message payload.
Deconstructing a HailStorm Request Message :
Let's take an example and briefly look at each part of a request message before we go into the real
detail. Say a friend has just got married and might need to update her last name in the contacts list
stored in your digital safe deposit box by the myContacts service. The message you'd need to send
HailStorm would look like this:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:srp="http://schemas.xmlsoap.org/rp/"
xmlns:m="http://schemas.microsoft.com/hs/2001/10/myContacts/"
xmlns:hs="http://schemas.microsoft.com/hs/2001/10/core"
xmlns:ss="http://schemas.xmlsoap.org/soap/security/2000-12">
First, we have the definition of the namespaces at work inside this SOAP envelope/message. These are
all pretty standard except number three which changes depending on the service you're addressing.
<s:Header>
<srp:path>
<srp:action>
http://schemas.microsoft.com/hs/2001/10/core#request
</srp:action>
<srp:to>
http://this.cluster.myContacts.msn.com/danm@wrox.com/
</srp:to>
<srp:fwd>
<srp:via/>
</srp:fwd>
<srp:rev>
<srp:via/>
</srp:rev>
<srp:id>
uuid:764CBFB8-A9FF-46D0-BAEC-3D11F9AA44A8
</srp:id>
</srp:path>
At the top of the header is the routing information describing what type of message this is, its ultimate
destination, and any intermediate points it will need to take on its trip there or on its trip back. Finally,
there is the unique identifier for the message that the response will quote back for reference.
<ss:licenses>
<hs:identity>
<hs:kerberos>0123456789ABCDEF</hs:kerberos>
</hs:identity>
</ss:licenses>
Second in the list is the Kerberos ticket used for talking with HailStorm. Later in the conversation, you
may also include here the role the server has assigned to you as this expedites the carrying out of your
instructions.
<hs:request service="myContacts" document="content" method="replace"
genResponse="always">
<hs:key puid="4D36E96A-E325-11CE-BFC1-08002BE10318"
instance="danm@wrox.com" cluster="this.cluster"/>
</hs:request>
</s:Header>
Last in the message header is information about the request itself; its destination, purpose, notes for the
response, and so on.
We could have included two further elements in the header ? and ?
but the former is specific to sending SOAP message asynchronously which we can't at the moment and
the latter, which replaces the standard request, wasn't working as we went to press. The XMI manual
contains full details of what they should do.
As noted before, the body of the message contains the actual instructions to HailStorm ? in this case, a
request to replace your friend's maiden name with her married name.
<s:Body>
<hs:replaceRequest
select="/hs:/myContacts/contact[@id='33']/lastName">
<m:lastName>Simon</m:lastName>
</hs:replaceRequest>
</s:Body>
</s:Envelope> An Insecure Present :
As we have already said, the Kerberos-based interchange is naturally still a while off. Therefore, the
initial release of HailStorm in a Box skirts entirely over the issue of security, replacing the Kerberos
ticket with a simple ID number generated when a first provisioning a HailStorm service for the user. If
you've already installed the SDK, you can discover your identity and your temporary ID using the
hspost executable in the Bin directory of the installation:
C:\HailStorm\Bin>hspost -p
Your username is danm - PUID = 7525
Similarly, the bodies of the SOAP packets sent between endpoint and service are not currently
encrypted either. We'll see when we construct an example query inside a SOAP packet where this
current shortcut fits in and the final solution that will replace it.
The Simple Object Access Protocol is described in its specification as "a lightweight protocol for the
exchange of [structured and typed] information [between peers] in a decentralized, distributed
environment". As this is the sort of environment we be using when programming against HailStorm
SOAP is ideal. Intended as a simple alternative to other over-the-wire protocols (like DCOM,
CORBA/IIOP and RMI) that could work within the generic Internet infrastructure with no other
assistance, its sole function is to define the format of the message sent between clients and servers.
Other internet protocols ? in this case, HTTP, TCP, and SMTP ? define the (synchronous and
asynchronous) transport mechanisms used to send the messages.
Each SOAP message is an XML document with three main elements: the SOAP envelope, the SOAP
header, and the SOAP body.
Fig - SOAP Envelope
- The <Envelope> element is the mandatory top-level element of a SOAP message,
wrapping up both the message itself and any information about the message that might be
necessary for its successful delivery and processing.
- The optional <Header> element lets you specify extra information about the message that is
not the message itself. For example, authentication, transaction management, and delivery
routes.
- The mandatory element contains the actual payload of the SOAP message, be it a
request from an endpoint or a response from a server. The latter might contain a <Fault>
element indicating an error or glitch occurred in the processing of the request.
SOAP also defines a namespace for the envelope at http://schemas.xmlsoap.org/soap/envelope/.
This takes the attribute encodingStyle that allows you to set the serialization rules used in the
SOAP message.
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Header>
some additional info about the message here
</s:Header>
<s:Body>
actual message payload in XML here
</s:Body>
</s:Envelope>
This schema is actually stricter than XML in an effort to keep things simple (which is the aim of SOAP
after all), preventing the use of DTDs and processing instructions in a message for example.
For further information on SOAP, check out the W3C specification at
http://www.w3c.org/TR/SOAP/.
SOAP :
The choice of SOAP as the communication protocol between HailStorm endpoints and servers is not a
surprise. Microsoft's open access strategy and HailStorm's web service-centric nature matches SOAP's
language and platform neutrality. However, SOAP never figures in HailStorm as an RPC medium (its
original function), carrying objects and serialized structured data across the web. Instead, it uses
SOAP's ability to route XML messages over the web to a server ? via zero or more intermediaries,
synchronously or asynchronously ? and receive them back the same way. Indeed, a lot more
information goes into the header of a SOAP envelope than in its message payload.
Deconstructing a HailStorm Request Message :
Let's take an example and briefly look at each part of a request message before we go into the real
detail. Say a friend has just got married and might need to update her last name in the contacts list
stored in your digital safe deposit box by the myContacts service. The message you'd need to send
HailStorm would look like this:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:srp="http://schemas.xmlsoap.org/rp/"
xmlns:m="http://schemas.microsoft.com/hs/2001/10/myContacts/"
xmlns:hs="http://schemas.microsoft.com/hs/2001/10/core"
xmlns:ss="http://schemas.xmlsoap.org/soap/security/2000-12">
First, we have the definition of the namespaces at work inside this SOAP envelope/message. These are
all pretty standard except number three which changes depending on the service you're addressing.
<s:Header>
<srp:path>
<srp:action>
http://schemas.microsoft.com/hs/2001/10/core#request
</srp:action>
<srp:to>
http://this.cluster.myContacts.msn.com/danm@wrox.com/
</srp:to>
<srp:fwd>
<srp:via/>
</srp:fwd>
<srp:rev>
<srp:via/>
</srp:rev>
<srp:id>
uuid:764CBFB8-A9FF-46D0-BAEC-3D11F9AA44A8
</srp:id>
</srp:path>
At the top of the header is the routing information describing what type of message this is, its ultimate
destination, and any intermediate points it will need to take on its trip there or on its trip back. Finally,
there is the unique identifier for the message that the response will quote back for reference.
<ss:licenses>
<hs:identity>
<hs:kerberos>0123456789ABCDEF</hs:kerberos>
</hs:identity>
</ss:licenses>
Second in the list is the Kerberos ticket used for talking with HailStorm. Later in the conversation, you
may also include here the role the server has assigned to you as this expedites the carrying out of your
instructions.
<hs:request service="myContacts" document="content" method="replace"
genResponse="always">
<hs:key puid="4D36E96A-E325-11CE-BFC1-08002BE10318"
instance="danm@wrox.com" cluster="this.cluster"/>
</hs:request>
</s:Header>
Last in the message header is information about the request itself; its destination, purpose, notes for the
response, and so on.
We could have included two further elements in the header ? and ?
but the former is specific to sending SOAP message asynchronously which we can't at the moment and
the latter, which replaces the standard request, wasn't working as we went to press. The XMI manual
contains full details of what they should do.
As noted before, the body of the message contains the actual instructions to HailStorm ? in this case, a
request to replace your friend's maiden name with her married name.
<s:Body>
<hs:replaceRequest
select="/hs:/myContacts/contact[@id='33']/lastName">
<m:lastName>Simon</m:lastName>
</hs:replaceRequest>
</s:Body>
</s:Envelope> | 
.NET
ASP (16) 
