Using HTTP in COM Applications

[Previous] [Next]

As fate would have it, HTTP has emerged as the industry's leading protocol for client-to-server communication. One key to this protocol's success has been that it's fairly simple to implement and is supported on every major platform. Its ubiquitous nature makes it valuable.

The phenomenon of the World Wide Web has had a profound effect on the way we build distributed applications. The industry as a whole has directed much of its recent attention to technologies related to Web servers and browsers. Companies are pouring millions of dollars into research and development to advance the capabilities of HTTP in many essential areas, such as load balancing and security.

Microsoft, like most other vendors, has recognized the strategic importance of HTTP. If fact, the architects of COM+ built their platform based on this assumption: An application must use HTTP for client-to-server communication to achieve the highest levels of scalability.

Figure 12-2 depicts a COM+ application with a scalable deployment architecture. Note that this application doesn't rely on DCOM. Instead, clients submit requests to IIS using HTTP. The Web farm plays a central role in this architecture because it allows a COM+ application to process hundreds of requests per second and to achieve higher levels of fault tolerance and availability.

Figure 12-2. The most scalable architecture for a COM+ application uses a Web farm infrastructure and request-based load balancing. This architecture forces you to use HTTP for client-to-server communication.

This architecture provides the means to scale out. You can accommodate more clients by adding more mid-priced server computers to the Web farm. As I discussed in Chapter 9, a Web farm that uses request-based load balancing also provides higher levels of fault tolerance and availability. Chapter 9 also pointed out some important considerations when you design ASP pages and components for a Web farm environment that uses request-based load balancing. As you'll recall, many techniques involving ASP Session objects and other middle-tier caching techniques simply don't work. However, that's the price of admission when you want to create a large-scale application.

You can see from Figure 12-2 that the database server doesn't lend itself to scaling out in the same manner as the servers running IIS and COM+ applications. In most cases, the database server computer represents a single point of contention. This means that you must scale up the database server instead of scaling out. To accommodate a growing number of users, you must buy a more expensive multiprocessor computer that provides adequate processing cycles, memory, and hard disk space.

As you can see, Web servers can be scaled out but the database server can't. This should lead you to conclude that it's best to do as much of your processing on the Web server as possible. You should look for opportunities to offload work such as security-related authorization checks from the database server to Web servers in the farm.

The database server also represents a single point of failure. If the database server crashes, your application is dead in the water. You can address this vulnerability by using clustering technologies. Cluster Service in Windows 2000 is intended primarily to provide failover support for applications such as databases and messaging systems. Cluster Service allows several physical computers to assume the identity of a single computer. Each computer plays the role of a node, which can take over if another node fails. Cluster Service supports two-node failover clusters in Windows 2000 Advanced Server and four-node failover clusters in Windows 2000 Datacenter Server.

As I explained in Chapter 10, you can further address issues related to fault tolerance and availability through the use of messaging. Once an HTTP request arrives at the Web server, you can use either MSMQ or QC to capture the client's requests. This allows an application to remain operational when the database server is off line. Messaging can also help speed up response times when the database server has a large backlog of requests. You should also understand that MSMQ isn't limited to sending messages between different computers. You can always send MSMQ messages between two applications running on the same Web server computer. This approach is pretty straightforward and allows you to reap the benefits of asynchronous execution and exactly-once delivery.

Microsoft is expected to release a product named AppCenter Server in the second half of the year 2000. AppCenter Server is a suite of products designed for companies that are deploying and administering applications in a server farm environment. AppCenter Server will include new support for administering and monitoring NLB and Cluster Service and will include a third form of loading balancing through the Component Load Balancing (CLB) service.

CLB allows you to distribute a set of COM clients across a cluster of server computers. Each server computer in the cluster is typically configured with the same set of COM+ applications. CLB is based on a load-balancing algorithm that runs when a client activates a COM object. CLB is thus a session-based load balancing technique as opposed to a request-based load balancing technique.

In an application that uses CLB, all clients send activation requests to a central routing server. The routing server acts as an object broker by redirecting each activation request to one of the COM+ server computers in the cluster. The Component Services administrative tool already includes various configuration options for CLB because the COM+ team originally planned to ship CLB with the initial release of Windows 2000.

It's important to understand that CLB is based on DCOM and thus has the same limitations as DCOM. Therefore, CLB is most valuable when used in a LAN environment. In the grand scheme of things, the request-based load balancing provided by products such as NLB and Cisco's LocalDirector are far more valuable to a distributed application.

Separating HTTP from HTML

I'd like to review the requirements for scaling an application one more time in order to make a point. Here are some of the common requirements for a large-scale application:

• The application must be able to handle thousands or tens of thousands of users concurrently.
• The application must provide high levels of fault tolerance and availability.
• The client must be able to access the application through a firewall.
• The application must provide access to users across the Internet.
• The application must provide secured access to users who aren't closely affiliated with your company.
• Users can access the application without requiring a system administrator to configure their computers.
• The application must be accessible to users running on platforms other than Windows, such as Linux and Macintosh.

As you've seen, HTTP is vital to meeting all seven of these requirements. However, using HTML with HTTP isn't as critical. In fact, only the last requirement and, to a lesser extent, the requirement before that one actually force you to use HTML.

Ask yourself whether your application really requires the use of HTML. If you're creating an e-commerce site and you want to reach every last user on the Internet, the answer will be yes. If you're building a business application for your employees, suppliers, or customers, HTML will often be optional.

Nothing in the scalable deployment model shown in Figure 12-2 forces you to use HTML. If you can assume that your users will all run a 32-bit version of Windows, you have a few alternatives. For example, your application's presentation tier can be a traditional desktop application built using Visual Basic. You can thus leverage the Visual Basic forms designer (the tool you've grown to love so much over the last decade). The only new trick you have to learn is how to write the code in Visual Basic to submit an HTTP request to IIS. As you'll soon see, this isn't difficult.

You should also ask yourself whether you can build a better user interface using HTML or using Visual Basic. In my experience, HTML-based applications (even those built using DHTML and lots of client-side JavaScript) can't begin to match the elegance and ease-of-use of most Visual Basic applications. If you do elect to build your client applications with Visual Basic, will you really miss developing HTML-based interfaces for the browser? I know a lot of developers who most definitely won't.

Visual Basic makes it easy to create forms to capture and validate user input. Many developers have become accustomed to using grid and treeview controls and presenting the user with tabbed dialog boxes. These features are often beyond the capabilities of HTML and the browser. If you've been attempting to get around the limitations of HTML by downloading ActiveX controls to run in Microsoft Internet Explorer, you've already required your users to run a 32-bit version of Windows. You might as well take the next logical step and use Visual Basic to create the entire client application.

Think of the additional complications forced upon you by the browser. When it comes to managing client-side state, you must choose between cookies, query strings, and hidden forms. When you create a Visual Basic application to run on the user's desktop, managing state is much easier. What's more, it's easy to save an ADO recordset or an XML document to the user's hard disk. You don't have to worry about the security sandbox imposed by a Web browser.

I'm not suggesting that HTML and browser-based development are going away anytime soon. HTML is still one of the best ways to solve the problems of cross-platform development and eliminate client-side configuration issues. However, it's your job to realize when HTML is a requirement and when it's not.

I can't help but mention one other issue at this point, which is more political than technical. Let's say that you follow my advice and create a Web-based application using a desktop application built with Visual Basic. Someone in management or in your company's marketing department might accuse you of being behind the times. In a design meeting, someone might ask, "Why isn't the application Web-based?" You must convince the others that the application is Web-based. It's really all about HTTP and not so much about HTML and the browser. If you need to throw around a few buzzwords to prove your point, just tell them, "HTML was last year. This application is built from the ground up using XML." Maybe that'll get them off your back.

Executing Method Calls Using HTTP and XML

There are a few ways to submit an HTTP request from a client application created using Visual Basic. I'll present an example using Microsoft's XML parser because it provides one of the easiest and most flexible approaches. Version 2 of Microsoft's XML parser ships with Windows 2000, but Microsoft has been releasing new versions at fairly frequent intervals. You should use the most recent version, which you can download from msdn.microsoft.com/xml/default.asp.

Unfortunately, I can't teach you how to use XML in this book. But I will present a simple example to demonstrate what it takes to submit an XML-based HTTP request to IIS from a Visual Basic application. In this example, a client application submits an HTTP request to the Web server using a simple XML document to pass an input parameter. An ASP page retrieves this input parameter, executes the requested method, and returns output parameters to the client using another XML document.

The example is based on a configured component named CCustomerManger. Let's say that this configured component has been installed in a COM+ server application on a Web server computer. We'll execute one of the component's methods, GetCustomer, which has one input parameter and two output parameters. Here's what the method implementation looks like:

 ' Parameters are defined as Variants to accommodate ASP page. Sub GetCustomer(ByVal Name, ByRef CreditLimit, ByRef AccountBalance) Dim conn As Connection, rs As Recordset Set conn = New Connection conn.Open sConnect Set rs = New Recordset rs.Open "SELECT CreditLimit, AccountBalance" & _ " FROM Customers" & _ " WHERE Customer='" & Name & "'", conn CreditLimit = rs("CreditLimit") AccountBalance = rs("AccountBalance") rs.Close Set rs = Nothing conn.Close Set conn = Nothing End Sub 

Since the CCustomerManager component has been installed in a COM+ server application, it's accessible to COM clients from across the network. However, we'd like to execute this method from a client application using HTTP as well. Let's start by adding an ASP page named GetCustomer.asp to the Web server with the following code:

 <%@ Language=VBScript %> <% Response.ContentType = "text/xml" set dom = Server.CreateObject("MSXML.DOMDocument") set obj = Server.CreateObject("WebMarket.CCustomerManager") dom.load Request dim Name, CreditLimit, AccountBalance Name = dom.selectSingleNode("//Name").text obj.GetCustomer Name, CreditLimit, AccountBalance %> <Response> <CreditLimit><%=CreditLimit%></CreditLimit> <AccountBalance><%=AccountBalance%></AccountBalance> </Response> 

This ASP page includes a few interesting things. Obviously, the ASP page must create an instance the CCustomerManager component in order to execute the GetCustomer method. However, before executing the method, the ASP page must retrieve the input parameter. This example assumes that the client has sent the input parameter in an XML document embedded in the body of the HTTP request.

The ASP page creates a DOMDocument object in order to deal with the incoming XML document. It populates this object by calling the load method and passing the ASP Request object. This technique works as long as the client has sent a well-formed XML document in the body of the request. (Note that this technique works with IIS 5 and Windows 2000 but not with IIS 4 and Windows NT Server.) Once the XML document has been loaded, the ASP page can extract the input parameter and execute the method. After executing GetCustomer, the ASP page prepares an XML response document to return to the client. Note that the ASP page explicitly sets the content type of the response to "text/xml" rather than the default, "text/html".

In the final step, we submit an HTTP request to execute GetCustomer from a desktop application written with Visual Basic:

 Const sURL = http://localhost/MyApplication/ ' Create an XMLHTTPRequest object to issue the request. Dim httpRequest As MSXML.XMLHTTPRequest Set httpRequest = New MSXML.XMLHTTPRequest ' Prepare an XML document to pass the input parameter. Dim Name As String, xmlRequest As String Name = txtName.Text xmlRequest = "<Request>" & _ "<Name>" & Name & "</Name>" & _ "</Request>" ' Open a connection to the Web server and send the request. httpRequest.open "POST", sURL & "GetCustomer.asp", False httpRequest.send xmlRequest ' Check for success/failure. If httpRequest.status <> 200 Then ' Raise error when return status isn't 200. Err.Raise MyErrorCode, , "HTTP transport error: " & httpRequest.status & _ " - Description: " & httpRequest.statusText End If ' Use a DOMDocument object to retrieve the method's output parameters. Dim ResponseDoc As DOMDocument Set ResponseDoc = httpRequest.responseXML Dim CreditLimit As Currency, AccountBalance As Currency CreditLimit = ResponseDoc.selectSingleNode("//CreditLimit").Text AccountBalance = ResponseDoc.selectSingleNode("//AccountBalance").Text 

Microsoft's XML parser provides an XMLHTTPRequest component that allows a client application to submit an HTTP request to the Web server. As you can see, the client application constructs a simple XML document that holds the method's input parameter. The client then invokes the XMLHTTPRequest object's open method followed by the send method to execute the code in the ASP page on the Web server.

Note that the third parameter of the open method indicates whether to submit the HTTP request asynchronously. Our example passes a value of False so that the call is conducted synchronously. The call to send blocks until the Web server returns a response. After the call returns, the client application creates a DOMDocument object for extracting the output parameters from the response XML document.

I've presented this example to prove a point: a client application can use HTTP in the same way that it uses DCOM to communicate with a server computer. What's neat about this example is that you can create a client application that can go back and forth between using DCOM and using HTTP. In a LAN environment, DCOM might be preferable at times because it can provide faster response times with a heavyweight connection. But when you need the benefits of HTTP, that option is available as well.

You should observe that the technique of submitting requests via HTTP is available to non-Windows clients as well as to Windows clients. The only requirement is that the client knows how to use HTTP and XML. This opens up a world that DCOM can't tap into.

Also note that the technique of submitting XML-based HTTP requests programmatically is not limited to applications with a user interface. For example, imagine a scenario in which a COM+ application running on a public Web server is required to call a business object running on a different application server. The use of HTTP will be important if your company has placed a firewall between the public Web server and the application server for security reasons. The firewall makes it hard to make the call using DCOM. However, if the application server exposes the business object to clients using HTTP, the public Web server can execute methods on the business objects without any problems.

SOAP and Web Services

The example I just presented shows three important things about executing methods using HTTP:

• It allows you to expose COM+ applications using a highly-scalable Web farm architecture.
• It allows you to integrate desktop applications built with Visual Basic.
• This approach is fairly grungy. It involves creating an ASP page for each method and explicitly preparing and parsing two XML documents in order to execute each method call. The code is fairly boilerplate in nature, but writing all those ASP pages and the required client-side code can get tedious.

Compared to DCOM, executing methods with HTTP in this fashion is particularly messy. DCOM hides the details of packing parameters into RPC messages and unpacking them on the other side. A client using DCOM simply invokes a method, and everything magically happens behind the scenes. So you might ask, "If they can make it so easy with DCOM and RPC, why can't they do the same for HTTP?"

Well, they can. In fact, many companies have been working hard to create a standard for executing method calls across HTTP. You've probably heard developers talking about Simple Object Access Protocol (SOAP). SOAP is a new specification whose goal is to standardize how clients execute methods across HTTP. It does this by defining a standard set of HTTP headers and an XML payload for transmitting method parameters and return values.

One of the most promising aspects of SOAP is that it provides a means of bridging heterogeneous systems. Keep in mind that SOAP is based entirely on HTTP and XML. Nothing about it ties you to the Windows platform on either the client side or the server side. This clearly isn't the case with DCOM.

For example, a Visual Basic client application can issue a SOAP request to a server computer running a UNIX operating system and an Apache Web server. The method's implementation can be written in Perl. Conversely, a non-Windows client application can submit a SOAP request to a server computer running IIS and Windows 2000 Server. The only requirement that SOAP imposes is that both the client and server must understand HTTP and XML.

One of the driving philosophies behind SOAP is to "invent no new technology." Most platforms already have functional Web servers and can communicate with HTTP. More and more platforms are picking up support for XML as well. SOAP tries to leverage the ubiquitous nature of HTTP and XML. It doesn't address issues such as load balancing and security because the underlying transport already takes care of them. SOAP simply extends HTTP by defining how clients prepare requests and how the server responds to them. At its most basic level, SOAP is like an interface in COM. It allows the client application and the Web server to agree on how to communicate.

SOAP is still in its early stages. The SOAP specification won't have much value until there are client-side and server-side implementations. You can obtain the SOAP specification and write these implementations yourself. (At the time of this writing the latest specification is available at http://msdn.microsoft.com/xml/general/soapspec-V1.asp) If you write a SOAP-based application by hand, your code will look a bit like example I presented earlier. However, you'll have to add a considerable amount of code to deal with things such as propagating application-specific errors and properly packaging complex data structures.

However, the real potential behind SOAP is that it allows software companies such as Microsoft to add support to their development tools and to the underlying platform. This will benefit developers because, over time, Microsoft and other vendors will make executing a method call over HTTP as easy as using DCOM is today.

Microsoft has become very fond of the term Web service, which simply describes an application that exposes its functionality through SOAP-based HTTP requests. Creating such Web services that rely on client-side and server-side implementations of SOAP isn't a trivial task. Microsoft, like many other companies, must address complex issues such as parameter marshaling and error propagation so that SOAP works as smoothly as DCOM does today.

Microsoft is currently working on a suite of development tools and utilities for developers who want to integrate SOAP into their applications. These tools and utilities will be packaged in the Web Services SDK. (The name of this SDK might change before you read this.) I haven't been able to obtain a beta copy, so I can't give you any details about how this SDK will support SOAP. I also have no information about when the Web Services SDK will be available. By the time you read this, however, you'll probably be able to download the SDK from MSDN.

I can say with confidence that SOAP will be a big part of Microsoft's development strategy for the foreseeable future. The Web Services SDK is likely to go through several releases, each one extending the capabilities of the one before it. You can also expect future versions of COM+ and Visual Basic to have built-in support for SOAP. A day might come when you can simply adjust a declarative component attribute setting or change a property value at runtime to switch back and forth between using DCOM and HTTP.