Modules

With V.2 of NeCom2, the Module-interface was introduced.

This Interface is a simple abstraction layer, to allow for extensions of the default functions, without the need to re-introduce new updates. All of the implementations follow one design-principle: static factory methods in interfaces. They define a "open" method, which allows you, to connect them to the representing NetworkInterface (ClientStart or ServerStart)

With the next major release (V.3, or V.2.1), some of the provided Modules will be released within their own maven-repository.

Pre-installed Modules

There are a total of 3 pairs of Module-implementations, that come native with NetCom2. Those are:

Communication

On the Client-Side, the Sender is a Module, that allows you to pass Objects to the Server-Side. The Sender can be used like this:

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

The functions are the same, as with V.1 and can be seen throughout this wiki. On the other side, we can see the Distributor interface, which will be added like this:

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

Advanced RMI

The Advanced RMI-API is explained in detail [here][https://github.com/ThorbenKuck/NetCom2/wiki/Advanced-RMI]. The 2 Modules, required for this, can opened like this:

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

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

Note

This Module is most likely going to be extracted into a separate maven-module with the next release! It is no basic functionality and therefor a simple extension.

Not marked Modules

There exist one type of Module, that does not require a specific NetworkInterface, yet is able to be connected to one or to instantiate one for you. These Modules are "SimpleModules", which do not inherit from the Module interface. They still are non-essential Extensions though.

Service-Discovery

NetCom2 brings with it a way, to utilize UDP for Service-Discovery.

This Service-Discovery is explained in detail [here][https://github.com/ThorbenKuck/NetCom2/wiki/Service-Discovery]. The Modules used for this are the following:

On the Client-Side, we use the ServiceDiscoverer

// To use the port 8787
ServiceDiscoverer discoverer = ServiceDiscoverer.open();
// To use a custom port
int port = ...
ServiceDiscoverer discoverer = ServiceDiscoverer.open(port);

On the Server-Side, we us the ServiceDiscoveryHub, again, nearly identical to the ServiceDiscoverer

// To use the port 8787
ServiceDiscoveryHub discoverer = ServiceDiscoveryHub.open();
// To use a custom port
int port = ...
ServiceDiscoveryHub discoverer = ServiceDiscoveryHub.open(port);

However, you can also provide more informations, like the hub-name and the target port for the ServerStart. For that, you can hook the ServerStart to it. See the Article for more informations.

Note

This Module is most likely going to be extracted into a separate maven-module with the next release! It is no basic functionality and therefor a simple extension.

Contributing

If you feel compelled to extend NetCom2, but don't want to dive deep into the mythical inner workings and complex mechanisms of NetCom2, you now can provide a simple maven-module/-project that provides an outside extension. In your Project, just create your own Module implementations and provide them to others (for example via maven-central).

Contact any developer, to get your Module featured on this site. You will not get featured, if your Module(s) are extremely bad designed and/or break NetCom2.

No one can force you, but for future improvements of the inner workings of your Module, we highly recommend that you use interfaces as much as possible and (instead of manually creating the new Object, i.e. Foo foo = new FooImpl) provide a static factory method within your interface (i.e. Foo foo = Foo.create() or Foo foo = Foo.open(new Bar())). This allows you, to change names, change signatures and so on, without the need of every developer to adapt to your change. You have way more freedom this way.

A tip to get you started: If you REALY need to have the Client, which is associated with the ClientStart, create a package, that is called com.github.thorbenkuck.netcom2.network.client, insert your module here and now you can cast to the NativeClientStart, which provides a Method called .getClient(). HOWEVER: If you do this, with any future release, your Code might break!