CA2323376A1 - Protocol independent service handler techniques, software, date structures, methods and systems - Google Patents
Protocol independent service handler techniques, software, date structures, methods and systems Download PDFInfo
- Publication number
- CA2323376A1 CA2323376A1 CA002323376A CA2323376A CA2323376A1 CA 2323376 A1 CA2323376 A1 CA 2323376A1 CA 002323376 A CA002323376 A CA 002323376A CA 2323376 A CA2323376 A CA 2323376A CA 2323376 A1 CA2323376 A1 CA 2323376A1
- Authority
- CA
- Canada
- Prior art keywords
- request
- service
- name
- protocol
- computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/562—Brokering proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
Abstract
Software abstraction components provide a means for having service handlers which can provide services in response to a request received from a requestor in a particular protocol regardless of the particular protocol. A number of protocol proxies are capable of receiving requests, each protocol proxy only being able to receive a request in a particular protocol.
Upon receiving a request, a protocol proxy decomposes the request into its parameters and stores the parameters as name/value pairs in a data structure. A broker, another software component, has a list or register of non-protocol specific service handlers. The broker asks the service handlers, in a particular order, to consider the name/value pairs in the data structure. If a service handler refuses to handle the request as decomposed into name value pairs, the broker asks the next service handler. If a service handler accepts the request, the service handler performs the requested service and adds response data, if appropriate, to the data structure. If the response data is to be returned to the requestor, the protocol proxy translates the data into the original protocol and returns the translated data to the requestor.
Upon receiving a request, a protocol proxy decomposes the request into its parameters and stores the parameters as name/value pairs in a data structure. A broker, another software component, has a list or register of non-protocol specific service handlers. The broker asks the service handlers, in a particular order, to consider the name/value pairs in the data structure. If a service handler refuses to handle the request as decomposed into name value pairs, the broker asks the next service handler. If a service handler accepts the request, the service handler performs the requested service and adds response data, if appropriate, to the data structure. If the response data is to be returned to the requestor, the protocol proxy translates the data into the original protocol and returns the translated data to the requestor.
Description
Protocol Independent Service Handler Techniques, Software, Data Structures, Methods and Systems Field of the Invention The invention relates to software abstraction and is particularly concerned with software for handling requests.
Background of the Invention Network interconnected computing devices communicate through network protocols, which are agreed upon sets of rules.
Each protocol corresponds to a different set of rules. There are hundreds or more different protocols including HTTP, Jini, DCOM, MAPI, FTP, etc.
It is known that a request in a particular protocol from a first computing device can be targeted to a particular service of a second computing device that understands the protocol. Typically, a service is software code that performs a particular function and can only understand or process requests of a particular protocol. The request could be for an infinite number of possible services, such as, for example, a request for email, a request for a web page, a request for a cell phone application, a request for a document, etc.
In other words, a service for providing email functions for an HTTP protocol, for example, can only provide services for an HTTP request. Accordingly, a request for email from a different protocol, such as DCOM, for example, would have to be handled by a service specifically programmed for providing email services using the DCOM protocol.
In other words, historically, services have been programmed to handle requests of a single protocol only. This creates a complex system which is both difficult to build and costly to operate. As a result, when shared services such as security, logging and metrics collection, for example, are required by a system, their integration is complex and difficult to manage since each service can only provide a function in relation to a single protocol. More generally, if any particular type of new function is to be provided by a computing device, a separate service must be programmed for each of the different protocols which may make a request for the new function.
Swnnnary of the Invention According to a first aspect, the invention provides computer-readable medium containing instructions for implementing: a means for storing data, one or more software components (request receiving components) for receiving requests, each request receiving component for receiving a request of a different protocol, and after receiving a request from a requestor in an original protocol, a request receiving component decomposing the request into its parameters and storing the parameters in the means for storing data; a software component (the querying component), the querying component for querying service handlers in a particular order, to find a service handler to volunteer to handle the request;
one or more non-protocol specific service handler software components (service handlers), each service handler for performing a particular service, and after receiving a query from the querying component, a service handler considers the parameters in the means for storing data and decides whether or not to volunteer to handle the request; and if the service handler volunteers to handle the request, the service handler performs the requested service; and if the service handler refuses to handle the request, then it informs the querying component.
Background of the Invention Network interconnected computing devices communicate through network protocols, which are agreed upon sets of rules.
Each protocol corresponds to a different set of rules. There are hundreds or more different protocols including HTTP, Jini, DCOM, MAPI, FTP, etc.
It is known that a request in a particular protocol from a first computing device can be targeted to a particular service of a second computing device that understands the protocol. Typically, a service is software code that performs a particular function and can only understand or process requests of a particular protocol. The request could be for an infinite number of possible services, such as, for example, a request for email, a request for a web page, a request for a cell phone application, a request for a document, etc.
In other words, a service for providing email functions for an HTTP protocol, for example, can only provide services for an HTTP request. Accordingly, a request for email from a different protocol, such as DCOM, for example, would have to be handled by a service specifically programmed for providing email services using the DCOM protocol.
In other words, historically, services have been programmed to handle requests of a single protocol only. This creates a complex system which is both difficult to build and costly to operate. As a result, when shared services such as security, logging and metrics collection, for example, are required by a system, their integration is complex and difficult to manage since each service can only provide a function in relation to a single protocol. More generally, if any particular type of new function is to be provided by a computing device, a separate service must be programmed for each of the different protocols which may make a request for the new function.
Swnnnary of the Invention According to a first aspect, the invention provides computer-readable medium containing instructions for implementing: a means for storing data, one or more software components (request receiving components) for receiving requests, each request receiving component for receiving a request of a different protocol, and after receiving a request from a requestor in an original protocol, a request receiving component decomposing the request into its parameters and storing the parameters in the means for storing data; a software component (the querying component), the querying component for querying service handlers in a particular order, to find a service handler to volunteer to handle the request;
one or more non-protocol specific service handler software components (service handlers), each service handler for performing a particular service, and after receiving a query from the querying component, a service handler considers the parameters in the means for storing data and decides whether or not to volunteer to handle the request; and if the service handler volunteers to handle the request, the service handler performs the requested service; and if the service handler refuses to handle the request, then it informs the querying component.
According to another aspect, the invention provides a computer-readable medium storing computer software and data that when loaded by a computing device facilitates handling of requests by non-protocol specific service handlers by the computing device comprising: a data structure for storing data;
one or more software components (request receiving components), each request receiving component for receiving requests of a different protocol, and upon receiving a request from a requestor in an original protocol, a request receiving component decomposing the request into its parameters and storing the parameters in the data structure for storing data;
a software component(a querying component) for querying non-protocol specific service handlers, the querying component querying service handlers in a particular order, to find a service handler to volunteer to handle the request as decomposed into its parameters in the data structure for storing data.
According to yet another aspect, the invention provides computer readable medium storing computer software and data that when loaded by a computing device defines an object oriented object for implementation by the computing device in an object oriented framework comprising a data structure for storing name/value pairs for use in processing requests to software components (request receiving components) for receiving requests by non-protocol specific service handlers, wherein the name/value pairs correspond to parameters in a request received by a request receiving component, each name identifying a corresponding parameter, the name/value pairs being incorporated within one of a hash table, a map and a dictionary.
According to yet another aspect, the invention provides a computer-readable medium storing computer software and data that when loaded by a computing device facilitates handling of requests by non-protocol specific service handlers by the computing device, the request having been decomposed into its parameters and stored in a data structure for storing data, the computer software and data comprising: a software component (a querying component) for querying non-protocol specific service handlers, the querying component querying service handlers in a particular order, to find a service handler to volunteer to handle the request as decomposed into its parameters in the data structure for storing data.
Advantageously, different embodiments of the present invention may permit:
~ reducing the complexity of the design and implementation of systems which provide multiple services for multiple network protocols;
~ reducing the number of implementations of executable code that have to understand a particular protocol;
~ allowing greater flexibility in system configuration and operation by treating all service requests as events in a standardized format;
~ reducing the time required for new application development of a multi-protocol, multi-service application;
~ providing an ability to manage multi-protocol, multi-service applications centrally, thereby allowing holistic security, metrics collection, and auditing capabilities to be implemented;
~ allowing rapid integration of aging applications into new systems where new protocols are to be supported;
~ allowing legacy protocols to utilize the functionality of new services with minimum effort.
one or more software components (request receiving components), each request receiving component for receiving requests of a different protocol, and upon receiving a request from a requestor in an original protocol, a request receiving component decomposing the request into its parameters and storing the parameters in the data structure for storing data;
a software component(a querying component) for querying non-protocol specific service handlers, the querying component querying service handlers in a particular order, to find a service handler to volunteer to handle the request as decomposed into its parameters in the data structure for storing data.
According to yet another aspect, the invention provides computer readable medium storing computer software and data that when loaded by a computing device defines an object oriented object for implementation by the computing device in an object oriented framework comprising a data structure for storing name/value pairs for use in processing requests to software components (request receiving components) for receiving requests by non-protocol specific service handlers, wherein the name/value pairs correspond to parameters in a request received by a request receiving component, each name identifying a corresponding parameter, the name/value pairs being incorporated within one of a hash table, a map and a dictionary.
According to yet another aspect, the invention provides a computer-readable medium storing computer software and data that when loaded by a computing device facilitates handling of requests by non-protocol specific service handlers by the computing device, the request having been decomposed into its parameters and stored in a data structure for storing data, the computer software and data comprising: a software component (a querying component) for querying non-protocol specific service handlers, the querying component querying service handlers in a particular order, to find a service handler to volunteer to handle the request as decomposed into its parameters in the data structure for storing data.
Advantageously, different embodiments of the present invention may permit:
~ reducing the complexity of the design and implementation of systems which provide multiple services for multiple network protocols;
~ reducing the number of implementations of executable code that have to understand a particular protocol;
~ allowing greater flexibility in system configuration and operation by treating all service requests as events in a standardized format;
~ reducing the time required for new application development of a multi-protocol, multi-service application;
~ providing an ability to manage multi-protocol, multi-service applications centrally, thereby allowing holistic security, metrics collection, and auditing capabilities to be implemented;
~ allowing rapid integration of aging applications into new systems where new protocols are to be supported;
~ allowing legacy protocols to utilize the functionality of new services with minimum effort.
Brief Description of the Drawings Preferred embodiments of the invention will now be described with reference to the attached drawings in which FIG 1 illustrates multiple network interconnected devices;
FIG 2 is a block diagram of the organization of computer memory of the devices of FIG 1;
FIG 3 is a block diagram illustrating a number of software components in accordance with an embodiment of the present invention;
FIG 4 is a flow chart describing steps carried out by the components of FIG 3;
FIG 5 is a representation of a sample HTTP request;
FIG 6a is an example of name/value pairs corresponding to the HTTP request of FIG 5;
FIG 6b is a representation of a service context corresponding to the HTTP request of FIG 5;
FIG 7 is a block diagram, similar to that shown in FIG 3, except with specific protocol proxies and specific handlers, in accordance with an embodiment of the present invention;
FIG 8 is sample pseudo code representing an algorithm implemented by the mail service handler of FIG 7, in accordance with an embodiment of the present invention;
FIG 9 is an example of the "value" that would have been added to a response element pursuant to the pseudo code of FIG 8;
FIG 2 is a block diagram of the organization of computer memory of the devices of FIG 1;
FIG 3 is a block diagram illustrating a number of software components in accordance with an embodiment of the present invention;
FIG 4 is a flow chart describing steps carried out by the components of FIG 3;
FIG 5 is a representation of a sample HTTP request;
FIG 6a is an example of name/value pairs corresponding to the HTTP request of FIG 5;
FIG 6b is a representation of a service context corresponding to the HTTP request of FIG 5;
FIG 7 is a block diagram, similar to that shown in FIG 3, except with specific protocol proxies and specific handlers, in accordance with an embodiment of the present invention;
FIG 8 is sample pseudo code representing an algorithm implemented by the mail service handler of FIG 7, in accordance with an embodiment of the present invention;
FIG 9 is an example of the "value" that would have been added to a response element pursuant to the pseudo code of FIG 8;
FIG 10 is an example of a response returned to a requestor by a protocol proxy of FIG 7;
FIG 11 is an example of how the response of FIG 10 may be implemented and may appear on a requestor~s monitor;
FIG 12 is a representative sample service handler interface, in accordance with an embodiment of the present invention.
Detailed Description FIG. 1 illustrates, by way of example, a digital computer network 20 including computing devices 22, 24 and 26.
Devices 22, 24 and 26 may, by way of example, be personal computers; mainframe computers; networking equipment such as routers, switches, frame relays; telephone switching equipment;
or the like. The network 20 may for example, be a wide area network, conforming to any of a number of known networking protocols including TCP/IP, IPX, Appletalk, WCP or the like.
Alternatively, the network 20 may be a local area network; a collection of interconnected smaller computer networks comprising an intranet or Internet; or a portion of the public Internet. As will be appreciated and as illustrated, network 20 may be interconnected with other networks such as the public Internet.
Computing devices 22, 24 and 26 are all network management devices that store network management data, among other things. Management of any of the network devices may be accomplished by access to one device 22, 24 or 26 by one of the other devices 22, 24 or 26, or other interconnected devices (not shown), in communication with network 20.
Each computing device 22, 24, and 26 comprises a processor interconnected with storage memory and a network interface. Additionally, each computing device may comprise an input/output peripheral capable of reading data from a computer readable storage medium, such as a floppy diskette, CD-ROM, tape or the like. The organization of memory of computing device 22 is illustrated in FIG. 2. The organization of memory of computing devices 24, and 26 is similar, but not illustrated. As shown, loaded within memory of each computing device is operational software, including preferably an operating system 32 network interface software 34; and application software 36. As will be appreciated, the operational software may be loaded from computer readable storage medium 28.
Operating system 32, may for example be a UNIX
operating system. Network interface software 34 typically comprises software allowing communication of device 22 with the remainder of the network 20 using one or more known network protocols. Network interface software 34 may, for example, be an Internet protocol suite, and could optionally form part of operating system 32. Application software 36 typically comprises software that in combination with operating system 32, provides other desired functionality of devices 22, 24 and 26.
In a distributed system, certain software and/or hardware is considered as server-side components and other software and/or hardware is considered as client-side components. For the purpose of the following description and examples, the client-side components will be considered to be resident on the device 24 and the server-side components will be considered to be resident on device 22. It is also possible that both the server-side components and the client-side components could be located on the same device 22, 24 or 26.
FIG 11 is an example of how the response of FIG 10 may be implemented and may appear on a requestor~s monitor;
FIG 12 is a representative sample service handler interface, in accordance with an embodiment of the present invention.
Detailed Description FIG. 1 illustrates, by way of example, a digital computer network 20 including computing devices 22, 24 and 26.
Devices 22, 24 and 26 may, by way of example, be personal computers; mainframe computers; networking equipment such as routers, switches, frame relays; telephone switching equipment;
or the like. The network 20 may for example, be a wide area network, conforming to any of a number of known networking protocols including TCP/IP, IPX, Appletalk, WCP or the like.
Alternatively, the network 20 may be a local area network; a collection of interconnected smaller computer networks comprising an intranet or Internet; or a portion of the public Internet. As will be appreciated and as illustrated, network 20 may be interconnected with other networks such as the public Internet.
Computing devices 22, 24 and 26 are all network management devices that store network management data, among other things. Management of any of the network devices may be accomplished by access to one device 22, 24 or 26 by one of the other devices 22, 24 or 26, or other interconnected devices (not shown), in communication with network 20.
Each computing device 22, 24, and 26 comprises a processor interconnected with storage memory and a network interface. Additionally, each computing device may comprise an input/output peripheral capable of reading data from a computer readable storage medium, such as a floppy diskette, CD-ROM, tape or the like. The organization of memory of computing device 22 is illustrated in FIG. 2. The organization of memory of computing devices 24, and 26 is similar, but not illustrated. As shown, loaded within memory of each computing device is operational software, including preferably an operating system 32 network interface software 34; and application software 36. As will be appreciated, the operational software may be loaded from computer readable storage medium 28.
Operating system 32, may for example be a UNIX
operating system. Network interface software 34 typically comprises software allowing communication of device 22 with the remainder of the network 20 using one or more known network protocols. Network interface software 34 may, for example, be an Internet protocol suite, and could optionally form part of operating system 32. Application software 36 typically comprises software that in combination with operating system 32, provides other desired functionality of devices 22, 24 and 26.
In a distributed system, certain software and/or hardware is considered as server-side components and other software and/or hardware is considered as client-side components. For the purpose of the following description and examples, the client-side components will be considered to be resident on the device 24 and the server-side components will be considered to be resident on device 22. It is also possible that both the server-side components and the client-side components could be located on the same device 22, 24 or 26.
FIG 3 illustrates a block diagram of server-side software components. As shown in FIG 3, a broker 40, which is a software component, is conceptually in the center, with different protocol proxies 42, 44, 46 on the left of the broker 40 and different non-protocol specific service handlers 50, 52, 54 on the right of the broker 40. A data structure, namely a service context 56 is shown. All the protocol proxies 42-46, the broker 40 and all the service handlers 50-54 are able to interact with the service context 56. The protocol proxies 42, 44, 46, the broker 40 and the service handlers 50, 52, 54 form part of the application software 36 of computing device 22 (FIG 2). A request 60 is shown as an input to the protocol proxy 44 and a response 62 is shown as an output from the protocol proxy 44.
Each of the protocol proxies 42, 44, 46 represents software code or a software component for receiving requests 60 compliant with a particular protocol, and then decomposing the request 60 into elements and storing the elements in the service context 56. The service context 56 is a means or a data structure for storing data. The broker 40 (which may also be referred to as a querying component) is software code or a software component for finding a service handler 50, 52, 54 to provide a service based upon the request 60 as represented by the elements in the service context 56. Each of the service handlers 50, 52, 54 represents software code for performing a different service in response to a request 60.
Each of the components 40-56 in FIG 3 will be considered in the context of the flow chart of FIG 4, which illustrates high level steps performed by the components 40-56 of FIG 3. At step 70, a request 60 is received by a particular protocol proxy (namely protocol proxy 44, in this example) from a requestor 63. The requestor 63 could be a client device 24 (FIG 1) or the executable software code (not shown), for example, on the server device 22. The client device 24 or the executable code directs the request 60 to a specific protocol proxy 42, 44, 46, in a manner known to those skilled in the art. The request 60 could, in theory, be a request for any of a virtually infinite number of possible services, such as, for example, receiving an email message, receiving a web page, looking up a telephone number in a database, etc.
The protocol proxy 44 may be considered as a protocol abstraction layer. At step 72 of FIG 4, after the request 60 is received by the protocol proxy 44, the request 60 is decomposed into its atomic elements or parameters, in name/value pairs 74, as appropriate. Because each protocol is a set of rules, each protocol proxy 42-46 is aware of the syntax and content rules applicable to a request of a particular protocol. Accordingly, each protocol proxy 42-46 will decompose a request 60 in a different manner.
FIGS 5 and 6a provide an example of how a particular request 60 may be decomposed into atomic elements, in name/value pairs 74. FIG 5 is a representation of an HTTP
request 60, showing sample data that might be contained in the HTTP request. (FIG 5 is a representation of an HTTP request because a verbatim copy of an HTTP request would not be understandable to a typical human reader.) An example of the name/value pairs 74 extracted from the HTTP request of FIG 5 is shown in FIG 6a.
In the example of FIG 6a, the name "url" is paired with the value "HTTP://www.servidium.com/mail net"; the name "user-id" is paired with the value "joe", etc. More specifically, a protocol proxy 42-46 receiving the request 60 understands the associated protocol, as noted above, and will therefore know how to properly decompose a request 60 into name/value pairs 74. Accordingly, with respect to the example name/value pairs 74 of FIG 6a, the protocol proxy 42-46 adds a name "url". (The term "url" does not appear in the request 60.
Therefore, in this example, the protocol proxy 42-46 adds the term "url" as a name to the name/value pairs 74.) The name "url" is paired with the url listed in the request 60, namely "HTTP://www.servidium.com/mail net". The protocol proxy 42-46 will then recognize the terms "msg id" and "user id" in the query string from the HTTP header shown in FIG 5, and add "msg_id" and "user-id" as names within the name/value pairs 74.
The names "msg-id" and "user_id" are paired with their associated values, which are the terms on the right side of the equals signs ("_"), namely "joe" and "1234", respectively. The remaining parameters or components of the request 60 are decomposed into name/value pairs 74 in a similar manner. Many different parsing or decomposing methods could be used and are known to those skilled in the art.
The service context 56 is a software object that has the ability to store name/value pairs and which resides in memory. The service context 56 could be implemented as any one of a number of data structures such as a dictionary, a hash table or a map, for example.
In cases where a requestor 63 may make several requests 60, it may be efficient to determine if the request 60 is being made by a requestor 63 who had previous requests 60 handled. Therefore, it is preferable to assign each requestor 63 a unique identifier. If that requestor 63 had made a previous request 60, then a service context 56 may already exist for that requestor. In that case, the name/value pairs 74 could be stored in an existing service context 56, as shown at steps 76 and 78. If at step 76 it is determined that no service context 56 exists for the requestor 63, then at step 80, the protocol proxy 44 creates a new service context 56, and the name/value pairs 74 are stored in the service context 56 at step 78. A new service context 56 could be created in a large number of ways known to those skilled in the art. In object oriented programming terms, to create a service context 56, a server context object (not shown) could be instantiated.
When the name/value pairs 74 are stored in the service context 56, the protocol proxy 44 could add other information to the service context 56 as well. An example of possible additional information that the protocol proxy 44 could store in the service context 56 is shown in FIG 6b, which is a representation of a sample service context 56. The information in the service context 56 is stored as name/value pairs, with the name being on the left of the equals sign ("_°) and the value being on the right, in this example. The data shown under the heading "Request Elements" is data from the name/value pairs 74 of FIG 6a. The protocol proxy 44, in this example, has added the additional headings "Protocol specifics", "State Information" and "Response Elements". An actual service context 56 may or may not use actual headings, as appropriate.
The data under "Protocol specifics" is simply the type of protocol, which the protocol proxy 44 may add to all service contexts 56 it creates. There could be other types of information that could be listed under "Protocol specifics"
depending upon the protocol. For example, a port (not shown) that the request 60 came on could also be added, etc. The data under "State information" is "session id=1". This means that the request 60 is (or is being treated as) the first request 60 from this particular requestor 63. Other information could also be listed under "State information", such as, for example, the time of day that the service context 56 was created, etc.
The name/value pairs under the heading "Response Elements" 79 would likely be missing when the service context 56 is created.
The data under "Response Elements" 79 is preferably added later by a service handler 50-54 as described below.
The broker 40 acts as a central controller between the proxy protocols 42-46 and the service handlers 50-54. The broker either maintains a list or register (not shown) of all of the service handlers 50-54 or else has access to a file or other object (not shown), for example, that contains a list or register of the service handlers 50-54.
At step 84, the broker 40 queries the service handlers 50-54 in a particular order, to determine if one will accept the request 60 and provide the requested service. There are a number of possible strategies that the broker 40 could use to determine the order of querying the service handlers 50-54. For example, the service handlers 50-54 would have been added to a list or register in a particular order. The broker 40 could query the service handlers 50-54 in the same order as they were added to the list or register. This would be a first-in-first-out (FIFO) order. Alternatively, the broker 40 could query the service handlers 50-54 starting with the last one added to the list or register and work backwards. This would be a last-in-first-out order. Alternatively, a developer-defined priority strategy could be used, where the developer, during the creation of the service handlers 50-54, assigns a priority value to each service handler 50-54. In this scenario, the broker 40 queries the service handlers 50-54 in an order determined by their priority values.
For each service handler 50-54 queried by the broker 40, the broker 40 asks the service handler 50-54 to consider the service context 56. Possibly considering the data in the service context 56, the service handler 50-54 determines whether or not it will accept the request 60. Because the request 60 has been broken down into name/value pairs 74, it is not necessary for the service handler 50-54 to understand any particular protocol to consider the request 60 as decomposed into name/value pairs 74 (or to provide the requested service).
A service handler 50-54 will have one or more criteria for determining whether or not to accept a request 60. For example, possible criteria that a service handler 50-54 may consider to determine whether or not to accept a request include: protocol type, the time of day, a particular name or value in the name/value pairs 74, user/role information, the availability of the service handler 50-54, etc.
At step 86 of FIG 4, if the first service handler 50-54 to be queried refuses the request 60, the service handler 50-54 provides a response to the broker 40 indicating that it has refused the request. At step 84, the broker 40 then queries the next service handler 40.
At step 86, if a service handler 50-54 accepts a request 60, then at step 90, the service handler 50-54 performs the requested service, using any required information from the service context 56. If the requested service does not require that information be returned to the requester, then the service handler 50-54 will preferably perform the service. If the service involves returning information to the requester 63, then the requested information would be added to the service context 56. For example, if the request 60 is for a message, then the service handler 50-54 may add one or more response elements 81, which response elements 81 are name/value pairs, to the service context 56 in the Response Elements section 79.
The value of a response element 81 will preferably be a software object in memory that may contain data, a string, text, etc. For example, the response elements 81 may be a name/value pairs such as:
"output" / <streamed date>
where the streamed data is the contents of the message. (The response elements could incorporate an infinite number of different name/value pairs. For example, a response element 81 could be of the form:
"boolean" / "true"
or it could be of the form:
"status"/ "service performed".
The contents of the response elements 81 depend upon a set of rules agreed upon by the protocol proxies 42-46 and the service handlers 50-54. Accordingly, the protocol proxies 42-46 may be programmed to understand that the term "output" means that the associated value is to be returned to the requestor 63.
Similarly, the protocol proxies 42-46 may be programmed to understand that if the name is "status" and the value is "service performed" then nothing need be returned to the requestor 63, because the service handler 50-54 would have already performed the requested service.
It is possible that a request 60 could be handled or processed or considered by more than a single service handler 50-54. For example, a logging service handler (not shown) may be used to compile statistics relating to every request 60. In that case, the logging service handler would want to "handle"
the request 60 but it would not actually perform the requested service. Accordingly, at step 93 of FIG 4, the logging service handler may "handle" the request 60 but, in this example, may also send a response to the broker 40 indicating that it is refusing the request 60 so that the broker 40 will query the remaining service handlers 50-54. Alternatively, the logging service handler may be able to provide a response (not shown) to the broker 40 other than a refusal indicating that the logging service handler has processed the request 60 to an extent, but also wants the broker 40 to continue to query the other service handlers 50-54.
At step 94, the protocol proxy 44 considers the response elements 81 and reacts accordingly. For example, as noted above, upon seeing the name "output" in a response element 81 stored in the service context 56, the protocol proxy 44, in this example, would know to return the streamed data to the requestor 63. If it is necessary for the response 62 to correspond to a particular protocol, then the protocol proxy 44 would translate or modify the streamed data to comply with the protocol.
As noted above, for some requests 60, the requestor 63 expects to receive a response 62, and at other times, the requestor may not expect to receive a response. For example, sometimes a requestor 63 who sends an email message wants confirmation that the message was sent. At other times, the requestor 63 does not want to be notified that the message was sent. Accordingly, at step 96, the protocol proxy 44 sends a response 62 to the requestor 63 only if appropriate.
FIG 7 is a block diagram similar to FIG 3, but with specific protocol proxies 100-104 and specific service handlers 106-110. The particular protocol proxies 100-104 and the particular service handlers 106-110 shown in FIG 7 are used for example purposes. Any protocol proxies and any service handlers could be used. In this example, protocol proxy 100 is a Jini proxy (hereinafter the "Jini proxy 100"), protocol proxy 102 is an HTTP proxy (hereinafter the "HTTP proxy 102") and protocol 104 is a DCOM proxy (hereinafter the "DCOM proxy 104"). Service handler 106 is a template service handler (hereinafter the "template service handler 106"), which, for example, may merge different input data sources into a single output. Service handler 108 is a mail service handler for returning email messages (hereinafter the "mail service handler 108"). Service handler 110 is a document service handler for returning contents of a document (hereinafter the "document service handler 110").
In this example, the request 60 as shown in FIG 5, and as described above is sent to the HTTP proxy 102. The HTTP
proxy 102 extracts the parameters of the request 60 and stores them as name/value pairs 74 as shown in FIG 6a, and as described above. The HTTP proxy 102 then considers if a service context 56 already exists for this request. For the purpose of this example, it will be assumed that a service context 56 does not already exist. Accordingly, the HTTP proxy 102 creates a service context 56 and stores the name/value pairs 74 in it under the heading "Request Elements", in this example. As well, as noted above and as shown in FIG 6b, the HTTP proxy 102 may add a name/value pair such as:
"session id"/ "1"
which signifies that the request 60 has been assigned a session identification of 1. Therefore, a subsequent request from the same requestor 63 could conceivably be appended or added to the already existing content of the service context 56.
The broker 40 then queries the service handlers 106-110 for a volunteer to handle the request 60. For this example, the broker 40 considers the service handlers from top to bottom as shown in FIG 7.
The broker 40 first queries the template service handler 106. In this example, the template service handler 106 refuses to accept the request and informs the broker 40 accordingly. For example, the template service handler 106 may only accept requests 60 where the service context 56 includes a name/value pair having a name "template"
The broker 40 then queries the mail service handler 108. Sample pseudo code (ie: partially complete code written in the Java programming language), representing an algorithm implemented by the mail service handler is shown in FIG 8. In this example, the mail service handler 108 considers the name/value pairs 74 in the service context 56 and extracts the associated value of the "url". As shown in the pseudo code of FIG 8, the mail service handler 108 will only accept requests where the url ends with "mail net". Because the url in this example ends with "mail net", the mail service handler 108 accepts the request.
The mail service handler 108 then obtains the requested email message using the values associated with the names "user_id" and "msg-id". Pseudo code representing an algorithm used by the mail service handler to obtain the requested email message is shown in FIG 8. As suggested in the pseudo code of FIG 8, when the requested email message has been obtained, it is added as a response element 81 to the service context 56. FIG 9 represents the "value" that would have been added as part of the response element 81, which represents the requested email message.
The HTTP proxy 102 then considers the response elements 81 stored in the service context 56 and translates the email message into its native protocol, which in this case is HTTP. The email message, converted into the HTTP protocol is then returned to the requestor 63. An example of the response 62 received by the requestor is shown in FIG 10.
An example of how the response 62 of FIG 10 may be implemented and how it may appear on the requestor's monitor is shown in FIG 11.
The service handlers 106-110 (or the service handlers 50-54) could be created by the same developers and/or included within the same software package or application as the protocol proxies 100-104 and the broker 40. Alternatively, any of the service handlers 106-110 could be added later, by any developer. Each service handler 106-110 must be able to communicate with the protocol proxies 100-104 and the broker 40 and must also be able to access the service context 56 and preferably store response elements 81 in the service context 56. Accordingly, each of the service handlers 106-110 must have an agreed upon interface 111. FIG 12 is a representative sample interface 111, showing partially complete software code written in the Java programming language. The interface 111 in this example returns the boolean "true" to the broker 40 if it handles the request 60 as decomposed in the service context 56 and returns "false" otherwise. An example of a representative implementation of an interface 111 is shown in FIG 8, which, as described above, is sample pseudo code representing the mail service handler 108.
As noted above, the service handlers 50-54 (or the service handlers 106-110) could be added at any time by a developer. Similarly, the protocol proxies 42-46 (or the protocol proxies 100-104) could be created by the same developers and/or included within the same software package as the broker 40 or alternatively, some or all of the protocol proxies 42-46 could be added later, by any developer. To create a protocol proxy 42-46, a developer may create a piece of software for performing the following functions: a protocol proxy 42-46 would be able to receive a request 60 from a requestor 63 in a particular protocol; it would decompose the request 60 into name/value pairs 74; it would either create a service context 56 or add the name/value pairs 74 to an existing service context 56, as appropriate; it would pass the service context 56 to the broker 40; it would consider the response elements 81 in the service context 56 after the request 60 has been handled by a service handler 50-54; it would "translate" the values in the name/value pairs of the response elements 81 into the original protocol, if appropriate (eg: if a name in the response elements indicates that the associated value is to be returned to the requestor 63) and return data (translated into the original protocol, if appropriate) to the requestor 63, if appropriate.
When a new service handler 50-54 is created, the new service handler 50-54 would be added to the list or register of service handlers (not shown) maintained by the broker 40.
Accordingly, the new service handler 50-54 would either have to call a method on the broker 40, for example, to add itself to the list or else use one of a number of techniques known to those skilled in the art.
As suggested above, the broker 40 could perform a number of additional functions relating to security, authorization, logging and metrics collection.
Numerous modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practised otherwise than as specifically described herein. For example, as described above, in one embodiment, the broker 40 queries each service handler 50-54 to find a volunteer. Alternatively, the broker 40 could query something other than the service handlers 50-54.
Further, as suggested above, a request 60 could be handled by more than one service handler 50-54.
For example, decision logic (not shown) for deciding whether a service handler 50-54 will handle a request 60 or not, can be divided into a separate software object (not shown) called a condition (not shown). A condition may apply to one or more service handlers 50-54.
When a service handler 50-54 registers itself with the broker 40, the service handler 50-54 also includes an associated condition.
When a request 60 is received by the broker 40, the broker 40 queries all of the registered conditions, passing them the service context 56. Based on the name/value pairs in the service context 56, a particular condition will either fire (accept the request) or not. A condition will fire if it finds data it requires in the name/value pairs of the service context 56. When a condition fires, the broker 40 delegates request 60 to one or more of the service handlers 50-54 that were registered with the broker 40 under the condition. Once all of the service handlers 50-54 that were registered with the broker 40 under the condition have been called by the broker 40 to handle the request 60, control passes back to the calling protocol proxy 42-46 as noted above, with the response elements 81 added to the service context 56, as appropriate.
Each of the protocol proxies 42, 44, 46 represents software code or a software component for receiving requests 60 compliant with a particular protocol, and then decomposing the request 60 into elements and storing the elements in the service context 56. The service context 56 is a means or a data structure for storing data. The broker 40 (which may also be referred to as a querying component) is software code or a software component for finding a service handler 50, 52, 54 to provide a service based upon the request 60 as represented by the elements in the service context 56. Each of the service handlers 50, 52, 54 represents software code for performing a different service in response to a request 60.
Each of the components 40-56 in FIG 3 will be considered in the context of the flow chart of FIG 4, which illustrates high level steps performed by the components 40-56 of FIG 3. At step 70, a request 60 is received by a particular protocol proxy (namely protocol proxy 44, in this example) from a requestor 63. The requestor 63 could be a client device 24 (FIG 1) or the executable software code (not shown), for example, on the server device 22. The client device 24 or the executable code directs the request 60 to a specific protocol proxy 42, 44, 46, in a manner known to those skilled in the art. The request 60 could, in theory, be a request for any of a virtually infinite number of possible services, such as, for example, receiving an email message, receiving a web page, looking up a telephone number in a database, etc.
The protocol proxy 44 may be considered as a protocol abstraction layer. At step 72 of FIG 4, after the request 60 is received by the protocol proxy 44, the request 60 is decomposed into its atomic elements or parameters, in name/value pairs 74, as appropriate. Because each protocol is a set of rules, each protocol proxy 42-46 is aware of the syntax and content rules applicable to a request of a particular protocol. Accordingly, each protocol proxy 42-46 will decompose a request 60 in a different manner.
FIGS 5 and 6a provide an example of how a particular request 60 may be decomposed into atomic elements, in name/value pairs 74. FIG 5 is a representation of an HTTP
request 60, showing sample data that might be contained in the HTTP request. (FIG 5 is a representation of an HTTP request because a verbatim copy of an HTTP request would not be understandable to a typical human reader.) An example of the name/value pairs 74 extracted from the HTTP request of FIG 5 is shown in FIG 6a.
In the example of FIG 6a, the name "url" is paired with the value "HTTP://www.servidium.com/mail net"; the name "user-id" is paired with the value "joe", etc. More specifically, a protocol proxy 42-46 receiving the request 60 understands the associated protocol, as noted above, and will therefore know how to properly decompose a request 60 into name/value pairs 74. Accordingly, with respect to the example name/value pairs 74 of FIG 6a, the protocol proxy 42-46 adds a name "url". (The term "url" does not appear in the request 60.
Therefore, in this example, the protocol proxy 42-46 adds the term "url" as a name to the name/value pairs 74.) The name "url" is paired with the url listed in the request 60, namely "HTTP://www.servidium.com/mail net". The protocol proxy 42-46 will then recognize the terms "msg id" and "user id" in the query string from the HTTP header shown in FIG 5, and add "msg_id" and "user-id" as names within the name/value pairs 74.
The names "msg-id" and "user_id" are paired with their associated values, which are the terms on the right side of the equals signs ("_"), namely "joe" and "1234", respectively. The remaining parameters or components of the request 60 are decomposed into name/value pairs 74 in a similar manner. Many different parsing or decomposing methods could be used and are known to those skilled in the art.
The service context 56 is a software object that has the ability to store name/value pairs and which resides in memory. The service context 56 could be implemented as any one of a number of data structures such as a dictionary, a hash table or a map, for example.
In cases where a requestor 63 may make several requests 60, it may be efficient to determine if the request 60 is being made by a requestor 63 who had previous requests 60 handled. Therefore, it is preferable to assign each requestor 63 a unique identifier. If that requestor 63 had made a previous request 60, then a service context 56 may already exist for that requestor. In that case, the name/value pairs 74 could be stored in an existing service context 56, as shown at steps 76 and 78. If at step 76 it is determined that no service context 56 exists for the requestor 63, then at step 80, the protocol proxy 44 creates a new service context 56, and the name/value pairs 74 are stored in the service context 56 at step 78. A new service context 56 could be created in a large number of ways known to those skilled in the art. In object oriented programming terms, to create a service context 56, a server context object (not shown) could be instantiated.
When the name/value pairs 74 are stored in the service context 56, the protocol proxy 44 could add other information to the service context 56 as well. An example of possible additional information that the protocol proxy 44 could store in the service context 56 is shown in FIG 6b, which is a representation of a sample service context 56. The information in the service context 56 is stored as name/value pairs, with the name being on the left of the equals sign ("_°) and the value being on the right, in this example. The data shown under the heading "Request Elements" is data from the name/value pairs 74 of FIG 6a. The protocol proxy 44, in this example, has added the additional headings "Protocol specifics", "State Information" and "Response Elements". An actual service context 56 may or may not use actual headings, as appropriate.
The data under "Protocol specifics" is simply the type of protocol, which the protocol proxy 44 may add to all service contexts 56 it creates. There could be other types of information that could be listed under "Protocol specifics"
depending upon the protocol. For example, a port (not shown) that the request 60 came on could also be added, etc. The data under "State information" is "session id=1". This means that the request 60 is (or is being treated as) the first request 60 from this particular requestor 63. Other information could also be listed under "State information", such as, for example, the time of day that the service context 56 was created, etc.
The name/value pairs under the heading "Response Elements" 79 would likely be missing when the service context 56 is created.
The data under "Response Elements" 79 is preferably added later by a service handler 50-54 as described below.
The broker 40 acts as a central controller between the proxy protocols 42-46 and the service handlers 50-54. The broker either maintains a list or register (not shown) of all of the service handlers 50-54 or else has access to a file or other object (not shown), for example, that contains a list or register of the service handlers 50-54.
At step 84, the broker 40 queries the service handlers 50-54 in a particular order, to determine if one will accept the request 60 and provide the requested service. There are a number of possible strategies that the broker 40 could use to determine the order of querying the service handlers 50-54. For example, the service handlers 50-54 would have been added to a list or register in a particular order. The broker 40 could query the service handlers 50-54 in the same order as they were added to the list or register. This would be a first-in-first-out (FIFO) order. Alternatively, the broker 40 could query the service handlers 50-54 starting with the last one added to the list or register and work backwards. This would be a last-in-first-out order. Alternatively, a developer-defined priority strategy could be used, where the developer, during the creation of the service handlers 50-54, assigns a priority value to each service handler 50-54. In this scenario, the broker 40 queries the service handlers 50-54 in an order determined by their priority values.
For each service handler 50-54 queried by the broker 40, the broker 40 asks the service handler 50-54 to consider the service context 56. Possibly considering the data in the service context 56, the service handler 50-54 determines whether or not it will accept the request 60. Because the request 60 has been broken down into name/value pairs 74, it is not necessary for the service handler 50-54 to understand any particular protocol to consider the request 60 as decomposed into name/value pairs 74 (or to provide the requested service).
A service handler 50-54 will have one or more criteria for determining whether or not to accept a request 60. For example, possible criteria that a service handler 50-54 may consider to determine whether or not to accept a request include: protocol type, the time of day, a particular name or value in the name/value pairs 74, user/role information, the availability of the service handler 50-54, etc.
At step 86 of FIG 4, if the first service handler 50-54 to be queried refuses the request 60, the service handler 50-54 provides a response to the broker 40 indicating that it has refused the request. At step 84, the broker 40 then queries the next service handler 40.
At step 86, if a service handler 50-54 accepts a request 60, then at step 90, the service handler 50-54 performs the requested service, using any required information from the service context 56. If the requested service does not require that information be returned to the requester, then the service handler 50-54 will preferably perform the service. If the service involves returning information to the requester 63, then the requested information would be added to the service context 56. For example, if the request 60 is for a message, then the service handler 50-54 may add one or more response elements 81, which response elements 81 are name/value pairs, to the service context 56 in the Response Elements section 79.
The value of a response element 81 will preferably be a software object in memory that may contain data, a string, text, etc. For example, the response elements 81 may be a name/value pairs such as:
"output" / <streamed date>
where the streamed data is the contents of the message. (The response elements could incorporate an infinite number of different name/value pairs. For example, a response element 81 could be of the form:
"boolean" / "true"
or it could be of the form:
"status"/ "service performed".
The contents of the response elements 81 depend upon a set of rules agreed upon by the protocol proxies 42-46 and the service handlers 50-54. Accordingly, the protocol proxies 42-46 may be programmed to understand that the term "output" means that the associated value is to be returned to the requestor 63.
Similarly, the protocol proxies 42-46 may be programmed to understand that if the name is "status" and the value is "service performed" then nothing need be returned to the requestor 63, because the service handler 50-54 would have already performed the requested service.
It is possible that a request 60 could be handled or processed or considered by more than a single service handler 50-54. For example, a logging service handler (not shown) may be used to compile statistics relating to every request 60. In that case, the logging service handler would want to "handle"
the request 60 but it would not actually perform the requested service. Accordingly, at step 93 of FIG 4, the logging service handler may "handle" the request 60 but, in this example, may also send a response to the broker 40 indicating that it is refusing the request 60 so that the broker 40 will query the remaining service handlers 50-54. Alternatively, the logging service handler may be able to provide a response (not shown) to the broker 40 other than a refusal indicating that the logging service handler has processed the request 60 to an extent, but also wants the broker 40 to continue to query the other service handlers 50-54.
At step 94, the protocol proxy 44 considers the response elements 81 and reacts accordingly. For example, as noted above, upon seeing the name "output" in a response element 81 stored in the service context 56, the protocol proxy 44, in this example, would know to return the streamed data to the requestor 63. If it is necessary for the response 62 to correspond to a particular protocol, then the protocol proxy 44 would translate or modify the streamed data to comply with the protocol.
As noted above, for some requests 60, the requestor 63 expects to receive a response 62, and at other times, the requestor may not expect to receive a response. For example, sometimes a requestor 63 who sends an email message wants confirmation that the message was sent. At other times, the requestor 63 does not want to be notified that the message was sent. Accordingly, at step 96, the protocol proxy 44 sends a response 62 to the requestor 63 only if appropriate.
FIG 7 is a block diagram similar to FIG 3, but with specific protocol proxies 100-104 and specific service handlers 106-110. The particular protocol proxies 100-104 and the particular service handlers 106-110 shown in FIG 7 are used for example purposes. Any protocol proxies and any service handlers could be used. In this example, protocol proxy 100 is a Jini proxy (hereinafter the "Jini proxy 100"), protocol proxy 102 is an HTTP proxy (hereinafter the "HTTP proxy 102") and protocol 104 is a DCOM proxy (hereinafter the "DCOM proxy 104"). Service handler 106 is a template service handler (hereinafter the "template service handler 106"), which, for example, may merge different input data sources into a single output. Service handler 108 is a mail service handler for returning email messages (hereinafter the "mail service handler 108"). Service handler 110 is a document service handler for returning contents of a document (hereinafter the "document service handler 110").
In this example, the request 60 as shown in FIG 5, and as described above is sent to the HTTP proxy 102. The HTTP
proxy 102 extracts the parameters of the request 60 and stores them as name/value pairs 74 as shown in FIG 6a, and as described above. The HTTP proxy 102 then considers if a service context 56 already exists for this request. For the purpose of this example, it will be assumed that a service context 56 does not already exist. Accordingly, the HTTP proxy 102 creates a service context 56 and stores the name/value pairs 74 in it under the heading "Request Elements", in this example. As well, as noted above and as shown in FIG 6b, the HTTP proxy 102 may add a name/value pair such as:
"session id"/ "1"
which signifies that the request 60 has been assigned a session identification of 1. Therefore, a subsequent request from the same requestor 63 could conceivably be appended or added to the already existing content of the service context 56.
The broker 40 then queries the service handlers 106-110 for a volunteer to handle the request 60. For this example, the broker 40 considers the service handlers from top to bottom as shown in FIG 7.
The broker 40 first queries the template service handler 106. In this example, the template service handler 106 refuses to accept the request and informs the broker 40 accordingly. For example, the template service handler 106 may only accept requests 60 where the service context 56 includes a name/value pair having a name "template"
The broker 40 then queries the mail service handler 108. Sample pseudo code (ie: partially complete code written in the Java programming language), representing an algorithm implemented by the mail service handler is shown in FIG 8. In this example, the mail service handler 108 considers the name/value pairs 74 in the service context 56 and extracts the associated value of the "url". As shown in the pseudo code of FIG 8, the mail service handler 108 will only accept requests where the url ends with "mail net". Because the url in this example ends with "mail net", the mail service handler 108 accepts the request.
The mail service handler 108 then obtains the requested email message using the values associated with the names "user_id" and "msg-id". Pseudo code representing an algorithm used by the mail service handler to obtain the requested email message is shown in FIG 8. As suggested in the pseudo code of FIG 8, when the requested email message has been obtained, it is added as a response element 81 to the service context 56. FIG 9 represents the "value" that would have been added as part of the response element 81, which represents the requested email message.
The HTTP proxy 102 then considers the response elements 81 stored in the service context 56 and translates the email message into its native protocol, which in this case is HTTP. The email message, converted into the HTTP protocol is then returned to the requestor 63. An example of the response 62 received by the requestor is shown in FIG 10.
An example of how the response 62 of FIG 10 may be implemented and how it may appear on the requestor's monitor is shown in FIG 11.
The service handlers 106-110 (or the service handlers 50-54) could be created by the same developers and/or included within the same software package or application as the protocol proxies 100-104 and the broker 40. Alternatively, any of the service handlers 106-110 could be added later, by any developer. Each service handler 106-110 must be able to communicate with the protocol proxies 100-104 and the broker 40 and must also be able to access the service context 56 and preferably store response elements 81 in the service context 56. Accordingly, each of the service handlers 106-110 must have an agreed upon interface 111. FIG 12 is a representative sample interface 111, showing partially complete software code written in the Java programming language. The interface 111 in this example returns the boolean "true" to the broker 40 if it handles the request 60 as decomposed in the service context 56 and returns "false" otherwise. An example of a representative implementation of an interface 111 is shown in FIG 8, which, as described above, is sample pseudo code representing the mail service handler 108.
As noted above, the service handlers 50-54 (or the service handlers 106-110) could be added at any time by a developer. Similarly, the protocol proxies 42-46 (or the protocol proxies 100-104) could be created by the same developers and/or included within the same software package as the broker 40 or alternatively, some or all of the protocol proxies 42-46 could be added later, by any developer. To create a protocol proxy 42-46, a developer may create a piece of software for performing the following functions: a protocol proxy 42-46 would be able to receive a request 60 from a requestor 63 in a particular protocol; it would decompose the request 60 into name/value pairs 74; it would either create a service context 56 or add the name/value pairs 74 to an existing service context 56, as appropriate; it would pass the service context 56 to the broker 40; it would consider the response elements 81 in the service context 56 after the request 60 has been handled by a service handler 50-54; it would "translate" the values in the name/value pairs of the response elements 81 into the original protocol, if appropriate (eg: if a name in the response elements indicates that the associated value is to be returned to the requestor 63) and return data (translated into the original protocol, if appropriate) to the requestor 63, if appropriate.
When a new service handler 50-54 is created, the new service handler 50-54 would be added to the list or register of service handlers (not shown) maintained by the broker 40.
Accordingly, the new service handler 50-54 would either have to call a method on the broker 40, for example, to add itself to the list or else use one of a number of techniques known to those skilled in the art.
As suggested above, the broker 40 could perform a number of additional functions relating to security, authorization, logging and metrics collection.
Numerous modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practised otherwise than as specifically described herein. For example, as described above, in one embodiment, the broker 40 queries each service handler 50-54 to find a volunteer. Alternatively, the broker 40 could query something other than the service handlers 50-54.
Further, as suggested above, a request 60 could be handled by more than one service handler 50-54.
For example, decision logic (not shown) for deciding whether a service handler 50-54 will handle a request 60 or not, can be divided into a separate software object (not shown) called a condition (not shown). A condition may apply to one or more service handlers 50-54.
When a service handler 50-54 registers itself with the broker 40, the service handler 50-54 also includes an associated condition.
When a request 60 is received by the broker 40, the broker 40 queries all of the registered conditions, passing them the service context 56. Based on the name/value pairs in the service context 56, a particular condition will either fire (accept the request) or not. A condition will fire if it finds data it requires in the name/value pairs of the service context 56. When a condition fires, the broker 40 delegates request 60 to one or more of the service handlers 50-54 that were registered with the broker 40 under the condition. Once all of the service handlers 50-54 that were registered with the broker 40 under the condition have been called by the broker 40 to handle the request 60, control passes back to the calling protocol proxy 42-46 as noted above, with the response elements 81 added to the service context 56, as appropriate.
Claims (19)
1. A computer-readable medium containing instructions for implementing ~ a means for storing data, one or more software components (request receiving components) for receiving requests, each request receiving component for receiving a request of a different protocol, and after receiving a request from a requestor in an original protocol, a request receiving component decomposing the request into its parameters and storing the parameters in the means for storing data;
~ a software component (the querying component), the querying component for querying service handlers in a particular order, to find a service handler to volunteer to handle the request;
~ one or more non-protocol specific service handler software components (service handlers), each service handler for performing a particular service, and after receiving a query from the querying component, a service handler considers the parameters in the means for storing data and decides whether or not to volunteer to handle the request;
and if the service handler volunteers to handle the request, the service handler performs the requested service; and if the service handler refuses to handle the request, then it informs the querying component.
~ a software component (the querying component), the querying component for querying service handlers in a particular order, to find a service handler to volunteer to handle the request;
~ one or more non-protocol specific service handler software components (service handlers), each service handler for performing a particular service, and after receiving a query from the querying component, a service handler considers the parameters in the means for storing data and decides whether or not to volunteer to handle the request;
and if the service handler volunteers to handle the request, the service handler performs the requested service; and if the service handler refuses to handle the request, then it informs the querying component.
2. The computer-readable medium of claim 1 wherein, decomposing the request into its parameters further comprises creating name/value pairs, whereby each relevant value or group of values in the parameters is associated with a name.
3. The computer-readable medium of claim 2 wherein the name is either provided in the request or provided by the request receiving component.
4. The computer-readable medium of claim 3 wherein storing the parameters in the means for storing data comprises storing the name/value pairs in the means for storing data.
5. The computer-readable medium of claim 4 wherein if the service handler handles the request, the service handler creates a response element and stores the response element in the means for storing data, which response element is a name/value pair comprising a name understood by the request receiving component indicating what action the request receiving component should take, if any, with an associated value; and the associated value comprises data to be returned in response to the request.
6. The computer-readable medium of claim 5 wherein if the name in the name/value pair of the response element indicates that associated value is to be returned in response to the request, then the request receiving component converts the value into the original protocol and returns the value to the requestor.
7. The computer-readable medium of claim 6 wherein the means for storing data comprises one of a hash table, a map, and a dictionary.
8. A computer-readable medium storing computer software and data that when loaded by a computing device facilitates handling of requests by non-protocol specific service handlers by the computing device comprising:
~ a data structure for storing data;
~ one or more software components (request receiving components), each request receiving component for receiving requests of a different protocol, and upon receiving a request from a requestor in an original protocol, a request receiving component decomposing the request into its parameters and storing the parameters in the data structure for storing data;
~ a software component(a querying component) for querying non-protocol specific service handlers, the querying component querying service handlers in a particular order, to find a service handler to volunteer to handle the request as decomposed into its parameters in the data structure for storing data.
~ a data structure for storing data;
~ one or more software components (request receiving components), each request receiving component for receiving requests of a different protocol, and upon receiving a request from a requestor in an original protocol, a request receiving component decomposing the request into its parameters and storing the parameters in the data structure for storing data;
~ a software component(a querying component) for querying non-protocol specific service handlers, the querying component querying service handlers in a particular order, to find a service handler to volunteer to handle the request as decomposed into its parameters in the data structure for storing data.
9. The computer-readable medium of claim 8 wherein, decomposing the request into its parameters further comprises creating name/value pairs, whereby each relevant value or group of values in the parameters is associated with a name.
10. The computer-readable medium of claim 9 wherein the name is either provided in the request or provided by the request receiving component.
11. The computer-readable medium of claim 10 wherein storing the parameters in the data structure for storing data comprises storing the name/value pairs in the data structure for storing data.
12. The computer-readable medium of claim 11 wherein the data structure for storing data is adapted to receive a response element from a service handler after the service handler has handled the request, wherein the response element is a name/value pair, the name/value pair comprising a name understood by the request receiving component indicating what action the request receiving component should take, if any, with an associated value; and the associated value comprising data to be returned in response to the request.
13. The computer-readable medium of claim 12 wherein if the name in the name/value pair of the response element indicates that associated value is to be returned in response to the request, then the request receiving component converts the value into the original protocol and returns the value to the requestor.
14. The computer-readable medium of claim 13 wherein the means for storing data comprises one of a hash table, a map, and a dictionary.
15. A computer readable medium storing computer software and data that when loaded by a computing device defines an object oriented object for implementation by the computing device in an object oriented framework comprising a data structure for storing name/value pairs for use in processing requests to software components (request receiving components) for receiving requests by non-protocol specific service handlers, wherein the name/value pairs correspond to parameters in a request received by a request receiving component, each name identifying a corresponding parameter, the name/value pairs being incorporated within one of a hash table, a map and a dictionary.
16. The computer-readable medium of claim 15 wherein the one of a hash table, a map and a dictionary is stored within a Java object.
17. The computer-readable medium of claim 16 wherein the data structure is used to convey data from a request receiving component to a service handler to handle the request.
18. The computer-readable medium of claim 17 wherein the data structure is adapted to have a response element added to it by a service handler, the response element being a name/value pair comprising a name understood by the request receiving component indicating what action the request receiving component should take, if any, with an associated value; and the associated value comprising data to be returned in response to the request.
19. A computer-readable medium storing computer software and data that when loaded by a computing device facilitates handling of requests by non-protocol specific service handlers by the computing device, the request having been decomposed into its parameters and stored in a data structure for storing data, the computer software and data comprising:
- a software component (a querying component) for querying non-protocol specific service handlers, the querying component querying service handlers in a particular order, to find a service handler to volunteer to handle the request as decomposed into its parameters in the data structure for storing data.
- a software component (a querying component) for querying non-protocol specific service handlers, the querying component querying service handlers in a particular order, to find a service handler to volunteer to handle the request as decomposed into its parameters in the data structure for storing data.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002323376A CA2323376A1 (en) | 2000-06-02 | 2000-10-17 | Protocol independent service handler techniques, software, date structures, methods and systems |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002310943A CA2310943A1 (en) | 2000-06-02 | 2000-06-02 | Methods, techniques, software and systems for providing context independent, protocol independent portable or reusable development tools |
| CA2,310,943 | 2000-06-02 | ||
| CA002323376A CA2323376A1 (en) | 2000-06-02 | 2000-10-17 | Protocol independent service handler techniques, software, date structures, methods and systems |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2323376A1 true CA2323376A1 (en) | 2001-12-02 |
Family
ID=25681865
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002323376A Abandoned CA2323376A1 (en) | 2000-06-02 | 2000-10-17 | Protocol independent service handler techniques, software, date structures, methods and systems |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2323376A1 (en) |
-
2000
- 2000-10-17 CA CA002323376A patent/CA2323376A1/en not_active Abandoned
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7181748B2 (en) | Multi-layer protocol reassembly that operates independently of underlying protocols, and resulting vector list corresponding thereto | |
| US9191347B2 (en) | Methods of routing messages using a listener registry | |
| US6275937B1 (en) | Collaborative server processing of content and meta-information with application to virus checking in a server network | |
| US7903656B2 (en) | Method and system for message routing based on privacy policies | |
| US7739382B2 (en) | Dynamic extension of network-accessible services | |
| US7606832B2 (en) | System and method for orchestrating composite web services in constrained data flow environments | |
| US7287067B2 (en) | Dynamically configuring a server computer | |
| US6192394B1 (en) | Inter-program synchronous communications using a collaboration software system | |
| US20040015578A1 (en) | Web services runtime architecture | |
| US20110219107A1 (en) | System and method for collaborative processing of distributed applications | |
| US20080307438A1 (en) | Status hub used by autonomic application servers | |
| US8799515B1 (en) | Rewriting of client-side executed scripts in the operation of an SSL VPN | |
| US20030204622A1 (en) | Dynamic invocation of web services | |
| US20090007253A1 (en) | Filtering technique for processing security measures in web service messages | |
| WO2005041035A1 (en) | Method and apparatus for processing service requests in a service-oriented architecture | |
| CA2436118A1 (en) | Policy implementation | |
| US20090019121A1 (en) | Message processing | |
| US20050021526A1 (en) | Method for ensuring the availability of a service proposed by a service provider | |
| EP1674961A1 (en) | Method for determining an applicable policy for an incoming message | |
| WO2003052650A2 (en) | Message filtering | |
| US20070266159A1 (en) | System and Method for Communication Between Remote Objects and Local Proxies | |
| US7516194B1 (en) | Method for downloading high-volumes of content from the internet without adversely effecting the source of the content or being detected | |
| CA2323376A1 (en) | Protocol independent service handler techniques, software, date structures, methods and systems | |
| US20050053050A1 (en) | Custom routing of object requests | |
| US20020161935A1 (en) | System and method for dynamically adding management information base object |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |