CGI Services Architecture
Recent Pages

Environment Variables
Handling Concurrency
Template Processing
RDF Responses
RDF Messaging
URL Rewriting
File Uploads
Sample Authenticated Se ...
HTTP Cookies
Client Authentication

Links on Twitter
CSA Home
Table of Contents



User ID

Campaigns petition banner

RDF Messaging

The Common Gateway Interface specs describe how the data should be passed from an HTTP client to an HTTP server in a machine-readable format. Nothing is said, however, about how the server should respond, leaving the response payload format completely up to the specific application. Many application-protocols have been designed to provide enough structure in the HTTP response body to make the response intellegible by a programmatic HTTP client. SOAP, XML-RPC and a few other message formats, often XML-based, have been designed exactly for the very purpose of making programs communicate with each other with simple (or supposedly so) RPC-over-HTTP mechanisms. Programs that operate in this way are usually referred to as Web Services.

As it often happens when new things -- or new ways to use old things -- are brought about, also Web Services have produced a good deal of marketing hype and they have not always delivered on promises. In fact Web Services are nothing new, neither they indroduce new things nor new ideas, but they are simply made possible in the first place by the clever people who designed the current Web with enough flexibility and extensibility.

One drawback of mainstream RPC-over-HTTP implementations, such as SOAP and XML-RPC, is that they do not work with current user-oriented Web browsers. If a Web application is to be used by both a programmatic client and a human client using a standard Web browser, two separate versions of the application need to be written: one that speaks HTML and another one that speaks an RPC-over-HTTP protocol.

CSA tries to address the above limitation by providing a request/response mechanism that can be used by both standard Web browsers and programmatic clients. Each type of client will see only the portion of a response that it can understand, with no need to provide different, specialized versions of a particular web service. As its more famous counterparts, also the RPC-over-HTTP mechanism provided by CSA, let's call it CSA-RPC, is based on XML, and in particular over an XML serialization of RDF. The mechanism provided by CSA is still experimental and it is in an early stage of development. It may change, even radically, or even be dropped altogether in future releases of CSA until it will (if ever) be declared as stable, so be warned.

Another acronym that has received much attention in the press is SOA (the short of Service-Oriented Architecture). Like Web Services, also SOA is nothing new, as from a general perspective a service in an SOA is a program that can be called from the network and that will return a structured document as a reply. In that respect, the CSA-RPC mechanism outlined above definitely makes every CSA application an SOA.

Trackbacks (0) | New trackback | Print

This Web Site is Copyright © 2007,2008,2009,2010 Carlo Strozzi, Some Rights Reserved
site map | recent changes | disclaimer