ISXDK:Services

Overview

Inner Space Services provide a method of in-process "remote procedure call" with caller ID. It is essentially an in-process client/server communications mechanism, which is allowed to pass pointers to original data (again, because of being in-process). This allows both ends of the message pipe to easily deconstruct and reconstruct function calls, without serializing data, as would be necessary in networked communications. Services use the term "master", rather than "server", to remove the implication that services are networked.

Typical life cycle of a service

1. Service is registered by Inner Space or an extension. Any number of clients may now connect to the service. This simple demonstration will only show a single client and does not explain every possible detail...
2. Client (generally an extension) connects to service by name. Service receives message that client connected
3. Communications ensue. Master can send broadcasts to all clients, notifications to any given client. Clients can send requests to the service.
4. Client disconnects from service. Service receives message that client disconnected
5. Service is unregistered by its master

Service Master

Registering a service

Services are registered with the RegisterService function in ISServiceMasterInterface, which is a sub-interface of ISInterface. This function takes 3 parameters: the pointer to your extension class instance (ISXInterface), the Name of the service, and a request callback function. The return value is a HISXSERVICE, which will either be NULL (0) upon failure, or a handle to your service, which is to be used when perfoming additional service operations.

A barebones service registration

HISXSERVICE hMyService=0;
void __cdecl MyService_HandleRequest(ISXInterface *pClient, unsigned int MSG, void *lpData)
{
}
.
.
.
hMyService=pISInterface->RegisterService(pExtension,"My Service!!",MyService_HandleRequest);