Method and system for an ontology based request/reply service

• US 10,079,865 B2
• Filed: 12/18/2014
• Issued: 09/18/2018
• Est. Priority Date: 12/18/2014
• Status: Active Grant

• Current Assignee: Software AG USA Incorporated (Software AG)
• Original Assignee: Software AG USA Incorporated (Software AG)
• Inventors: McDaid, Eddie, Chan, Desmond, Kennedy, Terence G., Kessler, Dieter
• Primary Examiner(s): Tokuta, Shean
• Assistant Examiner(s): Turriate Gastulo, Juan C
• Application Number:
  US14/574,974
• Publication Number:
  US 20160182433A1
• Time in Patent Office: 1,370 Days
• CPC Class Codes: H04L 51/214 using selective forwarding
• CPC Class Codes: H04L 65/4015 where at least one of the additional parallel sessions is real time or time sensitive, e.g. white board sharing, collaboration or spawning of a subconference
• CPC Class Codes: H04L 65/403 Arrangements for multi-party communication, e.g. for conferences data switching systems for conference H04L12/18; arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities H04M3/56; television conferencing systems H04N7/15
• CPC Class Codes: H04L 67/288 Distributed intermediate devices, i.e. intermediate devices for interaction with other intermediate devices on the same level
• CPC Class Codes: H04L 67/561 Adding application-functional data or data for application control, e.g. adding metadata
• CPC Class Codes: H04L 67/562 Brokering proxy services
• CPC Class Codes: H04L 67/566 Grouping or aggregating service requests, e.g. for unified processing
• CPC Class Codes: H04L 67/567 Integrating service provisioning from a plurality of service providers

Abstract

In a method, system, or computer-readable medium for an ontology-based request/reply service (RRS), different request/reply services (RRS) are hosted, each different RRS dedicatedly represents a different unique service and provides connections from client to server instance of the unique service, each different RRS accessed by client and server instances through a same independent communication layer (ICL). A request from the client is received through the ICL. The RRS is determined by the unique service indicated in the request, and instantiated dynamically as needed, according to an individual RRS ontology which establishes a syntactical and semantical framework dedicated to the unique service. The request is routed to the RRS and then through a server instance of the unique service to process the request; then a response is returned to the client to satisfy the request. It provides transport connectivity and mutual communication between combinations of clients, different RRSs, and server instances.

Claims

1. A system for an ontology-based request/reply service (RRS), comprising:

a storage which is configured to store an RRS ontology; and

a processor cooperatively operable with the storage, and configured to;

host a plurality of different request/reply services (RRS), each different RRS is dedicated to represent a different unique service and to provide connections from a client to a server instance of the different unique service, each different RRS is accessible by client instances and server instances through a same independent communication layer (ICL) that handles different transport protocols between different platforms;

receive, from the client through the ICL, a request that indicates a unique service and determine which RRS of the different RRSs is dedicated to represent the unique service which is indicated in the request;

determine whether the RRS, that is dedicated to represent the unique service indicated in the request, is already instantiated and available for communications with the client, so as to not re-instantiate the RRS,

instantiate an RRS of one of the different RRSs which is determined to not be already instantiated and available for communications, the RRS being instantiated according to an individual RRS ontology stored in the RRS ontology, wherein the individual RRS ontology provides a syntactical and semantical framework to establish processing which is dedicated to represent the unique service, wherein the one of the different RRSs has a plurality of subordinate RRSs instantiated corresponding to each of a plurality of unique services;

route the request which is received by the one RRS to the instantiated RRS of the different RRSs which is the subordinate RRS and is determined to be dedicated to represent the unique service which is indicated in the request, and then route the request through a server instance corresponding to the unique service indicated in the request to the subordinate RRS, to process the request and to return, from the subordinate RRS via the one RRS to the client, a response to satisfy the request; and

manage transport connectivity and mutual communication between a plurality of clients and the plurality of different RRSs, mutual communication between the plurality of different RRSs, and mutual communication between the plurality of different RRSs and a plurality of server instances.

2. The system of claim 1, wherein the processor is further configured to remove one or more of the plurality of different RRSs when no longer needed to process requests.

3. The system of claim 1, wherein the RRS ontology is configured to cause the instantiated RRS to support a plurality of parallel requests through the plurality of server instances all dedicated to the unique service.

4. The system of claim 1, wherein the RRS ontology is configured to cause the RRS to limit responses to the client request to a predefined maximum number of responses, when the client request is to the plurality of server instances which cause more than the predefined maximum number of responses to the client request.

5. The system of claim 1, wherein

the individual RRS ontology in the RRS ontology causes the instantiated RRS to act as a client that communicates requests to and receives replies from at least one of the different RRSs.

6. The system of claim 1, wherein the processor is further configured to manage requests and replies between the plurality of clients and the plurality of different RRSs according to pre-defined different types of conversation styles.

7. The system of claim 1, wherein the RRS is further configured to receive registration from the server instance, wherein the registration includes an indication of a rollback strategy in the event that the server instance disconnects while processing at least one unfinished request.

8. The system of claim 1, wherein each different RRS is accessible through a common application programming interface (API) which is common to all of the different RRSs.

9. A method for an ontology-based request/reply service (RRS), comprising:

hosting, by a processor, a plurality of different request/reply services (RRS), each different RRS is dedicated to represent a different unique service and to provide connections from a client to a server instance of the different unique service, each different RRS is accessible by client instances and server instances through a same independent communication layer (ICL) that handles different transport protocols between different platforms;

receiving, by the processor from the client through the ICL, a request that indicates a unique service and determine which RRS of the different RRSs is dedicated to represent the unique service which is indicated in the request;

determining whether the RRS, that is dedicated to represent the unique service indicated in the request, is already instantiated and available for communications with the client, so as to not re-instantiate the RRS,

instantiating, by the processor, an RRS of one of the different RRSs which is determined to not be already instantiated and available for communications, the RRS being instantiated according to an individual RRS ontology stored in an RRS ontology provided in a storage, wherein the individual RRS ontology provides a syntactical and semantical framework to establish processing which is dedicated to represent the unique service, wherein the one of the different RRSs has a plurality of subordinate RRSs instantiated corresponding to each of a plurality of unique services;

routing, by the processor, the request which is received by the one RRS, to the instantiated RRS of the different RRSs which is the subordinate RRS and is determined to be dedicated to represent the unique service which is indicated in the request, and then routing, by the processor, the request through a server instance corresponding to the unique service indicated in the request to the subordinate RRS, to process the request and then returning, from the subordinate RRS via the one RRS to the client, a response to satisfy the request; and

managing, by the processor, transport connectivity and mutual communication between a plurality of clients and the plurality of different RRSs, mutual communication between the plurality of different RRSs, and mutual communication between the plurality of different RRSs and a plurality of server instances.

10. The method of claim 9, further comprising removing, by the processor, one or more of the plurality of different RRSs when no longer needed to process requests.

11. The method of claim 9, wherein the RRS ontology is configured to cause the instantiated RRS, executing by the processor, to support a plurality of parallel requests through the plurality of server instances all dedicated to the unique service.

12. The method of claim 9, wherein the RRS ontology is configured to cause the RRS, executing by the processor, to limit responses to the client request to a predefined maximum number of responses, when the client request is to the plurality of server instances which cause more than the predefined maximum number of responses to the client request.

13. The method of claim 9, wherein

the individual RRS ontology in the RRS ontology causes the instantiated RRS, when executing by the processor, to act as a client that communicates requests to and receives replies from at least one of the different RRSs.

14. The method of claim 9, further comprising managing, by the processor, requests and replies between the plurality of clients and the plurality of different RRSs according to pre-defined different types of conversation styles.

15. The method of claim 9, further comprising receiving, by the RRS on the processor, registration from the server instance, wherein the registration includes an indication of a rollback strategy in the event that the server instance disconnects while processing at least one unfinished request.

16. The method of claim 9, further comprising providing, by the processor, accessibility to each different RRS through a common application programming interface (API) which is common to all of the different RRSs.

17. A non-transitory computer readable medium comprising executable instructions for a method for an ontology-based request/reply service (RRS), the instructions being executed by a processor to perform:

providing a storage which is configured to store an RRS ontology;

hosting a plurality of different request/reply services (RRS), each different RRS is dedicated to represent a different unique service and to provide connections from a client to a server instance of the different unique service, each different RRS is accessible by client instances and server instances through a same independent communication layer (ICL) that handles different transport protocols between different platforms;

receiving, from the client through the ICL, a request that indicates a unique service and determine which RRS of the different RRSs is dedicated to represent the unique service which is indicated in the request;

determining whether the RRS, that is dedicated to represent the unique service indicated in the request, is already instantiated and available for communications with the client, so as to not re-instantiate the RRS,

instantiating an RRS of one of the different RRSs which is determined to not be already instantiated and available for communications, the RRS being instantiated according to an individual RRS ontology stored in the RRS ontology provided in the storage, wherein the individual RRS ontology provides a syntactical and semantical framework to establish processing which is dedicated to represent the unique service, wherein the one of the different RRSs has a plurality of subordinate RRSs instantiated corresponding to each of a plurality of unique services;

routing the request which is received by the one RRS to the instantiated RRS of the different RRSs which is the subordinate RRS and is determined to be dedicated to represent the unique service which is indicated in the request, and then routing the request through a server instance corresponding to the unique service indicated in the request to the subordinate RRS, to process the request and then returning, from the subordinate RRS via the one RRS to the client, a response to satisfy the request; and

managing transport connectivity and mutual communication between a plurality of clients and the plurality of different RRSs, mutual communication between the plurality of different RRSs, and mutual communication between the plurality of different RRSs and a plurality of server instances.

18. The non-transitory computer readable medium of claim 17, further comprising removing one or more of the plurality of different RRSs when no longer needed to process requests.

19. The non-transitory computer readable medium of claim 17, wherein the RRS ontology is configured to cause the instantiated RRS to support a plurality of parallel requests through the plurality of server instances all dedicated to the unique service.

20. The non-transitory computer readable medium of claim 17, wherein the RRS ontology is configured to cause the RRS to limit responses to the client request to a predefined maximum number of responses, when the client request is to the plurality of server instances which cause more than the predefined maximum number of responses to the client request.