.NET and Smart Devices
To understand the goals of the .NET Compact Framework and SDP, it is important to review a bit of recent history, which places the goals in proper perspective.
In the summer of 2000, Microsoft began to reveal its plans for what, up to that time, had been loosely called Next Generation Windows Services, or NGWS. This amalgamation of a set of technologies and a vision for a ubiquitous Web-centric computing infrastructure coalesced under the moniker ".NET." Over the following months it came to mean two important things for technical leaders and developers: XML Web Services and the Microsoft Windows .NET Framework.
XML Web Services
In 1998, Microsoft, DevelopMentor, and UserLand Software worked together to create an XML encoding scheme that would provide direct computer-to-computer message-based interaction over the existing Internet infrastructure, including TCP/IP and HTTP as a transport. Their specification, SOAP, was submitted as an XML specification to the World Wide Web Consortium (W3C) and has been recommended and subsequently updated.[1] As a result, services built using SOAP are generally referred to as XML Web Services. At its core, therefore, a good working definition of an XML Web Service is a programmable application component accessible via standard Web protocols. Many people, Bill Gates included, have referred to the advent of XML Web Services as the "third wave" of the Internet, following the connectivity and presentation waves that preceded it.
[1] The current SOAP specification is 1.1 and can be found at www.w3c.org/TR/2000/NOTE-SOAP-20000508.
Obviously, the importance and promise of XML Web Services are its use of Internet standards and independence from the technologies that characterized the "component wars" of the 1990s, which were often reduced to battles between Microsoft's Distributed Component Object Model (DCOM)[2] and the Common Object Request Broker Architecture's (CORBA)[3] Internet Inter-ORB Protocol (IIOP). This independence means that XML Web Services tear down three primary barriers to interoperation and integration as shown in Figure 2-1.
[2] DCOM is based on the original COM specification from Microsoft.
[3] CORBA is an architecture for distributed objects created by the industry consortium Object Management Group (OMG)
Platform: Because SOAP has nothing to say about the technology used to create and consume SOAP messages and because XML parsers exists for all platforms, various vendors can implement toolkits and add-ons for their platforms to create and consume SOAP messages. In fact, there are over 80 SOAP toolkits available today. Removing the platform barrier, for example, goes a long way toward allowing software running on some flavor of Unix to communicate seamlessly with software written on Windows.[4]
[4] To speed standardized adoption of SOAP, Microsoft and IBM created the Web Services Interoperability Organization (WSI). See www.ws-i.org for more information.
Language: Because SOAP toolkits are available for multiple platforms, a variety of languages can be used on those platforms to create and consume SOAP. For example, IBM in its WebSphere product allows XML Web Services to be created using Java, while Microsoft includes XML Web Services creation in Visual Studio .NET (VS .NET) and Visual Studio 6.0 using VB .NET, and VB 6.0.
Device: Most important for our purposes in this book, XML Web Services break down the barriers between devices. This is the case because SOAP messages simply consist of XML and are, therefore, independent of the device (from a desktop PC to a Pocket PC to an appliance to a gaming console) on which they are consumed and their results displayed.
Figure 2-1. Web Services Interoperability. This diagram highlights the platform-, language-, and device-independent nature of XML Web Services.
Indeed, Microsoft and others envision a world where applications running on a variety of devices make use of a Web Services fabric to stay highly connected and bring together disparate silos of information, including business and personal information.
One of the reasons you're reading this book is that Microsoft and other leading industry organizations are betting that mobile devices will play a key role in the XML Web Services ecosystem.
Windows .NET Framework
The second important concept that grew out of .NET and was released along with VS .NET 2002 in February of 2002 was obviously the Framework. Although we assume most readers are familiar with the .NET development platform, a brief introduction for those who aren't is provided here. For an in-depth look at the common language runtime, see the books by Don Box, Dan Fox, and Jeffery Richter in the "Related Reading" section at the end of the chapter.
 | Simply put, the Framework consists of an EE, or virtual machine, referred to as the common language runtime, and a set of class libraries that provide the low-level interaction with the underlying operating system?often called the Base Class Libraries (BCL). Also provided are higher-level classes that expose programming models for developing specific types of applications and utilizing system services?often called the Services Framework.[5] Both of these components were released along with VS .NET 2002, which provided the IDE and language support for creating applications that utilize the Framework. However, in the initial release, applications written for the framework (referred to as managed code) were restricted to desktop PCs and servers running Windows 98, ME, NT, XP, and 2000. As you can imagine, the class libraries and the runtime engine must be present on any machine running managed code.[6]
|
In this scheme, the common language runtime includes a host of runtime features including a class loader, thread support, exception manager, security engine, GC, code manager, and type checker. In turn, all managed code is first compiled to a machine-independent intermediate language called Microsoft Intermediate Language (MSIL) and subsequently compiled to native instructions for execution in a JIT manner, as the common language runtime's class loader loads code at runtime.
When the code is compiled to MSIL by the developer using VS .NET, it is stored in a portable executable (PE) file called a module. The module contains the MSIL instructions, in addition to metadata that describes the types (classes, interfaces, enumerated types, and so on) in the code the developer has written, along with the dependencies on other types. The common language runtime and other tools in VS .NET rely heavily on this metadata to make sure that the appropriate code is loaded and to assist in enabling features such as IntelliSense and debugging in VS .NET. A module can then be incorporated into, or exist independently as, an assembly. An assembly is the fundamental unit of packaging, deployment, security, and versioning in .NET and contains a manifest (embedded in one of the modules or in its own PE file) that describes the version, an optional public key token used for uniquely identifying this assembly from all others, and a list of dependent assemblies and files.
It should be noted, however, that the rich nature of MSIL makes assemblies a prime target for reverse engineering. To avoid this, a number of third parties provide obfuscation products that work by renaming the symbols in the MSIL to make it more difficult for disassemblers to understand the code. The community version of PreEmptive Solutions Dotfuscator is included with VS .NET 2003 and can be used to obfuscate both desktop Framework and Compact Framework assemblies.
The object-oriented class libraries that contain roughly 6,000 types are organized into hierarchical namespaces (for example System, System.Data, System.Windows.Forms, and so on) and shipped in assemblies that are installed with the framework. These integrated class libraries are a boon for Windows developers because they unify the previously used programming models into a single framework that includes a rapid application development (RAD) forms package, full object-orientation, XML and data support, and full support for writing Web applications. They also expose new concepts to developers, including built-in support for creating and consuming XML Web Services. These programming models are then fully exposed through project templates in VS .NET.
Finally, it's important to note that the Framework is at its core language agnostic. Microsoft now ships five language compilers (VB, C#, J#, JScript, and Visual C++ with Managed Extensions) that produce MSIL and, thus, support building managed code. The rich metadata contained in assemblies and the use of MSIL serve to abstract language differences that in the past raised barriers when interoperating between languages. The picture that emerges can be summarized in Figure 2-2. Figure 2-2 highlights the architecture of the Framework and its role in application development. Note that VS .NET templates, composed of developer source code, and references to the Services Framework and BCL are then compiled into assemblies before being executed by the common language runtime.
Figure 2-2. The Microsoft Windows .NET Framework.
To summarize, the Framework and Visual Studio .NET provide several key benefits to developers and their organizations:
Developer productivity: The power of the unified programming model exposed in the Framework enables developers to build applications more easily and removes the glass ceiling felt by VB developers. In addition, VS .NET, with its plethora of features, including IntelliSense, code outlining, graphical designers, commenting, and integrated debugging just to name a few, enables developers to build applications more quickly.
Modern languages: As a corollary to developer productivity, the inclusion of modern object-oriented languages like C# and VB .NET allows developers to be more productive by using features such as inheritance and polymorphism. This benefit should not be underestimated, especially for developers coming from the procedural and weakly typed world of eVB.
Language choice: Although the .NET Framework may in the future be ported to CPU architectures other than x86,[7] it can more rightly be thought of as a multilanguage, rather than a multiplatform, environment. In fact, more than 25 languages from ISVs and academic institutions are either released or in the works.[8] This allows organizations to leverage their existing investment in these languages, rather than having to retrain their development staff. However, the abstraction provided by managed code also made it easier to create the .NET Compact Framework for devices, as we'll see later in this chapter.
[7] For example, there is an open source project called "Mono" that is porting the Framework to Linux, and Microsoft has released a FreeBSD implementation for academic use called "Rotor." For more information see www.go-mono.com. In addition, both C# and the Common Language Infrastructure (CLI) specification, which describes the runtime engine, were submitted and have been approved by ECMA as specifications ECMA-334 and ECMA-335, respectively. The common language runtime is a superset of the CLI.
[8] For example, Fujitsu COBOL for the Framework. For more information, see www.adtools.com/info/whitepaper/net.html.
XML Web Services integration: By integrating support for XML, SOAP 1.1, Web Services Description Language (WSDL[9] ), and other XML Web Services specifications, the Framework allows developers to create a new class of applications that are not only positioned to take advantage of the future Web Services fabric, but also provide a great way to promote intraorganization integration of line-of-business and legacy applications.
[9] Pronounced "wizz-dull." WSDL is an XML grammar used to describe the operations exposed by a Web Service.
As you can see, the myriad benefits of XML Web Services, coupled with the Framework, provide a compelling reason for development organizations to adopt .NET technology. And, because of its success, Microsoft has now extended these benefits to smart devices by releasing the .NET Compact Framework and SDP.
