Design Details
B.5 Adaptation Example Scenario
B.5 Adaptation Example Scenario
An example scenario for service adaptation is given in the following. In Figure B.17 a music player is depicted. It is assembled as a compound service, consisting of a generic user interface for a music player, a music library, a music decoder and a music output device.
Music Player
User Interface for Music Player
Music Library
Music Decoder
Figure B.17: Music Player Scenario
Static Adaptation
To adapt the service to the node context, the framework discoversservice re-alisations of each sub-service and chooses appropriate realisations according to their specified resource requirements and user preferences. For instance, if two realisations for the music output service are available, such as loud-speakers and headphones, the particular choice will depend on the user. In our sample scenario, the service description of the music player describes the user interface as a local service, whereas the other services can be either local or remote. As example, for the music library either a local library of the user or a public library provided in the network can be used.
As denoted by overlapping boxes in the figure, the chosen realisation of the music decoder has two implementations. Itsnormal implementation yields good quality, and the other implementation, which has a lower en-gagement value and is therefore intended for circumstances where resources
are short, yields lossy quality.
If no appropriate realisation of the music decoder is found that suits the node context, a possible realisation that is provided for local deployment could be also instantiated on a remote node by using the resource service concept, if a generous node is found in the network. In doing so, the network context has to be considered, thus it has to be checked if the network can provide the required bandwidth.
If the service realisations cannot be chosen such that all ports match the format of their counterpart, the framework can insert corresponding converter services, if available. For instance, if the resolution of the music decoder output format is 16 bit, but the input of the music output service requires 24 bit, a converter service could be inserted that adjust the format.
During service deployment also the interactive service attributes has to be determined. Such attributes could be the user interface language and the audio output format and bitrate of the music library.
In the following we assume that after static adaptation, an appropriate user interface and music decoder (normal implementation) is locally de-ployed. The music library is invoked remotely and only instantiated once, as such a library is not suited for replacement and therefore also not suited for redundant operation. For the output device remote loudspeakers are invoked.
Dynamic Adaptation
If, during execution of the music player, the user walks to another room, he/she might want to exchange the output device, as he/she cannot hear the loudspeakers anymore. So the user prompts the framework to present available music output devices and replaces for instance the loudspeaker with the locally attached headphones. In another case, where the remote loudspeakers become inaccessible in the network, the framework will request the user to choose a new output device. Furthermore, the user may request the framework to direct the music to more than one device. To lessen the number of user interactions, the user may also predefine a list with preferred service realisations, thereby the framework will always try to choose a service of this list.
B.5 Adaptation Example Scenario Appendix B
During service execution also the node resources can change. If the available resources become short, the framework will first prompt the service to perform its service intelligent adaptation, if the service did not do it already autonomously. For instance, if the availability of working memory becomes short, the service could decrease the amount of cached information.
If the service still overstrains the resources, the framework applies the service adjusted adaptation. Thereby the interactive attributes and the dif-ferent service implementations can be used. For instance, if the available network bandwidth decreases, the framework can adapt the audio bitrate used between the music library and the music decoder, if this bitrate is spec-ified as adynamicattribute in the service description. If this attribute is not specified or specified only as information, the service may adapt this bitrate in its service intelligent adaptation. Furthermore, if the node resources are short, the framework may decide to replace the normal implementation of the music decoder with the less costly one. Thereby short interruptions in the service execution may occur, as on the one hand, the framework does not react immediately to resource variations (to filter out transients), and on the other hand, replacement of an implementation will take some time.
If the resource shortage is over and resource availability stays on a high level for a certain period, the framework will replace the implementation again with the normal one.
If all previous adaptations did not solve the problem, the service in-dependent adaptation will take place. Thus, the music decoder could be instantiated on a remote node by using the resource service concept or re-placed by a better realisation, if such a one is available in the meantime.
Finally, the music player could also be terminated.
B.6 Examples of Service Description and Discov-ery Documents
In the following, some examples ofservice description and service discovery documents are given.
B.6.1 Service Description Document Examples
In this section some examples of service description documents are given.
The specification of the service description can be found in Appendix B.4.1.
Figure B.18 shows the description for a chess game. The game uses service sessions that consists of two service participants of the same role type. A individual service role is thereby locally executed in Java, and two implementations are specified for the service that differ in program size and needed working memory size.
Figure B.19 shows the description of a remote service that provides weather forecasts. The description specifies the corresponding ports, types and bindings. After the local ports have been registered to the remote ser-vice by using the specified bindingurl, the service can be used by query the remote service with a discovery message (WeatherForecastDiscovery) that specifies the location and date of the desired weather forecast. The service will reply with a message (WeatherForecastReply) that either contains the weather forecast or an error information as text.
Figure B.20 shows a fragment of the description of acompound service.
The service includes the subservices music decoder and music output that are interconnected. The description of the subservices can be directly used in a service discovery document to discover the corresponding subservices.
Figure B.21 describes a service that uses attributes. The attributes are also referenced by the output port of the service, which indicates that the at-tributes describe the characteristics of the corresponding port. The attribute outputFormat is only informative and specifies the used audio format of the port. The attributesoutputBitrate and outputSampleRate are both interac-tive, and enable the framework to dynamically choose the bitrate and the sample rate of the audio output port of the service according to the specified values.
B.6 Examples of Service Description and Discovery DocumentsAppendix B
Finally, in addition to the service description of the real-time mulitplayer game Rolf ’s Blast: client/server version in Section 5.3, the service descrip-tion of the corresponding server is presented in Figure B.22 and the service description of the peer-to-peer version of the game is given in Figure B.23.
B.6.2 Service Discovery Document Examples
In this section some examples of service discovery documents are given.
The specification of the service discovery document can be found in Ap-pendix B.4.2.
Figure B.24 presents the discovery document to discover services with identifier ”.../Games/Multiplayer/TurnBased/Chess” that can be locally ex-ecuted in a Java environment and that uses not more than 20000 bytes of working memory. The matching of theuri is specified as partial, this means that not only service descriptions with the same identifier could match, but also services with a more specific identifier, such as ”.../Multiplayer /TurnBased/Chess/MyChess”, or services with a more general identifier, such as ”.../Games/Multiplayer/”, could match the discovery document. This discovery document would therefore match the service description of the chess service described in Figure B.18.
Figure B.25 presents the discovery document for all services in the net-work that are executable on Palm OS and which consume not more than one megabyte of working memory.
SERVICE
Figure B.18: Sample Service Description: Chess (Service with Sessions)
B.6 Examples of Service Description and Discovery DocumentsAppendix B
Figure B.19: Sample Service Description: Weather Forecast (Remote
Ser-SERVICE
Figure B.20: Sample Service Description: Music Player (Compound Service)
B.6 Examples of Service Description and Discovery DocumentsAppendix B
Figure B.21: Sample Service Description: Synthesizer (Attributes)
SERVICE
uri = rosamon://Service/Entertainment/Games/Multiplayer/RealTime/RolfsBlast/ClientServer/Server url = rosamonTransport://192.168.0.4:4440/Rosamon/Services/Descriptions
completeness = true
comment = Server for Rolf’s Blast client-server version.
The server is not a player in the game.
GENERAL
name = Rolf’s Blast: client/server version (server) version = 1.0
Figure B.22: Service Description: Rolf’s Blast: Client/Server Version (Server)
B.6 Examples of Service Description and Discovery DocumentsAppendix B
SERVICE
uri = rosamon://Service/Entertainment/Games/Multiplayer/RealTime/RolfsBlast/PeerToPeer url = rosamonTransport://192.168.0.4:4440/Rosamon/Services/Descriptions
completeness = true
comment = Funny multiplayer game. Shoot the other players in a labyrinth.
Peer-to-peer version, which needs no service management by the Rosamon framework.
GENERAL
name = Rolf’s Blast: peer-to-peer version version = 1.0
Figure B.23: Service Description: Rolf’s Blast: Peer-to-peer Version
REQUEST SPECIFIC
matchUriPartial = true SERVICE
uri = rosamon://Service/Entertainment/Games/Multiplayer/TurnBased/Chess IMPLEMENTATION
CODE
ENVIRONMENT EE
name = J2SE version = 1.4 DEMANDS
memorySize <= 20000 bytes SESSIONS
Figure B.24: Sample Service Discovery: Chess
REQUEST SPECIFIC
matchUriPartial = true SERVICE
IMPLEMENTATION CODE
ENVIRONMENT EE
name = PalmOS DEMANDS
memorySize <= 1024 bytes
Figure B.25: Sample Service Discovery: Service for PalmOS