The development of ubiquitous computing systems benefits tremendously from the service-oriented computing concept in seamless interoperation of heterogeneous devices. However, architectures, services interfaces and network implementation of the existing service-oriented systems differ case by case. Furthermore, many systems lack the capability of being applied to resource constrained devices, for example, sensors. Therefore, we propose a standardized approach to present a service to the network and to access a networked service, which can be adopted by arbitrary types of devices. In this approach, services are specified and exposed through a set of standardized interfaces. Moreover, a virtual community concept is introduced to determine a secure boundary within which services can be freely discovered, accessed and composed into applications; a hierarchical management scheme is presented which enables the third party management of services and their underlying resources. In this way, application control logic goes into the network and environment context is dealt with intelligently by the system. A prototype system is developed to validate our ideas. Results show the feasibility of this open distributed system software architecture.
Applications based on the concept of Ubiquitous Computing [
Lots of research has been done spread over different applied areas of ubiquitous computing systems; no standard approach has resulted however. The architecture, the interfaces of services and the network implementation of these systems are different. Each system uses its own format to describe services and its own communication mechanisms. Additionally, application logic is typically encapsulated in the services and this makes the reusability of these systems rather difficult. Furthermore, many systems totally lack the capability of being applied to resource constrained devices like, for example, sensors.
We believe that a standardized approach to present a service to the network and to access a networked service, which can be adopted by arbitrary types of devices, is of high importance to provide a better interoperability and collaboration of heterogeneous devices and services. Security and privacy issues should be equally important as genericity and flexibility in this approach, since service providers do not want to share their services with just anybody. Secure service discovery and access must therefore be guaranteed. In addition, communication needs protection from being overheard. Moreover, application control logic should not be in the services but in the network. Environment context, like heterogeneity of networks, capabilities of devices, error-prone wireless channels and device mobility, should be dealt with intelligently by the system rather than by the users. In our research we have found the following to be the groundwork of the system architecture of ubiquitous computing systems.
• Control is separated from service functionality through third party binding. Services are passive and do not know their composition context.
• Services are specified and exposed in a generic way through a set of standardized interfaces, with parts for regular service functionality, external binding and external control.
• This interface definition should be more abstract than the standards (like UPnP and WSDL). We designed such an interface and separate (automated) mappings to UPnP and WSDL.
• A grouping and scoping concept is needed to limit service discovery and access. For this, we introduce the concept of virtual community. In this context a virtual community represents a security boundary that determines a secure service discovery, access and collaboration environment: within this environment, services can be freely discovered, accessed and composed into applications.
• Services and resources must be managed to allow robust applications and to adapt service quality. We designed a hierarchical management scheme that admits third party management. This management admits application oriented end-to-end QoS (Quality of Service) optimization through context-awareness.
In this paper, we propose an open distributed system software architecture which meets these mentioned requirements. The corresponding prototype system is called VICSDA (VIrtual Community-based Secure service Discovery and Access). In VICSDA, services hosted by devices are exposed in a generic way to enable the collaboration over a heterogeneous networking environment. Following component technology [9,10], capabilities of a service are expressed as provided interfaces; capabilities a service needs for its work are specified as required interfaces. Service compositions are created by connecting (binding) these required and provided interfaces. Special interfaces are used to program the extra-functional aspects including security, management and discovery, but also the mentioned binding. Separate orchestrators are capable of searching services and connecting them to form applications; the orchestrators can also expose themselves again as services. In this way, applications can be achieved by service collaboration [2,3] and application control logic goes to the network.
In order to protect services privacy, services can be organized into virtual communities (VCs) and become community services by implementing security-related interfaces. Consequently, only authenticated users can access community services. Service discovery, access, and collaboration all happen in the scope of a VC and are managed through a set of community services. Aiming at context-aware ubiquitous computing systems, management-related services and interfaces are implemented, based on a hierarchical resource management schema.
We present the approach in the following way. Section 2 presents the generic way of exposing a service to the network. How the prototype system VICSDA provides a reliable, flexible and scalable service collaboration environment through external orchestration is detailed in Section 3. Section 4 describes a 3D video streaming prototype to validate the feasibility of VICSDA. Finally, we discuss some related work and draw conclusions in Sections 5 and 6, respectively.
With respect to the mentioned 5 points in Section 1, the lifecycle of a ubiquitous computing application, depicted in
A service provider exposes a set of functions in the form of a generic service to the network.
When a service enters the network, it makes its presence known to other services on the network. This can be done using two mechanisms: mediated or immediate. If there is a repository service appears, it sends out the advertisement through e.g. broadcast or multicast. Services who are interested in this repository record this information and register themselves at this repository next. If there is no repository available, services broadcast themselves.
When there is a requirement of an application, an orchestrator is going to achieve it through service combination following the below steps. Security is an important concern in this step although not shown in the figure.
1) Service discovery: based on the situation whether there is a repository service, the orchestrator discovers required services through mediated or immediate way. It sends out service queries and then receives a list of available services with required functionalities.
2) Service binding: the orchestrator informs specific services to bind with each other in an order according to the application logic. During this process, the orchestra-
tor checks the match between services, e.g., the interfaces and the communication protocols.
3) Service invocation: this is the stage where a service is connected and invoked after the application starts. A service is called directly by another service. Although control is still done by the orchestrator, as shown in step 4, the orchestrator is no longer involved in service function invocation.
4) Run time service management: during the application execution, in order to guarantee the overall performance, e.g., the throughput of a service and robustness of the whole system, services are monitored and managed with respect to their availability and resource usage.
After the application finishes, the orchestrator orders services to disconnect from their bound services, clean up whatever state needs to be removed and relinquish the control which is implicitly transferred upon binding; this could also include to remove events subscriptions of services that were created for the purpose of the application.
As stated in the lifecycle of a ubiquitous computing application, the first step is to expose a service to the network. In order to cope with the heterogeneous networking environment of ubiquitous computing systems, we propose a generic approach to present a service to the network to allow more easily collaboration between services and devices. In this approach, a service, no matter what type of its host device would be, is composed of a set of interfaces, namely V_ITF, shown in
Different from the existing Web Services [
A provided interface shares the same concept with an interface of a Web Service or an UPnP service which is that a provided interface expresses the capabilities of a service and can be accessed via an access point. An example here is a “display” function interface of a multimedia service. Through calling the ‘display’ interface at its access point, this multimedia service can render a specified multimedia stream.
A required interface describes functionality that a service needs to perform; it must be provided at a so-called port. Before a service can deliver capabilities described in its provided interfaces, its required interfaces (ports) must be connected to provided interfaces (access points) of other services which provide matching functionality. This is done through a binding procedure.
Inspired by the “port” concept defined in WSDL, in V_ITF, a required interface is composed of a portName
and a portType. The portName describes what type of functionality is required. The portType describes abstract information of the potential functionalities of a service with a set of abstract methods and abstract messages involved. For example, the multimedia service has a required interface “control”. The portType of this required interface is “mouse” and the portType lists a set of methods should be provided by a provided interface of an other service including left-click, right-click, etc. A required interface can only be bound to a provided interface with a matching type through the specified PortType. Assume that this multimedia service needs to provide a “control” functionality which enables the multimedia content to be controlled by remote mouse-click events, it can bind to a mouse service which provides a matching “mouse” interface with required click functionalities. A required interface cannot be invoked in the same way as invoking a provided interface because it doesn’t associate with any access point. A required interface is only able to deliver functionalities, specified by portName, after it has been instantiated. This instantiation is done through the binding mechanism. Through binding, a required interface will be assigned an individual access point (see
The purpose of the binding interface is to bind a required interface of a service to another service that provides that matching function interface. Using the example mouse controllable video streaming scenario, the binding mechanism is shown in
The function interface is created based on the functionality provided by a service. All published methods of a service are added to the function interface. In addition, the function interface allows other services to query the description of a service, which contains the methods that can be invoked on the service, as well as the parameters and return types of these methods. An example functional interface of a mouse service is shown in
V_ITF is designed to support two service advertisement mechanisms: the mediated way which is achieved through a repository and the immediate way when there is no repository available on the network.
In an immediate discovery protocol, a service broadcasts advertisements and queries while it listens to messages of broadcasted advertisements and queries. In case a service requires some interfaces from other services, it
keeps a list of these services when it receives the advertisement messages from them. An example here is that a Repository starts periodically sending advertisement messages to all services in the network when it enters the network. Services who receive this advertisement will add it to their lists. Services’ startAdvertisement method will be called internally to negotiate an advertisement period for service periodic registration at the Repository. With the knowledge of the access point of this Repository, services can un/register themselves to the Repository and can query the Repository for other services providing specific interfaces. This Repository service will be detailed in Section III. The service advertisement protocol is depicted in
Furthermore, in order to be aware of the context change of the environment, a service can subscribe or unsubscribe to the events generated by another service. This functionality is provided by the EventGenerator and EventListener interfaces. EventGenerator interface and EventListener interface interact with each other to achieve eventing. The EventGenerator provides methods to register and unregister event listeners, as well as a me-
thod to inform all registered event listeners of the occurrence of an event. The EventListener interface provides a callback method that can be called by an event generator once subscribed events occur.
From service developers’ perspective, this generic V_ ITF approach offers the following advantages.
• V_ITF is an abstract specification that allows mapping to concrete deployment platforms. For example, access points of services are composed of protocol, host, port, and service name, e.g., protocol: HTTP; host: 131.155.68.172; port: 1107; service name: display. From this generic access point description, deployment platform specific access points can be created.
• V_ITF is an architecture concept to generalize service expressiveness to the network. Interface implementation of a specific service may or may not align with the boundary of its host device. For example, a service provided by a laptop is capable to implement all V_ITF interfaces. However, a service hosted by a resource constrained sensor can only implement the function interfaces, leaving the storage of its service description to other powerful node on the network. On the other hand, extensions to the V_ITF functionalities shown in
• V_ITF provides a required interface definition which allows late binding through using advertisement, discovery, and run-time binding. This enables to use external orchestrators to implement applications. They determine at run-time what services are available, how to compose them and what kind of protocols should be used during the communication, in order to make certain functionality available. Therefore the application logic goes to the network through these required interfaces and the behavior of services and the underlying resources can be managed via the network.
V_ITF is designed deployment platform independent. It is possible to wrap a V_ITF service into a deployment platform specific service without requiring any platform specifics. We provide this wrap tooling support by designing the V_MAP, which is a tool that wraps a deployment platform independent V_ITF service into a deployment platform specific service. UPnP and Web Service are two supported deployment platforms currently. However, more deployment platforms can be supported by extending V_MAP. The structure of V_MAP is depicted in
On a high level, V_MAP takes a mapping description (i.e. an XML file containing a description of a V_ITF service) as input and it can produce UPnP and Web Service services as output. These services provide the functionality that is described in the mapping description, as well as the functionalities defined in V_ITF. The wrapping is done by the Deployer. Because this wrapping is inherently deployment platform (and stack) specific, each deployment platform needs its own Deployer. As a consequence, two Deployers have been created, one for UPnP and one for WebService. Each Deployer reads a V_ITF service and modifies the source code in order to transform it into a deployable service. If new deployment platform support is needed, a new Deployer will be created.
From service developers’ point of view, V_MAP tool is simple to use. Given an existing application and a mapping description file that describes what functionality of the application should be exposed to the network, V_MAP automatically generates deployable services. Compared to the way making application functionality available on the network manually, V_MAP can dramatically save developers’ time.
Next to genericity and flexibility of V_ITF, security and maintaining control of shared services and resources over
the network should be of high importance in ubiquitous computing applications. From a service user’s perspective, how can he locate and access a service securely? During the application execution, how to prevent the logic chain from being interrupted? From a service provider’s perspective, how to protect his ownership and privacy of his services? For instance, in a video streaming scenario, it is needed to assure that an orchestrator only binds a video source service to trusted video sink services instead of to malicious ones.
For the sake of security and controllability, we present VICSDA [12,13], the prototyping system of V_ITF with security and management extensions. VICSDA forms a service-oriented virtual community (VC) overlay where services are wrapped as community services, service activities are done based on community membership, and behaviors of all the community members and services are monitored and managed. In this section the design of VICSDA including how to form and maintain a VC, and how to achieve applications with guaranteed QoS using external orchestration will be presented.
A VC is a dynamic contract-based aggregation whose members have commonalities and interact via shared services by means of a digital network like the Internet. It has rules that each member has to follow. It provides services to members and it has the potential to develop applications through external service orchestration. It monitors the environment of a running application and aims at providing optimized QoS to users. In the rest of this paper, when we discuss VCs we are not referring to any aggregation of people, but to the communication among them which is done through the collaboration of services hosted by digital devices.
A user can apply to join a VC and become a member. Members should obey the contracted management policy of that VC, for instance, they should trust each other and provide promised QoS. Their behavior associated to their reputation is monitored to guarantee a contracted QoS provision. In case of misbehavior, they pay some form of penalty. Each member is autonomous which means he has the right to determine what services that he owns can be shared and which member can access his shared services. And he is free to decide to deregister from a VC at anytime.
If a service provider becomes a VC member, he can publish his services into this VC. Plain services, which implement the V_ITF specifications, will consequently become VC services and be shared among members. This VC service registration is preceded by adding VC related functionalities to the plain services.
control and management functionalities.
The security interface is used for checking the identification and capability of a service user, which can be fetched from a ticket, to access a VC service. All activities including advertisement, discovery, access and collaboration are executed within the scope of a VC. Only authenticated users can access a VC service and communication messages are encrypted. Due to the fact that services are autonomous, VC service providers can define their services’ local access control policy through defining capabilities of different member roles and blocking malicious service users by editing a black list.
The resource management interface is designed to deal with the dynamic virtual community environment, where availability of a service, processing capability of a service host device, and network bandwidth can change anytime. This interface provides methods for checking the load of a service and monitoring the real time resource usage of a service, like memory, CPU, or battery power. With this information, VICSDA can be aware of the change of an application’s running environment and execute dynamic resource management.
In order to govern VC members’ behavior and facilitate the maintenance of a VC, for example maintain the member list, the service list and a better QoS guarantee for service cooperation, each VC service is evaluated with a credit value. This value will be periodically checked by the special services that make up the VC. When a service’s credit is below a predefined threshold value, that service will be deregistered from this VC compulsively.
To summarize, a VC can be envisaged as an overlay network for the existing services. In this overlay, a service has enhanced functionalities:
• It can filter access requests using its access control policy and all the exchanged messages are encrypted.
• Service activities including advertisement, discovery, access and collaboration are executed based on VC membership.
• It also supports the use of fine-grained VC control policies while leaving ultimate control of the local access to services at service providers.
• Meanwhile, a community service still has the properties of a plain service: all network interfaces still use the Service Oriented Architecture (SOA) [2,3,14] service interface; SOA standards such as Simple Object Access Protocol (SOAP) [
Basic functionalities of a VC, for example, member de/ registration, service de/registration, authentication and encryption, service collaboration and fault recovery are provided by specialized services depicted in
A VC is composed of several fundamental services: a VCEntry service with a JoinPolicy and a vcBlackList; a CertificateMan service with a RoleInfo listing designed roles of this VC; a Repository service which is assigned as this VC’s repository; an Orchestrator service to discover and compose services; a DevMan service running on each device with storing a device’s services in a serviceList and monitoring underlying resource usage using a soft-stateTable; a ResourceMan service serving as a resource scheduling and decision making engine; and a FaultRec service designed for the robustness of a VC.
VCEntry and CertificateMan are accessible to any parties including requesters on the network and internal VC members, while the other services are only available for VC members. For example, Repository, DevMan and ResourceMan can only be invoked by authenticated users.
A service provider needs to become a member before it registers services into a Repository. When a new VC is formed, a VCEntry service is created which is an entry service for users on the network to access this VC. The first action is the member registration. With the knowledge of this new VCEntry service’s access point (for example, obtained from broadcast messages over the network), users who intend to join this VC can access this service to become a member. JoinPolicy is a description of the agreed community joining policy. An example for a joining policy is that only those who supply personal information including IP address and e-mail ad-
dress can be approved to register as a member. When one meets the community joining policy, one will be authorized to be a community member.
A member is granted with specific roles and a certificate (ticket) signed by a CertificateMan. The new member could be a service user to access other services, or a service provider to register/deregister a service, or a combination of these example roles. A member can execute actions corresponding to his role while carrying a valid ticket.
In VICSDA, we use a Repository service to cache service registrations, receive service discovery queries, and perform matching between queries and registrations.
As a member, a service provider can register services into the Repository. His ticket to access the Repository will first be checked. With a valid ticket, services can be added to the Repository. When a service becomes inactive, its registration should be accordingly changed. Soft state registration is used to keep the consistency between a service and its registration at the Repository. Registrations have a specific validity period after which they need to be renewed [17,18,38]. This period is negotiated by a service and the Repository based on what they are capable of handling. When registering, a service specifies the minimum period, serviceAdPeriod, it is willing to handle and the Repository responds with the actual period, adPeriod, to be used. This allows a trade-off to be made between registrations freshness versus renewal overhead. Typically both services and Repository will increase the period when under heavy load and decrease the period when there are enough spare resources. The registration update process is triggered by a timer with adPeriod as the period. A service sends the renewal message to the Repository and the Repository updates it registrations.
Services are autonomous. They are free to define their own access control policy. With respect to this feature, VICSDA is designed to support the use of fine-grained VC control policies while leaving ultimate control of the local access to services at service providers. A community service is added an ACList and a BlackList as community properties. Service providers can specify each service’s local access control policy by defining capabilities of different roles and blocking malicious service users by editing the BlackList.
Access to a community service is restricted to authorized members. Different access actions are granted to differrent members according to their registered roles. A service user is required to provide a valid ticket to call functions at a service. This ticket shows which VC this user
belongs to and what kind of roles he can play there. A service first validates this ticket and then grants capabilities according to that user’s roles. Using the authentication and authorization of a VC, un-trusted or malicious access requests to services can be filtered.
One of the main goals of forming a VC is securing the interactions and keeping privacy of service providers. We design that all exchanged messages in a VC are encrypted and transferred in a secure channel set up between senders and receivers. Message receivers have to decrypt received messages before they can use them. Asymmetric cryptography [
In VICSDA, service combination is done by external orchestration, an Orchestrator, which binds required services at runtime. The focus of forming a VC is to enlarge the notion of external orchestration with a secure enriched service collaboration and composition. The current VICSDA platform can provide the ability to compose services into applications within virtual community boundaries.
We have accomplished building applications through external service orchestration with open source code available at [
In principle, in order to execute resource management a manner to manage services and resources which belong to different providers is required. Therefore, a device management service, DevMan, is implemented [
Two components, a serviceList and a soft-state
[{serviceName, serviceType, serviceID vcs[{vcName, serviceAccessPoint processID, adPeriod resources[{resourceID,maxAmount}]}]}]
A service can be registered into multiple VCs by the DevMan service of its hosting device. Using this serviceList, DevMan has the knowledge about which VC a service has registered (vcName), which process is running as a service instance for a VC (processID), how much resources can be used maximally by that process. If a service is not deployed or is deactivated, values of the vcs entry will be set to null. Details about the update mechanism will be addressed later in this section.
The structure of the soft-state
[{resourceID, vcs[{vcName, maxAmount}] tasks [{taskID, taskType, serviceID vcName, currAmount, flag}]}]
resourceID represents different types of resources, e.g. CPU, physical memory, virtual memory; vcs describes the maximum amount of resources a device can use for each VC. Each tasks entry expresses that a type of resource is allocated to which task (taskID), the type of this task (taskType), serving for which service (serviceID) in which VC (vcName) and current usage amount (currAmount). Tasks, viz. processes in multitasking operating systems, for service invocations, are independent and compete for resources. Possible status of a task can be running, ready, blocked, completed, failed and cancelled. Correspondingly, the resources they are competing for have different status (represented by flag) including allocated, reserved, released.
With the information of dynamic resources utilization by service in VCs logged in the soft-stateTable, DevMan can manage the resource reservation, scheduling, and even dynamic reallocation. For instance, when a device is heavily loaded, the DevMan can suspend a task which is handling a resource consuming service to release some amount of resources, or deactivate a service to withdraw all reserved resources when resources are excessively used by it. This helps the DevMan to prevent excessive resource use by one service which would result in a low overall performance of a device. Also important is that DevMan is a service can thus be accessed from outside the device, admitting a global management schema.
Service registrations and resource usage amount are soft-state data and have limited validity periods. In order to acquire a high accuracy of the observation and management, these data should be kept as fresh as possible. In VICSDA, the update process is triggered by a timer with adPeriod, which is used for service registration, as the period. Upon update, the DevMan observes the process where a VC service instance is running and then updates the registrations of the serviceList and that of the soft-stateTable. Besides the periodic update, the softstate
When we are discussing resource management, we assume that the Orchestrator has discovered all required services from the Repository and it needs to know the best composition and collaboration between services in order to provide a high application QoS.
In service oriented applications, the end-to-end QoS delivery from the service provider to the service user may span over different types of networks and can be therefore divided into the node level, network level and application level. Devices that host services belong to the node level. At the network level, the capability of the delivery channel is one of the crucial factors which affect the applications performance. End users specify their application-oriented QoS requirements at the application level.
With respect to meeting the expected end-to-end QoS, VICSDA takes hierarchical monitoring and prediction actions [
At the node level, devices are monitored to manage their local resources for handling invocations to services, which in turn can provide expected QoS. The DevMan monitors each hosted service by retrieving statistics from the serviceList and the soft-stateTable. With the current resource utilization information, the DevMan can manage the resource allocation to services in order to provide a high overall performance of the device. For instance, it can deactivate some services which are not serving any applications to release resources for another resource consuming service invocation.
Network capacity is crucial to service oriented applications. Especially in time-sensitive multimedia applications, packet loss and jitter will severely impact the video arrival rate at the destination service and the perceived QoS by end users. Therefore, at the network level, the capacity of the underlying networks is probed as another input parameter provided to the ResourceMan service to make resource management decisions and adaptations. We use existing work on network performance probing [22,23] to measure the bandwidth of the delivery channel
and anticipate network latency.
The functionality of the ResourceMan service at the application level is to process the gathered statistics from lower levels and to make service coordination decisions according to the required application QoS specified by end users. Additionally, it would be useful when service users report the delivered QoS, such that the service coordination decisions can be more efficient. Therefore, the ResourceMan is designed to also be able to receive feedback information at the application level. The mapping between the application-oriented QoS requirements into the performance-oriented resource metrics is provided by VICSDA [
The decision making engine of the ResourceMan service will make service coordination decisions which include the compatibility of a pair of services and the capability of a service to execute a specific task. Service compatibility means the matching between supported protocols of different services. Using the video streaming application as an example, the ResourceMan needs to check the compatibility between the encoding protocol of a video streaming service and the decoding protocol of a video display service. These protocols are part of the service properties and can be fetched from the service description by the ResourceMan. We have defined the schema of a VC service description to store this static information of a service [
With the estimated network condition and observed resource usage of the required services through the hierarchical monitoring architecture, the ResourceMan can then perform a schedulability test to estimate the capability of a device to execute a specific task of a service, for example, in the video streaming application, whether a display service can decode received bit streams within a given time constraint. In order to avoid the high kernel load caused by launching this video decoding task to that display service, the test is executed at a soft state level instead of directly at an operating system kernel. For this, the ResourceMan uses the current scheduling algorithm of the underlying node to test the schedulability of a task. For example, the host node of the display service is using the Earliest-Deadline-First (EDF) [
Moreover, in order to make the ResourceMan be aware of changes within the running environment of an application and to make adaptations accordingly, the publish/subscribe scheme of V_ITF is used [
We developed a prototyping system VICSDA and on top of it we built an interactive free view point 3D video streaming demo to address the feasibility of VICSDA. This application demonstrates within a VC, a 3D video that is interpolated between four cameras and rendered either on a high performance PC or a PDA. During the rendering an end user can select an arbitrary view point by moving or clicking the mouse which controls the display. The displayed content will automatically adjust to that view point. Moreover, users’ intention to change the display is tracked. The video can be redirected to another display when that display’s controlling mouse is double clicked. The mouse-s, video streaming and display services are available as services and connected by an orchestrator. The encoding and delivery protocol of the video is adaptive to the capacity of the delivery channel and of the display device. For instance, when the video is redirected from the PC to the PDA, the resolution of the video will be decreased from 800 × 600 pixels to 320 × 240 pixels. The video streams will be truncated from a 3D video format to a 2D video format to assure the resource-constrained PDA can decode all received frames in time and provide the end user a desired perceived QoS.
Using this demo, ideas of V_ITF and VICSDA have been examined including: 1) services are developed using the generic service interfacing V_ITF; 2) services can be deployed using different standards on different platforms; 3) control is done separately by a third party; 4) service discovery and access is limited within the scope of a VC for ownership protection; and 5) context-aware resource management is achieved through hierarchical monitoring.
For the realization, a 3D video streaming software [
The following digital devices are used: four cameras (to shoot a 5 minutes long video from different view point), two intermediate PCs (to generate the 3D video, and to host the 3D video streaming service), a PC (host of one display service), a PDA (host of another display service), and two control devices (one PC mouse and one PDA touch screen). The physical deployment and the system deployment of this application are given in Figures 13 and 14 respectively.
With the satisfactory video rendering as a concrete result which were shown as that only an authenticated user can access VC services and the encoding and delivery protocol of the video can adapt to the capacities of services, we conclude that the V_ITF design is feasible, the concept of VC and corresponding prototyping system VICSDA is efficient, and the hierarchical monitoring architecture is doable.
We compare our generic service programming approach
with several universal service programming methods, which spread over Web Services and UPnP specifications for service oriented applications, and OSAS designed for sensor networks.
Web Services are application programming interfaces (API) that can be accessed over the Internet via the HTTP protocol, and executed on a remote system hosting the requested services. Web Service is designed to support interoperable machine-to-machine interaction over a network. However, it is sometimes criticized for not being loosely coupled, because it is often implemented by mapping services directly to language-specific functions and by coupling application logic into services themselves. Many system developers feel this decreases the reusability of services. Different from Web Services, V_ITF separates services binding from service functionality much more explicitly. Moreover, Web Service implementation is commonly heavy-weight. In contrast, V_ITF is capable to be adopted by arbitrary types of devices including resource constrained sensors.
UPnP is an emerging standard for consumer electronics promoted by the UPnP Forum. It is technology for dynamically attaching devices directly to a computer. UPnP devices are “plug-and-play” in that when connected to a network they automatically announce their network address and supported device and services types, enabling clients that recognize those types to immediately begin using the device. Unfortunately, many UPnP device implementations lack authentication mechanisms while the available security protocols are complex,
and by default assume local systems and their users are completely trustworthy. From this point of view, V_ITF provides services with better security characteristics by defining their lightweight access control policies.
Another distinct aspect between V_ITF and the above mentioned service oriented specifications is the third party binding. In most existing specifications, extrafunctional aspects of an application, like service availability, performance and security, are tangled with functionalities of required services. Although web service orchestration and choreography [
OSAS (Open Service Architecture for Sensors) [
In the field of collaborative computing, there have already been some virtual community research activities. The virtual community concept in peer-to-peer (P2P) systems, for example BitTorrent [
A Personal Network (PN) [34,35] aims to achieve seamless communication between electronic devices in an ad-hoc fashion. A PN enables a user remote access to any of his personal services and content as if they were physically present in his vicinity. A PN supports applications based on sharing resources and takes context and location information into account. Architectures of PNs, resource discovery, self-organization, routing, and security are addressed. However, PNs mainly address the connectivity issue while the architecture of application building and the particular way of service sharing is not within scope. Also functionalities like context awareness, service discovery and resource management need to be realized.
VICSDA provides secure service sharing within a VC and the denial of access to community services from outside a VC. This relates to the concept of Authorized Domains, as proposed by the Marlin [
This paper presents a service interfacing approach V_ITF, which provides a generic way to expose a service to the network and to access a networked service. In the V_ITF specification, a service is composed of a set of standard interfaces besides the specific functions it can perform. Its interfaces can be divided into provided interfaces and required interfaces. The required interface definitions allow the availability of new functionalities through service binding. The specifically designed binding interface deals with the binding between two types of interfaces. Interface implementation of a specific service may not align with the boundary of its host device. Therefore, V_ITF can be adopted implemented on arbitrary types of devices including resource constrained sensors. V_ITF allows mapping to concrete deployment platforms. A mapping tool, V_MAP, is described, which currently can support wrapping a deployment platform independent V_ITF service into UPnP and Web Service deployment platforms.
In order to maintain access control to shared services over the network, we introduced virtual community concept to services. A VC defines a secure boundary for service activities. Within this boundary, service discovery, access and collaboration are done freely, while services are monitored and managed. To build such a virtual community overlay the flexible V_ITF is extended with security, resource management and credit management interfaces. Regarding the autonomous nature of a service the VC design supports the use of fine-grained VC control policies while allowing service providers defining their local access policy to services. Methods of how to form a VC, how to register as a member and later share services with other community members are introduced subsequently. Services are registered at the Repository through the DevMan service which also performs monitoring and management. Each device has one DevMan service which tracks the dynamic resource usage of hosted services on that device. With the performance statistics of services and of the network gathered by the ResourceMan service, performance of required services can be predicted. The publish/subscribe scheme is used to be aware of changes in the environment. In this way, inherent dynamics of the ubiquitous computing systems can be handled and application-oriented QoS can be guaranteed.
The corresponding prototype system VICSDA is developed and a 3D video streaming application is implemented. Concrete outcome proves the feasibility of the generic service programming and access approach. Secure service discovery and access control have been achieved. The application shows the successful separation of service control from service functionality through the external orchestration. The optimized the displayed video quality over adapting the 3D video’s encoding and delivery protocol based on the capacity of the delivery channel and of the display devices showed the effectiveness of the hierarchical monitoring design.
Applying V_ITF into the low capability device domain, such as sensor networks is our current research focus while some of the described functionalities still need implementation (like the immediate service discovery protocol). In addition we combine V_ITF with a component framework in order to move to a system that allows dynamic software updates while remaining predictable and secure. Strengthened authorization and authentication mechanism will be researched in order to provide the secure access to services hosted by sensor nodes. Fault detection and recovery of the system will also be addressed in the future to facilitate enhanced reliability and robustness of VICSDA.
This work is supported by the research project of Freeband I-Share: Intelligent Middleware for Sharing Resources for Storage, Communication and Processing of Multimedia Data, supported by the Dutch government.
We would like to thank our anonymous reviewers. Their invaluable feedback helped substantially in improving the quality of the paper. Our thanks are also to Remi Bosman, Melissa Tjiong, Goran Petrovic, Peter de Width, Jurjen Middendorp, and Pim Vullers for their technical feedback at the implementation stage of this work.