Jakša Vučković
With the popularization of SOAP and Web Services, time has come to redefine the underlying protocol. This document describes an extension for HTTP that gives new power to the World Wide Web. Aspects like RPC and RPC callbacks, Method Discovery, Object Management and Deployment are the main issues of this protocol. It is recommended to have familiarity with HTTP v1.1, XML and SOAP before reading this document.
With the growth of Web Applications, web pages are
assuming a new role in Internet. Not just content, but service. So the HTML is
beginning to be the new GUI standard. Many applications today offer web
interfaces even if they are not intended to be used by an Internet wide public.
These interfaces are mostly used for remote administration of web servers,
application servers or even operating systems (ex. Linuxconf).
But web pages do not offer the same user interaction
effectiveness as standard OS dependant graphical interfaces. All interaction
between application and interface has to be done by page requests. And only the
client may start such interaction. Here we try to define a protocol that will
extend the functionality of web pages.
The protocol is an extension of HTTP 1.1. A set of
new HTTP methods are defined plus the ability to send requests from server to
client. The methods defined by this extension are:
Along with the HTTP 1.1 methods, these methods provide all the functionality needed by a modern Web Application or Web Service. We’ll try to examine these new features.
The new web page model can be used as an Object
Oriented User Interface, allowing the user to browse pages like files on the
local file system and perform operations on them without opening the page.
From now on we’ll refer to web pages as web
objects because each web object can have a set of operations defined. This is
the same idea that stands at the basis of the Web Services and SOAP
technologies. It allows B2B processes to interact in an automated way.
The RPC protocol used to invoke these operations is
the existing SOAP protocol. But instead of sending SOAP messages in a POST
method, we define a new CALL method specifically for this. So the new
request format will be:
CALL object-url HTTP/1.2
Attribute: value
…
<SOAP-ENV:Envelope>
…
</SOAP-ENV:Envelope>
The difference between the POST and CALL methods is that a POST method is assumed to return a new page; CALL instead returns a success code and eventually a return value.
The protocol also assumes the possibility that the server sends a CALL request to the client. We’ll see this scenario when we talk about graphical interfaces.
Client request:
CALL
http://www.mydomain.com/webobjects/int_var.obj HTTP/1.2
<SOAP-ENV:Envelope>
<SOAP-ENV:Body>
<xmlns:m="http://www.mydomain.com/webobjects/int_var" />
<m:GetValue/>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Server response:
200 OK
<SOAP-ENV:Envelope> <SOAP-ENV:Body>
<xmlns:m="http://www.mydomain.com/webobjects/int_var" />
<m:GetValueResponse> <Value>34</Value> </m:GetValueResponse> </SOAP-ENV:Body></SOAP-ENV:Envelope>
The Web Services standard way of discovering the methods of an object is to look at its WSDL file that contains all the definitions. But where do we get that file? There is no specified way to associate a web object to its WSDL file. So we introduce the METHODS method. This one returns the set of operations performable on a web object.
Let’s look at an example:
Client request:
METHODS
http://www.mydomain.com/webobjects/int_var.obj HTTP/1.2
Server response:
200 OK
<webobject name=”int_var.obj”>
<webmethod name=”SetValue”>
<parameter name=”val” type=”xsd:int”/>
</webmethod>
<webmethod name=”GetValue”>
<return type=”xsd:int”>
</webmethod>
</webobject>
This example describes a web object called int_var that has two operations: SetValue and GetValue. The first accepts an integer parameter and does not return anything. The second operation GetValue has no parameters and returns an integer value.
The protocol also offers a way for browsing objects just like on a file system. The method DIR returns the contents of a directory in a verbose listing.
Client request:
DIR http://www.mydomain.com/webobjects/
HTTP/1.2
Server response:
200 OK
<contents>
<webobject name=”int_var.obj” type=”…” size=”5343”/>
<webobject name=”float_var.obj” type=”…” size=”7500”/>
<webobject name=”string_var.obj” type=”…” size=”14100”/>
<html name=”index.html” size=”2343”/>
<file name=”tutorial.pdf” size=”254322”>
</contents>
The attributes of the webobject element are:
The type file is an XML document describing the interface of an object. Its structure is identical to the METHOD response of the object. It is obvious that the type file is redundant, because we can discover methods of an object with a METHODS request. But it is mainly used when we have a lot of objects of the same type. So the client doesn’t have to request METHODS on each object. The type attribute is optional so there is no need to have a type file for each object.
Another important aspect of web sites is their administration. One should be able to deploy, remove and manage web objects.
The methods used for deploying and getting objects from the server are the HTTP standard methods PUT and GET. The PUT method uploads an object on the server. The GET method unlike with the CGI returns the object itself, and not the output of the object. To get the output of the object we will use another method as explained further.
Another HTTP 1.1 method that we use is DELETE. This one obviously deletes an object from the server.
Two new methods were introduced for object management: MOVE and COPY. Both methods have 2 resources in their request, the source and the destination. For example a move request might be:
Client request:
MOVE http://www.mydomain.com/webobjects/int_var
http://www.mydomain.com/myfolder/int_var HTTP/1.2
Server response:
200 OK
<webobject name=”int_var”>
<webmethod name=”SetValue”>
<parameter name=”val” type=”xsd:int”/>
</webmethod>
<webmethod name=”GetValue”>
<return type=”xsd:int”>
</webmethod>
</webobject>
The MOVE method can be used to rename objects like on UNIX systems. If the destination resource is a directory, the object will be moved, but it will maintain the same name. The COPY method must specify its destination resource object name (?).
The new protocol enables the use of web pages as a fully empowered application interface, allowing applications to control and change their graphical interface without reloading the page. As we’ve seen earlier the GET method is not the one used for opening an object interface. We’ll use OPEN instead.
A client connected to the server can open and close objects. This concept is like opening and closing files or starting and stopping programs. When a client does an OPEN on an object, the server returns the HTML file describing the graphical interface of that object.
Client request:
OPEN
http://www.mydomain.com/webobjects/string_var.obj HTTP/1.2
Server response:
200 OK
Content-Type: /text/html
Size: 14100
<html>
…
</html>
HTML can be extended to allow interaction between client and server. For example it should be possible to invoke operations on objects from the HTML file. There are two possible methods for doing this. One is to call methods from links. The user clicks on a link and the browser just calls the appropriate method of the web object. A better one approach is to allow embedded code to call object methods. Code associated to a link could manage the parameter values of a call. There are already various languages for embedding code in HTML (JavaScript, JScript, VBScript).
<img
src=”button.gif” OnClick=”value = webobject.getValue()”>
When a client closes the interface of an object it should send a CLOSE message to the server notifying that resources allocated to a running instance of an object could be freed.
Client request:
CLOSE
http://www.mydomain.com/webobjects/string_var.obj HTTP/1.2
Server response:
200 OK
This could cause some security problems if a malicious client opens a lot of objects and never closes them. A server could free all resources associated to that client, when the connection with that client is closed. Still a client could open objects on the same connection, but the server could limit the number of open objects per connection.
Being open for an object means that an instance of that object is running. All session data of the object must be created, and if the object is an agent it must become active. An open object could call operations on its graphical interface, for example to update some data. Thus the HTML should be extended to support invocations from the server. A set of procedures could be defined in an HTML file that can be called from the running object instance.
Server request:
CALL
http://www.mydomain.com/webobjects/stockQuotes.obj HTTP/1.2
<SOAP-ENV:Envelope>
<SOAP-ENV:Body>
<xmlns:m="http://www.mydomain.com/webobjects/int_var"/>
<m:updateQuote>
<Name>IBM</Name>
<Value>53.2</Value>
</m:updateQuote>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Client response:
200 OK
<SOAP-ENV:Envelope> <SOAP-ENV:Body>
<xmlns:m="http://www.mydomain.com/webobjects/int_var"/>
<m:GetValueResponse/> </SOAP-ENV:Body></SOAP-ENV:Envelope>