Jockey Design |
The core Jockey plaform runs as an operating system service. This is an NT service for win32 platforms, or a unix daemon on Unix/Linux/OS X.
|
|
In the diagram above, the Jockey system JVM is instantiated by the service controllers for the operating systems. This service controller functionality will have to be provided by shell scripts or batch files on other operating systems that do not have service control support.
The Jockey system will use a separate interface into the JNI shared library to inform the JNI library about the Jockey JVM instance. After this round trip initialization process, from the service controller, to the Jockey JVM, then to the JNI shared library, the Jockey system will be available to user applications.
The service controller mechanism ensures that Jockey runs as a single instance on a peer machine. User applications run in separate VMs and must use the JNI library to communicate with the single instance of Jockey.
The application to service communication mechanism could be implemented in several ways; the JNI DLL solution is a simple and expedient IPC mechanism, which allows different programming languages to access the Jockey service. This method could be replaced with local socket calls, but that would require a language neutral serialization format and a socket protocol, which would add significantly to development time.
An enterprise class Jockey implementation has three API contracts or protocols that it must support. The system must support a application communication API for interacting with applications, a service invocation API for interacting with services, and the P2P communication API for interaction with other peers on the peer network. A Jockey implementation can be defined as a piece of software that conforms to these API/protocol contracts.
|
The language neutral architecture of Jockey requires a Jockey implementation to support services implemented in programming languages other than that of the Jockey implementation. Web Services represent an industry standard method of describing and invoking services in a language neutral manner.
Jockey must provide a Service Bridge (SB) Interface to support interaction with services. The Jockey implementation provides a pluggable SB implementation that is capable of interacting with services that are implemented as Web Services, as well as services in other service frameworks.
Jockey supplies the Service Interface (SI) API to enable application or elements of the peer network to make use of installed services.
Jockey must provide a Peer Bridge (PB) Interface to support interaction with various peer networks. The Jockey implementation provides a pluggable PB implementation that is capable of interacting with peer networks such as JXTA, Gnutella, and others.
Jockey also provides a Peer Interface (PI) API, so that applications or services that wish to participate in the peer network can establish an identity, explore the peer network, and categorize the network into network groups.