Overview
GridServer hosts Services in an automatically scalable, load balanced, and fault-tolerant environment. Services can be written in a variety of languages and do not need to be compiled or linked with DataSynapse code.
Service implementations can be constructed using any of the following options:
|
•
|
Dynamic Libraries (.so, .dll) with methods that conform to a simple input-output string interface |
|
•
|
Commands, such as a script or binary |
These Services can be accessed in one of two ways:
|
•
|
Service API — a client-side API in Java, COM, C++, R, or .NET |
|
•
|
Service Proxy — GridServer-generated C# or Java client stubs |
The basic Service execution model is the same as that of other distributed programming solutions: method calls on the client are routed over the network, ultimately resulting in method calls on a remote machine, and return values make the reverse trip.
The chief benefit of hosting Services on GridServer over other approaches is that it virtualizes the Service. Rather than send a request directly to the remote machine hosting the Service, a client request is sent to the GridServer Manager, which enqueues it until an Engine is available. The first Engine to dequeue the request hosts the Service. Subsequent requests might be routed to the same Engine or might result in a second Engine running the Service concurrently. This decision is based on the Service’s priority, the amount of resources the Service has received in comparison with other Services, and how much state related to the Service resides on the first Engine. If an Engine hosting a Service fails, another takes its place. This mechanism, in which a single virtual Service instance (the client-side object) is implemented by one or more physical instances (Engine processes) provides for fault tolerance and essentially unlimited scalability.