Module based extensions

Module based extensions

With the Version 2.0, the interface com.github.thorbenkuck.netcom2.interfaces.Module was introduced. This interface is used, to create extensions to the NetCom2 core classes, the ServerStart and the ClientStart.

The signature

The Interface has 2 methods. The method setup and close. I addition, it is required to add a generic type to this interface, which is a subclass of the NetworkInterface.

Setup is used to hook the Module to the NetworkInterface, whilst close should "disconnect" the NetworkInterface from this Module. Most of the time, setup registers Communications to the CommunicationRegistration, whilst close un-registers those. You are not required to implement the close method. By default, it does nothing. It is however highly recommended to implement a close-routine.

Pre-installed Modules

NetCom2 brings with it four implementations of the Module interface. Those are

Sender

The Sender is a Module for the ClientStart. It allows you to send Object to the Server, request Registrations and more. It can be used like this:

ClientStart clientStart = ...
Sender sender = Sender.open(clientStart);

It is recommended to store this instance and reuse it. Every sender keeps track of the Observables set for the Registrations. They are NOT interchangeable!

Distributor

This Distributor is a Module for the ServerStart. It is used to realize multicast Communication, or (to put it simply) to distribute Objects to multiple Clients at the same time. It can be used like this:

ServerStart serverStart = ...
Distributor distributor = Distributor.open(serverStart);

The Distributor is not state-based; It does not store/maintain custom objects for specific requests. However: It is still highly recommended to only create one instance of this. A Distributor hooks an Observer to the Cache, which is provided by the ServerStart. Therefor, if you have multiple distributors, you have multiple observers. This means, that if you use the cache based Communication (aka adding Objects to the cache to inform registered Clients), they will receive one CachePush for each open Distributor.

RemoteObjectFactory

The RemoteObjectFactory is part of the Advanced RMI-API. It is used on the ClientStart. You can open it like this:

ClientStart clientStart = ...
RemoteObjectFactory factory = RemoteObjectFactory.open(clientStart);

With this interface, the only time you should have only one Object of it is, if you use fallbacks that should be universally available. Every instance of the RemoteObjectFactory maintains it's own set of fallbacks.

RemoteObjectRegistration

The RemoteObjectFactory is part of the Advanced RMI-API. It is used on the ServerStart. You can open it like this:

ServerStart serverStart = ...
RemoteObjectRegistration registration = RemoteObjectRegistration.open(serverStart);

With this interface, there is no specific requirement to haveonly one Object of it. Note however, that every RemoteObjectFactory works independent. You can have 2 RemoteObjectFactories, which both have the same object registered. Whichever calculates slower will be ignored. The RemoteObjectFactory will ignore any secondly received Objects for the same request.

Future plans

With the next major release (which ever this will be), some of those may be relocated into their own maven-project.

Concrete: The RemoteObjectFactory and RemoteObjectRegistration are great additions, but they are not required to use NetCom2. They will be very likely relocated.

Providing custom Modules

You can provide custom Modules, that extend NetCom2 and release them for others to use.

For that, all you have to do is, to provide an implementation of the Module interface and release it for others to use. If you want to be featured, just open an Issue to be featured. It should contain a (no so) small explanation of what your Module is about, how to use it and where to find it.