Subproject B1 (until June 30, 2015)

Parameterized Service Specifications

Services are discovered, composed, and analyzed in on-the-fly computing, in order to create high quality customer-specific IT solutions satisfying customer’s requirements. Subproject B1 develops techniques for configurable, comprehensive specification of services and requirements for services, including functional as well as non-functional service properties. Based on their specifications, services have to be matched against the given requirements. For matching, subproject B1 also develops advanced techniques for such comprehensive, configurable service specifications.

Motivation

In on-the-fly computing, customer-specific IT services are created automatically from flexibly combinable services based on customer’s requirements. An example is the Trip Planner service (depicted in the picture above) composed from the Google Maps service, a local traffic service PaderSprinter, a restaurant finder PaderTouristik, and a rating service. These services are available for trade in so-called on-the-fly markets (OTF markets).

Service matching compares a customer's requirements to a service's specification. Thereby, it serves as a prerequisite for discovery and composition of services in OTF markets. Comprehensive service specifications contain functional as well as non-functional properties of services. Thereby, they serve as a basis for accurate matching results, as many different service properties can be taken into account. However, this kind of comprehensive matching takes too much time. In contrast, matching of simpler service specifications runs faster but the obtained matching results are less accurate. B1 faces the challenge to deal with trade-offs like these.

Furthermore, in OTF markets, different providers use different specification languages to specify service properties (e.g., well-known SAWSDL or OWL-S). This fact further complicates the service specification and matching in OTF markets.

A Comprehensive Service Specification Language

In order to meet the challenges noted above, subproject B1 develops a holistic approach for the specification of services and their matching. In the center of this approach is a definition of a comprehensive core language in form of a metamodel. The core language includes concepts for the specification of functional properties of a service (such as operation signatures, pre/postconditions, protocols, or data flow) as well as non-functional properties (such as performance, privacy, reputation, or prices). For matching, service specifications written in different specification languages have to be transformed into the core language, for which matching approaches are defined. This reduces the effort for matching heterogeneous service specifications written in different languages. For transformation into the common language, subproject B1 provides a user-friendly model transformation approach by-example, whose users do not need an expertise in metamodeling.

As explained above, the expressiveness of the core language for a service market is a subject to the following trade-off: on the one hand, highly expressive service specifications require much specification effort from modelers and result in significant overhead for the matching because different service properties have to be matched. On the other hand, low expressive service specifications require few specification and matching effort, however the obtained matching results are unreliable because matching accuracy is relatively low for simple service specifications. Therefore, the comprehensive core language is configurable depending on the characteristics of the considered OTF market. Based on these characteristics, the comprehensive common language is configured in a way that matching of its specifications is optimal wrt. accuracy of matching results and matching efficiency.

Matching

As noted above, in On-The-Fly Computing, we have to deal with comprehensive service specifications describing many different properties of a service or a request. However, we cannot expect customers or providers to provide such comprehensive specifications for several reasons: For example, customers are not always willing and able to specify their needs completely and precisely. Similarly, providers do not always provide complete specifications as they do not know all details (e.g., the exact performance of a service) or because they want to protect business interests. This leads to the presence of incomplete and imprecise service specifications.

There are already many service matching approaches described in literature, but they are not able to deal with incomplete or imprecise service specifications. The reason is that current matching approaches make unrealistic assumptions, for example, they assume that the specifications are always precise and complete.  Thus, we developed a new concept to address this challenge: Fuzzy Matching Processes.

Using Fuzzy Matching, we are able to classify and quantify different occurrences of fuzziness in service specifications: requester-induced fuzziness, provider-induced fuzziness, algorithm-induced fuzziness, and transformation-induced fuzziness. Depending on the kind of specification, quantifications can be based on different methods, e.g., percentage fuzziness scores or fuzzy sets.

In order to be able to deal with many different service properties, (fuzzy) matching approaches are combined with each other. Thereby, they build comprehensive matching processes consisting of several matching steps. These matching processes are configurable as they allow different combinations of matching steps as well as further variations, e.g., different aggregation strategies for matching results. This configurability allows us to optimize matching to the specific characteristics of a certain market.

Tools

The developed languages, specification techniques, and tools serve as the foundation for the CRC. B1 develops several tools: Service Specification Environment, Service Specification, Matching, and Analysis Environment, MatchBox, and LM Configurator. They are presented in the [link]overview of our tools[link].