Page 1
Page 2
Page 3
Page 4
Introduction
So i had taken my 1st cut at WSE from
the Compact Framework (.NETcf) many months ago
... (/cfWSE). Since then, i have gotten
to do a lot more Web Service (WS) work using the .NETcf.
So I felt I was ready for a 2nd attempt to raise the
bar ... although this article is really the 3rd in
a long running series. I could not continue the /cfWSE article
because .NETcf was lacking the System.Security.Cryptography
namespace; so that is why I wrote the follow up
/spCrypt article. Now I can continue where I left off.
My motivation is 2-fold: (1) because WSE does not exist
for .NETcf. (2) give me an excuse to learn some more
of the Global Xml Architecture (GXA) specifications.
This time, client-side development will be with .NETcf
using the SP 2003 emulator. Server-side will mostly use
the WSE 2.0 implementation (currently a tech preview), along
with some of the WSE 1.0 sample web services.
SmartPhone
Developed this with the SmartPhone
2003 emulator. 2003 is important, because SP 2002 does not
support .NETcf. Also, 2003 has .NETcf with SP1 in ROM.
Pocket PC 2003 and Pocket PC Phone Edition 2003 do not have
SP1 in ROM, so you could get unexpected behavior. In general
though, this code should work on any device that can run
the .NETcf. You must also take into account what level of
cryptography and algorithms the device / emulator provides
(below).
WSE1
WSE has been released and supported
by MS for a while. The WS specs it supports are WS-Addressing,
DIME, and WS-Security.
WSE2
This is the latest release of WSE that
has been a tech preview for a while. It had some breaking
changes between it and version 1. One such change was moving
to WS-Addressing instead of WS-Routing. It still supports
DIME and WS-Security. It also adds support for WS-Trust,
WS-Policy and Ws-SecureConversation.
Service Pack 1 (SP1) Rant
For SmartPhone, .NETcf and SP1 are
in the ROM! For Pocket PC 2003, .NETcf is in ROM, but
not SP1 ... so install it. The problem is the download is
just a bunch of zip files, that you have to manually copy
around. It explicitly states no new interface changes, but
there are some methods that I want to overload now which
just became available in SP1; i can deploy the runtime to
support them but I cant use VS .NET to build to that. To
get VS .NET to build with that overload for CE / PPC, I
have to unzip the files that were deployed and then manually
rename those files to compile against, or build against
an assembly meant for SP (see below). My hope is that .NETcf
SP installation will integrate with VS .NET in the future.
GetWebRequest / GetWebResponse
These are the methods on HttpWebClientProtocol
that can now be overridden with SP1. This is useful to set
HttpHeaders, KeepAlive, and such on the underlying HttpWebRequest
and HttpWebResponse used by the autogenerated web reference.
For a SP project, you can to it right off the bat. For CE
or PPC you have to update the System.Web.Services.dll that
VS .NET builds against. What I had to do was copy the assembly
that SmartPhone builds against into the CE directory, and
then I could override that method on PPC and CE apps as
well. You also have to make sure (at least) SP1 is on the
emulator or device that you deploy to.
SP - C:\Program Files\Microsoft Visual Studio .NET 2003\CompactFrameworkSDK\
v1.0.5000\Windows CE\Smartphone\System.Web.Services.dll
CE / PPC - C:\Program Files\Microsoft Visual Studio .NET 2003\CompactFrameworkSDK\
v1.0.5000\Windows CE\System.Web.Services.dll
Session
ASP.NET handles session by using cookies.
On the full .NET framework (.NETfx) you can access
the CookieCollection to add/remove cookies, but not on .NETcf.
So if you wanted to do stateful WS calls your options were
cookieless sessions (required WS change), or handle all
the SoapMessaging by using the lower level HttpWebRequest/Response
classes. By hooking GetWebRequest/Response, you can add
the proper cookie headers directly to the HttpWebRequest
without changing the service, and still have the convenience
of using a web reference proxy. A better way would be per
keith ba's WS book, in which Session information is passed
using a SoapHeader, and it is not reliant upon a protocol.
I do not know of a specification that exists for this?
Service Pack 2 (SP2) Rant
Same as above for SP1, plus you dont
get an update for SmartPhone. SP2 has some Web Service fixes
and performance improvements... which I obviously want.
My hope is that SP2 fixes some of the bugs I will detail
below. Maybe it will eventually be deployed by the phone
carriers, since they can update the ROM? NOTE per an MS
newsgroup posting, SP2 will be in the next SmartPhone SDK
release ... whenever that is :)
SoapHeaders
One of the SP2 fixes is supposed to
handle how null SoapHeaders are handled. I think the behavior
is that if you have a null SoapHeader as InOut on the .NETcf,
then it will send the element as xsi:nil= "true", while
the full framework will not send the SoapHeader at all.
Another has to do with namespace handling. Something to
the effect of on the .NETcf I had to explicitly declare
a Namespace on a child element to be the same as the parent,
while this re-declaration did not have to be done on the
full framework. There was a similar issue with XmlAttributes
and how they had to be declared more explicitly. Related
to this, there is an SP2 fix for XmlTextReader and namespace
handling which comes in handy as well.
WS-Utility / Timestamp
I had implemented this previously. All
I did was extend it to more fully support the specification.
I ran it against the WSE2 Timestamp sample, and it will
probably work for the WSE1 Timestamp sample as well. One
thing to note is that the SP emulator displayed the same
time as my desktop, but its default time zone was (GMT London,
Dublin) so all of my calls would fail until I changed the
TimeZone and the Time. It was annoying to do this manually,
so I wrote a little pInvoke class to handle updating
the TimeZoneInformation bias for me. This gets called
every time my test app loads, so you would have to modify
it to fit your own time zone. Also, if you leave the Emulator
running for a while (e.g. about an hour), the time will
get out of synch with the desktop by a number of minutes.
So if your TimeStamp expiration time is about 5 minutes,
then you will start getting TimeStamp expiration SoapFaults.
Just restart the emulator and it will synch again.
//request
<Timestamp xmlns="http://schemas.xmlsoap.org/ws/2002/07/utility">
<Created>2003-11-07T23:48:21Z</Created>
<Expires>2003-11-07T23:53:21Z</Expires>
</Timestamp>
//response
<wsu:Timestamp>
<wsu:Created>2003-11-07T23:49:34Z</wsu:Created>
<wsu:Expires>2003-11-07T23:50:34Z</wsu:Expires>
</wsu:Timestamp>
Web Reference Wrappers
Instead of changing autogeneated web
reference proxies (to add SoapHeaders and such), I always
subclass them. This lets me update the web references frequently
as the interface changes and not worry about losing any
Attributes I have added to that code. The problem is the
way I overloaded the WebReference invoke of the WebMethod
using the 'new' keyword does not seem to work on the full
framework. It fails with the 'methodName' cannot be reflected
exception. I think the proxy code generator should
be changed to add the virtual keyword. NOTE when I
tested on the full framework, my clients typically did not
use WSE. WSE clients inherit from Microsoft.Web.Services.WebServicesClientProtocol
so they might exhibit different behavior.
{any} and {@any}
The X in Xml stands for eXtensible.
This flows into the specifications themselves. Alot of times
you will see {any} and {@any} which represent any XmlElement
and any XmlAttribute can show up as valid nodes. Used to
be all over HailStorm. If a web service declares them, then
your client will be generated with them as well. Great for
the .NETfx, but they have issues on .NETcf. On .NETfx,
if it is an 'in' SoapHeader with an XmlAnyElement or XmlAnyAttribute,
then the WS would get called if you left them
as null. Sometimes you would get this behavior on .NETcf.
For the TimestampHeader, I would either get a NullReferenceException
or an IndexOutOfRangeException and no stream would be sent
out for the WS request. I would get similar results if I
actually set the values before trying to make the WS call.
For retrieving 'out' SoapHeaders from a web service
call, I can get XmlAnyElement and XmlAnyAttributes on the
SoapHeader itself. If that SoapHeader element contained
a sub element that also contained an XmlAnyElement, that
would work; but if it contained an XmlAnyAttribute, then
it would fail with an exception something like: 'Text' is
an invalid node type. Line 1, position 392. So I would typically
decorate the SoapHeaders accordingly with XmlAnyElement
or XmlAnyAttributes and then comment them out as things
broke. NOTE that XmlAnyElement and XmlAnyAttribute
are different than UnknownSoapHeaders. XmlAnyElement and
XmlAnyAttribute would be child nodes of a known SoapHeader.
//request
<AnyShIn xmlns="http://tempuri.org/" strAttribute="strAttrib">
<strElement>strElem</strElement>
<anyShSub strAttribute="strAttrib">
<strElement>strElem</strElement>
</anyShSub>
</AnyShIn>
//response
<AnyShOut strAttribute="strAttrib" myAnyAttrib="myAnyAttribValue" xmlns="http://tempuri.org/">
<strElement>strElem</strElement>
<anyShSub strAttribute="strAttrib">
<strElement>strElem</strElement>
<myAnyElem myAnyAttrib="myAnyAttribValue" xmlns="" />
</anyShSub>
<myAnyElem myAnyAttrib="myAnyAttribValue" xmlns="" />
</AnyShOut>
Next Page