4-1. IMPLEMENTING AN SOA ARCHITECTURE in Font

Generation Code 39 in Font 4-1. IMPLEMENTING AN SOA ARCHITECTURE

The answer is that all Web application infrastructures have a cross-referencing algorithm, as presented in Figure 4-11.

Figure 4-11. URL cross-referencing to functionality In Figure 4-11, the HTTP server receives a request that starts a series of steps on the HTTP server. The HTTP server has a notion of executing filters and a handler. The filters are responsible for manipulating the request so that the called handler has the proper context. Which handler is called is determined by some algorithm, which we will call the URL processor. By default, when an HTTP server executes the URL processor, the URL is mapped to a file. If the request was [http://myserver.com]/dir/file.html, then the HTTP server attempts to find the file [base directory]/dir/file.html. If the file is found, the file extension processor is loaded, which in the case of .html happens to be a static file processor. (If the extension is .php or .aspx, then the PHP or ASP .NET processors are executed and generate content based on the instructions in the file.) From a REST perspective, this is the wrong URL processor algorithm. It is an easy algorithm, but it is the wrong algorithm, at least from the perspective of REST.

From the perspective of REST, all URLs represent resources on the server side; however, while a file is a resource, it is not a resource from the perspective of the application. This is very a big distinction that must be understood: REST URLs are application-specific resources. Using an application-specific resource means that you are exposing functionality based on the business logic, not technology. Using REST, you can separate the resource from the implementation, much like interface- or contract-driven development. To illustrate the separation of the resource from the implementation, consider the following C# code: interface IBase { void Method(); } class Implementation1 : IBase { public void Method() { } }

class Implementation2 : IBase { public void Method() { } } The IBase interface defines a method and is implemented by two classes, Implementation1 and Implementation2. This process is referred to as interface-driven development, because when the client uses either implementation, the client doesn t use the actual implementation but the interface of the implementation, as illustrated by the following source code: class Factory { public static IBase Instantiate() { return new Implementation1(); } } class UseIt { public void Method() { IBase obj = Factory.Instantiate(); // ... } } In the example source code, the Factory class has a static method, Instantiate, that creates an instance of IBase by instantiating Implementation1. In the UseIt.Method class, an instance of IBase is instantiated by calling the Factory.Instantiate method. The UseIt class has no idea whether Implementation1 or Implementation2 is instantiated, and it uses the interface as defined by IBase, expecting the interface methods to be implemented correctly. When using dynamic languages, you use duck typing, and the defined contracts result in implied functionality. Let s relate interface-driven development to URLs and separate the resource from the representation. The resource is the interface, and the representation is the implementation. Currently, most Web technologies bind together the resource and representation or use implementations directly, as the URLs http://mydomain.com/item.aspx and http://mydomain.com/item.jsp illustrate. The direct bindings are the .aspx and .jsp extensions, and the proper interface-defined URL would have been http://mydomain.com/item. Ironically, all Web technologies implement the separation of resource from representation for the root URL /, as illustrated by the following HTTP conversation. (Note that the conversation has been abbreviated for explanation purposes.) Request GET / HTTP/1.1 Host: 192.168.1.242:8100 User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Response HTTP/1.1 200 OK Server: Apache/2.0.53 (Ubuntu) PHP/4.3.10-10ubuntu4