...
- Function administration
- Function invocation from a Geode client
- Function invocation from a Geode server
Having the FunctionService being responsible for three distinct areas of responsibility makes it really hard to extend and maintain the code base.
In order to have a more concise service the proposal is to:
- Separate the client and server function service implementations into different distinct classes
- Move the function administration to be a server-side function only..
- Move the FunctionService from static access to instance-based access, like RegionFactory being accessed from Cache.
As can be seen in the below class diagram, the FunctionService is split into 3 key areas:
- Common code
- Server code
- Client code
The FunctionServiceBase is shared by both the server and client function service. The client function service exposes only client-side function services:
- onServer
- onServers
- onRegion
The server function service will expose:
- onMember
- onMembers
- onRegion
The different function service implementations will be responsible for its area of expertise. The client function service would not know about server-side services and would not expose functionality that cannot be used.
For the splitting of the FunctionService into the client and server components, the