In a dynamic service-based architecture, services can come and go. Services starting always announce themselves in some way. Services may disappear gracefully and also announce this before going, or may just crash or become otherwise inaccessible (through network failure for example). It is also common in service-based systems for some signs of "liveness" to be used: services have to renew leases or repeatedly announce their presence on a regular basis.
Clients attempting to use services have to locate them. This also involves some search component, usually followed by a session in which further information about the service is obtained by the client from the service itself. Finally, clients will interact with services, typically by some action such as making remote method calls, setting up a data stream, etc.
These activities all require activity within the network and memory and cpu use within the various components. Most of these activities (except for final interaction) would not be needed in static service systems such as web services. Static systems often have addresses "hard-coded" and do not have to perform joins, disappearance and search. However, sensor networks are unlikely to be static: components will fail, run out of power or simply stop network activity to conserve power, joining in again when appropriate.
A Jini system consists of three types of entity: a lookup service containing information about services known to be (probably) alive; a set of services which register with lookup services; and a set of clients that use lookup services to locate services and make calls on these services.
Jini uses mobile objects to represent services. A service will register itself to a lookup service by uploading a proxy object in "marshalled" form. Clients download these from the lookup service and instantiate them in the client's virtual machine. The client will make method calls on the proxy object, which may or may not communicate back to the original service.
Jini services announce themselves by a multi-stage process: upon startup they make multicast searches for lookup services. Lookup services will reply using TCP and download a lookup service proxy. The service will then upload its own proxy using TCP to the lookup service. This part of discovery involves one or more multicast packets, and then TCP connections to download and upload two objects respectively in marshalled form. In addition to this network activity, the service must be able to instantiate the lookup service proxy. This will usually require a trip to an HTTP server to download class files for the lookup service proxy and enough memory within the service to instantiate the proxy.
Clients perform a similar multi-stage process to find services. They make a multicast search involving one or more UDP packets to find lookup services. Each lookup service will again download a lookup service proxy which must be instantiated within the client, usually involving a trip to an HTTP server. For each lookup service proxy they may make a request for service objects, which will communicate back to its lookup service. The lookup service will download none, one or many service proxies to the client and each downloaded proxy will be instantiated within the client, which will involve getting its class files from an HTTP server.
There is thus a large amount of network activity in both service registration and service discovery. These involves objects being instantiated in servers and clients and marshalled objects being stored in lookup services.
Additional network activity is involved in keeping the network "alive": registration of each service in a lookup service is leased and has to be renewed by a remote method call, typically every two minutes. In addition, lookup services usually announce their presence every X minutes by a multicast call.
Interaction between a proxy and its service is not specified by Jini. It could be anything: RMI remote method call, other TCP transaction, setting up an RTP stream, etc.
UPnP also consists of three types of entity, but not the same as Jini. Devices are intended to correspond to physical entities and may contain a number of services (for example, a device may contain a humidity sensor service as well as a temperature sensor service). Control points are the client side entities that use services on devices. UPnP has a "traditional" view of services: a service remains in the device and its description is made public as a url. Interaction with a UPnP service is by the remote procedure call mechanism of SOAP and the SOAP endpoints are given in the service description. A device acts as a "container" of services and the device description lists the service types and the urls of their descriptions. UPnP devices announce themselves by multicast. Since there is no lookup service to register with, anouncements are made continuously, at about one minute intervals. An announcement contains the url of a device description, from which the urls of the services can be found. The device and service descriptions are both XML documents. Clients can wait for device announcements or can make multicast search requests for devices. A client will send several multicast packets for each search request to allow for unreliable UDP transport. Each matching device will respond with the address of its device description There is a steady network traffic caused by each device announcing itself. Client search will involve a "burst" of search packets followed by an HTTP retrieval of device description, in turn followed by zero or more HTTP requests for service descriptions. While there are no object transfers in UPnP, all devices and control points must be able to parse XML documents for descriptions and also for SOAP messages. UPnP specifies that SOAP be used for procedure calls between client and service. However, they recognise that "out of band" transmissions can also occur, as illustrated by streaming media.
For any service starting up, we want to be able to say how much network traffic it generates. For Jini this will be affected by the number of lookup services but we can assume this is small (say, just one).
We also want to be able to measure the amount of network traffic to keep it alive (for Jini, lease renewal; for UPnP, repeated broadcasts)
For any client, we want to measure the amount of network traffic involved in making a search
For Jini services, how much memory is involved in "hosting" a lookup service proxy
For Jini clients, how much memory is involved in hosting a lookup service proxy and a typical service proxy
For UPnP clients, how much memory is involved in loading and parsing XML descriptions of devices and clients.
How do these scale for large numbers of services? For UPnP, this could be one service per device to many services per device. Not relevant for Jini? Jini has the memory requirements etc for the lookup service.
Additional issue: how are these affected by "volatile" services? e.g. of 10,000 services, 1,000 stop and start each second?