Service discovery protocols can be thought of as network protocols that allow for the automatic detection of both services and devices that are offered by a computer network’s various devices. There are a lot of service discovery protocols available. In this article, we will take a look at the attributes of three of the more popular ones – Service Location Protocol, Simple Service Discovery Protocol, and UDDI for Web Services.
Before we proceed, we should point out that a Service Discovery Protocol should not be confused with a Session Description Protocol. The latter is used to describe multimedia sessions for the purposes of session invitation, session announcement, and other forms of multimedia session initiation.
Service Location Protocol
The Service Location Protocol can be thought of as a service discovery protocol that allows for computers and other related devices to find services in a local area network sans prior configuration. Service Location Protocols have been designed to scale from smaller networked that are not managed to larger enterprise networks. In RFC 2608, Server Location Protocols are defined as Standards Track documents.
Service Location Protocol is employed by devices as a means of announcing services on a local network. Each service has to have a URL that is then utilized as a means of locating that service. What is more, it may have to have an unlimited amount of name value pairs, which are referred to as “attributes.”
Every device has to be always in at least one scope. Scopes can be thought of as simple strings. They are used as a means of grouping services. Scopes can be compared to the network neighborhood in other systems. A device is typically unable to see services that are located in different scopes.
A printer’s URL might resemble the following:
Such a URL is descriptive of a queue called prnqueue that is situated on a printer with the host name ntprinter. The protocol that is used by this printer is LPR. Keep in mind that a special URL scheme called “service:” is also being employed by the printer.
These URLs are not necessary, but any URL scheme may be employed. Doing so allows you to search for all kinds of services of the same type, regardless of the protocol they employ.
The three premiere components of the URL type “service:” are also referred to as server type. The first of these two components are referred to as “abstract service type.” In a URL schema that is not related to “service:”, the name will always be for the service type.
So a printer’s attributes might resemble the following:
The above example utilizes standard syntax for attributes in SLP. The only thing that has been added is a series of new lines in order to improve the example’s readability.
Service Location Protocol assigns three different roles to devices. A device may also have more than one role – up to three at once. The roles are as follows:
- User Agents
- Service Agents
- Directory Agents
Today, the vast majority of daemon implementations are able to act as both Service Agents and User Agents. They can typically be configured to become Directory Agents also.
The Service Location Protocol is a protocol that is packet oriented. The vast majority of packets are transmitted through UDP. TCP can also be utilized for the transmission of longer packets, though. Owing to the potential unreliability of UDP, Service Location Protocol repeats all multicasts a number of times in increasing intervals until an answer has been arrived at.
All devices are required to listen on port number four hundred twenty seven for UDP packets. Directory and Service Agents should also listen for TCP on that port. Multicasting is utilized extensively by Service Location Protocol, especially by devices that join a network and are in need of seeking out similar devices.
Service Location Protocol’s operation can differ tremendously depending on whether or not a Directory Agent is in the network. When a client initially joins a network, a query is multicast for Directory Agents on that network. In the event that no Directory Agent answers the query, then it will be assumed that it is in a network without Directory Agents.
It is possible for Directory Agents to be added later, when they multicast a “heartbeat” packet in an interval that is predefined, which will be received by all the other devices in the network.
When a DA is discovered by an SA, then it is required to register all services at the Directory Agent. When a service vanishes, then the SA should contact the Directory Agent in order to cancel the registration.
To send a query through a network without a Directory Agent, the UA will have to send a multicast UDP packet that contains that query. All the SAs that boast matches will then send a UDP answer to the UA in question.
If the answer will not fit in to a UDP packet, then the packet will be identified as “overflown.” At that point, the UA is then free to send the query directly to the SA utilizing TCP. TCP is capable of transmitting packets of any size.
In order to be able to send a query in a network with a Directory Agent, the UA will have to send the query to the Directory Agent utilizing either TCP or UDP. Every SA must register all services with the Directory Agent; thus, the Directory Agent should be able to fulfill the request totally and will then simply send the result to the UA.
Simple Service Discovery Protocol
A Simple Service Discovery Protocol is an expired IETF Internet draft that was co-authored by Hewlett Packard and Microsoft. Simple Service Discovery Protocol forms the basis of the Universal plug and play discovery protocol.
The Simple Service Discovery Protocol provides a method through which different network clients may uncover network services. Clients make use of Simple Service Discovery Protocol with very little static configuration – or none at all. Simple Service Discovery Protocol provides multi cast discovery support, discovery routing, as well as server based notification.
UDDI for Web Services
UDDI stands for Universal Description, Discovery, and Integration. It is an XML based, platform independent registry for businesses all over the world who would like to be listed on the World Wide Web.
Universal Description, Discovery, and Integration is an open industry initiative that is sponsored by OASIS. It enables companies to publish service listings while discovering one another, as well as defining the ways in which services and software applications interact over the World Wide Web.
A business registration through Universal Description, Discovery, and Integration consists of the following three components:
- White Pages
- Yellow Pages
- Green Pages
Universal Description, Discovery, and Integration is regarded as one of the main standards of Web Services. Universal Description, Discovery, and Integration is designed to be interrogated by SOAP messages while simultaneously rendering access to Web Services Description Language documents that describe the message formats and protocol bindings that are necessary for interaction with web services listed in the directory.
Universal Description, Discovery, and Integration was composed in the year 2000 during a time when authors had a vision of a world in which consumers of Web Services would be linked up with providers through either a private or public dynamic brokerage system.
In such a vision, anyone who was in need of a service like credit card authentication could then go to their service broker and choose one supporting the desired SOAP or other service interface and meeting other criteria. In a world like that, the publicly operated Universal Description, Discovery, and Integration broker or node could be critical for everyone.
For the customer, open brokers would return services that were listed for public discovery by others. For the providers of services, the ability to get a good placement through a reliance on the metadata of authoritative index categories within the brokerage would be essential.
The Universal Description, Discovery, and Integration has been integrated in to the Web Services Interoperability standard as a central component of the infrastructure of web services. By the year 2006, it was on the agenda to be utilized by over seventy percent of the Fortune 500 businesses in either a private or public implementation – especially among those businesses that were looking to optimize the reuse of services or software.
A lot of those businesses subscribe to some type of service oriented architecture, server programs, or database software that is licensed by some of the main founders of OASIS and UDDI.org.
The Universal Description, Discovery, and Integration specifications supported a Universal Business Registry that was accessible by the general public. Such a registry was based on a naming system that was built around a Universal Description, Discovery, and Integration driven service broker.
In early 2006, it was announced by Microsoft, SAP, and IBM that they would be closing their public Universal Description, Discovery, and Integration nodes.