SYSTEM AND A METHOD FOR OPTIMIZED SERVER-LESS SERVICE VIRTUALIZATION

• US 20200136933A1
• Filed: 01/08/2019
• Published: 04/30/2020
• Est. Priority Date: 10/24/2018
• Status: Active Grant

• Current Assignee: Cognizant Technology Solutions India Private Limited (Cognizant Technology Solutions Corp.)
• Original Assignee: Cognizant Technology Solutions India Private Limited (Cognizant Technology Solutions Corp.)
• Inventors: Raskar, Hemant
• Granted Patent: US 10,819,589 B2
• Time in Patent Office: Days
• CPC Class Codes: G06F 2009/45562 Creating, deleting, cloning virtual machine instances
• CPC Class Codes: G06F 2009/45583 Memory management, e.g. access or allocation
• CPC Class Codes: G06F 2209/5011 Pool
• CPC Class Codes: G06F 2209/5015 Service provider selection
• CPC Class Codes: G06F 9/45508 Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation
• CPC Class Codes: G06F 9/45558 Hypervisor-specific management and integration aspects
• CPC Class Codes: G06F 9/5055 considering software capabilities, i.e. software resources associated or available to the machine
• CPC Class Codes: G06F 9/5077 Logical partitioning of resources; Management or configuration of virtualized resources specific details on emulation or internal functioning of virtual machines G06F9/455
• CPC Class Codes: G06F 9/52 Program synchronisation; Mutual exclusion, e.g. by means of semaphores
• CPC Class Codes: H04L 41/0654 using network fault recovery ring fault isolation or reconfiguration in loop networks without recovery actions by a network management system H04L12/437
• CPC Class Codes: H04L 41/0806 for initial configuration or provisioning, e.g. plug-and-play
• CPC Class Codes: H04L 41/0886 Fully automatic configuration
• CPC Class Codes: H04L 41/0895 Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
• CPC Class Codes: H04L 41/40 using virtualisation of network functions or resources, e.g. SDN or NFV entities
• CPC Class Codes: H04L 41/5012 determining service availability, e.g. which services are available at a certain point in time
• CPC Class Codes: H04L 41/5054 Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
• CPC Class Codes: H04L 41/5058 Service discovery by the service manager
• CPC Class Codes: H04L 43/0805 by checking availability
• CPC Class Codes: H04L 43/0876 Network utilisation, e.g. volume of load or congestion level
• CPC Class Codes: H04L 43/20 the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV
• CPC Class Codes: H04L 67/51 : Discovery or management thereof, e.g. service location protocol [SLP] or web services
• CPC Class Codes: H04L 67/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 admission control or resource allocation H04L47/70
• CPC Class Codes: H04L 69/40 : for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection management of faults, events, alarms or notifications in data switching networks H04L41/06

Abstract

A system and a method for providing service virtualization in a distributed computing architecture without a central server is disclosed. The present invention provides one or more service pods implementable on one or more workstations. Each of the one or more service pods is configured to host one or more virtual services. Each of the one or more service pods interface with one or more live services to generate virtual service data to emulate said live services. The one or more service pods interface with each other via a network fabric technique and interact with one or more client applications to be tested. Each of the one or more service pods are configured to receive and process requests from one or more client applications using various modes of service pods. The present invention provides complete abstraction of the one or more workstations from the one or more service pods.

Claims

1. A system for providing server less service virtualisation implementable on one or more workstations in a distributed computing architecture, said one or more workstations interfacing with one or more application servers and one or more dependency components, each of the one or more workstations comprising:

a memory storing program instructions;

a processor configured to execute program instructions stored in the memory;

and at least one virtual service subsystem in communication with the processor configured to;

host a plurality of virtual services emulating one or more live services hosted by one or more dependency components, wherein each of the plurality of virtual services are interconnected via a network fabric technique;

generate a system-meta-data using a computation technique, wherein the system-meta-data comprises a fabric access table to enable communication between each of the plurality of virtual services;

determine availability of one or more live services for completing one or more service requests received from one or more client applications via the one or more application servers; and

determine one or more virtual services in the absence of one or more corresponding live services to complete the one or more service requests based on the system meta-data.

2. The system as claimed in claim 1, wherein the at least one virtual service subsystem comprises one or more service pods in communication with the processor, the one or more service pods configured to host the plurality of virtual services using one or more network ports, further wherein at least one of the service pods is configured to automatically manage and recover the corresponding one or more service pods in case of failure or maintenance of corresponding workstations.

3. The system as claimed in claim 1, wherein the at least one virtual service subsystem comprises a plurality of service pods in communication with the processor, each service pod configured to:

monitor, analyze and record behavior of the one or more live services in response to the one or more service requests; and

generate and update virtual service data based on the recorded behavior to provide one or more virtual services emulating the one or more live service, wherein more than one virtual service hosted by respective service pods are associated with same protocol type selected from a group comprising of http, JMS, JDBC, FTP, SOAP, REST, FIX, LDAP and RMI.

4. The system as claimed in claim 3, wherein more than one virtual service hosted by respective service pods are of a different version of each other.

5. The system as claimed in claim 2, wherein the plurality of virtual services sharing the same port have same network namespace and respective service URLs, further wherein the plurality of virtual services sharing the same port are managed by employing JVM level critical section and semaphores.

6. The system as claimed in claim 3, wherein each service pod is configured to provide respective thread-pool size and default threads or protocol specific threads to the associated virtual services.

7. The system as claimed in claim 2, wherein the service pod comprises a pod-Shadow unit configured to create and destroy instances of service-pods;

and

provide high level data-encapsulation to hide respective service pod instances and data.

8. The system as claimed in claim 1, wherein each of the plurality of virtual services is provided a unique virtual service identifier, wherein the unique virtual service identifier enables identification of one or more virtual services to complete the one or more service requests.

9. The system as claimed in claim 3, wherein each of the plurality of service pods are interconnected using the elastic network fabric technique, further wherein the elastic network technique includes generating the system-meta-data using the computation technique.

10. The system as claimed in claim 9, wherein the at least one virtual service subsystem comprises one or more crossbar switches in communication with the processor, wherein the one or more crossbar switches are deployed as an independent unit separate from the plurality of service pods, further wherein the one or more crossbar switches interface with one or more service pods, the one or more crossbar switches configured to:

receive data associated with one or more service pods registered with the one or more crossbar switches;

generate the system-meta-data and transmit the system-meta-data to the plurality of service pods registered with one or more crossbar switches, wherein the system-meta-data comprises a fabric access table including service host, protocol name, list of destination service pods registered with one or more crossbar switch, default crossbar switch and one or more crossbar switches managing the plurality of service pods;

select appropriate one or more service pods to complete one or more service requests based on a mode in which the one or more service pods are operating;

provide a gateway to exchange data between the plurality of service pods; and

update the fabric access table after completion of one or more service requests.

11. The system as claimed in claim 10, wherein the computation technique comprises:

determining a total number of service pods associated with each of the at least one virtual service subsystem to generate a list of service pods;

SP={SP1, SP2, SP3, SP4, . . . , SPp} where, p is total number of Service pods;

generating a list of virtual services managed by each service pod by computing a total number of virtual services associated with each service pod;

E(SP_p)={E1, E2, . . . , En} where, n is total number of virtual services managed by service pod p;

generating a list of service pods registered with each crossbar switch by evaluating a number of service pods registered with a crossbar switch;

SCS={SCS1, SCS2, . . . SCSc} where, c is total number of crossbar switches, SCS(c)={SP1, SP2, . . . SPd} where, d is total number of service pods registered with given SCS-c;

generating a list of service pod modes by evaluating total number of service pods mode;

List of Service pods Modes SPM={SPM1, SPM2, . . . SPMm} where, m is total number of service pod modes;

generating a list of service pods operating in a given mode out of the various modes by evaluating total number of service pods operating in the given mode;

Service pods operating in a given Mode SPM(m)={SP1, SP2, . . . SPk} where, m is the service pod Mode and k is total number of service pods in given mode m;

generating a fabric access table based on the list of virtual services managed by each service pod, list of service pods registered with each crossbar switch and the list of service pods operating in a given mode;

FaT(SCS(c))={FaT1, FaT2, . . . , FaT(t)} where, t is total number of FaTs for given number of services pods registered with given SCS-c, FaT(t)={SPM(m), E(SPp), SCS(c)}; and

generating a list of pod-clusters available with each crossbar switch;

PCluster(c)={PClst1, PClst2, . . . , PClsts}, PClst(s)={SP1, SP2, . . . , SPx} where, s is total number of pod-clusters formed at given SCS-c, x is total number of services pods present in given with given pod-cluster-s.

12. The system as claimed in claim 1, wherein the system-meta-data comprises a list of service pods, a list of virtual services, a list of service pods registered with a crossbar switch, a list of service pod modes and a fabric access table.

13. The system as claimed in claim 3, wherein the at least one virtual service subsystem comprises a service pod manager in communication with the processor, wherein the service-pod manager is deployed as a unit separate and independent from the plurality of service pods, the service-pod manager interfaces with the plurality of service pods, the service-pod manager configured to view status of the plurality of service pods and manage one or functions associated with the plurality of service pods.

14. The system as claimed in claim 13, wherein the one or more functions include starting and stopping of one or more service pods, and configuring parameters associated with each of the plurality of service pods, further wherein the parameters associated with a service pod include logging configuration, network ports, external data, request response pairs and request routing configurations.

15. The system as claimed in claim 2, wherein the one or more service pods are configured to reject excessive service requests by using a dynamic request-Queue with a bounded capacity.

16. The system as claimed in claim 9, wherein each service pod is configured to operate in one or more modes at a given time, wherein the one or more modes include deployment mode, response mode, delegation mode, proxy mode, cluster mode and load balancer mode, further wherein the one or more service pods operating in the deployment mode are configured to send a register request to one or more crossbar switches;

and share initialization data with the one or more crossbar switches upon successful acknowledgement.

17. The system as claimed in claim 20, wherein one or more service pods operating in the response mode are configured to:

process one or more service requests from the one or more client applications using a second set of rules, wherein the second set of rules include validating respective end-point URLs associated with one or more virtual services; and

provide a response to the one or more service requests based on the validity of respective end-point URLs.

18. The system as claimed in claim 17, wherein the one or more service pods operate in the delegation mode if the one or more end-point URLs are invalid, the one or more service pods operating in the delegation mode are configured to:

process one or more service requests from the one or more client applications using a third set of rules, wherein the third set of rules includes determining an association between the end-point URL with other service pods in a network fabric; and

routing the one or more service requests to the other service pod in the network fabric on determination of a valid association.

19. The system as claimed in claim 16, wherein the one or more service pods operating in the proxy mode are configured to process one or more service requests from the one or more client applications using a fourth set of rules, wherein the fourth set of rules include routing the one or more service requests to one or more requested end-point URLs without validation.

20. The system as claimed in claim 16, wherein two or more service pods hosting same type of virtual services or a different version of a given virtual service are configured to operate in the cluster mode as a pod-cluster, further wherein the one more or more service requests from the one or more client applications are redirected from one service pod to other service pods associated with the pod-cluster to balance load.

21. The system as claimed in claim 16, wherein the plurality of service pods operating in the load balancing mode are configured to:

monitor the availability of one or more service pods in a network fabric; and

process one or more service requests from the one or more client applications using a fifth set of rules, wherein the fifth set of rules includes determining and selecting one or more service pods configured with same type of virtual services with valid end-points;

determining operating condition of the selected one or more service pods using a continuous test technique, wherein the continuous test technique includes determining the one or more selected service pods capable of generating a response to a mock request and rejecting the one or more service pods that are unable to generate the response; and

determining load on each of the selected service pods by evaluating CPU usage, response time and memory, further wherein the service pod with least response time is selected for redirecting the one or more service requests.

22. The system as claimed in claim 1, wherein data associated with completion of requests is transmitted to one or more corresponding crossbar switch, further wherein the data associated with completion of requests includes endpoint URL, request type, response type, request and response payload, and service pod ID.

24. The method as claimed in claim 1, wherein hosting the plurality of virtual service comprises:

monitoring, analyzing and recording behavior of the one or more live services in response to the one or more service requests; and

generating and updating virtual service data based on the recorded behavior to provide one or more virtual services emulating the one or more live service.

23. A method for providing server-less service virtualization in a distributed computing architecture, wherein the method is implemented by at least one workstation comprising at least one processor executing program instructions stored in a memory, the method comprising:

hosting, by a processor, a plurality of virtual services emulating one or more live services hosted by one or more dependency components, wherein each of the plurality of virtual services are interconnected via a network fabric technique;

generating, by the processor, a system-meta-data using a computation technique, wherein the system-meta-data comprises a fabric access table to enable communication between each of the plurality of virtual services;

determining, by the processor, availability of one or more live services for completing one or more service requests received from one or more client applications via the one or more application servers; and

determining, by the processor, one or more virtual services in the absence of one or more corresponding live services to complete the one or more service requests based on the system meta-data.

25. The method as claimed in claim 23, wherein the plurality of virtual services are selected from http, JMS, JDBC, FTP, SOAP, REST, FIX, LDAP and RMI.

26. The method as claimed in claim 23, wherein the plurality of virtual services sharing a same port have same network namespace and respective service URLs, further wherein the plurality of virtual services sharing the same port are managed by employing JVM level critical section and semaphores, further wherein each of the plurality of virtual services have respective thread-pool size and default threads or protocol specific threads.

27. The method as claimed in claim 23, wherein the plurality of virtual services are hosted by one or more service pods interconnected by one or more crossbar switches using the elastic network fabric technique, further wherein the elastic network technique includes generating the system-meta-data using the computation technique.

28. The method as claimed in claim 27, wherein the computation technique comprises:

determining a total number of service pods associated with each of the at least one virtual service subsystem to generate a list of service pods;

SP={SP1, SP2, SP3, SP4, . . . , SPp} where, p is total number of Service pods;

generating a list of virtual services managed by each service pod by computing a total number of virtual services associated with each service pod;

E(SP_p)={E1, E2, . . . , En} where, n is total number of virtual services managed by service pod p;

generating a list of service pods registered with each crossbar switch by evaluating a number of service pods registered with a crossbar switch;

SCS={SCS1, SCS2, . . . SCSc} where, c is total number of crossbar switches, SCS(c)={SP1, SP2, . . . SPd} where, d is total number of service pods registered with given SCS-c;

generating a list of service pod modes by evaluating total number of service pods mode;

List of Service pods Modes SPM={SPM1, SPM2, . . . SPMm} where, m is total number of service pod modes;

generating a list of service pods operating in a given mode out of the various modes by evaluating total number of service pods operating in the given mode;

Service pods operating in a given Mode SPM(m)={SP1, SP2, . . . SPk} where, m is the service pod Mode and k is total number of service pods in given mode m;

generating a fabric access table based on the list of virtual services managed by each service pod, list of service pods registered with each crossbar switch and the list of service pods operating in a given mode;

FaT(SCS(c))={FaT1, FaT2, . . . , FaT(t)} where, t is total number of FaTs for given number of services pods registered with given SCS-c, FaT(t)={SPM(m), E(SPp), SCS(c)}; and

generating a list of pod-clusters available with each crossbar switch;

PCluster(c)={PClst1, PClst2, . . . , PClsts}, PClst(s)={SP1, SP2, . . . , SPx} where, s is total number of pod-clusters formed at given SCS-c, x is total number of services pods present in given with given pod-cluster-s.

29. The method as claimed in claim 23, wherein the system-meta-data comprises a list of service pods, a list of virtual services, a list of service pods registered with a crossbar switch, a list of service pod modes and a fabric access table.

30. A computer program product comprising:

a non-transitory computer-readable medium having computer-readable program code stored thereon, the computer-readable program code comprising instructions that, when executed by a processor, cause the processor to;

host a plurality of virtual services emulating one or more live services hosted by one or more dependency components, wherein each of the plurality of virtual services are interconnected via a network fabric technique;

generate a system-meta-data using a computation technique, wherein the system-meta-data comprises a fabric access table to enable communication between each of the plurality of virtual services;

determine availability of one or more live services for completing one or more service requests received from one or more client applications via the one or more application servers; and

determine one or more virtual services in the absence of one or more corresponding live services to complete the one or more service requests based on the system meta-data.