This section describes the protocols that embody the service model. First, a general description of the service architecture is presented. Second, the service discovery protocol is explained. And lastly, we explain how a service provides a control interface to a client application.
The service model is composed of three components: service abstractions, a service discovery service, and a client API. Services are processes that provide useful functionality for clients. Clients are processes that use services. The Service Discovery Service (SDS) is a directory service that allows a client to locate desired services. For example, dc discovers available services when it is executed and uses services selected by the webcast. A simple webcast may only need a single camera service while the Berkeley MIG Seminar webcast requires two camera services, an archive playback service for the opening segment, and a special-effects service. The service model allows dc to configure the services required for the particular broadcast.
SDS is a service that lists available services in the infrastructure through a soft-state protocol [17]. A push-pull protocol is used to gather and retrieve information. Services push information to the SDS service and clients pull information from the SDS service. Idle services periodically announce their presence to a well-known multicast address. This information is cached by the SDS service. A timer is associated with the information when it is received. The timer is decremented every half-second. Periodic updates by the services reset the timer. If the timer goes to zero, the service is assumed to be unavailable (i.e.- killed or busy).
Clients query the SDS service cache to locate a desired service. The query can request a specific service or a collection of services (e.g., ``all services in 405 Soda"). The SDS process responds with data that satisfies the query. Clients periodically query the SDS service to discover new services.
The service information returned to the client includes the contact and attribute information required to access and use the service. Service attributes provide information about the service (e.g., location, functionality, etc.) and are used to distinguish service types. Contact information includes an IP address and port number pair that can be used by the client to initiate communication with the service.
A client application uses the IP address and port number pair to create a TCP connection with a service. An ad-hoc, non-blocking Remote Method Invocation (RMI) mechanism is implemented that allows the client to invoke methods on service objects.
After initializing and establishing communication with a service, the client application displays a user interface to control the service. The control interface must be provided to the client by the service. Otherwise, the introduction of a new service will require either: 1) that the client source code be modified or 2) the service control interface be limited to a few predefined interfaces. Our experience with webcasting is that the infrastructure varies from room-to-room and is constantly changing. Consequently, the service interface must be incorporated into the definition of the service.
Dc uses the GetUIControl method to obtain the interface code segment from the service. This code segment when evaluated will display the control user interface and handle input. Dc is implemented in Tcl/Tk so the code segment is a script that creates the interface and input event mappings. The code segment has two arguments: a window and a socket. The service interface widgets are displayed in the window, and the socket is the TCP connection to the service process. Dc supplies the arguments when it evaluates the code segment. The socket is used to handle user interface events. For example, a StartReplay method is invoked the on a replay service object when the Start button is pressed in the replay dialog box shown in figure 7.