| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
Communication Bus Architecture (CBA)
-- conceived of and written by Borne Mace
Get the source! http://www.jos.org/source/org/jos/util/bus/
Technologies Involved:
Objects Involved:
Overview (Draft 2 (17-April-1998)):
The CBA has changed in scope a bit from its conception, and what I used to refer to as the CBA is now two separate entities, one still being referred to as the CBA and the other being the Massively Extensible Service Systems (MESS).
CBA Overview (Draft 1 (17-April-1998)):
The current concept is that there will be a main InfoBus for the Jos JVM. Applications will need only implement the BusMemberListener interface and access the InfoBus though the instantiation of a BusMember object. The BusMember object was developed to greatly simplify the process of connecting, listening, and posting to the InfoBus. The application can register it's interest with the BusMember, and the BusMember can automatically filter incoming bus information so that the application only gets the information it is interested in. BusEvent are what is sent to the application from the BusMember, it is sent though the BusMemberListener interface. In this way, multiple classes can listen for incoming information from a single BusMember object.
The BusMember can hold information about the application it is acting as a proxy for. Information it can hold includes a name, description, and a list of attributes. These attributes can be any kind of object. The information is accessed through the BusMemberInterface interface. The BusMembers information holding capabilities are implemented using a BeanDescriptor object.
The MESS is being implemented using the CBA, this will be both a proof of concept for the CBA and an excellent example for integrating CBA capabilities quickly and easily into any application. The alpha release of the CBA is finished other then some additional documentation that needs to be done, for the alpha release a few lesser capabilities have not been implemented.
MESS Overview (Draft 1 (17-April-1998)):
The MESS involves most of what I explained in the 1st Draft of the CBA(below) and based on that you can see where I got the name. I will attempt to clarify it's capabilities a little further in this version of the document.
The alpha release of the MESS is based mainly on two objects, the ServletManager and the TcpListenerManager, so it will be those two objects and their interaction that I will explain further.
The TcpListenerManager will allow an object implementing the TcpConnectionListener interface to register as being interested in information about incoming connections on a certain TCP socket. At this point the TcpListenerManager will create a TcpListener to listen for incoming requests on that port. If there is already a TcpListener assigned to that port the requestor will be notified and no TcpListener will be created. If/When a connection comes in on a port a TcpListener is listening on, it will notify the requestor that a connection was made and pass the requestor the connection socket, the TcpListener will then go back to listening on the socket for more connections.
The ServletManager acts as a single point of control for most/all system services (such as an HTTP server, imap4 server, pop3 server, ftp server, etc..). These services will be implemented in the form of servlets. The ServletManager will register with the TcpListenerManager for it's servlets, and hand incoming client requests off to the appropriate servlet. Several services which the servlets may need (such as authentication and encryption services) could be offered at this ServletManager level.
Currently the MESS is implemented to the point that the TcpListenerManager can communicate with the ServletManager through the CBA but that is all. I have estimated an alpha release of the MESS by the 1st of May. At that point additional capabilities (such as the ServiceRegistry and RMI functionality) can be added before the beta release.
I have currently postponed the implementation of the UdpListenerManager, UdpListener, and UdpConnectionListener until a not yet determined point in the future. There is a lot more to get working before worrying about the lesser used datagrams.
Overview (Draft 1 (15-April-1998)):
Object communication and socket communication are somewhat different, and my approach attempts to combine the two together to support both old style socket services and RMI/IIOP compliant server side objects. The JosServiceRegistry would be in essence an RMIRegistry and support the registration of RMI Services and brokerage of RMI requests to the appropriate service. The JosServletManager would support the registration and invocation of servlets based on incoming TCP/UDP information from the JosTcpListenerManager and JosUdpListenerManager. The ServletManager would register interest in information (TCP or UDP) with the appropriate ListenerManager, at which point the ListenerManager would start up a Listener of the appropriate type on the appropriate port, and wait for incoming information. When incoming information was received the ListenerManager would notify whomever registered interest in the port that an incoming connection was received. This means objects other then the JosServletManager could use the TCP and UDP ListenerManagers.
The JosServletManager would implement JosConnectionSubscriber (as would any other object interested in receiving information about incoming connections) and the ListenerManagers would implement the JosConnectionPublisher interface. In this way multiple objects could receive information about incoming packets on a certain port. It is questionable whether information beyond the arrival of the connection should be distributed in this manner, since if multiple objects were given a handle to a tcp socket and used it greatly odd things could occur, then again, perhaps we want capabilities like that.
My reasoning behind the break up of the TCP and UDP ListenerManagers was two fold. First was because TCP and UDP network communications are very different and specialized managers should be faster at handling incoming connections. On the other hand, the UDP service may very well want a direct reference to it's JosUdpListener without the overhead of the JosUdpListenerManager in cases where streaming UDP information is coming across the network, and it could bog down the JosUdpListenerManager. I think it also feasible to run RMI in the same manner, and create the Server side RMI objects one the request comes in. In this was Servlets could often act as TCP, UDP, and RMI information handlers to provide a specific functionality across all network protocols.
Other then initial discovery I don't know to what point I currently want to use the InfoBus technology, but lets all talk about this and hash out some concepts. I would like to get implementing this (or whatever we decide on) ASAP.
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|