Windows CE Web Services
Web services are typically put to use in environments in which resources like memory and disk-space are of little concern, but what happens when such resources are scarce and circumstances still require using Web services? Enter the world of embedded devices, where the ABC's for using Web services are a little different than those used in full-fledged computing environments. In this tip, we will address the state of affairs for Web services in Windows CE, one of the primary operating systems used in embedded devices.
Windows CE is an operating system (OS) built from the ground up solely targeting the embedded device market, this in contrast to its close relative 'Windows XP embedded', which even though targets similar devices, is based on the more PC-orientated OS of the same name. Another important fact to point out about Windows CE is that it's a componentized OS, making Windows CE the basis for multiple customized OSes used by device manufacturers. Among these OSes you will find Windows for Pocket PC and Windows Mobile to name few, the relevance is that branding aside, Windows CE's technical foundations touch many devices in the embedded market.
Moving along to Web services in Windows CE, we come to another fork in the road, one of using either managed or unmanaged code for designing Web services. The differences in taking either route come from the fact that Microsoft has two top-tier programming models: one using the .NET framework -- dubbed 'managed', due to its memory management capabilities -- and another using COM/DCOM objects -- often called 'native' due to its lack of integrated memory management.
Now we turn specifically toward the deployment of Web services in Windows CE devices, because even though the consumption of Web services in such devices is also interesting in itself, deploying Web services in embedded devices is the far more powerful business scenario. Just think of a device this size capable of providing real-time information to other applications running in an SOA, for tasks ranging from monitoring and tracking to any other area in which PC environments are simply not a viable option.
To begin from familiar ground, we will illustrate the main differences you will encounter when deploying Web services from the heavier-weight Windows XP or Windows Vista OSes to the more lightweight Window CE OS. Parting from this, it will be assumed you have all the usual suspects for developing Windows applications, in the form of: Visual Studio IDE, knowledge of COM (for non-managed Web services) and .NET (for managed Web services), and dexterity in one of the many programming languages supported by Microsoft.
Embedded Web services with COM
Lets start by exploring the unmanaged version of Web services in Windows CE -- or the .NET-agnostic kind. The building blocks for creating 'native' Web services start off by making use of Microsoft's SOAP toolkit, which is included Windows CE and has the same fundamentals as its PC-oriented version, providing a backing Web server and ancillary parts for executing COM objects exposed as Web services.
For creating COM objects targeting Windows CE, you will need to make use of a toolkit like eMbedded VisualBasic or C++ capable of creating the DLL's needed by the OS, both of which are predecessors to the .NET Compact Framework. One of the biggest advantages to using 'native' Web services in Windows CE, even though some consider this 'unmanaged' approach a step back to newer paradigms, is that their structure and deployment process is fundamentally equal to Web services deployed on big-iron servers.
The biggest hindrance, if any, comes from the actual registration of COM objects -- DLL's -- into the operating system's registry, but this issue is not tied to which Microsoft OS is being used and is simply the way in which 'unmanaged' applications work in the Microsoft world. For step by step instructions on deploying 'unmanaged' web services you can refer Mike Hall's reference document: Building Native Web Services in Windows CE .NET.
Embedded Web services with .NET
Moving onto managed code Web services in Windows CE, the first thing you will need is the .NET Compact Framework, the piece of software that will do the 'managing' of Web services in Windows CE. The differences between the compact version and its more popular standard version, is that the compact version lacks and often supplants certain features for more resource-limited friendly parts, be it in the form of framework classes or components.
As far as the logic and classes for composing Web services are concerned, not much changes between the two frameworks. However, the biggest hurdle to cross is the lack of support for standard .NET Web services -- the ASMX kind -- and the inclusion of a Web server into which Web services will be deployed. The deployment of Web services using the standard .NET framework is tightly knit to use ASMX files and IIS (Internet Information Server). The former avoids many of the scaffolding code involved in creating Web services, and the latter provides the administration of 'managed' Web services. The .NET Compact Framework lacks support for both given its embedded nature.
Not withstanding, this doesn't necessarily hinder the deployment of managed Web services onto Windows CE, it simply makes the process a little more complicated. The manner in which to tackle such a problem is by creating a small footprint Web server running inside the .NET compact framework and use it to serve out Web services results from a device running Windows CE. for such a scenario we point you toward Richard Jones' discussion on Web Services on devices running Windows CE, which contains full source code on how the create a small footprint Web server for the purpose of deploying Web services on Windows CE.
With this we bring to a close our discussion on deploying Web services to Windows CE enabled devices. Hopefully with this side by side comparison for deploying managed and unmanaged Web services on portable devices rather the more resource-rich Windows OSes, you will be well on your way to increasing the versatility of your SOA designs.