The Internet

The Internet
In this chapter, we have covered many of the base technologies that underpin the Internet: hardware, protocols, and the domain name system. There remain some interesting topics for us to discuss:
Intranets and Extranets
Firewalls and Web Proxies
XML Web Services
Intranets and Extranets
An intranet can use TCP/IP technologies in a very similar way to the Internet. The difference is of course that an intranet is a private network, where all users are known. The intranet is not intended for general public access, and some data, if not all, must be secured from outside access. Securing the intranet from the Internet at large is a task carried out by firewalls:

An extranet is a private network like an intranet, but extranets connect multiple intranet sites belonging to one company or partner companies over the Internet using a tunnel. Creating a VPN (Virtual Private Network) over the Internet in this way offers significant cost advantages over leasing private lines for the purpose.

Firewalls
So, a firewall secures the intranet from the mayhem and disorder that is the Internet. Firewalls are also often used to secure a subnet inside a company from other subnets, to restrict access to the first subnet to only specified users and/or tasks.
In order to create a secure network with a firewall, that network must be configured so that all incoming and outgoing traffic has to pass through the firewall: naturally, there must be no alternative routes that bypass the firewall.
Firewalls can work at various layers of the OSI model. Packet filters check packets and filter them according to the IP addresses and port numbers of the network and transport layers. Packets from or to particular IP addresses can be granted permission to pass through the firewall, either into the network, or out to the world beyond. Port numbers can be used with packet filtering to specify what services can be used on each side of the firewall. For example, a firewall can be set so that the Internet side (known as the red side in firewall terminology) may access only web servers, at certain IP addresses behind the firewall, through HTTP. Such a configuration can be seen in the next picture, where a second firewall secures the internal company network that contains the mail server, file services, and user workstations. If applications running on the web server need access to data from the intranet, specific protocols and ports can be configured for the second firewall.

If security filters with a port number are defined, every packet sent through the firewall must be passed up to the transport layer to be checked. A higher level of checking is possible using application filters. An application filter must know about the commands of the application level protocol, such as FTP, HTTP, or SMTP, and can for instance permit certain files to be copied from the Internet to the intranet, but not the other way around, by allowing FTP GET commands, but not FTP PUT commands. SMTP application filters often deny mails that use DEBUG commands, as SMTP DEBUG mails can be used to break into local networks.
Web Proxies
A web proxy caches web requests from clients. Internet browsers on the intranet can be configured to use a web proxy that forwards the HTTP request to the web server on the Internet. The web proxy can cache web requests so that future client requests requesting the same page are not answered by the web server, but by the cached page stored by the web proxy.
Another function of the web proxy is to restrict access to specific web sites, and to log the web requests made by users.
The Microsoft Internet Security and Acceleration Server (ISA) acts both as a firewall and a web proxy to secure the network and increase performance.
XML Web Services
An XML Web Service is an application that can be identified by a URI, and can be called remotely using Internet friendly protocols such as HTTP.
At the heart of XML Web Services lies SOAP (Simple Object Access Protocol). SOAP defines an XML format for calling remote methods regardless of the technologies used to implement those methods.
A typical process for invoking web services is shown in the following figure:

First we have to find a web service that meets our requirements, which we can do by querying a UDDI server using the UDDI (Universal Description, Discovery and Integration) protocol. Publicly available web services can be registered on a UDDI server, such as http://www.uddi.org or http://www.salcentral.com, which provides search functionality. The UDDI server returns certain information about web services that match specified requirements, such as a link to a WSDL (Web Service Description Language) document that details the methods exposed by the web service in a computer-readable XML format. If a web service is not to be made publicly available, its WSDL document can be exchanged in other ways, or by a private UDDI server. Microsoft offers a UDDI server that can be installed with Windows .NET Server.
The methods and parameters described by the WSDL document can be used to build SOAP requests to call the web service.
ASP.NET is an easy way to create a web service using the classes in the System.Web.Services namespace.
The SOAP specification can be found at http://www.w3.org/2000/xp/Group/.
.NET Remoting
The Remote Procedure Calls (RPC) protocol was the first widely recognized way to call functions across a network. RPC is a high-level protocol that does not require the client to create a message and send it to the receiving side, and to pick up the message on the server and analyze it to invoke the required function. Instead, the application programmer can invoke a function directly on the server. The RPC proxy running on the client marshals the remote method call (that is, transforms it to a network message) to send to the server, where the RPC stub unmarshals the message and invokes the method.
Because RPC was function-oriented, DCOM (Microsoft's Distributed Component Object Model) extended it to add object orientation.
.NET brings a new model for distributed applications, and a successor to DCOM-.NET Remoting. .NET Remoting offers far greater flexibility and extensibility over DCOM.
The picture below shows an architecture overview of .NET Remoting. The remote object exposes some methods for remote calls. A proxy is created on the client mirroring the remote object in that it exposes the same public methods. The client invokes these methods on the proxy class, and the proxy uses a formatter to format the messages so that they can be sent across the network.
The network transport is defined by the channel. On the server, another formatter unformats received messages, and passes them to the dispatcher which calls the methods on the remote object:

.NET Remoting permits interceptors, or sinks, to be placed at certain points in the flow on the client or server-side to add additional functionality, such as logging, duplicating calls for reliability reasons, or dynamically finding servers.
.NET Remoting supports a variety of channels and formatters. The .NET Framework v1.0 offers a TCP and an HTTP channel, and SOAP and binary formatters. If we choose the HTTP channel and the SOAP formatter, .NET Remoting becomes the same as XML Web Services. The TCP channel with binary formatters is a fast communication mechanism. If both the client and server use .NET technologies, .NET Remoting is a fast and easy to use communication mechanism.
You can read more about XML Web Services in the Wrox books Professional XML Web Services is independent of the underlying technology, while Professional ASP.NET Web Services concentrates on web services in ASP.NET, and C# Web Services is more technical, using both ASP.NET and .NET Remoting to implement web services.