|
By now, we have been thoroughly exposed to the acronym HTTP. It stands
for Hypertext Transfer Protocol, and is one of the underlying technologies of
the World Wide Web. A Web page is delivered from a server to a browser through
HTTP. An HTTP Request is the instruction sent from the browser to the server. An
HTTP Response is the result of the request, sent by the server to the browser. A
Web page is delivered within the HTTP Response.
There is a variant of HTTP that we may also have encountered: HTTPS. This
protocol is the secure version of HTTP, where the request and response are
encrypted before transmission. Secure HTTP is used for most Web applications
where personal, financial or sensitive information is being sent from browser to
server or vice versa. A Web server must have a server certificate, acquired from
a third party certifying body, for it provide an HTTPS service.
Another new variant of HTTP is HTTPR - for Reliable HTTP. This new protocol
is being developed by IBM for adoption as a standard by the Internet Engineering
Task Force (IETF). In a nutshell, HTTPR aims to ensure that a Web transmission
gets delivered to its destination only once, or gets reported as undeliverable.
HTTPR is geared toward business-to-business communications over the Web, such as
paying a bill or processing a purchase order, where a request must be delivered
once and only once to its intended receiver.
To understand more about how HTTPR works, we need to know a bit more about
HTTP.
The Principle of HTTP
Accessing pages on the Web is an easy concept. You simply type a URL into
your browser, click Go, and the requested page displays. In the background,
however, a flurry of computer and network activity makes the simple process
work. Your browser has to format your Web page request into an HTTP Request. It
has to work out the Internet IP address of the server that you are requesting
the page from. A number of computers on the Internet must then pass your HTTP
Request from machine to machine until it reaches the Web server. The Web server
must then interpret the request, fetch the requested resource, and start sending
the multiple elements of the page back to you across the Internet as HTTP
Responses. Lots of things can go wrong. For example, if the page you requested
does not exist, the Web server will send an HTTP Error 404. Sometimes, some
elements of the page may be delivered successfully, but other parts are not
delivered successfully. For this reason, HTTP is not all that reliable. Pages
don't always get delivered, and neither the browser nor the server can be sure
that a request or response made it to its destination.
When informational content is being requested and delivered, this
unreliability of HTTP doesn't present too many problems. If the page doesn't
display, you might try again, or try again later. It may be annoying, but it
isn't critical.
However, where the Request/Response is transactional, as is the case
for most Web applications, this unreliability becomes a problem. For example,
you just clicked the Transfer button in your Internet Banking application, and
your browser page seems to be 'hung'. Did your funds transfer go through? Should
you try again and risk sending the money twice? Did your funds go to the correct
account, as you didn't receive the acknowledgement you expected? In such cases,
the unreliability of HTTP is a big problem. And as more and more Web activity
becomes transactional as Web applications become the norm, HTTP's limitations
will become critical.
Enter HTTPR
HTTPR (or Reliable HTTP) is designed to ensure the delivery of
Requests and Responses from one system to another. Rather than replace HTTP,
HTTPR is layered on top of HTTP. HTTPR requests and responses are packaged as
the 'payload' of an HTTP transmission. HTTPR has three operational modes:
sessionless, simple sessions, and pipelined sessions.
Reliable HTTP enables transmission failures to be reported more accurately.
If a Web server is unavailable or rejects a particular request, then the browser
will know that the request failed. This ability to report a message failure is a
key features of HTTPR.
HTTPR ensures that a transmission reaches its destination, and further
ensures that each parcel of information is delivered only once. In our funds
transfer example above, you need to be confident that the transfer is processed
only once. So if for some reason a request hits the server twice, the server
needs to understand that the second request was a duplicate.
HTTP is often described as 'sessionless', in that each request is treated by
the server as a unique event unconnected to any other request. The server
therefore doesn't know that the request is just received is from the same
browser that made another request 30 seconds ago. HTTP doesn't maintain a
'persistent connection' between browser and server. However, HTTPR does allow
persistence, and this persistence leads to reliability. A persistence mechanism
retains the previous messages in a storage system.
When Will We See It Being Used?
Version 1.1 of HTTPR is currently (December 2002) released, and version 2.0
is in draft form. IBM has published the standard for public comment and
feedback. It has not yet been adopted by IETF. IBM's WebServices Toolkit (a Web
application software development kit) already provides support for HTTPR, but we
probably won't see widespread use of HTTPR 'in the wild' for at least one year.
More Information
|