Zen :: Worlds :: Design

For every service group, there is a service master, a service manager and a service.

At this point it is unclear if the service master and service manager can be made generic and included in Zen Enterprise, and so for now we'll assume that master and manager are unique for each servvice group.

You'll notice that this closely mimics the method based service architecture using the Zen Core plugin system. The primary differences are the lack of a factory and the inclusion of a master.

Service

In service oriented architecture, services are components much like C++ components, except instead of handling method calls via direct message dispatch, it handles method calls via Zen Enterprise messaging?.

Our current implementation of Zen Enterprise does not include direct support for service contracts yet, but eventually it will, and the notion is still used. A service contract is the "interface" of the service. This contract provides details about the meta data? of the messages used while interfacing with a given service.

Generally you would take this service contract and generate the client proxies, but since Zen Enterprise is lacking this feature, we're currently hand-coding the client proxies.

Service Manager and Service Master

A service manager is a service that is used to start and stop other component services. There is one service manager instance in any given application server.

The service master is used as a service registry and for load balancing. Clients refer to a service master to determine the appropriate service that it should use for any given service contract (i.e. interface) as well as a few other details that are specific to each service master.

A service master is treated as a singleton within a cluster, but generally there are more than one service masters that are used for redundancy, load distribution and failover.

Service Discovery

In order to discover the location of a service, a client will first use the generic Zen Enterprise Service Registry?. The service registry returns the endpoint? and the serviceId? of the requested service. This data is cached locally, but if the data is missing then the systems master service manager is referenced, which in turn references the specific service master for that interface.

If necessary, a service master will locate a service manager within its registry and request a given service be loaded, configured, initialized and started.

Specific Examples

Using the Zone Service as a specific example, starting from the client we have a client proxy called I_ZoneService located in the ZoneClient library.

Other interfaces include I_ZoneMaster which is used to query for particular I_ZoneService

TODO Complete