Service Architecture

For those with an understanding of CORBA[31] the internals of the service layer should be fairly straight-forward. The Haystack service model utilizes an architectural framework that borrows a number of important ideas from the OMG specifications for CORBA.

In the Haystack notation, just as in CORBA, services are merely objects that act as clients, servers, or peers. A service encapsulates a specific functionality behind a well defined interface. This functionality can be readily invoked from any other service. A session can be represented as follows (see Figure ):

  
Figure: Abstract inter-service communication model

1. In the first step, service A and B are both loaded (i.e. they are instantiated) in a HaystackRootServer (see Section ). In Figure  both use the same HaystackRootServer, but as we shall see, this isn't necessary. Both services invoke the register(...) method of the HsNameService (see Section ), with an abstract version of their name (represented by the ServiceName class).
2. In the second step, service A wishes to communicate with service B, so A will generate the ServiceName for B, and submit the name to getService(...) request to the HsNameService. The HsNameService will respond with a pointer to the instantiated version of B running within the HaystackRootServer.
3. In the final step, service A can now communicate with B. For now, it is assumed that A knows which methods B has made public. In the future services will be implemented as JavaBean objects [25] that define an introspection method (so that A can dynamically decide how to call B).

• Service Types