1 Introduction

Over the past two decades, mobile technology has gained widespread popularity and has become a part of day-to-day life. In particular, smart phones and mobile devices strongly impact the way human beings communicate and deal with digital information. The modern era has witnessed rapid advancements in the field of mobile technology and wireless networking. As a response to this advancement and growth, a large number of services are emerging in the market that can provide digital information over hand held mobile devices. With such dramatic growth, smart phones and mobile devices have the potential to become “service providers” from merely being “service consumers”.

The materialization of the vision to host and provision web services in peer-to-peer manner over mobile devices can bring a new level of usability to mobile users. The mobile web services will allow the mobile user agent to directly interact with other mobile user agents. This reduction of human intervention in service provisioning will speed up service execution, limit the chances of error, automate redundant tasks, and most importantly reduce the annoyance of human users. A few prospective applications of mobile web services are: (1) Credit cards, debit cards, visiting cards can be provided as web services from mobile devices without the need of having the user search for them or even carry them physically. (2) Localization of personal information can be done seamlessly through services over mobile devices. (3) Modern mobile devices are equipped with powerful sensors. Mobile devices laden with such sensors play the role of a “gateway” facilitating proper access to the capabilities of the sensors. (4) Mobile services are particularly useful in scenarios where there is little or no preexisting infrastructure by functioning through ad-hoc networks. Examples of these scenarios are war-front, post-disaster relief. In this paper, we use the term mobile services to imply self-contained and reusable services that are provided by mobile devices or sometimes by human users via mobile devices. Such mobile services are application components that facilitate device to device communication over mobile environments. They provide means to communicate between various software applications of mobile devices. Such services may be utilized for commercial and non-commercial purposes.

The realization of web services over mobile devices has gained attention in the community. Several approaches have been proposed to provide web services over modern mobile devices [1, 4, 8, 11, 23, 45]. However, a key challenge that is overlooked in mobile environment is “service description”. Service description is crucial for the consumers of services to get a sense and better understanding of the offered services and operations. Well expressed descriptions provide clear and structured instructions on how to invoke a service which is particularly important to first time service consumers. This is of further importance in mobile environments, where the service invocation requires a great deal of service understanding owing to the dynamic nature of transient services. Traditionally, WSDL (Web-Service Description Language) [53] is used to describe and publish the functional description of web-services. Well written WSDL documents provide binding implementation information, detailed description of input–output messages, information on how messages are sent through the network, amongst others. Further, WSDL documents facilitate discovery of the intended web-services over standard service registries such as UDDI—Universal Description Discovery and Integration [32]. On the flip side, however, WSDL documents only provide the functional information of a web-service. They do not provide information on the other crucial aspects of a web service that might be of utmost importance in selection and proper usage of mobile services over mobile devices.

In an earlier work of ours [50], we were able to incorporate functional, non-functional, contextual, and business aspects of services to service descriptions for mobile devices. In this work, we plan to build upon that work to incorporate several more important aspects to such descriptions of mobile services. These include descriptions of service collaborators, data source details, hardware aspects, and consumer base. Mobile devices may sometimes act as the “gateway” to information provided by data sources such as embedded sensors, third party applications, or other mobile services. In such scenarios, the mobile service provider and the data source can be viewed as two separate entities. Both the entities are operated autonomously, with their own unique characteristics and further both entities are prone to failure independently. Traditional service description solutions do not suffice here as they consider data source and service provider as indistinguishable entities. An important perspective covered by the proposed mobile service description is: “data source” and “mobile service provider” are looked upon as two disjoint and independent entities with decoupled description. Further, we acknowledge the fact that mobile web services are usually light weight and provide limited functionality. Mobile services can be combined and aggregated among themselves to build and compose more complex and useful services. Hence, this collaboration can lead to provide services that can be readily useful in a real world scenario. In the proposed approach, we further incorporate details on the collaborative partners. To the best of our knowledge, this paper is the first attempt at considering the service provider and data source as two separate and autonomous entities and proposes a service description solution accordingly.

The aim is to provide a lightweight solution that is dynamically update-able and facilitates rich service descriptions in mobile environments. We emphasize, however, that the proposed solution is not a replacement for existing technologies but one that complements it. It acknowledges the heterogeneity of the environment that supports a co-existence of wired, wireless, and mobile devices. The idea is to extend the WSDL 2.0 [53], to incorporate non-functional, contextual, business, data source, collaborator information. The extension takes into account the constraints and issues of mobile environments. To the best of our knowledge WSDL 2.0 is best suited for our requirements. WSDL 2.0 is capable of describing both the major web service technologies: SOAP based and REST (Representational State Transfer) based; this is possible as WSDL 2.0 has good support for describing HTTP bindings. WSDL 2.0 further provides a generic mechanism to define service operations using Message Exchange Patterns (MEP) [53]. This feature encourages message-oriented operations and supports arbitrary message exchanges that are pertinent for heterogeneous mobile environments. Although several other description languages have been proposed since the inception of WS-* technology, most do not take into account the distinct nature of mobile environments. Furthermore, continuing with WSDL would require least tinkering with existing protocols and technologies. Being XML based, WSDL 2.0 has very convenient in-built extension capabilities that can sufficiently cater to our requirements. Our approach is to extend WSDL 2.0 to accommodate various other description aspects in addition to the functional description that it already takes care of.

We acknowledge the fact that usage of WSDL might be limited now a day, several practitioners might be using few of the non-standard approaches RPC-based or GET/PUT/POST based methods for describing the services. There could possibly be various types of such methods that are used by different groups of service practitioners. However, these methods are just popular work-around for service description, none of these methods is a standard for cross organizational business communication. While, WSDL is widely accepted as a description standard by the service practitioners and scientific community. Hence, WSDL 2.0 based proposed approach would provide a standard way of describing a mobile based web services that are meant to be used by other systems (including legacy and modern systems) for the purpose of service discovery in mobile environment. Alternatively, the proposed work can also serve as an aggregator of description information and documentation for the mobile services. Furthermore, the capability for combination and integration of the description with other mobile services can be a business advantage in collaborating with other service providers or to provide cross-platform capabilities. Therefore, the service providers can be motivated to adopt the proposed description not necessarily as a description itself, but as an artifact of documentation, one that can include multiple relevant aspects. As a bonus, they get to benefit from the proposed contributions.

The rest of the paper is organized as follows: a motivating scenario for mobile SOA and service description is presented in Sect. 2. A brief description of the problem forms Sect. 3. Detailed discussion on the extensible, dynamic service description is included in Sect. 4. Evaluation of the proposed approach is presented in Sect. 5. The related work is presented in Sects. 6 and 7 concludes the article and sketches future work directions.

2 Motivating scenario

In mobile based SOA environments, each mobile device can perform the functionalities of both a service consumer and service provider. As a service provider, a mobile device can host and publish services. As a service consumer, a mobile device can select and invoke mobile services. In the service system, the usual stages are: Service Publishing, Service Discovery, Service Selection, Service Binding, and Service Invocation. Service description is an integral part in most of these stages. In this section, we present a brief scenario that demonstrates the importance of the non-functional, contextual, and business aspects of service description in addition to the usual functional description. Further the scenario discusses about the prospective application of mobile services:

Alice is a high risk cardiovascular patient. Recently, she had implanted an ECG sensor in her body that monitors her cardiovascular health and provides statistics and information as a mobile service via her mobile phone. This service could be consumed by her cardiologist and she would be provided with proper prescriptions as per her current health. One day on her way to another city, she had a sudden cardiac arrest. The mobile service on her mobile phone observed the alarming variations in her ECG signals. Thereafter, the mobile service discovered the nearest ambulance through the latter’s exposed mobile service. Further, the mobile service of Alice’s phone automatically provided access to her latest ECG signals to the ambulance support medical staff and thus enabling them to prepare well in advance for the patient. The ambulance was able to discover Alice’s current location through another service on her mobile phone that provided GPS coordinates. Further, when the ambulance was on its way, the ambulance’s mobile service provided the doctors at the nearest hospital with the latest information on the situation including the ECG signal data. Simultaneously, the hospital was able to make use of Alice’s ECG mobile service to gather her ECG history. This helped the doctors at the hospitals to study her medical profile and case in detail prior to her arrival. On its way to the hospital, the ambulance was able to make use of the services exposed by other travelers on their respective mobile devices to avoid the busy route and opt for the path with less traffic. Meanwhile, the insurance company was contacted by Alice’s mobile service and her hospital information was shared, so that the financial aspect could be taken care of even before her arrival. Alice’s cardiologist was also able to provide details of his/her prescriptions via his/her mobile service to the doctors in the hospital so that the latter could learn about her medications and allergies if any.

In the discussed scenario, service description would enable various devices (service consumers) to shortlist required mobile service based on their non-functional, contextual, data source, hardware aspect in addition to the functional aspect. Suppose Alice’s device is made to negotiate with few irrelevant and outdated mobile services that are providing the same functionality. This might have result in some fatal consequences. In such cases, the role of service descriptions other than the functional aspect is of utmost importance. A detailed service description is of utmost importance in case of device-to-device service interaction. In such cases, these service description would enable the service consumers to effectively discover and use the offered mobile services that are not probably provided by the functional service description.

Now, when the updated non-functional, contextual, and business information were made available to the service consumer along with the functional service description, it saves a service consumer the hassle of communicating and negotiating with irrelevant service providers. These aspects of description are therefore worth considering in a mobile scenario: non-functional description would give mobile service consumer an idea about the overall performance of a mobile service; business related constraints or information (such as availability of service in her locality, usage price for service, service background i.e. human provided, in-house developed service, sensor provided service) would be provided through the business description; contextual description would brief them about the context of the service offered.

Furthermore, these mobile services may offer services on the basis of data provided by an external entity (e.g. in case of shortest route services GPS sensors and map services are used or in case of body area network). In such scenarios, information of those data sources becomes crucial. Moreover, information about the service provider’s hardware is also important to assess the feasibility of the service and claimed service QoS from the provider’s hardware. This information (non-functional, contextual, business, data source, hardware, collaborator), however, cannot be archived in the service registry along with the functional description. This is because mobile devices are by nature inherently mobile and hence these descriptions continuously vary. There needs to be, therefore, a mechanism to support and ease the frequent updates of the service description.

In the following sections, we summarize the problem and demonstrate our solution that offers wider (covering functional, non-functional, contextual, business, data source, collaborator, and hardware aspect), light-weighted and update-able service descriptions to handle the challenges in mobile environments.

3 Problem statement

Several heterogeneous mobile devices constitute the mobile environment. These devices could be of varying processing capabilities, power requirements, memory, transmission protocols. Further, these devices are prone to uncertain behavior and dynamic changes as they usually are in continuous motion and they can randomly join/leave the network. Therefore, a holistic service description mechanism is required for services hosted by such mobile devices that comprehensively covers the various unique aspects of the mobile environment. Merely a functional service description does not provide enough information to the service consumer for service selection in such environments. Service selection made on the basis of only functional service description may lead to the invocation of an obsolete service or an off-line service provider.

A novel approach is required that takes into account the distinct nature of mobile environments and that considers service aspects in addition to the functional description, such as the non-functional, contextual, data source description, hardware, and business descriptions of a mobile service. In the current scenario legacy wired systems and modern wireless mobile systems coexist. Therefore, a completely novel architecture that intends to replace the existing solutions is undesirable. A service description solution that complements the current solutions and also has added features catering to mobile environments is the need. As elaborated in the earlier sections, in mobile environments the service descriptions require frequent updates owing to regular context changes, non-functional and/or business related changes. Moreover, mobile environments are prone to failures reasons being frequent network outages, battery limitations and are usually constrained in terms of processing power. This leads to the added requirement of a ‘lightweight approach’ for such service descriptions. Further, keeping in mind the distinct nature of mobile environments, information about the data source, collaborator, and hardware becomes an important parameter during service selection. Hence, a service description approach that considers the issues associated with mobile environments and at the same time blends with the existing technological solutions is required.

We summarise the requirements of mobile service description as: detailed (including non-functional, contextual, business, collaborator, data source, hardware aspects in addition to functional); run-time update-able (i.e. dynamic); and lightweight.

4 Proposed approach

In the subsequent subsections, we provide details about the proposed approach:

4.1 Design concept

We propose to use the following service description documents for mobile services: 1. Functional Description Document. 2. Non-functional Description Document. 3. Contextual Description Document. 4. Business Description Document. 5. Data Source Description Document. 6. Collaborator Description Document. 7. Hardware Description Document.

WSDL documents are widely used for service descriptions. These documents provide detailed functional description of services. Hence, we rely on WSDL documents for functional description of the services provided over mobile devices. In this work, we propose to link the WSDL document with other description documents mentioned above using the “import” statement defined in WSDL. The “import” mechanism allows referral to other WSDL documents defined elsewhere. We use this to connect descriptions that are split across multiple documents for the mobile service. The partitioned descriptions enable lightweight, dynamic, and consistent management of the overall service description.

Fig. 1
figure 1

Proposed mobile service description

Full size image

Figure 1 shows an abstract view of the proposed approach. There are three primitive entities: Service Provider (mobile device hosting a service), Service Consumer (mobile or non-mobile device), and Service Registry (mobile registry or traditional non-mobile registry). These entities have the Publish/Find/Bind relationship between them as shown in Fig. 1. The service descriptions are split into multiple documents and placed at the Service Registry and the Service Provider (i.e. the mobile device in this case). The motive behind this splitting and placing of multiple parts of the description at different locations is: (a) to facilitate faster, independent, and dynamic updates related to service provider in the descriptions and keeping the description up-to-date. (b) to maintain the overall consistency of the description in case of simultaneous updates. (c) to provide a lightweight and detailed service description.

The descriptions of a mobile service may be dynamic and subject to updates regularly. This includes descriptions related to the current network (Wi-Fi or GSM), location, current availability status of the mobile service provider hosting the service. These updates are managed by various independent entities or authors and, therefore, the mutual independence of separate description documents saves the hassle of inconsistent updates. For instance, the non-functional description of a mobile service can be managed and updated by a third party auditor or a broker, whereas the contextual description can be managed by a simple mobile application residing on the same device. This demonstrates the efficacy of splitting and delocalising service description documents in the mobile environment.

The proposed approach does not rely on any specific type of service registry. The service registry can be the traditional systems such as UDDI or mobile service registry solutions [49]. Being XML based, proposed description can be accommodate in any mobile service registry; while the WSDL is already known to be adopted by existing service registries. The proposed approach defines novel process for the service description retrieval: (shown in the Fig. 1):

  1. 1.

    Search a service at the service registry.

  2. 2.

    Retrieve the functional service description from the service registry.

  3. 3.

    Retrieve the rest of the service descriptions from the mobile service provider.

4.2 Description components

As discussed in last subsection, we propose to use various service description documents that provide a holistic understanding of a mobile service and that describe the mobile provisioned services in a distributed manner. As shown in Fig. 2, seven service descriptions are interlinked by the import statement and an information base about the service consumers. Each element of the descriptions has an attribute “isDynamic”, that indicates whether the element is dynamic or not i.e. if the element requires regular updates. This particularly helps in cases where a third party broker or application is responsible for updating the description. In this paper, we include several description metamodels for mobile services, however, defining all the elements associated with each description metamodel is out of the scope of this paper.

Fig. 2
figure 2

Service description infoset for mobile services

Full size image

A brief overview of each service description is as follows:

4.2.1 Functional description

As discussed in the earlier subsection, we rely on WSDL 2.0 for a detailed functional description of the service (refer to Fig. 2). A functional description should describe “What”, “How”, and “Where” of a service:

  • What The function of a service or the operations that a service provides is described by the functional description of a service. The interface component of the functional description (refer to Fig. 2) helps to achieve this.

  • How The mode of invoking the service, the message formats, and transmission protocols used by the service constitute an important part of the function description. The binding component of the functional description (refer to Fig. 2) helps to achieve this.

  • Where The location of a service or the URI of the service endpoint conveys to the service consumer the address of the service. The service component of the functional description (refer to Fig. 2) and the endpoint element in it defines the URI of a service deployment.

This description is usually the first criterion during the service selection process. First of all, the services are shortlisted on the basis of the functionality they provide, subsequent filtering of the services is done through further criteria. In the proposed approach, therefore, we link the remaining descriptions of the service with the functional description using the “import” statement. A typical import statement comprises a namespace and the location of the importing description document: \(\mathtt{<}\) import namespace=“anyURI” location=“anyURI”\(\mathtt{> <}\)documentation\(\mathtt{/>}\mathtt{</}\)import\(\mathtt{>}\).

4.2.2 Non-functional description

The non-functional properties or the quality of service implies the overall performance of the service experienced by the service consumers. We propose to associate a “timeStamp” attribute with the non-functional description document that indicates the time-stamp of the last update. In the uncertain mobile environment, the non-functional properties change with a change of context of service (e.g. location, network, battery etc.). Hence, the time-stamp brings in a degree of certainty to the non-functional description. This helps in better management of dynamically varying description elements. We propose to use the “timeStamp” attribute with the business and contextual descriptions as well.

We propose four ‘Quality of Service’ (QoS) groups in mobile environments:

  1. 1.

    serviceQoS Service QoS are the quality attributes of a service as experienced by service consumers. A few important QoS attributes include: Availability, Capacity, Latency, Throughput, Performance, Reliability.

  2. 2.

    networkQoS Network QoS include the quality attributes associated with the underlying network used by the service. This network varies from Wireless LAN, GSM, WiMAX. A few attributes of this group are: Packet Loss, Network Delay, Delay Variation, Bandwidth Capability.

  3. 3.

    systemQoS System QoS are the quality attributes that characterize the whole system instead of just the service or network or third party application. A few attributes in this category are: Accessibility, Security, Usability, Scalability, Interoperability, Robustness (Failure-Management), Extensibility.

  4. 4.

    otherQoS This group or placeholder is proposed to categorize the quality attributes that do not fall in any of the groups mentioned above. This group is extensible and can further categorize service attributes. A few examples of this group are: Testability, Modifiability, audit-ability.

This description is not only limited to these four types and can be extended to include other QoS attribute categories as well. A few pointers to work on non-functional properties of services are [14, 28, 33, 34]. We consider the QoS as the totality of the features and characteristics of the service that are based on its ability to satisfy the implied needs (as per ISO 9000). In this paper, we only focus on the description of the claimed or known QoS values of the offered services. Determination/Estimation of the varying QoS attribute values is beyond the scope of this work.

4.2.3 Business description

The business related information of a service is expressed in the business description document. This description mainly comprises:

  1. 1.

    Legality The legal obligations or conditions associated with the service are represented by this placeholder. For instance, a service is not available in a specific country, the service is making use of proprietary applications, disclaimer notifications. The legality description is particularly important in case of mobile services as they can easily migrate from one legal boundary to another.

  2. 2.

    Certification The certification placeholder specifies the business related certifications or licenses associated with the service. For example ISO certification, SSL security certificates.

  3. 3.

    Usage Requirement The preconditions for service usage (if any) and other service usage requirements are described by the usage requirement placeholder. This may include the minimum version of software agents or device capabilities.

  4. 4.

    Cost The Cost or pricing placeholder specifies the price for use of the service. The cost placeholder could further be extended to cover discounts, special offers, group pricing for a set of services.

Apart from this, the business description document could include information related to referred service choreography, service offering background (e.g. in-house development, third party applications), service version [6], service scope (what a service covers and what it does not), service type (human provided or manual, automated, semi-automated). The business description information is necessary in mobile environments as it provides greater exposure to the business related offerings of mobile services.

4.2.4 Contextual description

The often varying context of mobile devices makes the contextual information of utmost importance for services provisioned over mobile devices. A good definition of the term context is given by Bazire and Brézillon [7]: “Context is any information that can be used to characterize the situation of an entity, where the entity is a person, place, or object that is considered relevant to the interaction between a user and its application, including the user and the application themselves”.

The context information includes constraints, nature, and attributes that influence the behavior of the service. The description chiefly has placeholders or category for the following elements:

  1. 1.

    deviceContext This represents the context of the mobile device that hosts and provisions the service. This includes device related information, its operating conditions.

  2. 2.

    userContext This placeholder depicts the user (mobile device owner or human service provider) related information. User context is worth considering in mobile environments as the mobile device user’s (or human service provider’s) activities, behavior can directly influence the service experienced by the service consumers. This may include the user’s routine, availability of the service, the user’s background (e.g. profession), user’s situation (walking, running, driving), location (address, GPS coordinates, time zone). Further, this placeholder may include the preference details of the user, for example consumer A should be able to access the service but not consumer B. However, this preference management is out of the scope of present work.

  3. 3.

    serviceContext Service related contextual information is depicted by this placeholder. A few examples of service context are service domain, service connection preference, service specialisations.

  4. 4.

    businessContext Business contextual information includes information such as preferred business scenario (e.g. combination of user’s and device’s context), preferred service partners, compositions.

Service and Documentation are common attributes in all descriptions. Service specifies the associated service name and its URI for which the description has been provided, while documentation specifies the human readable descriptions of the attributes and service description. These two attributes are borrowed from WSDL 2.0.

4.2.5 Data source description

In mobile services, mobile service providers (or mobile devices) often serve as the “gateway” to information provided by the data source which is itself an independent entity. The data source can be anything that provides the mobile service with data. The data source and mobile service provider can be viewed as two independent entities that have independent failures, context, capacity. Examples of such data sources are internal sensors that are physically located within mobile devices (GPS sensor, digital compass, barometer, pedometer) or external sensors (smart home sensors, body area network sensors etc.) or third party mobile software applications.

As technology progresses towards the Internet of Things (IoT), there is expected to be rapid increase in the number of such data sources. The mobile service provider will then more commonly provide an abstraction for data obtained from such ‘things’. The abstraction would be such that the data is made available in formats that are standard and facilitates seamless usage. While for the service consumers, the description of these data sources would provide a better understanding and a holistic view of the service. That, consequently, might become an important service selection criteria. The data source description primarily contains placeholder for the following elements:

  1. 1.

    LocationDetail This comprises the location details of the data source. This includes the GPS coordinates and other the location information.

  2. 2.

    CapacityDetail This comprises the technical details on the data source. This mainly includes the operating capacity of the data source. In certain scenarios, this may include battery information and computation capacity as well.

  3. 3.

    QoSDetail This provides non-functional information on the data source. This may include availability, throughput, reliability, network delay, security information.

  4. 4.

    ContextualDetail Contextual information (as discussed in the earlier point) provides information about the constraints, nature, and structure of the factors that influence the behavior of the data source.

The data source descriptions are provided and managed by the mobile service provider and the data source. This document could further be viewed as: Dynamic Part (These are the pointers to the inforamtion located at data source and are likely to change) and Static Part (This information is placed at the service provider e.g. CapacityDetail, QoSDetail). This description is necessary as it provides greater exposure to the important constituents of the mobile service.

4.2.6 Collaborator description

Mobile devices are powerful enough to provide services on their own, yet their capabilities can be improved manifold through mobile service collaboration. Description and information on collaborators helps prospective service consumer to take a decision on a service provider.

Collaborator description provides information and conformity to the service consumer about the service being offered. In this paper, we provide the following placeholders for collaborator description:

  1. 1.

    FunctionalDetail This placeholder is proposed to provide information on what, how, and where of the service collaborator. The functional description of the collaborator may be reused.

  2. 2.

    BusinessDetail This placeholder is proposed to provide business related information on the collaborator. This includes legality, usage requirements, and other related aspects.

  3. 3.

    WorkflowDetail This placeholder provides information on the particiapating workflows of a collaborator. This is mainly to provide the information about the collaborator’s work assessment.

  4. 4.

    UpdateFrequency This placeholder specifically works towards prevention of out dated information in a large workflow. This enables the service consumer to have an updated service all the time.

The collaborators description could already present as the mobile service description. Therefore, instead of managing all the information at the service provider, it manages a short summary of the functionality offered by the collaborator and provides the pointer to the functional description of the collaborator. WorkflowDetail provides active workflows with a collaborator as few of the workflow may become outdated due to collaborator’s service update.

4.2.7 Hardware description

Hardware details of the service provider are provided in this placeholder. This description is introduced to minimize the need of service negotiation from non-potential providers. Service consumers can assess the service claim and the hardware that is used to provide the service before actually using the service. The following placeholders are introduced for a detailed hardware description:

  1. 1.

    SensorLists Modern mobile devices are equipped with several modern sensors. This placeholder provides a detailed list of the equipped sensors and their functionality.

  2. 2.

    MemoryDetail This briefs the service consumer about the memory details of the mobile device providing the service. Memory details include information on the primary memory and secondary memory of the mobile device. In certain scenarios, this placeholder also includes details about external memory locations (in case cloud storage is used).

  3. 3.

    PowerDetail Power or battery plays an important role in the selection of mobile services. This placeholder provides the runtime power profile (device battery over a specific time period) of the mobile device.

  4. 4.

    ManufacturerDetail This placeholder provides information on the manufacturer, kernel versions, and other device related information. This could further provide information on the manufacturer of the mobile processor, WiFi and bluetooth adapters.

Mobile service provider may fetch the hardware related details at runtime using APIs exposed by the modern mobile operating systems. For example android provides detailed and sophisticated libraries that access the hardware information efficiently. This description document could viewed as two parts: Static Part (comprises the unchanging elements—SensorList, ManufacturerDetail and is placed at the service registry) and Dynamic Part (comprises the changing elements—MemoryDetails, PowerDetail and is placed in the vicinity of the service provider).

4.2.8 Consumer base details

The consumer base provides details about the earlier consumers of the service such as number of consumer accessed, location partitioning of consumers. This helps prospective service consumers better assess a service provider. We can further extend this placeholder to include feedback and rank the service providers. These can be used to propose a recommendation system for mobile services. Detailed discussion on such recommendation systems is beyond the scope of this paper.

5 Evaluation

We have evaluated the proposed approach with the rationale of demonstrating its usability, feasibility in practical scenarios, and efficacy for mobile service description. We have used the following evaluation techniques (as discussed in [44]): (1) Feature Comparison, (2) Empirical Evaluation, and (3) Conceptual Evaluation. Section 5.1 provides a detailed feature comparison, Sect. 5.2 discusses the empirical evaluation, Sect. 5.3 makes use of case studies for theoretical evaluation.

5.1 Feature comparison

In this section, we provide a thorough comparison of the proposed approach with existing service description methods available in literature. For this comparison, we have examined 22 related approaches and compared the proposed approach with them. We have selected few of the key points for comparison with the aim to assess the applicability of these approaches in mobile services. For example, applicable domain states whether a work is applicable in wireless/mobile domain or not, ability to dynamically update the description determines in volatile mobile environment whether change in description is incorporated in methods or not, representation style states whether approach is syntactical or semantic, aspect of description covered states which description aspect is covered by an approach, techniques used for description states XML, JSON, RDF or any other technique is used for presenting description, validation approach for the method states whether an approach is applicable in real world application or not. Tables 1 and 2 present a detailed comparison of the proposed approach and existing works chronologically in literature.

Table 1 Comparison of proposed approach with existing approaches in literature
Full size table
Table 2 Salient features of existing approaches in literature
Full size table

5.2 Empirical evaluation: prototype

We put together a working prototype for assessing the feasibility of the proposed approach. Actual mobile devices were used to deploy the prototype. The prototype is capable of managing dynamic service descriptions in a mobile environment. For this, an android application was developed that is capable of communicating with service registries, retrieving the description documents, extracting relevant information from these descriptions, and updating the descriptions dynamically. The Android operating system was chosen to implement the prototype because it is open source, has wide market share and availability. The proposed approach is generic and can be extended for use on any mobile platform. Our experimental setup comprised four mobile devices (including two Samsung Galaxy S Duos with Android 4.0, Google Nexus 7 with android 5.0, and Asus Zenfone 5 with Android 4.4), one laptop (Intel i3 2.13 GHz with 3GB of RAM) and a few instances of the prototype running on virtual instances of android devices on the laptop.

The proposed framework was evaluated in a practical setting. We requested four volunteers to deploy the prototype over mobile devices and roam around within the institute campus. We established an experimental wireless network within the institute’s building to connect the volunteers’ mobile devices, laptop, and its running virtual instances. This is shown in Fig. 3a. During the experiment, the mobile devices followed a random pattern of mobility as the volunteers did not follow any predefined roaming pattern. Our prototype also had a small memory footprint of 1.14 MB. This clearly indicates the feasibility of the prototype for use in the real world. We devised the prototype as background service and ran it for 17 h 34 min (as shown in Fig. 3b). The prototype for the proposed approach has power consumption of around 63 mW [when assessed for 40 description requests. For a quick reference, gmail android app had 567 mW, facebook android app had 1297.5 mW, GSM call had 511 mW, and Airplane Mode had 6.4 mW power consumption (depends on build/model of mobile phone)]. CPU usage is 5 s when the prototype analyzed for 17 h 34 min. Further, the prototype can coexist with other applications and does not hinder with them. Our approach and prototype did not cause problems to ongoing calls and other native applications. Presented is the result of description request made to the prototype with an active call and without an active call. Preliminary results show there is not much lagging in response time in both the scenarios as shown in Fig. 4. A brief overview of how the various features of the proposed approach were realized in our prototype implementation is given in Table 3.

Fig. 3
figure 3

Empirical evaluation: prototype and battery usage. a Mobile service description prototype setup. b Prototype battery usage on the android device

Full size image
Fig. 4
figure 4

Prototype performance on the android device with and without call

Full size image
Table 3 Proposed features and its prototype realization
Full size table

Two mobile devices and a virtual android instance played the part of the service provider and hosted services along with the description documents as discussed earlier. Further, we engineered a ‘watchdog’ application to sense the changes in the service provider’s contextual, business, and non-functional information and accordingly kept the description documents updated. We made use of a mobile based service registry [49] and hosted the functional description documents over it. The mobile devices acting as service consumers retrieved the functional description document (i.e. WSDL document) from the service registry. Subsequently, the consumers extracted the location information on the other description documents (viz. business, contextual, non-function) from the same WSDL and these were retrieved.

5.3 Conceptual evaluation: case study

In Sect. 5.2, we described a real world deployment of the proposed approach by developing a working prototype and deploying it over real mobile devices. In order to further validate the proposed service description, we apply the proposed approach on the case studies and analyse the same in this section.

We acknowledge that the conventional wisdom about case study research has several prejudices. These prejudices have been discussed in detail in an interesting article “Five Misunderstandings About Case-Study Research” by Bent Flyvbjerg [16]. Going along the points mentioned in this article, we present three different service case studies that may exist in the service ecosystem. First, we discuss the case of a shopping mall where the services provide information on the latest offerings: MallLatestOffer. Second, we discuss the case of a SalesmanTracking mobile service. And third, we take the example of a CarPoolingMate service. Table 4 discusses these cases briefly. The motive behind discussing these three examples is to assess our description approach for three types of primitive mobile services: (1) Automated Mobile Services: Services that are offered by mobile device itself and do not involve the human. Example—Mobile services that offer sensor provided information, Mobile services that offer personal information viz digital visiting card. (2) Semi-Automated Mobile Services: Services that are provisioned over mobile devices that sometimes requires human intervention. Example—Mobile service that offers meeting availability for a person along with its GPS location. (3) Manual Mobile Services: Services that are offered by human and mobile devices act as a gateway or interface for their services. Example—Mobile service interface for human provided services [42].

Table 4 Mobile services case study details
Full size table
Table 5 Mobile service description requirement coverage
Full size table

We perform requirement coverage analysis of the proposed description approach for these case studies in Table 5. This coverage analysis helps us assess whether the proposed mobile description is required for various types of mobile services and whether the proposed description meets the unique description requirements of various classes of mobile services i.e. Automated mobile services that make use of the device’s sensor or other services, semi-automated services that may use other services and sensors and also make use of manual information/data supply, and manual services that requires manual supply of information/data (human-automation continuum).

Based on our analysis with these case studies, all services definitely require a functional description. Most other descriptions discussed in the paper are usually also required by most services. The exceptions to this are description about data-source and the collaborator which are not necessary for manual mobile services as there is no other collaborator involved.

Limitations A few important limitations of the current work are listed as follows: (a) The current work does not deal with the privacy, security issues of the mobile service provider. Security and privacy issue is one of the prime concerns for the solutions that work over the web. These issues may include provision for the access control, authentication of legit service consumers, confidentiality, and integrity of the provider–consumer communication. (b) The current work does not handle dynamic QoS (Quality of Service) of the mobile web service. Currently, we consider claimed QoS by the service provider. Dynamic QoS is also one of the important challenge that may lead future research. Owing to the dynamic, volatile, and unpredictable nature of the mobile service provider, the QoS is bound to change. The dynamic QoS properties would further motivate the practitioners to adapt the mobile services as a new dimension of SOA. (c) Finally, the current evaluation of the approach was conducted within a supervised lab environment. The power and data requirements, service description discovery performance, and other results were therefore well within acceptable range. There could be slight variations in these if the experiments were carried out at a much larger scale including thousands of mobile devices.

As discussed, there are few of the limitations in the current work. These limitations can be looked as the open research challenges. These challenges do not prevent the adaptability of the proposed approach. The proposed work is one of the preliminary works in the field of mobile service description, that would provide a foundation for the added features i.e. security, privacy, dynamic QoS and many more.

6 Related work

Service description is an important mean that provides service specification to the prospective service consumers. Although literature emphasize the necessity of service descriptions for mobile web services, the unique service description requirements for mobile services is often overlooked. Existing literature rely on the traditional approaches of service description for mobile services, however, these approaches fall short to cater the specific needs of the mobile environment.

One of the most prominent and widely used description languages is WSDL [12]. It has been used traditionally to describe wired web services. WSDL describes various functional perspective of web services including service, interface, operations, endpoint, binding, and type definition. Despite the fact WSDL being effective and popular, it does not cover various other aspects of the service specifications (non-functional, contextual, business, data-source) that are pertinent to the mobile environments. As WSDL is capable of providing functional information, some of the works focused on extending WSDL to incorporate unavailable properties while relying on WSDL to describe functional aspect. A detailed discussion and comparison of the proposed approach and such existing works is already presented in Tables 1 and 2 of this paper. (We have studied the existing approaches for service description from the point of view of mobile devices.) One of the work discusses about versioning of web service interfaces and was introduced in description by Juric et al. [24], WSDL extension was proposed to support versioning of service interfaces at development-time and run-time. Agarwal and Jalote [3] proposed extensions to WSDL and suggested end-to-end support for non-functional properties description, measurement, and update. Amongst recent work [19] extend WSDL for describing complex geodata in GIS services.

O’Sullivan [34] presents a domain independent taxonomy for conventional services and web services, that is capable of describing non-functional properties. There work provides the ability to communicate non-functional properties along with the service descriptions. Scheithauer et al. [43] presents various perspectives and service properties to specify service description. Zachman framework [55] was used for specifying service properties and their relationship from a service provider’s viewpoint for service descriptions depending on the relative perspective. Kritikos et al. [27] presents an extensible ontological specification OWL-Q that provides semantic QoS based web service description. Cardoso et al. [9] and Charfi et al. [10] proposed a new service description language named Unified Service Description Language (USDL). USDL supports human and IT supported services and provides a domain independent description. However, we feel that an entirely new technology is constrained owing to lack of support for legacy systems.

Recently there has been several approaches proposed for cloud services. Galán et al. [18] proposed a service specification language based on OVF (Open Virtualization Format) standard for cloud computing platforms. Sun et al. [47] presents a description for cloud resources of cloud service provider, thus enabling the cross-cloud implementations. Liu and Zic [29] proposed cloud# to provide the service delivery transparency and enhance the trust of cloud service users. This cloud service specification focused on describing how services are delivered inside a cloud. Sun et al. [46] presents an interesting survey of service description languages from the point of view of cloud computing.

A few other related endeavours include: an ontology related to the context explained in [40], Dustdar’s survey on context aware web-service systems [39, 48] context ontology for mobile environments. Dorn and Dustdar [15] is an inspiring work by Dorn and Dustdar that suggests three types of context for mobile web-services: User-related Context, Service-related Context, Task-related Context. Knutson et al. [26] is a patent that makes use of WSDL and proposes multi-parted description. Although it only describes functional description in multiple documents. A recent work [37] presents linked USDL that aims to provide automated service trading over the web and provides a vocabulary based on linked data for this purpose. The work [20] takes linked USDL to the next level and adds semantic model with the intent to provide shared service level agreement over the web in automated manner. However, none of these works deal with the description of mobile hosted services specifically.

Though most of these works do not provide generic specification to fit functional, non-functional, contextual and business aspects of services. Moreover, these works do not cover tackle the specific requirements of dynamic update, separate specifications for data sources, and collaborators. To the best of our knowledge, no existing work is especially dedicated to incorporate the intricacies of the mobile environment. Our work is the first attempt to propose a service description mechanism for such environments.

7 Conclusions and future works

In this paper, we present a novel, lightweight, dynamic, and extensible mechanism for service description especially designed for services hosted over mobile devices. The proposed service description facilitates automated service discovery, selection, and composition. The approach is designed around WSDL 2.0 with the intent of making it useful across both wired and wireless environments.

The mobile environment is very dynamic and it is normal for service description attributes to change frequently over time. We proposed the partitioning of the mobile service description into multiple parts: Functional Description, Non-functional Description, Business Description, and Contextual Description. Further, we added descriptions to facilitate better assessment of mobile services by service consumers such as data source information, collaborator description, hardware details. The parts of the description that tend to change regularly are made local to the mobile device hosting the service. The motive is to enable seamless dynamic updates in service descriptions without compromising on the overall consistency of the description. The proposed solution has the potential to further ease the service selection for prospective service consumers in peer-to-peer manner. Further, the solution has the potential to help consumers confine service shortlisting and would avoid the obsolete and irrelevant services.

Future work in this direction would be towards investigation of additional properties for mobile services and the application of the proposed approach for service selection in the field of service oriented crowd sourcing. We also plan to extend the prototype into a sophisticated tool to assist developers in extracting the various aspects of dynamic descriptions. Further, we plan to evaluate proposed approach on the larger scale. We also plan to design a dynamic querying model for more efficient description search and dynamic QoS in a distributed mobile environment. We further plan to extend our approach to include semantic descriptions for mobile services. Future work may include security and privacy issues during description exchange.