Internet Information Server (IIS) is the application server for the Windows platform. This
application server has been evolving for the past 10 years, and will continue to evolve into t
foreseeable future. IIS has gone from serving static markup to a full-featured application ho
ing environment. ISAPI applications have been available as a point of extensibility for years
A number of the technologies you’ll be looking at in this chapter are implemented as ISAPI
applications: ASP.NET, SQLXML, and SOAP exposure of Enterprise Services. Others, such as
the COM SOAP stack, are beyond the scope for this book.
■Note As IIS continues to evolve, you can expect to see ASP.NET leveraged for more and more functiona
ity, as this is the ISAPI extension of choice for extending the behavior of IIS using the .NET Framework. We
provide full coverage of ASP.NET as an application pipeline in Chapter 2.
ASP.NET Framework
With the ASP.NET Framework, Microsoft has created an ISAPI application that enables the
functionality of IIS to be extended using the .NET Framework. We examined a number of wa
this is done within the Framework Class Library in Chapter 2. In this section, we’ll focus on
some of these implementations, and how they enable you to leverage IIS as a network end-
point for cross boundary and cross machine communication.Web Services
In addition to serving requests for Web Forms, the ASP.NET Framework also acts as the
.NET SOAP Stack. (We examined some details of the generalized concept of a SOAP Stack in
Chapter 6.) A SOAP Stack is a process that listens to a well-defined network endpoint for
incoming SOAP messages posted to the server. It maps these requests to a service implemen-tation, and translates the results of the service into a SOAP response.
In the .NET Framework, Web Services are so well integrated into IIS and ASP.NET that
most people don’t even realize they’re using a SOAP Stack at all if they learn Web Services
using the .NET Framework. For any other platform, you’d have to go out and pick a SOAP
Stack, install it, and take specific steps to map types to service operations you want to expose.
This is true for Java platforms, and it is even true for exposing COM types as Web Services.
Visual Studio .NET and ASP.NET make this so easy that it can be taken for granted by most
developers. By mapping asmxfiles to types, by automatically handling requests for asmxdocu-ments in ASP.NET, by auto-generating WSDL documents, and by auto-generating client-side
proxies, the Web Service handler built into ASP.NET hides all of the standards-based details of
the underlying protocols and wire format in use.
This can be a good thing or a bad thing. A service-oriented purist would shudder at the
thought of it, and would advocate a “WSDL first” approach to service development. The other
extreme would be to acknowledge the simple fact that if you need a method on a type exposed
across your network, you can slap the WebMethod attribute on it, put an asmxdocument in front
of it, and you’re done (as long as chunky statelessness is a given for the method design).
CHAPTER 8 ■ HOSTING AND COMMUNICATIONS 275
Exposing your .NET types as Web Services vastly increases the reach of your managed
code. If you’re in an environment where there are several platforms and languages in use, Web
Services dramatically decreases the amount of time and churn spent integrating packages and
applications. By hosting your Web Services within IIS, you can also give them exactly the reach
you want them to have. You may have services within a department, services exposed to the
entire enterprise, and services exposed over the Internet to partners and vendors. You can
even publish public services for general consumption. These can be subscription based or free
(see www.xmethods.net). The broader the reach of your Web Services, the greater the chances
you’ll want to adopt some of the WS-* specifications for functionality such as authentication,
message routing, and transactions. You can do this with the Web Service Enhancements add-on available for free and supported by Microsoft (see Chapter 6 or http://msdn.microsoft.com/
webservices/webservices/building/wse/default.aspx).
Remoting
ASP.NET also acts as a host for remoted components. The Remoting handler is automatically
mapped to requests of files with extensions of .soap or .remvia a configuration document that
gets added to the root of your web application, requests of specific network endpoints are
mapped to types living in assemblies in the application’s bin directory.
Discussions about Remoting internals are beyond the scope of this book (see Tom Barnaby’s
book, Distributed .NET Programming in C# (Apress, 2002) for excellent coverage). However, in
this chapter, we’ll still take a look at a couple of ways .NET types can be exposed via Remoting.
Here’s a simple type that by inheriting from MarshalByRefObjectis pinned in the process it’s
created within; and so it can be called via Remoting.
This component then can be exposed via ASP.NET using the following entry in the
web.configof an IIS application:
The client requires a configuration file to use the remoted type. Here’s a configuration file
you can use as the app.configfor a simple console application:
Running Codes
class BookService : MarshalByRefObject
{
public DataTable getBookList()
{
SqlConnection cn = new SqlConnection(connStr);
SqlCommand cm = new SqlCommand(
"select BookID, Title From Book Order by Title", cn);
DataTable dt = new DataTable();
try
{
cn.Open();
dt.Load(cm.ExecuteReader());
return dt;
}
catch { }
finally
{
if (cn.State == ConnectionState.Open) cn.Close();
}
}
}
0 comments:
Post a Comment