Architecting with Web Services

Web Services impart two remarkable benefits to users - one rather obvious, the other less so. First, they replace common binary RPC formats, such as DCOM, CORBA, and RMI. Because these use a proprietary communication protocol, they are significantly less architecturally flexible than Web Services. As devices utilize more and more of the Internet, platform neutrality will be a great advantage.

Less obvious but more important, Web Services will be used to transfer structured business communications in a secure manner, potentially ending the hold that sterling has on the Electronic Data Interchange (EDI) market. HTTPS with 128-bit SSL can provide the security necessary for intracompany information transfer. Furthermore, Microsoft has recently (as of this writing) released Web Services Enhancements 3.0 (WSE), as well as the Windows Communication Foundation (WCF), which enables you to easily use WS-Security and other advanced protocols to apply credentials, encryption, and digital signing to your SOAP messages in an easy and straightforward manner.

Why Web Services?

So, why Web Services? Well, they are remarkably easy to deploy with Visual Basic. The key to remoting with Web Services is the WSDL contract - written in the dense WSDL protocol you saw earlier. IIS 5.0, 6.0, and 7.0 does that in conjunction with the .NET Framework, analyzing the VB code and dynamically generating the WSDL code for the contract.

In addition, Web Services are inherently cross-platform, even when created with Microsoft products. Yes, you’ve heard this before, but so far this seems to be true. The standard XML schemas are centrally managed, and IBM mostly built the WSDL specification, so Microsoft seems to have toed the line on this one.

Finally, they best represent where the Internet is heading - toward an architecturally neutral collection of devices, rather than millions of PCs surfing the World Wide Web. Encapsulating code so that you can simply and easily allow cell phones to use your logic is a major boon to developers, even if they don’t know it yet.

How This All Fits Together

Note that Web Services are not a feature of the .NET Framework per se. In fact, Web Services run fine on Windows NT4 SP6, with the SOAP Toolkit installed. You can do most anything you are doing here with VB6 and IIS 4.0.

However, the .NET Framework encapsulates the Web Service protocol into objects. It is now an integrated part of the strategy, rather than an add-on. If you are currently working in a VB6 environment, take a look at the SOAP Toolkit (downloadable from MSDN at http://msdn.microsoft.com/webservices), and understand that the services you build are available not only to different flavors of Windows, but also to IBM and Sun platforms.

The goal of Web Services is to provide a loosely coupled, ubiquitous, universal information exchange format. Toward that end, SOAP is not the only mechanism for communicating with Web Services - the HTTP GET and HTTP POST protocols are also supported by the .NET Framework. Response is via HTTP, just like normal RPCs with SOAP. This enables legacy Web applications to make use of Web Services without the benefit of the .NET Framework.

State Management for XML Web Services

The Internet is stateless by nature. Many of the techniques used for managing state in ASP.NET Web applications are the same techniques you can use within the XML Web Services built on the .NET platform. Remember that XML Web Services are part of the ASP.NET model, and both application types have the same objects at their disposal.

Therefore, just like an ASP.NET application, XML Web Services can also use the Application object or the Session object. These sessions can also be run in the same process as the XML Web Service application itself - out of process, using the .NET StateServer, or by storing all the sessions within SQL Server.

To use sessions within XML Web Services built on the .NET platform, you must turn on this capability within the WebMethod attribute by using the EnableSession property. By default, the EnableSession property is set to False, so to use the HTTPSessionState object, set this property to True, as shown here:

  Imports System.Web Imports System.Web.Services Imports System.Web.Services.Protocols <WebService(Namespace:="http://www.lipperweb.com/namespace")> _ <WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1)> _ Public Class Service     Inherits System.Web.Services.WebService    <WebMethod(EnableSession:=True)> _    Public Function SessionCounter() As Integer       If Session("Counter") Is Nothing Then          Session("Counter") = 1       Else          Session("Counter") = CInt(Session("Counter")) + 1       End If       Return CInt(Session("Counter"))    End Function End Class 

The EnableSession property goes directly in the parentheses of the WebMethod declaration. This property takes a Boolean value and needs to be set to True in order to work with the Session object.