Summary
This chapter
looked
at the need for an architecturally neutral, ubiquitous, easy-to-use, and interoperable system to replace DCOM, RMI, and CORBA. It discussed how Web Services fill the gaps successfully because HTTP is used as the language-independent protocol, XML is its language (in WSDL) and transport mechanism, and SOAP enables you to package messages for sending over HTTP.
The chapter also described how to create and
consume
Web Services programmatically using Visual Basic, and discussed the abstract classes provided by the .NET Framework class library to set up and work with Web Services. In particular, it looked at the
WebService
,
WebServiceAttribute
,
WebMethodAttribute
, and
WebServiceBindingAttribute
component classes of the
System.Web.Services
namespace, in addition to the
System.Web.Services.Description
,
System.Web.Services.Discovery
, and
System.Web.Services.Protocols
namespaces.
Finally, it outlined some of the downsides to using any distributed architecture (Web Services included), but it finished with an optimistic note on where Web Services might take us in the future.
Chapter 27:
Remoting
Overview
Remoting
is the .NET technology that enables code in one application domain (
AppDomain
) to call into the
methods
and properties of objects running in another application domain. A major use of remoting is in the classic
n
-
tier
desktop approach, where presentation code on the desktop needs to access objects running on a server somewhere on the network. Another primary use for remoting is when code in ASP.NET Web Forms or Web Services needs to call objects running on an application server somewhere else on the network. In short, remoting is the technology to use when your
n
-tier code needs to talk to the business or data tier running on an application server.
Remoting is conceptually somewhat similar to Web Services. Both remoting and Web Services are TCP/IP-based technologies that allow communication between different machines over an IP network. This means that they both pass through firewalls, and they both provide stateless and connectionless communication between machines. These two technologies share a lot of the same principles.
|
|
Important
|
It is important to recognize that Microsoft has merged the functionality of remoting,
Web Services, enterprise services, and MSMQ (Microsoft Message Queue) into the
Windows Communication Foundation (WCF)
- the
next
generation of the technolo
gies. You can find more information on WCF in
Chapter 30
.
|
When working with XML Web Services, the biggest problem with SOAP is that it is not lightweight. It’s designed with maximum platform interoperability in mind, which puts certain limits on how data can be transferred. For example, imagine that platform A stores integer
variables
as a 4-byte block of memory, with the
lowest
-value byte appearing first. Now imagine that platform B also uses a 4-byte block of memory, but this time the highest-value byte appears first. The encoding of the value is different. Without some form of conversion, if you copy that block of bytes from platform A to platform B, then the platforms won’t agree on what the number actually is. In this scenario, one platform thinks it has the number 4, whereas the other thinks that the number is actually
536870912
.
SOAP gets around this problem by representing numbers (and everything else) as strings of ASCII
characters
- since ASCII is a text-encoding standard that most platforms can understand. However, this means that the native binary representations of the
numbers
have to be converted to text each time the SOAP document has to be
constructed
. In addition, the values
themselves
have to be packaged in something that you can read (with a little bit of effort). This leads to two problems: massive bloat (a 4-byte value starts taking hundreds of bytes to store) and
wasted
CPU cycles used in converting from native encoding to text encoding and back again.
You can live with all these problems if you only want to run your Web Service on, say, Windows 2000, and have it accessed through a client running on a
cell
phone. SOAP is designed to do this kind of thing. However, if you have a Windows XP desktop application that wants to use objects hosted on a Windows 2000 server (using the same platform), the bloated network traffic and wastage in terms of conversion is sub-optimal at best and ridiculous at worst.
Remoting lets you enjoy the same power of Web Services but without the downside. If you want, you can connect directly to the server over TCP and send binary data without having to do any conversions. If one Windows computer has a 4-byte block of memory holding a 32-bit integer value, you can safely copy the bit pattern to another Windows computer and both will agree on the number. In effect, network traffic
sanity
is restored and processor time isn’t wasted doing conversions.
