You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

Background

Geode provides a FunctionService. Currently this FunctionService is defined to be static. In order to remove the "static-ness" of the FunctionService it is required to be made available off the Cache in a similar fashion as the RegionFactory. The currently exposes functionality that available for both client/server interaction and peer-to-peer, which can be confusing to users writing clients.

Dependencies

The FunctionService refactor requires that the Geode is split into two distinct modules:

  • server cache
  • client cache

Currently, both the client and server cache code resides in the same file (GemFireCacheImpl). Without the clear distinction of client or server cache code, the splitting of client and server function service code is unclear and complex.

Proposal

The current FunctionService provides 3 different services:

  • 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 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.

 

 

 

 

 

  • No labels