FADA stands for “Federated Advanced Directory Architecture”. It is a virtual Lookup Server in the sense that different Lookup Servers (FADA nodes) will work together to provide the LookupServer functionality from any entry point. Also, any of these Lookup Servers will cooperate with the rest to find implementations of services.
This is the major difference with Jini. With Jini you can have as many Lookup Servers as you want within a LAN, but the client is responsible to find them all (though facilities are provided). In Jini LookupServers don’t cooperate, so in order to find a service proxy the client has to ask them all. The good news is that broadcast protocols are fairly efficient in a LAN, so a client can make just one lookup request on all Lookup Servers. Unfortunately this can not be achieved in the internet without additional logic and cooperation among LookupServers.
This is exactly what FADA provides. Furthermore, the FADA is a truly distributed system, in the sense that there is no central authority or common communication channel, and LookupServers inner to the overall virtual LookupServer operation of FADA work in a peer-to-peer fashion. The overall topology is an hybrid centralized + decentralized topology, where the distributed FADA architecture acts as a centralized server from the clients’ point of view.
The FADA (as well as Jini) holds proxies for services. A proxy is a Java class that performs communication with a real service, and that can be downloaded at run-time by clients. Clients use the public methods on the proxies to access the services. These public methods are specified in Java interfaces that service proxies implement. A FADA node is a service that acts as an entry point to the database.
Service providers must implement Java classes that act as a gateway to use their services, which may be written in Java or not. In case they aren't, the Java class they provide to the federation, the service proxy from now on, can use whatever method to communicate with the service. For example, the service could be written in C, and using JNI the service proxy could access the service. Or the service could be accessed through http, and the service proxy could open sockets to the proper ports to communicate with the service. Or it could be implementing some JXTA service. Writing a service proxy in Java doesn't force any kind of implementation on the server side. Only a minimum of compatibility is requested.
Note that these proxy objects will be executed in the client's machine, so this fact must be taken into account when designing and implementing service proxies.
We've seen the similarities between FADA and Jini. But, due the fact that FADA will work over whole Internet, FADA also has some differences from standard Jini:
FADA nodes are designed and implemented to work together. This means that FADA nodes are ready to contact and collaborate with other FADA nodes by default. Although Jini Lookup Services can be federated, FADA has this behavior built-in, and users of FADA (both service providers and clients) don't have to deal with it.
The Jini sample implementation was thought for working over broadcast capable, low-latency LANs, and uses some of the features of such networks to achieve its job. FADA is designed to work over the Internet. This introduces several differences:
Jini uses broadcast to discover the available Jini Lookup Services; broadcast can not be achieved in the Internet: first of all routers refuse to propagate broadcast packets, but in case they didn't a single packet would flood the whole Internet to reach every single connected host. In case some of them responded with a broadcast too, this would provoke a packet storm, disturbing other hosts not involved in the communication. In a LAN this is not an issue. In the Internet this approach can not be used, so discovery is not performed (by now) by FADA nodes. They need an explicit reference to already existing FADA nodes. This problem is actually being worked on.
Jini does some of its housekeeping thinking in the low delays of a LAN. For example, service proxy registrations are not granted, but kept for an amount of time called the lease time. Service providers get a lease object upon registration. If they wish to keep the registration up they must periodically renew this lease. Jini offers some ways to automate this mechanism for the service providers. But these mechanisms are based on the knowledge of a low delay for communication between hosts in the LAN. This statement doesn't keep true for the Internet, where delays of several seconds are not rare. The default Jini behavior must be changed. FADA takes into account these high delays, and tries to adapt to them. Failure recovery in certain situations has also been contemplated and achieved.
Jini performs communication over a reliable network, say the LAN. But FADA deals with the higher possibility of network failure of the Internet: the more involved parties, the higher the probability of error. It doesn't rely on reliable connections. This leads to an approach of doing things “maybe once”, instead of “at most once”, as it is not possible to assure things will be done exactly once. Despite that, FADA is not very sensitive to failures: only performance degrades.
Another great difference between Jini and the FADA is that the former uses RMI as the basic communication channel, while the FADA uses HTTP. Although RMI can be tunneled through http with the help of certain cgi script made available by SUN Microsystems, there is an implicit overhead when transferring objects through such channel. FADA nodes exchange potentially shorter messages to cooperate, and thus the overhead is diminished. Also, working with http directly allows clients to interact with the FADA through firewalls, provided that there is some kind of http proxy or tunnel available.
Project hosted by