The Web Inside
What happens if you apply the REST design pattern to its logical conclusion?
Ajax is changing the nature of Web applications and placing new demands on server-side code. Proposed solutions and server-side development platforms perpetuate current code-based thinking. This article examines a new, different, and proven approach based on RESTful resource-oriented development that eliminates emerging complexities by leveraging the principles that have made the Web successful.
Before Ajax, servers were responsible for the creation and delivery of complete HTML pages displayed in Web browsers. For each request, a traditional Web application extracts information from a database, binds it to Java objects, performs business processing, and creates an HTML page.
With Ajax, client-side JavaScript code controls the application flow and makes fine-grained requests from servers for information and services (see Figure 1). To service these new clients, servers must support more URL endpoints or information channels, each of which supplies resource representations encoded as JSON, XML, and HTML. These representations require a new set of bindings from Java objects, which adds even more complexity to server-side development. Is the traditional way you develop on the server-side the most efficient process for fine-grained Ajax applications?
What if the Web's boundary extended beyond the server? What if the Web reached into the data tier and eliminated your need to understand and manage data types? You would have a set of Web application surfaces that extended across the network, from the Ajax client-side to the server-side and through the layers of your application to the data (see Figure 2).
In this type of system, your server-side application would become a set of mappings from external URL addresses to server-side resources. If these mappings extend to the data, then your objects and code would disappear. Just as Web pages can be composed from related bits of information, server-side software can compose a resource representation from the core data and return a result. How can you implement this system? Is it a practical way for you to develop your server-side applications?
Using the Web for Software Dev
To enable software construction using principles from the Web, you must adopt a single important concept: Use URI addresses to identify all the elements in your system. These elements include resources, services, information channels, and program code. To create a URI address, such as a URL, you use a scheme, such as http: or ftp:, and an address. You must augment schemes that are focused on small-scale, in-memory operations within contexts appropriate for application software to create URI schemes that work well between computers, such as http:. For example, a channel: scheme identifies information channels, and a resource: scheme identifies specific resources by name. With internal URI addressed resources providing your core application entities, you can construct a system by mapping external URL addresses to internal resources. Figure 3 illustrates a simple example of this approach.
In Figure 3, the external URL /index.html is mapped to an internal resource identified by file:/src/index.html, or a file residing within the file system.
A more sophisticated system might generate the resource representation for /index.html using an XSLT transform of an XML file. Figure 4 shows you which mappings are required to implement this approach:
In Figure 4, the external /index.html resource is mapped to a functional program that uses XSLT to transform an XML document into the requested resource. Here is the full URI for this transformation:
active:xslt+operand@file:/src/index.xml+operator@file:/src/layout.xsl
This URL uses the active: scheme, which you can use to specify functional programs within a URI.
The active: scheme depicted in Figure 5 specifies a function or service and a series of named arguments. Each argument references a URI that provides the value. This recursive use of URIs creates a tree-shaped set of related resources that together result in a resource representation computation.
In Figure 5's XSLT transformation program, the XSLT service is passed to the resource file:/src/index.xml as the value of the operand parameter and the resource file:/src/layout.xsl as value of the operator parameter. A URI identifies a resource and defines a functional program that computes the resource representation. This duality is possible because of the resource orientation, a level of indirection, and the deferral of binding until the moment of execution. The active: scheme adheres to the URI standards, and it is key to building applications from a Web-resource–oriented approach.
An internal URI might also identify procedural code. For example, language runtimes for JavaScript, Ruby, Python, or other languages can be designed as URI addressed services. Here is the URL to invoke a JavaScript program in this type of system:
active:javascript+operand@f
ile:/src/myprogram.js
The JavaScript runtime would execute the program contained in the myprogram.js file. With JavaScript support in the server, you can run Ajax libraries in client-side and server-side code.
More Advantages to URI Addressing
There are other advantages to URI addressing. Because each resource is fully identified by a URI, you can use the URI as the key for a cache in which the transformed representation is stored. Web-style caching of each fine-grained constituent resource can dramatically speed up your performance.
The consistent use of URI addressing also makes each architectural layer similar to the others. You can apply the same principles to the presentation, logic, and persistence layers, reducing your need to master a wide range of technologies and APIs. In the figures above, you don't need to transform information into objects, and deal with RDBMS-to-object and object-to-XML binding issues.
Implications of a Web Approach
Using a Web approach to build software systems provides interesting implications. New URL endpoints and information channels can be added to an existing system without disturbing its mappings; you simply add them to your system. Information channels can also be semantically distinct, providing new views or sending information through new analytical or transformative processes. Caching the results of computations under the URI of a resource is automatic and not only increases performance, but it also results in self-tuning applications because the cache holds the resource representations that have been most recently requested. Finally, you don't need lots of code to build systems with a Web approach since most of the logic is comprised of mappings. When code is required, it is placed behind URI addresses and the context is constrained to only that information required by the function. Small-scale development is much easier to test, debug, and maintain.
The Role of NetKernel
The idea of using URI addresses inside of software systems was pioneered at Hewlett Packard Labs and fine tuned by 1060 Research. Realizing this idea, 1060 Research's NetKernel is a new application server that connects URI addressing to the microkernel that powers your system. In NetKernel, each resource request is delivered to the microkernel where the address resolution and subsequent evaluation are scheduled for synchronous or asynchronous execution on a tightly managed set of execution threads. To demonstrate this process, 1060 Research designed, built, and tested the forum software, which is available for your review at http://demo.1060research.com/book/architectguide/app-forum-lite-doc-guide.
As an Ajax developer, you can find many advantages to using NetKernel, or Web principles, to build server software. HTTP requests for resources and services are directed through mappings to URI identified resources within the server. This direct mapping to micro server-side Ajax services reduces external complexity, and the ability to build these services using Web principles reduces internal complexity.
Your performance also improves. You can cache each internal resource, even the fine-grained ones used to compose larger resources. Instead of executing procedural code as in traditional systems, the applications built with NetKernel perform automatically the least amount of work necessary to return a resource. Even if you add explicit caching to a traditional system, you cannot match the automatic caching of resources that occurs in NetKernel.
You will find server-side, Web-style development a natural companion of client-side development. The ideas that compose this development style—such as URI addressing, mappings of external to internal resources, the elimination of various bindings, and support for JavaScript coding—are an ideal companion for innovative, next generation, Ajax-client–based systems.
About the Author
Randolph Kahle is an experienced software executive with years of experience with HP and Microsoft. As a senior marketing manager with Microsoft, he was instrumental in the launch of Visual Basic, SQLServer, Microsoft Access, and Microsoft's developer focused programs, such as the Microsoft Developer Network.