10.2 Web Service Fortresses


10.2 Web Service Fortresses

A Web service fortress shares many characteristics with a presentation fortress. Both act as security buffers protecting your enterprise. Both act as gateways to the outside world. Both receive their requests over the Internet.

There is one major difference between the two fortress types: A presentation fortress receives its requests from browsers. A Web service fortress, on the other hand, receives its requests from programs.

Because the presentation fortress is receiving its requests from a browser, you can start with the assumption (security concerns aside, for the moment) that it is your code making the request. It is not your code running inside your presentation fortress, but it is your code nevertheless. In his fiefdom architecture, Pat Helland calls this code emissary code . Because the emissary sending the request is written by the same group that wrote the guard receiving the request, there is no need for strong standards documenting the requests that are accepted by the presentation fortress.

Keep in mind that from a security perspective, you never assume that the request really came from your code (security Rule 6, earlier in this chapter). But this is a different issue. From a documentation perspective, you can assume that the typical presentation fortress request is coming from something you have written that has been offloaded to the browser.

A Web service fortress is different. There is no assumption that it is receiving its requests from anything you wrote. For this reason you need to be able to describe exactly what your fortress can do in a way that a program outside your organization can understand. You must also adhere to some recognized standards as to exactly how the request will be made and transmitted, and the responses returned.

The standards that are defining Web service fortresses (or just Web services, for those who are not yet proponents of the software fortress model) are the SOAP family of standards.

I have already discussed SOAP in the context of heterogeneous synchronous drawbridges . Although there is widespread agreement within the industry today that SOAP is the solution, there is very little agreement in the industry as to exactly what problem SOAP is supposed to solve. I hope that the software fortress model will help clarify exactly when SOAP should be used and what problems it should be used to solve.

SOAP can contribute solutions for two problems: The first SOAP-amenable problem is how to accept programmatic requests from outside the enterprise. Included in this is all the peripheral issues, such as describing what requests you're willing to accept, making some delivery guarantees , and perhaps even adding a pinch of security (just for old time's sake). Because systems outside of the enterprise are the least trusted of all systems, we insist that these requests go through a no-man's-land. We implement this no-man's-land as a Web service fortress.

The other SOAP-amenable problem is to provide a heterogeneous synchronous drawbridge between two fortresses (probably business application fortresses) inside the enterprise. We can't use homogeneous synchronous drawbridges (our first choice) because the fortresses are running on different technology bases. Because both systems are inside the fortress, they are relatively trusted (relative to an outside fortress). For such fortresses we may not insist that such communication go through a no-man's-land.

In the future, SOAP will probably find itself taking part in not only heterogeneous synchronous drawbridges, but heterogeneous asynchronous drawbridges, as message queue-like technologies begin to incorporate SOAP support natively.

10.2.1 J2EE versus the .NET Approach

At this point in time, there seems to be little disagreement among the vendors on their support for the SOAP technologies. If there is any argument, it is over who is embracing SOAP more, how deeply SOAP is being placed in the technology, and how transparent the use of SOAP is. On the basis of the vendors ' use of SOAP, there is no obvious reason for choosing either J2EE or .NET for a Web service fortress.

Although SOAP does not provide a compelling reason for choosing between J2EE and .NET, it is more helpful in choosing between the various J2EE vendors. At this point there are only three enterprise-credible J2EE vendors: IBM, Sun, and BEA. Of these, IBM is the clear leader in Web services. Until recently, Sun was arguing that SOAP-like standards aren't even necessary, and BEA has so far taken a back seat to Sun.

Virtually all of the critical SOAP standards are, as of now, a joint development effort between IBM and Microsoft. Microsoft deserves credit for originating the SOAP concept, and IBM deserves credit for giving the technology credibility within the enterprise space. Given IBM's leadership in this area, it should probably be a top contender among those companies who plan to use SOAP and J2EE heavily.

10.2.2 Technology Overview

Recall from the discussion on synchronous drawbridges (Chapter 5) that SOAP is a mapping protocol that describes how a method request can be represented as a string (an XML string, not that it matters). That stringified method request then needs to be transmitted from the requestor to the requestee by means of component-like surrogates. For a Web service fortress, requests are transmitted typically via HTTP.

Before I cover the different standards, let me go through the sequence of events that occurs as a message goes from the requestor through the Web service fortress and eventually on to a business logic fortress. The characters involved in this drama are shown in Figure 10.6.

Figure 10.6. Web Service Fortress Characters

These characters have the following functions:

  • Flora is a foreign process that wants to make a request of a Web service fortress.

  • Sam and Seth are both SOAP surrogates.

  • Gwen is an incoming guard.

  • Ed is an envoy.

  • Walt is the worker that runs the logic of the Web service fortress.

Let's go through the flow of information from Flora the foreign process through the Web service fortress and on to the back-end business application fortress. Let's assume that Flora's request is to withdraw 500 dollars from account number 1000. To simplify, we won't worry about idempotency (a topic discussed earlier in this chapter).

Flora wants to request the withdrawal, but she doesn't know anything about SOAP. Her software vendor has provided her with the ability to create a SOAP surrogate. A SOAP surrogate is a surrogate that knows how to make remote fortress requests using the SOAP protocol and the HTTP delivery mechanism. So Flora asks Sam, her SOAP surrogate, to withdraw 500 dollars from account number 1000.

Sam packages the request as a SOAP string and ships it to the Web service fortress. The request is picked up by Seth, another SOAP surrogate. Seth unpacks the SOAP string and determines that the request maps to a method supported by Gwen, the incoming guard. Gwen is a native component. Seth sends a component-style method request to Gwen.

Gwen decides to accept the request. She passes the information on to Walt the worker bee, the one who knows how to process the request. Note that processing the request probably means routing it to a business fortress elsewhere within the enterprise.

Walt now decides which fortress will get the request and which drawbridge he will use. He determines that the necessary drawbridge is the one presided over by Ed the envoy. Ed packages Walt's request and sends it on to his (Ed's) drawbridge. The infogram will be sent on to the business fortress that has the knowledge (and data) to process the withdrawal request.

Ed's drawbridge is a standard software fortress drawbridge. It can be asynchronous heterogeneous, asynchronous homogeneous, synchronous heterogeneous, or synchronous homogeneous. I discussed the characteristics of each of these drawbridges in Chapters 4 through 6.

Given this sequence of events, we can start to understand how the various standards of the SOAP family play together.

At the lowest level, we need a standard algorithm for representing a request as a string, and we need a standard transport protocol. As already discussed, SOAP defines the stringification algorithms, and HTTP is the likely transport protocol (at least, in the Web service fortress scenario). SOAP thus allows Flora the foreign process to make a request on one of the enterprise business systems mediated by Walt the Web service fortress worker bee. Most importantly, SOAP allows Flora to make this request without knowing anything what soever about the business system, including the technology base on which it is built, the language in which it is programmed, or even the operating system on which it runs. The only thing Flora needs to know is that SOAP requests are accepted.

A SOAP request string has a complex format. There is no way that Flora (or more precisely, Flora's programmer) will be able to construct a SOAP string. So, to allow Flora to make the SOAP request in a natural way, the vendor of Flora's technology base will make the use of SOAP totally transparent to Flora. To do this, the vendor will provide tools to automatically generate Sam the SOAP surrogate. From Flora's perspective, Sam just looks like a normal component with normal methods. Little does Flora know or care that Sam packages his methods as SOAP strings and transmits them using HTTP. Nor does Flora know anything about Seth, Sam's counterpart in the Web service fortress.

But how do these tools automatically create Sam? The building of Sam is driven by the definition of Seth. So to build Sam, the Sam-generating tool needs at least the following information:

  • Where in Internet space does Seth live?

  • What requests is Seth willing to receive?

  • What is the exact format of these requests?

  • What information will Seth return?

  • How will errors be handled?

Furthermore, the Sam-generating tool needs this information in a standard format that the tool can automatically read. This format must be independent of the platform on which Seth lives because the Sam-generating tool will probably be running on a platform other than the one supporting Seth. So we need not only a standard for making the request of Seth (which we have, SOAP), but also a standard for describing what these requests will look like. In other words, we need a standard for describing the requests that the Web service fortress is willing to accept on behalf of the enterprise.

The standard that describes what requests will be accepted by a Web service software fortress is the Web Services Description Language ( WSDL ). WSDL contains all of the information that the Sam-generating tool could possibly need to create a fully functional Sam that can work with Seth.

If you think that the SOAP format is complicated, wait until you see WSDL. The purpose of WSDL is to allow tools to generate SOAP surrogates automatically so that you are protected from all the complex mysteries of SOAP. But who will protect you from the far more abstruse mysteries of WSDL?

Just as the vendors will provide tools to " consume " WSDL (i.e., create SOAP surrogates corresponding to WSDL documents), they will also provide you with tools to generate WSDL documents automatically. How this is done is not defined by any standard. When you're evaluating different vendors, one of the things you should look at is how well they shield you from both WSDL and SOAP.

A likely scenario for creating a WSDL document is that you will define an interface for a native component using a vendor-specific GUI tool. A compiler option will indicate that you really want this component to support SOAP. When the tool sees the SOAP option set, it will automatically create both the SOAP receiving surrogate (Seth) and the WSDL document that defines Seth and that will ultimately form a template for Sam.

There is still one more problem. How does Flora's system find the WSDL document that defines the SOAP requests that enable her tool to create Sam, who can then talk to Seth?

A general rule in computer science says that you never pass up the opportunity to create another standard ”if possible, more than one. In the case of finding WSDL documents, we have been blessed with not one but two standards.

Universal Description, Discovery and Integration ( UDDI ) is a relatively mature standard that allows one to find random WSDL documents spread across the Internet universe. Maturity, in this case, does not equate to value. So far there has been virtually no use of UDDI. The reason, I believe, is that UDDI is oriented toward finding WSDL documents for "new" collaborators ”that is, collaborators with whom you have never worked before. In my experience, finding new collaborators isn't hard, and we don't need a standard that solves this problem. What we really need are standards oriented toward collaborators we already know about. Finding them isn't hard; working with them is. Given the mistaken premise of UDDI, I think we will see what little use it is getting eventually die out. Therefore I won't discuss UDDI further.

The other standard for finding WSDL documents is known as Web Services Inspection Language ( WS-Inspection ). As of press time, WS-Inspection is still in draft state, so it is too early to know if it will make it. However, like most of the successful Web service “ related standards, this is a joint effort by the only two vendors that anybody cares about in the enterprise space: IBM and Microsoft. It thus seems likely that this standard will eventually become a permanent feature of the Web service landscape.

WS-Inspection differs from UDDI. Whereas UDDI allows you to find any vendor, including those you never heard of, that supports a specific service, WS-Inspection is less grandiose. It only tries to solve the problem of working with known collaborators. It allows you to go to a specific Web site and discover the Web service fortresses the organization supports and the WSDL documents that describe those fortresses.

10.2.3 SOAP Problems

Lest you think that SOAP will solve all of your problems, let me reassure you. SOAP, as it exists today, lacks many of the features we would expect from a serious messaging backbone. Many of these problems are under attack by various standards, but it will likely be years before these standards are finalized and implemented.

Here are some of the issues you can expect to see with SOAP for the near future:

  • There is no guarantee that a SOAP message will ever be delivered. And there is no guarantee that if it is delivered, it won't be delivered multiple times. Thus it is critical that all SOAP messages be idempotent. (Idempotency was discussed in Section 10.1.)

  • There is no way to tell who is on either side of the message. There is no way for Flora the foreign process to know that her message is being delivered to Walt the Web service worker bee, and there is no way for Walt to know that the message really came from Flora.

  • There is no privacy with SOAP. Both messages and replies are transmitted in clear text over the Internet. Not only can they read the message, they can change it on route.

It could be argued that these missing features are requirements not of the stringification algorithm (SOAP), but of the underlying transport protocol (e.g., HTTP). And, in fact, some of these features are provided by HTTPS. However, the general consensus in the industry is that SOAP should be enhanced to include these types of functionality.

10.2.4 Scalability

Scalability is generally less of an issue for Web service fortresses than for presentation fortresses for several reasons.

First, few people are actually using Web service fortresses. As I have discussed, the more common use for SOAP is as a heterogeneous synchronous drawbridge technology within the enterprise, and even here, it is still in its infancy.

Second, most presentation fortresses perform far more work than do most Web service fortresses. The scalability demands for a Web services fortress are therefore much lower. To start with, figuring out how to interpret the incoming request is much more demanding for a presentation fortress than for a Web service fortress. Add to this the work of managing browser state (a problem most Web service fortresses don't need to worry about) and creating a beautiful presentation (another issue that doesn't concern the Web service fortress). In contrast, the Web service has to do little other than check security (a function also required of the presentation fortress) and route the request to a business fortress. Not exactly a hard life!

Still, it is possible to design your Web service fortress in such a way that it can't scale. The most common problem is not so much a scalability problem as it is a general performance problem. In other words, it's not that you can't increase the number of users on your system, it's that you can't get even one user to work successfully.

When single-user performance is a problem for a Web service fortress, the likely cause is an architectural flaw in the design of the drawbridge to the fortress. The common flaw is creating the drawbridge interface with too fine a granularity, meaning that poor Flora the foreign process needs to make too many SOAP requests to get any work done. SOAP, especially SOAP delivered with HTTP, is a very expensive protocol and should be used sparingly.

The best solution to single-user performance problems is to look carefully at the drawbridge requests. The requests should be designed to be coarse-grained, self-contained, and idempotent. It is almost always better to send in more information in fewer infograms than less information in more infograms.

On the remote chance that you have an overwhelming demand for your Web service fortress, you will use a similar approach to scaling out as you would for your presentation fortress ”that is, IP load-balanced , loosely coupled clusters.

10.2.5 Security

Given what little help we get from the SOAP protocol, the security issues for Web service fortresses look a lot like those for presentation fortresses. With minor modifications, the 11 rules for protecting a presentation fortress apply to Web service fortresses as well. Let's go through them.

The first four rules are pretty much unchanged. Rule 1 (firewall in front) and Rule 2 (firewall behind) apply equally well to Web services. Rule 3 (keep up with patches) also applies, but the reality is that the vendors probably won't release nearly as many patches for your Web service fortress as they will for your presentation fortress. In any case, keep up with whatever they do send. Rule 4 (run on a minimal system) also works for Web service fortresses. You want to accept SOAP requests, period.

Rule 5 (validate user input) is similar for both fortress types. You still need to validate input, for the same reasons. You need to guard against process hijacking, and you need to make sure you don't accidentally pass through unintentional commands to the trusting fortress critters who live farther down the food chain.

Rule 6 (no assumptions about request origins) is probably less of a problem for a Web service than for a presentation fortress because the Web service architect harbors no illusions about where the request came from.

Rule 7 (guard the connections) is exactly the same for the Web service fortress. Secure sockets, one of the ways of guarding the presentation fortress, is a good candidate for Web service fortresses as well. Eventually guarding the fortress may become less of a problem as more and more security is built directly into the SOAP protocol.

Rules 8 through 11 are the fallback rules, those that assume intruders will eventually gain control of your precious Web service fortress. All four rules are the same for Web services as for presentation fortresses. Rule 8 (minimal permissions) protects a hijacked Web service fortress, Rule 9 (stage on a safe server) guarantees recovery, Rule 10 I will discuss in a moment, and Rule 11 (use a software fortress architecture) is just a generally good way to live life.

Rule 10 (don't store anything of value in the fortress) deserves some specific discussion. This rule is really the whole reason for having a Web service fortress.

Many companies are thinking of using Web service technologies to allow collaborators to access their business systems directly over the Internet. I believe that this is much too risky because it is almost impossible to fully protect a system connected to the Internet. Once they break into such a system, they have full access to confidential data, proprietary algorithms, and trusted accounts.

On the other hand, collaboration over the Internet is an intriguing possibility (still a somewhat remote possibility, as things stand today). Web service fortresses represent a compromise position, allowing collaboration while still managing (but unfortunately , not eliminating) your security risk.

10.2.6 Reliability

Scale out for reliability, just as you do with your presentation fortress. It is actually easier to make a Web service fortress reliable than to make a presentation fortress reliable, mainly because it is harder to screw up state management.

For a presentation fortress, the state of the requestor is the state of the browser, and browsers seem to have a natural propensity to holding on to long- term state. Of course, the assumption that the presentation fortress should care about the browser's state is more psychological than technical because, as we all know, browsers also communicate with a stateless protocol (HTTP). That doesn't seem to stop us from expecting the poor overworked presentation fortress to find a way to manage the browser's state.

For a Web service fortress, the state of the requestor is the state of the foreign process. People understand that this request is going to go through SOAP and that SOAP is a naturally stateless protocol (one SOAP request remembers nothing about the previous SOAP request). Therefore, nobody asks the Web service fortress to maintain the state of the foreign process.

10.2.7 Integrity

Like the presentation fortress, the Web service fortress is transactionally protected against internal failure. And again, the main challenge is making sure that all requests are, as Pat Helland would say, idempotent. There is nothing new to add here.



Software Fortresses. Modeling Enterprise Architectures
Software Fortresses: Modeling Enterprise Architectures
ISBN: 0321166086
EAN: 2147483647
Year: 2003
Pages: 114

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net