WO2004088953A1

WO2004088953A1 - A method and apparatus for accessing data on a computer network

Info

Publication number: WO2004088953A1
Application number: PCT/GB2004/001329
Authority: WO
Inventors: Steven Simpson; David Hutchison
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 2003-03-31
Filing date: 2004-03-26
Publication date: 2004-10-14
Anticipated expiration: 2005-09-30
Also published as: GB0307408D0

Abstract

An HTTP proxy server (240) forwards most requests onto other proxies and servers unchanged, but intercepts requests (600) for URNs from a client device (100), and provides its own responses (625) to them. The proxy (240) provides a Java environment in which it can execute Java subroutines called proxylets. Proxylets can be requested (605) and loaded in (610) from a proxylet repository server (500) and executed while the proxy (240) is running, so its capabilities can be augmented dynamically. A proxylet acts as a miniature proxy - it accepts requests which the proxy has decided to supply, and must provide corresponding responses. To achieve this, it can act as a client, talking, with get URL HTTP request messages (615) and (200) OK HTTP responses (620), with upstream entities, which may be other proxylets in the same (or even in another) proxy, or other proxies and servers (400) which the proxy is configured to use. A proxylet can also load other proxylets into its environment.

Description

A Method and Apparatus for accessing data on a Computer Network

Field of the Invention

The present invention relates to a method and apparatus for accessing data on a computer network. In particular, it relates to a method of accessing a resource such as a document from a computer network by means of an identifier of the document, which identifier is independent of the current location of the document.

Background to the Invention In a computer network, it is conventional for a document to be identified by means of an identifier which specifies the location in which the document is stored. A Uniform Resource Locator (URL) is a well known example of a document identifier which specifies the location at which the document (or more generally the resource) is stored on the computer network. Each URL expresses the name or address of a server which can provide the resource, the protocol used to talk to the server and a local reference to, identify the resource within the server. That is, a URL implies a mechanism and a location to obtain the corresponding resource. A Uniform Resource Identifier (URI) is a more general term for a type of machine readable address and URLs can thus be said to be a subset of URIs. A discussion of the nature of URIs is given in a publication (a so-called Request For Comments (RFC)) from the Internet Engineering Task Force (IETF) authored by T.

Berners-Lee et al. entitled "Uniform Resource Identifiers (URI): Generic Syntax"; RFC 2396, IETF, August 1998.

Although in many cases a URL adequately specifies a mechanism to obtain a resource from a computer network, there are several problems associated with the use of URLs as resource identifiers: i) First, resources may migrate. Webspace providers can withdraw from service, and website maintainers can choose an alternative host server. This may result in the URL of a resource changing, which then requires users to find out the new URL or else for a re- direction mechanism to be put in place. ii) Second, resources may be replicated. Many important websites are often "mirrored" to reduce the load on servers, and to reduce response times to clients that are able to find the nearest mirror. However, this requires user interaction, and produces many distinct references to the same resource - which one should be given when identifying a resource? Each URL may imply a location which may be convenient from one part of the network but inconvenient from another part. iii) Third, conceptual collections of resources may be divided over several sites, causing the URL's of the component resources to vary arbitrarily, when it would be preferable to have a single schema for identifying the components regardless of their location or the necessary mechanism for communicating with the respective server to obtain the resource.

The IETF devised a new type of URI, referred to as a Uniform Resource Name (URN), to address the above mentioned problems with URLs. A URN is a persistent, location- independent resource identifier which identifies a resource, rather than explicitly locating it (or specifying what retrieval mechanism to use to retrieve it). This means that: i) a URN for a resource need never change and the resource can change location independently of the URN; ii) a resource identified by a single URN can exist at multiple locations simultaneously; iii) a collection of resources identified by a related class of URNs can be arbitrarily partitioned and spread over several physical locations. Clearly, in order for a URN to be used to access a resource, some kind of URN resolution mechanism is required. The IETF decided that exactly how this is done should not be prescribed so that many different methods could evolve to allow different types of URN to be resolved in different ways as appropriate. Nonetheless, the IETF have proposed a possible mechanism for resolving URNs which is set out in IETF's RFC's 2168 and 2169. The proposed method involves the browser extracting parts of the URN and using them to form a query to the DNS system which, possibly after several look-ups in the DNS system, returns the location (essentially in the form of a URL) of one or more servers which can resolve the URN. The browser should then contact the server offering the URN resolution service with the URN to be resolved and the contacted server will then perform the requested resolution (eg into one or more corresponding URL's). As noted above, the proposed resolution method requires new and specialised activities to be carried out at the client terminal. However, this requires each and every browser to be modified to permit such a resolution to occur. Furthermore, whenever a new resolution protocol is proposed which requires additional functionality on the part of the client to take advantage of it, the browser software will again need to be updated on each and every client device which wishes to take advantage of the increased functionality.

Summary of the Invention

According to a first aspect of the present invention, there is provided a method of accessing a resource stored on a server device from a client device, the client device being connected to the server device via a computer network, the method comprising: transmitting from the client device to an intermediate device a naming identifier which identifies the resource without specifying an associated server device within the computer network; at said intermediate device, resolving the naming identifier into a corresponding at least one locating identifier which specifies the server device storing the resource; and requesting the server device specified by the locating identifier to transmit a copy of the resource to the client device. In the present application, the term intermediate device is used in a very broad sense to mean any device which is connected to the network other than the client device (the intermediate device may even be the server device on which the resource is stored) and thus includes specialised router devices and other server devices. Preferably however, the intermediate device is itself a server device running an application which permits (typically small) programs to be dynamically loaded and run on the server device in response to a request from a remote device connected to the network; hereinafter, such an application shall be referred to as an Execution Environment for Proxylets (EEP) and the programs which are dynamically loaded and run shall be referred to as proxylets. In a currently preferred embodiment, an EEP is provided as part of a programmable HTTP proxy which includes ports to which a proxylet can attach its own ports to form a mesh of interconnected HTTP-processing components (which includes proxylets). Some portion of the mesh traverses the EEP within the proxy, and components therein are dynamically loaded, and as a result this portion of the mesh may change over time. Dynamically loaded HTTP -processing components are proxylets. Such a programmable HTTP proxy is described in greater detail below. A discussion of the operation of an alternative EEP and example proxylets is given in co-pending UK patent application number 0226762.3 the contents of which are hereby incorporated herein by way of reference. Note that the programmable HTTP proxy which is described in greater detail below may include as part of a mesh HTTP-processing components which behave like proxylets (in that they have ports for receiving requests and transmitting responses, etc.) but which are not dynamically loadable. In general, any such component could be replaced by a dynamically loadable proxylet or vice versa, however in particular implementations it may be more convenient for a developer to simply perform certain more mundane housekeeping type functions with static components. Of course, using dynamically loadable proxylets throughout has the advantage of enabling even mundane housekeeping functions to be enhanced dynamically by simply creating a newer updated proxylet to dynamically replace the old one without requiring downtime of the HTTP proxy.

Preferably, the naming identifier is a URN and the intermediate device resolves the URN into one or more URLs. The intermediate device may simply return the resulting URL(s) to the client device to permit the user (or possibly the browser application on behalf of the user without requiring user intervention - see the IETF's RFC's 2295 and 2296 for further details of how this might be implemented) to then initiate a request to the server (or any one of the servers) storing the desired resource requesting that the server transmit a copy of the resource to the client device. In an alternative embodiment, however, the intermediate device automatically issues such a request to a corresponding server such that the client device automatically receives a copy of the resource without further interaction from the user. In this case, the browser running on the ultimate client device preferably does not know the actual URL used to access the resource. This ensures that if a user bookmarks the resource or forwards it on to a third party, the URI used is the URN and not a corresponding URL. In the event that the URN is resolved into only a single URL, it is clearly trivial for the intermediate device to issue a request for the resource to the corresponding server. In the event that the resolution of the URN by the intermediate device establishes that there are a plurality of corresponding URLs (for example because the resource is located at a number of different mirror sites) the intermediate device preferably measures one or more metrics (such as, for example, the Round Trip Time) for each of the servers associated with the corresponding URLs and automatically issues a request to the server with the best measured score or scores (eg the shortest RTT) to transmit the resource to the intermediate device (which can then forward it on to the client device).

Brief Description of the Drawings In order that the present invention may be better understood, an embodiment thereof will now be described, by way of example only, with reference to the accompanying drawings in which:

Figure 1 is a block diagram illustrating a computer network according to an embodiment of the present invention;

Figure 2 is a signal diagram illustrating the signals passed between various components of the network of Figure 1 in carrying out a method embodying the present invention; and

Figure 3 is a signal diagram illustrating the signals passed between various components of the network of Figure 1 in carrying out an alternative method embodying the present invention.

Detailed Description of Embodiments of the Invention Figure 1 is a block diagram of a computer network generally designated 10. The network is shown to include a client device 100, an Internet Service Provider (ISP) facility 200, the Internet 300, a remote host server 400 and a proxylet repository server 500. At the ISP facility 200, there is a Local Area Network 210 a general server 220, a Domain Name Server (DNS) 230, and a programmable HTTP proxy server 240 and a router or gateway 250 connecting the ISP facility 200 to the Internet 300. The skilled reader will appreciate that the diagram is schematic only and many elements of a real computer network have been omitted for the sake of clarity as they are not germane to an understanding of the present invention. In order for a user operating client device 100 to access a resource located on host server 400, the user types into a web browser which is running on the client device 100 a Uniform Resource Identifier (URI) for the resource (the URI may be either a Uniform Resource Name (URN) or a Uniform Resource Locator (URL)). The web browser generates a standard "GET" request based on the entered URI (in the case that the user enters a URN, the browser in this embodiment behaves in the same way as it does for the case that the user enters a URL (ie the browser "assumes" that the entered URN is in fact a URL - many common browsers currently available will not in fact do this and instead will generate an error - however, it is straightforward to modify a browser to have the enhanced functionality required for this purpose and having made this modification, no further modifications will be required to deal with new URN resolution proxylets which may be developed after modification of the browser software).

In the present embodiment, all HTTP requests from the browser on the client device 100 are programmed to go via HTTP proxy server 240 (located at the ISP facility 200) which is acting as a first-pass HTTP proxy server whose specialist functions are described below (note that it is common procedure for the browser of a client to communicate with a proxy rather than attempting to determine the IP address of the server corresponding to each URL input via the DNS system and then setting up a direct connection with the corresponding server itself, instead it directly communicates only with the proxy which is then responsible for determining the IP address of the corresponding server and setting up the direct connection, etc.). An HTTP proxy acts as an HTTP server to browsers and other proxies (which are downstream of the proxy), and as a client to servers and other proxies (which are upstream). A downstream entity normally must be somehow configured in order to make use of a proxy - most browsers have a configuration option to which the proxy's address is given, or accept a proxy configuration script which can determine the address more dynamically. Once configured, a browser can send its HTTP requests to the proxy. The proxy may forward them on to a server that can provide the requested resource (and so it will also forward the responses from the server to the client), or forward them on to another proxy (and forward the corresponding responses back), or provide a response itself. It could also modify requests and responses that it forwards. This means that, provided that a browser will send resource requests through the proxy, the proxy can provide additional content-delivery services (such as caching) without any further extensions to the browser. The programmable HTTP proxy server 240 includes, in the present embodiment, a URN identification component which, in the present embodiment, is a proxylet and examines incoming HTTP requests from the client device 100 and reacts in one of the following ways: i) if the request includes a URL, the URN identification component causes the programmable HTTP proxy server 240 to simply forward the request on to server 220 which is hosting a more conventional HTTP proxy (which provides caching services) which processes the request in a conventional manner (eg by contacting DNS server 230 if necessary to obtain the IP address of the server associated with the URL contained in the request and eventually obtaining and forwarding back to the URN identification proxylet a suitable response (eg a 200 OK response including the requested resource) which is then passed back to the client device 100); or ii) if the request includes a URN, the URN identification component passes the request for processing by a generic URN resolving component (which is a proxylet in the present embodiment) which is up-stream of the URN identification component. The generic URN resolving component is so-called because it is not namespace-specific but rather it is namespace-independent. However, it may (and almost certainly will in practice) in turn call further, more specialised, namespace-specific URN-resolving components to complete the resolution of the URN (the generic URN resolving component loads such components into the EEP and hence are proxylets; the way in which proxylets are instantiated within the execution environment provided by the programmable HTTP proxy application of the present embodiment is discussed in greater detail below); having resolved the URN to identify an appropriate corresponding URL, in the present embodiment, a namespace-specific URN resolving proxylet retrieves the corresponding resource (or enough information to obtain it) and forwards it directly to the client device 100.

The present embodiment thus provides an HTTP proxy which forwards most requests onto other proxies and servers unchanged, but intercepts requests for URNs, and provides its own responses to them. The proxy provides a Java environment in which it can execute Java subroutines called proxylets. Proxylets can be loaded in and executed while the proxy is running, so its capabilities can be augmented dynamically. A proxylet acts as a miniature proxy - it accepts requests which the proxy has decided to supply, and provides corresponding responses. To achieve this, it can act as a client, talking to upstream entities, which may be other proxylets in the same (or even in another) proxy, or other proxies and servers which the proxy is configured to use. A proxylet can also load other proxylets into its environment.

A generic URN-resolving proxylet also forms part of the present embodiment, and is placed in the proxy somehow (e.g. by the administrator of the proxy), so that it receives requests for URNs. It also maintains references to a set of namespace-specific proxylets which it has installed and placed upstream of itself, to which it can delegate certain interactions. This set is initially empty, but may grow or shrink over time. Each of these proxylets is associated with a URN NID, is expected to be able to generate a useful response to any request for URNs in that namespace, and has been downloaded from an address which can be derived from the NID according to some configured rule.

When the generic URN-resolving proxylet receives a request for a URN (which should therefore be of the form urn:<nid>:<nss> as defined in IETF's RFC 2141, it extracts <nid>, and looks for an installed proxylet associated with <nid>. If present, it can immediately delegate the request to that proxylet, which is expected to provide a useful response because of its nid association. If such a proxylet is not present, the generic proxylet passes the nid through the configured rule to obtain the address of the proxylet, and attempts to download and install it in the set. If this fails, the generic proxylet may respond with an error, or delegate the request to some other configured upstream entity. If the installation succeeds, the generic proxylet can delegate to the new namespace-specific proxylet as before. The namespace-specific proxylet may make use of <nss> to complete the interaction.

The generic proxylet or the proxy may employ some policies to determine when to reinstall currently-loaded proxylets, in order to ensure that the latest resolvers are available.

Figure 2 illustrates an example case of resolving a URN to obtain a copy of a resource located on Host server 400 (a so-called URN to Resource or N2R service). The client device 100 sends a GET URN message 600 to the programmable HTTP proxy server 240. In this example, the URN refers to an IETF RFC, a copy of which document is stored on the host server 400. At the programmable HTTP proxy server 240, the URN identification proxylet determines that the GET request references a URN rather than a URL and thus passes the GET request to the generic URN resolving proxylet. The generic URN resolving proxylet identifies the URN as being in respect of an IETF document and thus goes about loading in an appropriate proxylet for resolving that type of URN (in this case an IETF URN resolving proxylet). It does this by sending a GET "proxylet" HTTP request 605 to the proxylet repository server 500. The proxylet repository server 500 has a copy of the requested proxylet and thus sends a "200 OK" HTTP response 610 which includes the requested proxylet (note in fact in the present embodiment, this request and response interaction may go through another proxy - eg the "normal" proxy server 220 - depending on the location of the proxylet repository server relative to the programmable proxy server and the way in which the programmable proxy has been configured. Also note that in the present implementation, this is done using the networking facilities provided in the Java programming language within thejava.net package including the well-known classes and interfaces such as URL, URLConnection and URLClassLoader, etc.).

When the requested IETF URN resolving proxylet is received at the programmable HTTP proxy server 240, the received proxylet is instantiated (and retained for future use) and the original GET URN request is passed to it for processing. The URN is then resolved, in the present example, into a single URL. The IETF URN resolving proxylet then proceeds to send a GET "URL" HTTP request 615 to the host server 400 (again possibly via one or more additional proxies such as proxy 220). Upon receipt of the GET "URL" HTTP request 615 at the host server 400, the host server 400 behaves in a conventional manner to retrieve the requested resource and sends it along with a "200 OK" HTTP response 620 back to the EEP server 240. This is returned unchanged, through the IETF proxylet, the generic proxylet and the identification proxylet, to the client device 100 as part of a "200 OK" HTTP response. The retrieved IETF specific proxylet is retained, in the present embodiment, such that next time it is required for resolving an IETF URN, it does not need to be re-fetched from the proxylet repository 500. As mentioned above, the above described example is termed a URN to resource (N2R) service because, from the perspective of the client device, a URN is converted directly into a corresponding resource. Figure 3 illustrates an alternative case in which the URN is converted into one or more URL's with the user then being given the choice to select which URL to access conventionally in order to obtain the desired resource. This type of method can be useful where there are a number of mirror sites and the user (or, in a preferred embodiment, the browser) wishes to select the best site from which to obtain the resource according to some predetermined metrics such as round trip time, etc., and is termed a URN to URLs or N2Ls service.

Thus, as shown in Figure 3, initially the client device sends a GET "URN" HTTP request 650 to the programmable HTTP proxy server 240. This request is then passed to the URN identifying proxylet which determines that the request refers to a URN (as opposed to a URL) and therefore passes it to the generic URN resolving proxylet. The generic URN resolving proxylet identifies the URN as being in respect of (for example) an ISSN document and thus goes about loading in an appropriate proxylet for resolving that type of URN (in this case an ISSN URN resolving proxylet). It does this by sending a GET "proxylet" HTTP request 655 to the proxylet repository server 500. The proxylet repository server 500 has a copy of the requested proxylet and thus sends a "200 OK" HTTP response 660 which includes the requested proxylet (note that in the present implementation, this is done using the networking facilities provided in the Java programming language within the java.net package including the well-known classes and interfaces such as URL, URLConnection and URLClassLoader, etc.). If the generic URN resolving proxylet has recently loaded the ISSN URN resolving proxylet, it will probably be retained in the programmable HTTP proxy server and messages 655 and 660 are redundant and processing instead jumps immediately to the following stages (as indicated by arrow 665).

Once the ISSN URN resolving proxylet is successfully started (and retained for future use), the original GET "URN" request is passed to it for resolution. In the present example, the resolution only proceeds as far as to obtain the corresponding one (or more) URLs which are then passed back (from the ISSN URN specific resolving proxylet via the generic URN resolving proxylet) to the client device 100 in a suitable "3XX HTTP redirection response" 670 (eg a "302 FOUND" redirection response where only a single URL is returned). In the present example (of an ISSN document URN) only a single corresponding URL is obtained and sent to the client device 100. Thus the browser, in the present example, determines that only a single URL has been passed back and thus automatically sends out a "GET URL" HTTP request 675. This passes to the programmable HTTP proxy server 240 which determines that the request relates to a URL and thus simply forwards the request on to a conventional HTTP proxy (located in the present embodiment in server 220) as another GET "URL" HTTP request 680. The conventional HTTP proxy running on server 220 then processes the request and returns the desired resource back (via a "200 OK" HTTP response 685) to the URN identifying proxylet running on programmable HTTP proxy server 240, which in turn forwards the document on to the client device 100 via another "200 OK" HTTP response 690. Note that in this example, server 220 is also taken to have recently cached the requested document so that no additional messages need to be sent to the host server 400 containing the original version of the document. Since this method returns one or more corresponding URL's to the client device rather than the resource itself, this method is referred to as a URN to URL's service (N2Ls).

In the present embodiment, four namespaces have been implemented as namespace- specific proxylets. For the IETF namespace, which identifies RFCs and Internet Drafts, an alternative IETF URN specific proxylet contains the addresses of several sites that hold RFCs and Internet Drafts, and downloads the requested document (as identified by the nss) from one of these sites, and provides it as the response. It will also try other sites if its initial choice is not forthcoming, and keeps track of response times to each site to help to choose one for future requests.

For the issn namespace, which identifies journals, periodicals and other serials, the proxylet wraps a configured prefix and suffix around the nss, to form a new URI. It then responds with a 302 redirection to instruct the browser to request the resource identified by that URI instead.

For the unregistered hdl namespace, which identifies documents and resources in the Handle system, the same proxylet is used, but with a different prefix and suffix. A request for the new URI will itself generate another 302 redirection, which should be the final document.

For the unregistered os namespace, which was developed purely for demonstration purposes, the proxylet forms part of an application-level overlay network which is assumed to have been established. The participants of this overlay exchange information about mapping certain nss strings to URIs, and the metrics used to determine the overlay topology should favour mappings which produce URIs which are more favourable to the location of the namespace-specific resolver (e.g. the bandwidth between the proxy and the servers of those URIs is greater).

In the above example, only a single URL was obtained as corresponding to the URN. However, in a more general case a number of URLs may be obtained. In this case, in the present embodiment, the proxy (which is assumed to be using HTTP version 1.1 or higher) returns a "300 MULTIPLE CHOICES" HTTP response including all of the obtained URLs. In an enhancement to the present embodiment, the proxy, prior to sending the 300 response first measures the Round Trip Time (RTT) to each server associated with the different URLs and includes this information with the response. Alternatively, in a N2R service, if the proxylet obtains multiple different URLs it can first perform a RTT measurement of the different possible servers and then automatically contact the closest server, etc.

In the above embodiments, the functionality of the programmable HTTP proxy is deliberately somewhat limited and a conventional proxy is relied upon for providing conventional proxy services (eg caching) in respect of normal URLs. However, in a more sophisticated embodiment, instead of having a separate programmable HTTP proxy and a conventional proxy, a single proxy can be used which performs both functions.

In the above embodiments, the functionality of the programmable HTTP proxy server 240 is provided by a programmable environment which at any moment consists of zero or more proxylet instances whose ports may be interconnected to form a mesh. Herein, the term "downstream" is used to mean "towards the user agent" (ie towards the client device 100), and "upstream" is used to mean "towards the origin server" (eg host server 400). A Downstream Facing Port (DFP) is a port that can receive HTTP requests from downstream and return corresponding HTTP responses downstream. An Upstream Facing Port (UFP) is a port which can send HTTP requests upstream, and receive corresponding HTTP responses from upstream.

The term "channel" is used herein to denote a connection between a UFP and a DFP. A DFP may be connected by zero or more channels; a UFP may be connected by at most one channel. In the present embodiment, each proxylet instance has one or more DFP's through which HTTP requests may enter the proxylet instance, and corresponding responses leave. The proxylet identifies its DFP numerically, ie O-(n-l), if there are n DFP's.

Each proxylet instance has zero or more UFP's, through which the proxylet instance may direct HTTP requests, and receive corresponding responses. The proxylet may thus communicate either with other, upstream, proxylets or with other items connected to the network. The proxylet may identify its UFPs by any arbitrary configuration.

Additionally, the programming environment itself provides at least one UFP (the environment UFP(s)) to connect to one or more proxylet instances' DFPs, and drive HTTP interactions through the environment. When a mesh is configured, it must be provided with a subset of these, each identified to that particular mesh numerically from zero. Each mesh may be configured with a different subset if the proxy provides some other selection mechanism, eg. user identification by proxy authentication.

The execution environment additionally provides one or more DFPs (the environment DFPs) for connecting to some proxylet instances' UFPs and to service HTTP interactions forwarded through or generated by the environment. When a mesh is configured, it is provided with a subset of these, each identified to that particular mesh numerically from zero. Each mesh may be configured with a different subset if the proxy provides some other selection mechanism. Downstream of an environment's UFP(s) and upstream of the environment's DFP's are hidden components to translate HTTP messages between byte stream and data structures. A UFP and a DFP may be connected together directly to form an identity mesh.

In the present embodiment, three Java Interfaces are defined for permitting proxylets to manipulate HTTP messages:

HttpRequestlnput This expresses a read-only HTTP request, including request line, header, content and footer. Calls to obtain parts of this may block until those parts have been read in from the network. Conversely, some parts may be readable as soon as they are available, despite other parts not arriving.

HttpResponseOutput This expresses a write-only HTTP response. It is effectively a placeholder for a response to be provided later. The caller must provide each part and indicate that it is complete.

HttpReactor This interface represents a channel: its implementation is a DFP; the holder of a reference to one is effectively a UFP. A reactor has a single method which takes an HttpRequestlnput and an HttpResponseOutput (ie instantiations of object classes which implement these interfaces respectively). These represent an HTTP interaction from the point of view of the server (or other upstream entity looking back in a downstream direction).

A very simple reactor configured with a reference to another reactor may simply pass both the request and the response (or rather, the place-holder for the response) on to the other reactor, reducing the need to copy between a chain of reactors when no modifications are taking place.

In the above described embodiments, the following proxylets are connected into a mesh: i) The URN identification proxylet, which has one DFP which is connected to the environment UFP which is provided by the programmable HTTP proxy 220. The URN identification proxylet has a first and a second UFP. ii)The generic URN resolution proxylet which has one DFP which is connected to the second UFP of the URN identification proxylet. The generic URN resolution proxylet has a first and a second UFP.

There are also a varying number of specific URN resolving proxylets. Each has a first UFP to which it should forward requests that it cannot resolve successfully. Each has a second UFP to which it should issue any requests in order to perform its resolution. Each has one DFP to receive URN requests.

The generic URN resolution proxylet has a UFP per specific URN resolution proxylet connected to that specific proxylet's DFP. It ensures that the first UFP of each specific proxylet is connected to the same DFP to which its own first UFP is connected . It ensures that the second UFP of each specific proxylet is connected to the same DFP to which its own second UFP is connected

The first UFPs of both the URN identification proxylet and the generic URN resolution proxylet are connected (possibly via one or more further proxylets to perform housekeeping tasks such as, for example, to perform typical browser type functions of downloading a configuration script - such as an ECMAscript or a Javascript - to be executed to control the onward routing of HTTP requests) to the environment DFP whereby HTTP requests can be transmitted away from the programmable HTTP proxy to other elements in the network, and whereby incoming HTTP responses from other elements in the network can be passed back to whichever proxylet issued the corresponding request.

Claims

1. A method of accessing a resource stored on a server device from a client device, the client device being connected to the server device via a computer network, the method comprising: transmitting from the client device to an intermediate device a naming identifier which identifies the resource without specifying an associated server device within the computer network; at said intermediate device, examining the received naming identifier, determining one or more resolving programs adapted for resolving naming identifiers into corresponding locating identifiers, each of which specifies the server device storing the corresponding resource, and dynamically loading and running the or each determined resolving program to thereby resolve the naming identifier into a corresponding at least one locating identifier; and requesting the server device specified by the at least one locating identifier to output a copy of the resource.

2. A method as claimed in claim 1 wherein the naming identifier is a Uniform Resource Name as set out in IETF's RFC 2141.

3. A method as claimed in either preceding claim wherein the intermediate device is a server device providing an environment in which execution threads may be dynamically initiated according to dynamically loaded blocks of Java code.

4. A computer network including a client device, a server device and an intermediate device connected together by means of the computer network, wherein: the client device includes means for transmitting a naming identifier to the intermediate device, which naming identifier identifies the resource without specifying an associated server device within the computer network at which the resource is located; and the intermediate device includes means for examining the received naming identifier, determining one or more resolving programs adapted for resolving naming identifiers into corresponding locating identifiers, each of which specifies the server device storing the corresponding resource, and dynamically loading and running the or each determined resolving program to thereby resolve the naming identifier into a corresponding at least one locating identifier; and means for requesting the server device specified by the at least one locating identifier to output a copy of the resource.

5. A proxy server comprising: downstream facing means for receiving HTTP requests and transmitting HTTP responses; upstream facing means for receiving HTTP responses and transmitting HTTP requests; and executable environment means for permitting programs which process HTTP requests to resolve a naming identifier into one or more locating identifiers to be dynamically loaded and executed.

6. A client device comprising browser means for issuing HTTP requests to a proxy server and receiving HTTP responses from a proxy server, wherein the browser means is operable to generate HTTP requests for transmission to a proxy server in which the HTTP request requests a resource identified by reference to a naming identifier which identifies the resource without specifying an associated server device within the computer network.