Fis-TransportInterface/doc/explanation.txt

Currently the way it works is, tranport service, which is the websocket or http or whatever transport protocol that is selected will have a universal emit and subscribe public method 
so, the concept of having bi directional will be somewhat weaved into every class object of said transport service. What it will do is that, when a client is connected, i mean it 
doesn't have to be literally like in the case of http, we will assume a logical channel so to speak. So when a client is connected, the connected client will be assinged an ID,
one that will be used by the connection manager to instantiate a set of adapter with the assigned id, to identify the client as well as the type of transport it used. 
Essentially, a set of adapter is tied to one client and it's associated transport type.

There the core of this transport interface, or at least that what I will choose to call it, will communicate with transmission manager, which in turns will be communicating with 
connection manager to handle how the message is received and transmitted. The need for this is to allow the integration for re-transmission service, so that messagecan be 
re-transmitted over, should there be an interuption of sorts. 

Now, in this context, we are talking about a server that can have multiple client connected to it, so that means there is a need to manage multiple 'traffic' with these connectedc
clietns. To remember their credentials so as to be able to handle retransmission should they lost connection for whatever reasons, while dealing with various type of transport.
FOr now, the example provided is only using websocket at the moment, another transport sample, which is http will be prepared at a later stage when i get this websocket working,
with multiple clients as well as the server acting as a receiver itself. 

So, when an application starts, which assume to be the provider, will instantiate a transmission manager. The transmission manager will in turn instantiate a connection mnager ,
and the connection manager will also instantiate a transport service specified at .env file. Once that is done, the connection manager will then subscribe to the transportevent 
also instantiated within it's component, and be exposed to transmission manager as well, so that all the concerned parties that are subscribed to transport event, will know what's 
happening. So, in this websocket's context: A client is connected, a transport event is reported and announced. Connection manager will listen to this type of event and 
instantiate a set of adapters to cater for this specific client. It will keep a copy with it's class, and can be retrieved by transmission transmitter and receiver and request response
class. They too will also be listening to new adapter set event so to speak, and store the reference pointer in it's own local memory array. 
So here's how it is, the app which is 
the producer, once calls for transmission manager to instantiate a set of transmission methods, which is the message transmitter, receiver and request response class, which doesn't 
care what the underlying transport that is being used, will use the instantiated objects to perfrom all the available methods to transmit and receive message, even as far as 
emulating request response behaviour. So, when the producer wants to send a message, it will send through the message transmitter instantiated earlier. By the way, forgot to mention,
when a client is connected, an ID will be assinged to the client, the same id that was assigned is also assigned to the adapter, which makes it easier to be managed later as I continue
to develop this point. I probably mentioned this a few paragraphs, but anyway, as I was sating the message transmitter will read the message and see what adapter it's using,
and search through it's array adapter ref, to find the matching adapterID, and then using that adapter to pass along the message. The adapter tha was chosen would have already been
mapped with it's associated transport service to send the message out to the respective clients. At least that whole gist of it. 
With that in mind, the retransmission service will sit at the adapter side, since each adapter is tied to one client and it's respective transport type, so it's easier to manage.
All events or activities will go through one, well "global" subject, which is the transport event instantiated at connection manager.