Development | .NET Compact Framework

SmartPhone (SP) and WebService Enhancements (WSE) with .NETcf
Written by casey chesnut  [author's bio]  [read 46807 times]
Edited by Derek

         

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 

Back to .NET Compact Framework | [Article Index]