Service ecosystems are electronic market places which emerge as a result of a shift toward service economies. The aim of service ecosystems is to enable to trade services over the internet. One obstacle to realize this new form of market place is a missing common description for electronic provisioned services. Additionally, methods and tools must become available which have to realize this description. A Business Service Description Methodology for Service Ecosystems allows describing electronically consumed services, offers modeling facilities and ontologies, links professional and technical theories, and provides a methodology which supports domain experts. This will improve to propose services, service discovery & selection, service negotiation & service contracting, service monitoring & profiling, service substitution, and service composition.
Tertiarisation describes a structural change in developed countries concerning the sectoral composition. Countries shift from an industry economy toward a service economy. Drivers of this change include globalization, technological change, and an increasing demand for services [24]. Considering this trend, it becomes clear that services and the service economy play an important role in today's and tomorrow's business. In line with this trend, service ecosystems emerge, such as eBay, Google Base, Amazon.com, SalesForce.com, and SAP Business by Design. The vision of service ecosystems is an evolution of service orientation and takes services from merely integration purposes to the next level by making them available as tradable products on service delivery platforms [4]. They aim at trading services over the internet between different legal bodies, compose complex services from existing ones, and IT-supported service provisioning [10].
Figure 1 depicts steps which are involved in service trade: (1) service proposition, (2) (4) service monitoring & profiling (cf. [13]). Midst service proposition, service providers advertise their services toward potential consumers, whereas during discovery & selection, service consumers specify their service preferences toward providers. In the event a service consumer selects an appropriate service, providers and consumers negotiate and finally agree on service levels (SLA) which are monitored throughout service consumption. In the event service levels are not met, compensations must be triggered. During service profiling, valuable information on services' performance is stored, which is gathered while service usage and monitoring.
In order to enable service trade, a shared and common understanding of services must become available. Nonetheless, no established language exist to define, to agree on, and to monitor service properties [13]. On top of that, Booms and Bittner [5] argue that services are different to goods, that is services are intangible, and thus, can neither be stored, transported, nor resold. Goods are produced at some point, stored, and eventually consumed at a later point. In contrast, production and consumption of services take place at the same time.
Goods can be transported from one point to another. Services, on the other hand, are consumed at customers' locations, thus, production and consumption happen in one place. Whereas goods can be resold, services' outcome cannot be sold to another party. Additionally, services can hardly be standardized, since service experience is unique and depends on the individual expectations.
While ample technical specification exists to describe services, conceptual notations to elicit business-relevant domain knowledge are lacking. Suitable technical specifications for service descriptions include: (1) Web Service Description Language (WSDL) [27], (2) Web Ontology Language for Services (OWL-S) [14],
(3) Web Service Modeling Ontology (WSMO) [28], and (4) Service Level Agreements for Web Services (WSLA) [11], just to name a few. Currently, semantic concepts to describe web services base on formal approaches, such as first-order logic and predicates. This hinders domain experts to describe services with these concepts. A more sophisticated approach must become available.
Recent work concentrats on the business service modeling discipline with a focus on how to formalize the relationship between business operational requirements and to implement them with service-oriented architectures (cf. [6]). However, the focus lies in business process transformation [22]. No attempt has been made for service descriptions.
The basic questions that I attempt to answer is (1) how one can extend the semantics of existing modeling notations in order to allow the modeling of service descriptions, and (2) how this can be mapped to technical specifications. This problem can be subdivided into the following questions. Section 6 elaborates on how to answer these questions.
1. What are service ecosystems and their service description requirements? 2. Which service properties are relevant for service ecosystems? 3. How are service properties modeled during service design utilizing process model notations and business model notations? 4. How are service properties implemented with web service technology? 5. How is coherence established between service description design and implementation, and how can service properties be derived from business models and implemented with web service technology?
4 State of the Art Baida et al. [2] elaborate a notion for the concept of services. It includes realworld services, internet-based services, and web services. Papazoglou's extended service-oriented architecture [23] comprises a basic service description. It includes the aspects: service capability, service interface, service behavior, and service quality attributes. My research focuses on the service capability and is understood as functional properties, and on the service quality attributes which is understood as non-functional attributes.
Quartel et al. [26] describe a framework for concept service modeling (COSMO). The framework comprises two orthogonal dimensions: service aspects and level of abstractions. Service aspects include: structure, behavior, information, goal, and quality. Single interaction, choreography, and orchestration represent levels of abstraction. Each intersection is a placeholder for models or implementation languages. The quality aspect refers to non-functional properties, goals to functional properties. This framework supports to establish coherence between different service description artifacts.
Oaks et al. [15] write about the lack to specify service capabilities, that is, what services, or agents, can do. They offer a structured and machine interpretable capability description. This approach will be of help to specify a service's functional properties.
O'Sullivan [21] illustrates in his PhD thesis a wide range of quality attributes to describe real-world services. These attributes include availability, obligations, price, payment, and discounts, just to name a few. His work will support the understanding of non-functional properties.
Gordjin et al. [7] offer a structured approach, namely the e 3 -Value Model to gather requirements for e-commerce applications. It includes three levels of abstraction and a six steps process for guidance. They argue that current requirement engineering methodologies are inadequate for the e-commerce domain. Their work will guide my understanding for service requirement analysis.
The ontology presented by Osterwalder [20], offers a holistic way to describe business models. It comprises the following concepts: (1) value proposition, (2) target customer, (3) distribution channel, (4) relationship, (5) value configuration, (6) capability, (7) partnership, (8) cost structure, and (9) revenue model. My research focuses on the value proposition, the value configuration, and the capabilities. The value proposition equals services' functional and non-functional properties. The value configuration represents the interplay of different services to meet a value proposition. Capabilities embody the competencies to execute a business model and thus, depict requirements toward services.
The Open-EDI reference model [9] distinguish between a business operational view and a functional service view. Dorn et al. [6] refines the business operational view into business models and process models, and the functional service view into deployment artifacts and software environments. These works helps to categorize models and implementation languages and to correlate them in order to establish coherence.
To date, I spent most of the time to gain knowledge in the field of "semantic web services" and "services research" in general. Furthermore, I looked into "business models" and "modeling".
As a preliminary result would count the investigation, consolidation, and verification of service properties. Firstly, a literature research was carried out.
Secondly, identified approaches were explored and compared. Additionally, similarly properties from all approaches were consolidated. Thirdly, for a better understanding and reduction of complexity, likewise properties were grouped into sections. Each section was named on the basis of the corresponding properties. Following this, available experts were identified for each section. These experts were questioned about all sections and properties in general and the section regarding the interviewee's expertise in particular. The answers were integrated into the comparison. The properties were used to describe existing services. Lastly, results were published [30,29].
Additionally, I looked into service engineering methods. Three colleagues and I work on a service engineering methodology on the basis of the Zachman framework and model driven architecture (MDA). Our intermediate results were published at the RESER 2008 conference [12].
Recently, I motivated and extended to use the Zachman Framework as a coherence framework for service description notations and realization languages (cf. Scheithauer et al. [29]).
This section introduces an approach to tackle the challanges mentioned in section 2. I call the final outcome of my research project Business Service Description Methodology for Service Ecosystems. It allows describing electronically consumed services, offers modeling facilities and ontologies, links professional and technical theories, and provides a methodology which supports domain experts.
My research approach follows the information system research cycle of Hevner and March [8]. Design science in general follows a five-step process: (1) Problem awareness, (2) suggestion, (3) development, (4) evaluation, and (5) conclusion. This research proposal addresses the following steps: problem awareness (cf. section 3) and suggestions with references to development and evaluation (cf. section 6).
My course of action is subdivided into five steps. Each step illustrates the development part according to Hevner and March's information system research cycle (cf. [8]).
Step 1 -Service Ecosystems: I will investigate existing literature about this phenomenon in terms of stakeholders, drivers, success factors, purposes, challenges, definitions, and technology. I have already identified key sources for this phenomenon [4,32,33]. Additionally, the analysis of existing service market places such as Amazon.com, SalesForce.com, Google Base, and StrikeIron.com will improve my understanding.
Step 2 -Service Properties: I will investigate existing literature about service properties. Sources are versatile and include standards (ebXML [16], Dublin Core Meta Data [1], IEEE 830-1998 [31]) and academic publications (O'Sullivan [21], Barbacci et al. [3]). I will develop a set of properties which satisfy service ecosystems requirements. These properties comprise functional and nonfunctional characteristics.
Step 3 -Modeling Languages: I will investigate existing modeling languages to express service properties. Already identified model languages include the business model ontology [20], the e 3 -value model [25], UML Profile and Metamodel for Services (UPMS) [18], UML Profile for Modeling Quality of Service (UPMQoS) [17], and Service Component Architecture (SCA) [19]. Additionally, I will investigate process-oriented modeling languages, such as BPMN, EPC, and petri nets, in order to identify links between service description and process model languages.
Step 4 -Realization Languages: I will investigate existing realization languages to implement service properties. Already identified realization languages include WSDL [27], Web Service Modeling Ontology (WSMO) [28], Web Ontology for Services (OWL-S) [14], and Web Service Level Agreements (WSLA) [11].
Step 5 -Methodology: The methodology to describe services for service ecosystems is the resulting artifact of my research. On the basis of service ecosystem requirements, service properties, and modeling & realization languages, I will develop a cohesive methodology to describe and realize service descriptions.
Nowadays, service engineering and describing the final product is a decoupled parallel process. My research supports to intertwine these processes into one, allowing an exchange of requirements throughout service engineering, and thus, improves the service outcome -expectations ratio. Identified service properties and a language to model value requirements improve service discovery; since service consumer and provider use the same language to discover and propose services, and a modeling language hides technical details and enables domain experts to specify service requirements. Also, my work simplifies service selection, since a common set of service properties unifies services and allows to easily compare them. A common set of service properties may serve as a skeleton for service contracting and thus, lowering transaction costs. Furthermore, during service provisioning, service consumer and / or service provider may benefit from service properties as key performance indicators (KPI) for monitoring purposes.
This thesis is supervised by Prof. Dr. Guido Wirtz from the Distributed and Mobile Systems Group, University of Bamberg. This project was funded by means of the German Federal Ministry of Economy and Technology under the promotional reference "01MQ07012". The responsibility for the content of this publication lies with the authors.