Distributed Applications Vs Service Oriented Architectures

Service-based distributed applications are based on strong agreements on where the services are located and what kind of functionalities they provide. For example, in the following figure, a user interface service sends a query to a serch service, which in turn decides which index service can better reply to the query. The search service hardcodes the references to the two index services. The drawback of this choice is that whenever an instance of an Index Service has to be added/removed from the architecture, the status of the search service needs to be manually modified. In turn, this means that it is hard for multiple organizations to cooperate over the same distributed system.


In a Service-Oriented Architectures services can join (registering a profile) or leave (unregistering the profile) the system anytime; e.g., peer to peer applications. To this aim SOAs are operated by so-called Enabling Services, which are in charge of keeping the map of available services and offer discovery mechanisms. Typically, services are designed to discover on demand and interact with services of given types (i.e. providing certain APIs and relative functionalities), rather than to refer to known instances of services. The figure below shows how the search scenario above can be interpreted in a SOA.


In this scenario, both User Interface Services and Search Services must dynamically look up the Enabling Services to find the search services and the index services, respectively, that are available for their use. Note how the introduction of a new search service in the architecture (the one on the right), is followed by: registration of the service, look up of the status to automatically configure the service, and finally notification of the registration of the new services to the user interface, which subscribed to such events. By subscribing to registration and unregistration of a type of service (e.g. search service), the consuming service (e.g. user interface service) can avoid "polling", i.e. repeated look up operations to the Enabling Services to update the internal status.