• About Us
  • People
  • Collaborators
  • Courses
  • Joining Us
  • Visitors
  • Directions
  • Infrastructure
• Research Labs
  • Services Research
  • Semantic Web
  • Semantic Science
  • Bioinformatics
  • Data Mining
  • Metadata
  • D.I.A.C
• Projects and Funding
• Library
• News

METEOR-S

The METEOR (for "Managing End To End OpeRations") project [4] initally started at BellCore in 1990 and was continued at the LSDIS lab until 1998. A commercial spinoff, Infocosm, inc. and the product METEOR EAppS (for Enterprise Application Suite) are other notable accomplishments.

Adopting to the SOA and semantic Web evolution, METEOR evolved into METEOR-S where S stands for services (or Service oriented Architecture) and semantics. It was largely carried out at LSDIS Lab during later 1990s and 2006. One of the significant contributions of METEOR-S research is the submission of WSDL- S specification as a W3C member submission, along with IBM. In 2006, the W3C created a charter for the Semantic Annotation of Web Services (SAWSDL), which used WSDL-S as its primary input. SAWSDL became a W3C candidate recommendation in January 2007.

While other prominent semantic Web service efforts in OWL-S and WSMO have focused on creating service ontologies and process composition to a large extent, the objective of METEOR-S is to define and support the complete life-cycle of Semantic Web processes. METEOR-S adopts an evolutionary approach towards semantic Web services, by extending current SOA (WS-*) standards and specifications to support semantics. We identify three main stages in the life-cycle as illustrated in the Figure. The first stage comprises of techniques to define annotation mechanisms to extend current SOA standards. Using the annotations to support enhanced discovery and publication of services along with the support for configuration and data-mediation is addressed in the second stage. The third stage addresses identifying events and adapting to various events during execution.

overview of the METEOR-S Framework

While other prominent semantic Web service efforts in OWL-S and WSMO have focused on creating service ontologies and process composition to a large extent, the objective of METEOR-S is to define and support the complete life-cycle of Semantic Web processes. METEOR-S adopts an evolutionary approach towards semantic Web services, by extending current SOA (WS-*) standards and specifications to support semantics. We identify three main stages in the life-cycle as illustrated in the Figure. The first stage comprises of techniques to define annotation mechanisms to extend current SOA standards. Using the annotations to support enhanced discovery and publication of services along with the support for configuration and data-mediation is addressed in the second stage. The third stage addresses identifying events and adapting to various events during execution.

Specification and Annotation

The building blocks of SOA-based solutions are self-describing Web services that can be reused across various applications. The Web Service Description Language (WSDL) was created specifically for this purpose and describes the data elements, operations and message bindings. However, WSDL descriptions are not sufficient for the client to unambiguously decipher each operations intended purpose as well as the intended content of its parameters. SAWSDL (which evolved from WSDL-S, first proposed in [9]) overcomes the above limitation by adding semantic meta-data to WSDL elements. Semantic annotations are added to WSDL elements using the modelreference extensibility attribute. The modelreference value of a WSDL element contains a reference to a concept in the ontology that defines the semantics of that element. This allows service providers to better describe their interfaces and allows clients to better understand the interface descriptions. The original ideas for WSDL-S and SAWSDL were founded on the four types of semantics for services -

1. data semantics:

   descriptions of the data elements of a service

2. functional semantics:

   descriptions of the various operations andfunctional capabilities of a service

3. non-functional semantics:

   descriptions of the non-functional requirementsand guarantees

4. execution semantics:

   descriptions of events and faults and how to handle them [7].

We discuss the impact of semantic annotations in realizing dynamic configuration in the next section.

Dynamic Configuration

Our research has demonstrated the value of semantic annotations in realizing dynamic SOA environments. The METEOR-S middleware discussed in [3] demonstrates a SOA middleware that supports run time discovery and binding of partner services. Service requirements are both functional and non-functional. Service discovery selects partner services that fulfill the functional requirements. From this set, partners that fulfill the non- functional requirements are selected using constraint analysis.

Discovery and Publication

Selection of partner services that fulfill the functional requirements of a client is the first step to realize dynamic SOA environments. The METEOR-S Web Service Discovery Infrastructure (MSWDI) is a peer to peer frame- work for efficiently discovering partner services [8]. MWSDI uses an ontology-based approach to organize registries, enabling semantic classification of all Web services based on domains. Each of these registries sup- ports semantic annotation of the Web services, which is used during discovery process. MWSDI defines four kinds of peers

1. An operator peer controls a Web Service Registry. The role of the Operator peer is to control a registry and to provide Operator services for its registry. The Operator peer also acts as a provider for the Registries Ontology to all other peers who need it.
2. A gateway peer acts as an entry point for registries to join MWSDI. It is responsible for updating the Registries Ontology when new registries join the network. It is also responsible for propagating any updates in the Registries Ontology to all the other peers. Gateway peer is not associated with any registry.
3. Auxiliary peers act as providers of the Registries Ontology.
4. The Client peers are transient members of the peer-to-peer network, as they are instantiated only to allow users to use the capabilities of the MWSDI.

Multi-Paradigm Constraint Analysis

Partners that fulfill the functional requirements may not fulfill the non-functional requirements. Selecting part- ners who also fulfill the non-functional requirements is the second step. Non-functional requirements are typ- ically modeled as Service Level Agreements (SLAs). The SLAs lack semantic metadata and are often very generic, thus making it hard to match SLAs from two services. In [6], the authors present a framework to enhance WS-Agreement with structure and semantic metadata. The framework includes a well defined XML based syntax for expressing and semantically annotating SLAs. The additional semantic information allows one to incorporate rules and enables the system to make better matches dynamically.

Non-functional requirements themselves can either be quantitative (supply time ≤ 5 days) or non-quantitative (Security must be RSA). To deal with both, we proposed a multi-paradigm constraint analysis in [1]. The con- straint analyzer uses integer linear programming based techniques for optimizing the quantitative constraints and SWRL and SPARQL based techniques for non-quantitative constraints.

Data Mediation

One of the key benefits of SAWSDL is the systematic approach to data mediation using XSLT. Rather than using XSLT’s to mediate between message instances and schemas, SAWSDL advocates mediation at the level of ontologies. To translate a service schema to an ontology, SAWSDL specifies two key techniques

1. lifting schema mapping
2. lowering schema mapping

Lifting schema mapping is an XSLT transformation to convert a service schema to an ontology schema. Lowering schema mapping converts an ontology schema into a service schema. To achieve mediation between two service schemas, the source schema is lifted to its corresponding ontology schema. Using schema transformation techniques, the lifted schema is translated into the target ontology schema. This is lowered into the target service schema. The systematic approach offers a huge upgrade in defining and reusing transformation functions [5].

Adaptation

The adaptation phase addresses the problem of adapting business processes to runtime events and faults. These include system events such as service unavailability, as well as business level events such as shipment delays. Creating a middleware system with the ability to monitor and adapt to both types of events can be viewed as a two-step problem. The first step is to identify and subscribe to the events to which the system might need to adapt. The second step is to adapt to those events as and when they occur. We present an approach to automatically identify events that may impact the execution of a process in [2]. We build upon our research in the area of semantic associations to discover events that are associated with various requirements in a functional and a non-functional ontology.

Once the events are identified, we address adaption as a stochastic decision making problem using Markov Decision Processes(MDP) [10]. MDP policies are generated by using the events identified, event probabilities described by partner services and the cost impact of the events as described in the SLAs. Further, a cost penalty for adaptation is calculated by considering the constraints that occur across services (inter-service dependen- cies). This allows us to ensure that the adaptation does not violate the process optimality requirements. We discuss three approaches- 1) a centralized approach in which a central controller maintains all the MDP state information, 2) a decentralized approach in which each MDP acts independently of the other in deciding the optimal action and 3) a hybrid approach in which the decentralized MDPs communicate with each other via the central controller.

References

1. R. Aggarwal, K. Verma, J. A. Miller, and W. Milnor. Constraint driven web service composition in meteor-s. In IEEE SCC, pages 23–30, 2004.
2. K. Gomadam, A. Ranabahu, L. Ramaswamy, K. Verma, and A. P. Sheth. Mediatability: Estimating the degree of human involvement in xml schema mediation. In ICSC 2008.
3. N. Krishnakumar and A. P. Sheth. Managing hetergeneous multi-system tasks to support enterprise-wide operations. Distributed and Parallel Databases, 3(2):155–186, 1995.
4. J. A. Miller, D. Palaniswami, A. Sheth, K. Kochut, and H. Singh. Webwork: Meteor’s web-based workflow manage ment system. Journal of Intelligent Information Systems, 10(2):186–215, 1998.
5. N. Oldham, K. Verma, A. P. Sheth, and F. Hakimpour. Semantic ws-agreement partner selection. In WWW, pages 697–706, 2006.
6. A. Sheth. Semantic web process lifecycle: Role of semantics in annotation, discovery, composition and orchestration, 2003.
7. A. P. Sheth, K. Gomadam, and J. Lathem. Sa-rest: Semantically interoperable and easier-to-use services and mashups. IEEE Internet Computing, 11(6):91–94, 2007.
8. K. Sivashanmugam, K. Verma, A. P. Sheth, and J. A. Miller. Adding semantics to web services standards. In ICWS, pages 395–401, 2003.
9. K. Verma, P. Doshi, K. Gomadam, J. A. Miller, and A. P. Sheth. Optimal adaptation in web processes with coordi- nation constraints. In ICWS, pages 257–264, 2006.
10. K. Verma and A. P. Sheth. Semantically annotating a web service. IEEE Internet Computing, 11(2):83–85, 2007.