Flow Remoting
A framework for distributed, service-oriented applications
Requirements
This section outlines both functional and non-functional requirements for Flow Remoting.
Usecases
There are two high-level usecases for Flow Remoting. It can be used in combination with the Flow framework to provide maximum runtime-flexibility or it can be used on top of bare OSGi. When used without the Flow Framework however, the user is limited to the programmatic interface of the framework, annotations, sessions and runtime-configuration rely on the Flow Framework. In practice, this means that service discovery, binding and rexporting have to be made programmatically, using plain Flow Remoting API.
At application level, the framework allows for different levels of distribution awareness. It is possible to make the distribution of the application transparent, rendering the application (and the user) unaware of its distributed nature. This scenario is useful to add distribution to initially local applications. Instances arise however, where the application should be explicitly aware of its distribution. These usage-scenarios are supported by providing a rich set of features that allow the user to make use of the full power of distribution. Examples are asynchronous message passing and callbacks.
Flow Remoting distinguishes between two actors, the service provider and the service consumer. The service provider exports one or more services for other actors to consume. A service consumer uses services exported by a service provider. Obviously a single actor can play the role of both provider and consumer at the same time.
The following is a list of usecases supported by Flow Remoting:
- Export services for remote access. Users are able to export locally running services for remote access. The framework maintains a directory or list of exported services. Exporting a service includes adding it to this directory. The service is also made available for access over the network. To accomplish this, Flow Remoting relies on various remoting strategies, such as Web-services, RMI or R-OSGi.
- Discover remote service providers. Flow Remoting is able to locate service providers at runtime. As with exporting, different strategies can be used to discover service providers. First off, different discovery strategies are used for different types of service providers. The local area network can be periodically scanned for other Flow Remoting instances using broadcasts. Flow Remoting can also connect to generic service providers such as plain RMI servers or Webservice-UDDIs if the user provides the necessary URI details.
- Bind remote services. A service consumer can bind to remote services using the same strategy that was used to export these services.
- Invoke remote services. Again, different strategies are supported. If the application is unaware of distribution, proxies and synchronous method invocation are used. If distribution is not made totally transparent, asynchronous messages and callbacks can be used.
The following usecase diagramm outlines the above introduced usecases and visualizes their hierarchy.
Design-goals
Flow Remoting will be designed with regard to extensibility, ease of use and robustness. The fact that different remoting strategies such as webservices, RMI and R-OSGi can be chosen makes the framework universally usable and extensible. It is also important to keep the code independent of the Flow Framework.
Architecture
Flow Remoting itself is service-oriented. The framework is in fact an aggregation of services providing functionality to support the usecases outlined above.
FLow Remoting is a collection of OSGi bundles. The core bundle is named org.flow.remoting. This Bundle defines 2 service interfaces: IServiceExporter and IServiceProviderLocator. The IServiceExporter service exports locally registered services for remote access. The IServiceProviderLocator service is used to locate remote service providers in the local area network or over the internet. Both service interfaces are meant to be implemented in different ways, allowing the support of different transport protocols. These interfaces are intended to be implemented within other bundles. An implementation of the IServiceExporter interface uses a specific remoting technology ie. RMI. This means that the more implementations of this interface are available at runtime, to more potential clients the system can export its services to. The same observation can be made about the IServiceProviderLocator interface. An implementation of this interface provides the capability to locate and use remote service providers. The API section covers these interfaces in detail.
The following passage explains how locally registered services are made available for others over the network. A IServiceExporter implementation must listen for services that are registered by other bundles. If such a registration occurs, the implementation must retrieve the corresponding SericeReference and look for a particular hint (the EXPORTING_HINT ). If this property is set, the IServiceExporter must verify if the service can be exported. The tests performed at this stage are dependent on the implemented remoting technology. If all tests pass, the service can be exported. If not, the service is not exported.
Now lets take a look at what happens on the other side. Implementations of the IServiceProviderLocator interface are able to connect to remotely available services. Once a connection is established, the framework generates a special peer bundle and registers it with the local OSGi bundle context. The peer bundle represents the remote service provider. The peer bundle itself registers a service of the type IPeer. This service can be used to bind and unbind remote services. NOTE: if the Flow Framework is used, it tracks peer bundles at runtime and transparently binds to services. Consult Flow Framework integration for further details. If the remote service provider becomes unavailable at runtime, the peer bundle is deactivated and subsequently removed.
Classloading
Whenever remote services are invoked, the client may need classes at runtime, which were unavailable at the time when the client was developed / deployed. This makes it necessary that peer bundles use a special classloader which is able to dynamically perform lazy loading of class descriptions at runtime. One example is RMI classloading.
API
Flow Framework integration
Flow Remoting registers peer bundles when it connects to remote service providers. When a peer bundle is started, the Flow Framework inspects it, in order to discover available services. To be able to detect available services, Flow Remoting supplies an adapted ServiceDescriptorFactory which generated adapted ServiceDescriptors. This mechanism allows seamless integration with the Flow Framework; Dependencies of local services or local service consumers can subsequently be satisfied by remote services.
Implementation
by Daniel Meyer