- What Are XML Web Services?
- When Are XML Web Services Appropriate?
- Using the .NET Framework to Create XML Web Services
- Hailstorm: An XML Web Services Example
- Summary
- Q&A
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
Using the .NET Framework to Create XML Web Services
Since XML Web services are one of the cornerstones of the .NET platform, no discussion of them is complete without an understanding of what the .NET platform is and what it offers developers.
While XML Web services can and are being built to run on other platforms, no platform seems to offer the developer as much choice and control as .NET. Under .NET, developers are free to create XML Web services using several different languages and have them all communicate seamlessly. Updated versions of technologies such as ASP and ADO make creating XML Web services easier, while tools such as the WSDL.EXE and Visual Studio's Web References Dialog make consuming an XML Web service as easy as using a DLL.
Common Language Runtime Brings Languages Interoperability
One of the most important developments in the .NET framework is the creation of Common Language Runtime, or CLR. CLR is a runtime library used by all Visual Studio languages, with the exception of unmanaged C++. This library ensures that all programming languages work under the same object model when requesting operating system services or even dealing with each other.
CLR also imposes a common data typeset on languages. This mean that programs written in any .NET language can pass parameters to objects written in any other .NET language and be assured that they are type safe.
Another benefit of CLR is that any compiler can be written to make use of it. At present, plans exist to create compilers for .NET versions of Perl, COBOL, Python, and several other programming languages. This means that a large number of developers can leverage their existing skills into the creation of .NET applications and XML Web services without the need to learn a new language.
Compiling to the Intermediate Language (IL)
At the heart of CLR is the intermediate language, or IL. The IL is a low-level language, like assembly language, that is not configured to any one operating system or CPU, unlike assembly language. All languages compiled in Visual Studio, again with the exception of unmanaged C++, compile to IL code.
Any platform that is running the .NET framework can utilize IL code. Windows is currently the only platform that will run .NET, but plans exist for other operating systems. IL code is compiled into native machine code when it is first run. This concept is similar to Java's Just in Time compilation, but differs in one key area: once IL code has been compiled to native machine code, it need never be compiled on that machine again. This gives .NET-generated code the ability, in theory at this point, to be written once and run on multiple platforms. It also avoids the performance hits taken by languages like Java and Visual Basic, which are compiled or interpreted every time they are run.
Another upside of the IL is performance between languages. In the past, vast speed differences existed between languages such as Visual Basic and C++, but now, with all languages compiling to a common low-level language and then ultimately to native code, performance variance between languages should be small and limited to differences in how a language handles individual tasks.
.NET Handles Memory Management and Platform Architecture Specifics
The .NET framework automates many of the lowest-level tasks that programmers currently need to write Windows programs and make use of object-oriented technologies. Currently, developers need to explicitly handle such tasks as object reference counting, application threading, and process management. Under .NET, these tasks are completely automated.
Developers need not worry about memory models, far pointers, or system architecture specifics anymore. As .NET is rolled out on different platforms, the platform-specific implementations such as memory addressing will be handled within the framework and abstracted away from the programmer.
ADO.NET Makes Working with Data Easier
ADO.NET, sometimes referred to as ADO+, is the newest version of Microsoft's Active Data Objects. This set of ActiveX controls provides a consistent set of programmatic controls to a wide array of data sources, not limited to relational databases. Using ADO.NET, programmers need to know very little about the actual data source and how to program to it specifically.
This newest version of ADO.NET has XML functionality built in throughout. Data can now be expressed in terms of XML and transformed and manipulated in much the same way as any other XML documents.
Storing Data in the Dataset
The Dataset is a new feature of ADO.NET. It allows data to be stored in memory in what can best be described as an internal relational database. The Dataset is composed of table objects, called DataTables, maintained by the TablesCollection. The DataTable itself is made up of a RowsCollection and a ColumnsCollection.
Also contained within the Dataset is a RelationsCollection that contains the Dataset's DataRelation objects. DataRelation objects define matches between columns in two tables within the Dataset.
Web Applications with ASP.NET
Perhaps no technology in the new .NET framework is as closely tied to Microsoft's version of XML Web services as ASP.NET, also known as ASP+. In fact, XML Web services in the .NET framework are really just specialized ASP applications.
The biggest difference between ASP+ and previous versions of ASP is compilation. All ASP+ applications compile to native code the first time they are run by an individual client. Each client, be it Internet Explorer 3.2, 4.0, or 6.0, causes a separate compilation to be created, but the compiled code can be cached and reused if so desired.
This compilation works exactly like other applications written in .NET except that ASP+ applications are compiled to IL by IIS. This allows ASP+ developers to work with the same tools they have been using, such as Notepad and Word, and also lets them use Visual Studio .NET to create ASP applications.
With the move toward compiled ASP+ applications and the use of the CLR, ASP+ is now more robust and complete than ever. No longer are ASP applications limited to the functionality built into IIS and its ASP engine; ASP has full access to the same components, error handling, and operating system services as any other programs that you develop.
It should also be noted that with the move to compiled code, ASP+ applications can currently be written in Visual Basic, C#, and JavaScript, but with the advent of more compilers and Visual Studio plug-ins, more languages will be supported in the very near future.