Export (0) Print
Expand All
Expand Minimize

Physical Architecture

 

Matt Powell
Microsoft Corporation

June 20, 2001

In the last column, Scott talked about the issues involved when designing a contract for your Web Service. In this column, we will look at some of the issues and decisions you will need to make when actually taking the Web Service as it was developed, and deploying it on a machine or a collection of machines for use in the real world.

Before we start digging into the Physical layout of Web Services, let's take a quick look at one of the issues our readers has brought up.

Performance and the XML DOM

After reading the earlier At Your Service column on Authentication and Authorization, one of our readers was skeptical of the Favorites Service approach of using an instance of the XML DOM object as the underlying store of our local key cache. His concern was the length of time a selectSingleObject call on the XML DOM object might take, and the potential performance ramifications. Considering this was one of the most commonly executed pieces of code in the Favorites Service, the concern is very real.

First, let's take a look at what we are doing with the DOM in regards to performance. For starters, we use the free-threaded version of the DOM object so that we don't have to marshal all our access to the key cache through a single thread. Because of this, multiple threads can read the cache simultaneously. Secondly, the instance of the DOM that holds our cache stays loaded in virtual memory at all times—we never have to create a new instance of the DOM or reparse the corresponding XML.

Now, this still begs the question of whether the queries against our DOM instance, where we are looking for a specific key, are too time consuming. To fully answer this question, we should go through the process of building a large XML document that matches the contents of our cache instance and perform a large number of queries for random keys in this document. Up to this point, we have not made such an analysis, although we plan on doing further performance work for Phase II of the Favorites Service. We have, however, confirmed through testing that even with a large number of entries in the cache (approximately 7,000), the entire Favorites Service is capable of operating within our performance guidelines. Further, testing has verified that requests for a licensee whose key is in the cache is significantly faster than a request where the key needs to be updated from the back end.

We will try to provide a more thorough performance analysis in the future. In the meantime, let's talk about how we setup the architecture that hosts the Favorites Service.

What Is a Physical Architecture?

When creating a Web Service, or any other distributed application, you need to figure out what code needs to run where. Such questions as the following must be answered:

  • What components need to have access to the database?
  • How many databases are there?
  • What parts of our application need to run in a different physical location in order to prevent outside access?
  • What other back-end services are required for my components?

The physical architecture defines where the pieces of an application are installed, and what sort of configuration options will meet the needs for security, reliability, and performance. In the case of a Web Service, this will usually take the form of a Web Server listening for SOAP requests, which then interacts with a back-end infrastructure that may consist of database servers, messaging systems, and so forth. Let's take a look at the pieces that make up the Favorites Service.

The Favorites Design

The Favorites Service, as with any typical Web Service, relies on a Web Server platform. In particular, we run the Favorites Service on Microsoft® Internet Information Server 5.0. We use the SOAP Toolkit version 2.0 to provide our SOAP support, and we implement our main business logic in COM components written in Microsoft® Visual Basic®. Our COM components communicate with three different databases to round out the basics of our Web Service.

There is, however, more to the Favorites Service than simple Web Service support. The Favorites Service is a licensed service, so we had to provide a Web site where users could request licenses and update their license information. We also needed an internal Web site for performing administrative tasks, such as granting and managing licenses, as well as generating global reports. Our licensing infrastructure requires us to send e-mail to our licensees for various reasons (such as to inform them of their first password and to remind them when their license is about to expire).

Another aspect of the Favorites Service is the security requirements that play into how our components are distributed. For instance, the Administrative Web site used to grant and manage licenses must only be accessible by our own people. We can limit access by making the Administrative Web site only accessible on the back-end private network. Other parts of the Favorites Service cannot be physically protected in this manner, and require an authentication scheme for controlling access. Still other parts of the Favorites Service should be available to the general public.

Another aspect of security with the Favorites Service is not only that we have to control access to certain pieces of information, but we also need to guarantee the privacy of that information. For instance, we want to make sure licensee names and passwords for the Favorites Service cannot be viewed by someone sniffing packets on the network.

So let's take a look at some of the specifics of the functionality provided by the different portions of the Favorites Service. We will start with a look at the three sub-services that make up the core of the Favorites Service. The table below indicates the three sub-services, the security setup of each, the installed components required by each, and the back-end services that each must communicate with.

Virtual directory Accepts Page Security COM components Requires back end access to:
/SSF SOAP/HTTP over SSL Logon.ASP

(Logon Web Service)

Anonymous IIS access.

Channel encrypted with SSL.

Public access granted while authenticating.

SSFFavorites.Logon

SSFKeyCache.Key

SSFAudit.AuditLog

SSFEvent.Event

SSF-Logon SQL Database

SSF-Report SQL database

  SOAP/HTTP Account.ASP

(Account Web Service)

Anonymous IIS access.

Channel not encrypted.

Application authentication.

SSFFavorites.Account

SFKeyCache.Key

SSFAudit.AuditLog

SSFEvent.Event

SSF SQL Database

SSF-Report SQL database

  SOAP/HTTP Report.ASP

(Report Web Service)

Anonymous IIS access.

Channel not encrypted.

Application authentication.

SSFFavorites.Report

SSFKeyCache.Key

SSFAudit.AuditLog

SSFEvent.Event

SSF-Report SQL database

The three Web Services tend to exist on a single machine, but in reality, there is no requirement that all three be on a single machine. Certainly, in a typical Web farm scenario, there is no guarantee that a request for a particular service on a given server is followed by another request to the same server.

Note that the Logon Web Service requires SSL communication, which implies that the Web Service has an SSL server certificate installed. Also, note that since we are communicating with SOAP, we must be sure that the SOAP Toolkit 2.0 is installed on any machine running one of these Web Services.

Authentication is a requirement for both the Account and Report Web Services. Authentication is performed by making a Logon method call to the Logon Web Service. The returned key is then used in future calls to the Account and Report Web Services, and provides a quick means for authenticating users of these services.

As far as back-end support is concerned, the Web Services interfaces simply require access to the different databases that store the information for the Favorites Service. Note that all these services, and all the following Favorites Service components, require back-end access to the SSF-Report database. Access is required because that is where audit records are saved, and we audit every event performed by the Favorites Service.

As mentioned before, there is more to the Favorites Service than just the actual Web Services. The table below describes the other Web sites required by the Favorites Service and the components, security, and back-end services that they access.

Virtual directory Accepts Page Security COM components Requires back end access to:
SSFPublic HTTP/HTML form input <ALL> Anonymous IIS access.

Channel encrypted with SSL.

Public access granted to request licenses. Application Authentication otherwise

SSFLicensing.Licensing

SSFAudit.AuditLog

SSFEvent.Event

SSF-Logon SQL database

SSF-Report SQL database

SOAP Access to Favorites Service

SSFAdmin HTTP/HTML form input <ALL> Access only allowed from private network.

Can use Integrated IIS security to limit user access

SSFLicensing.Licensing

SSFAudit.AuditLog

SSFEvent.Event

SSF-Logon Database

SSF-Report SQL Database

SMTP Service to send e-mail

/SSFClient HTTP/HTML <ALL> Requires some sort of end-user authentication. Sample site uses cookies to store username. SSFEvent.Event SOAP Access to Favorites Service

For all three of these virtual directories, access is through a Web browser viewing a Web site. The SSFLicensing component is the heart of the /SSFPublic and /SSFAdmin virtual directories, since it is launched by the ASP pages receiving HTML form input to do the work of managing licenses. The /SSFClient virtual directory is not a critical part of the real Favorites Service. It is just a sample client application that accesses the Favorites Service. We have it using the SSFEvent.Event object since it needs to report any errors in some manner, and we use the SSFEvent object to do our event error logging.

Also notice that the SSFAdmin virtual directory requires not only database access on the back end, but it also requires access to e-mail services as well. This is so we can notify licensees with their passwords, and use it as a reminder mechanism if they change their contact information or if their license is about to expire. Also notice that the SSFPublic site requires SOAP access to the Favorites Service. This allows licensees to see their report information without writing an application to make their own SOAP request. The data itself comes from the Report Web Service, and the SSFPublic site simply performs an XSL transform to display the data in HTML.

Besides the Web Services and Web sites that make up the Favorites Service, there are also some back-end batch processes that must run. For instance, SSFReportService.EXE must run every night in order to gather snapshot information for the data in our reports. For any installation of the Favorites Service, there must be only one instance of SSFReportService that runs, even if you have the Favorites installed on a Web farm. Also, in the case of the Favorites Service installed at http://coldrooster.com, we needed to have an automated process that grants licenses without manual intervention. In this case, we created a custom process, SSFAutoAdmin, that runs every five minutes and automatically grants any pending licenses.

Batch process Security COM components Requires back-end access to:
SSFReportService Requires database access SSFAudit.AuditLog

SSFEvent.Event

SSF SQL database

SSF-Report SQL database

SSFAutoAdmin Requires database access SSFLicensing.Licensing

SSFAudit.AuditLog

SSFEvent.Event

SSF-Logon database

SSF-Report SQL database

SMTP Service to send e-mail

Molding the Architecture onto Real Hardware

Having established the requirements for COM components and the various backend services for the different portions of the Favorites Service, let's take a look at how we actually implemented the Favorites Service on physical hardware for our http://www.coldrooster.com implementation. Figure 1 shows our implementation for the Cold Rooster Favorites Service.

Figure 1. Favorites Service implementation on http://www.coldrooster.com

We can see that for the Favorites Service we have separated the networking communication into two main entities: the public network and the private network. The machines in the Web Farm are connected to both networks so they can receive requests from the Internet, and access the SQL Servers on the back-end private network. No direct access to the SQL Server Cluster is allowed from the Internet. Each machine in the Web Farm is hosting the /SSF virtual directory where the three Web Services reside (Logon, Account, and Report). They are also hosting the /SSFPublic virtual directory that provides the public HTML interface for requesting licenses. We do not host the /SSFClient site on http://www.coldrooster.com, although we use the Favorites Service on all of the standard Web pages on our server. We use Microsoft® Load Balancing Services to dispense network traffic to the different machines in our Web farm, and we use Microsoft® Application Center to manage the content on our machines. We have a VeriSign certificate for coldrooster.com installed on each of the machines in our farm.

Our SQL cluster hosts all three of our databases (SSF, SSF-Logon, and SSF-Report) on the same logical SQL instance. The cluster itself uses Microsoft® Cluster Server in a master/slave configuration, and shares a Disk Array through a fiber channel.

The Admin Machine performs a number of functions. First of all, it hosts our SMTP service, which allows us to send e-mail, so it must be connected to the public network. It also hosts the /SSFAdmin virtual directory, so access to it needs to be limited. We use IP Address Security to restrict all access to the Admin Machine to its local IP address so that it will not service any requests from any other machine. We also use the Admin Machine to host the batch processes that need to run for the Favorites Service. On top of all this, the Admin Machine is where we do our Microsoft Application Center staging and monitoring so that we will be able to deal with any failures that might occur with any of our machines.

Conclusion

When designing your Web Service, you need to take into account how each portion of your application will access the services and components it requires. We broke the Favorites Service into the sub-services it requires, along with the various virtual directories that make up the other aspects of the Favorites Service, and we laid out the requirements for each. Understanding these relationships helped us to build the installation program for the Favorites Service (a forthcoming article), as well as allowed our operations staff to determine the details of how they must configure our site.

In the next issue of At Your Service, Scott will be back to write about Interoperability Issues with Web Services.

 

At Your Service

Matt Powell is a member of the MSDN Architectural Samples team where he helped develop the groundbreaking SOAP Toolkit 1.0. Matt's other achievements include co-authoring "Running Microsoft Internet Information Server" from Microsoft Press, writing numerous magazine articles, and having a beautiful family to come home to every day.

Show:
© 2014 Microsoft