290 likes | 452 Views
Tools For Composite Web Services: A Short Overview By Richard Hull, Jianwen Su. Presented By Venkatavasishta Chemudupati. Outline. Introduction Web Services and Standards Models of Web Services and Composition Analysis of Composite Services Conclusion. Introduction.
E N D
Tools For Composite Web Services: A Short Overview By Richard Hull, Jianwen Su Presented By Venkatavasishta Chemudupati
Outline • Introduction • Web Services and Standards • Models of Web Services and Composition • Analysis of Composite Services • Conclusion
Introduction • What is Web Services ? • It is defined by the W3C as "a software system designed to support interoperable machine-to-machine interaction over a network". Web services are frequently just Web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services. • Challenge is to develop modeling techniques and tools to enable their composition and analysis. • In this paper, an overview of assumptions and underlying concepts as well as composition models such are explained.
Anatomy of Web Service Composition Goal(s) • No unified model, e.g., • BPEL: Strong on orchestration, info sharing • OWL-S: Strong on goals, activities, discovery • “Roman” model: Strong on activities, orchestration Activities Orchestration, Monitoring Discovery/ Self-description Info sharing (Messaging)
BPEL Key dimensions in web service composition OWL-S “semantics” Commitment Protocols CTR-S -Calc WSCL Mealy BPML Complexity of glue language Roman CSP WSDL Complexity of component services SIGMOD'04
Outline • Introduction • Web Services and Standards • Models of Web Services and Composition • Analysis of Composite Services • Conclusion
Web Services Standards Stack: Key Elements UDDI Discovery WS-Choreorgaphy Choreography BPEL4WS OWL-S ServiceModel Composition WSCL (Individual)ServiceDescription WSDL OWL-S ServiceProfice XMLMessaging SOAP HTTP, SMTP, FTP, etc. Network
Simple Object Access Protocol • A W3C standard • Originally developed for BizTalk • A light weight replacement for complicated distributed object technology • “XML-RPC”, typically through HTTP, also JMS … • Lowest level of service interaction Web Server SOAP Envelope External Service Web Service
Web Service Definition Language (WSDL) • WSDL provides a framework for defining • Interface: operations and input/output • Access specification: SOAP bindings (e.g., RPC) • Endpoint: the location of service Supports Port Type Operation How to invoke Formats & Protocols Input & Output How to encode Binding Message Implements Provides Port Service
Web Service Conversation Language (WSCL) • A key to web service composition: • Interactions between services • WSCL specifies a conversation (behavior signature) as a labeled graph: • Nodes: interactions, individual units of responses • Edges: transitions, sequencing of interactions • Edge labels: conditionson transitions
Business Process Execution Language (BPEL) • Allow specification of compositions of Web services • business processes as coordinated interactions of Web services • Allow abstract and executable processes • Influences from • Traditional flow models • Structured programming • Successor of WSFL and XLANG • Assumes WSDL ports • Standardization through OASIS
Outline • Introduction • Web Services and Standards • Models of Web Services and Composition • Analysis of Composite Services • Conclusion
OWL-S: Model and Composition • OWL-S is an ontology built on top of Web Ontology Language (OWL) by the DARPA DAML program. It replaces the former DAML-S ontology. "OWL-S is an ontology, within the OWL-based framework of the Semantic Web, for describing Semantic Web Services. • It will enable users and software agents to automatically discover, invoke, compose, and monitor Web resources offering services, under specified constraints. • Here we adopt the approach recently introduced by work by work on First-order Logic Ontology for Web Services (FLOWS) as it is somewhat closer to relational database formulation than originally used by OWL-S.
Functionality Description • Preconditions • Set of conditions that should hold prior to service invocation • Inputs • Set of necessary inputs that the requester should provide to invoke the service • Outputs • Results that the requester should expect after interaction with the service provider is completed • Effects • Set of statements that should hold true if the service is invoked successfully • Often refer to real-world effects, e.g., Package being delivered, or Credit card being debited
Process Specification Language • A recent ISO standard which is first order logic ontology for describing the core elements of processes. • PSL is layered with PSL-Core at base and many extensions viz. PSL-OuterCore. • PSL-OuterCore provides first-order predicates that can be used as basic building blocks of processes and execution. • In a typical usage, application domain is created by combining PSL-OuterCore with domain specific predicates and sentences to form theory. • The models of theory can be thought of as a tree, whose nodes are activities with edges from one occurrence to another. • A path can be viewed as one possible execution of steps.
OWL-S and PSL Combined • Now, to provide a database-oriented cast on PSL and OWL-S • The PSL and domain-specific predicates associated with our example can be viewed essentially as relations in a relational database. So, we might have
Results concerning automatic composition of OWL-S • In first one, it is assumed that all relevant aspects of application domain are represented using finite number of propositional fluents and permitted input and output is finite. • The goal is then specified in terms of overall effect to be achieved starting from initial state. • Another approach proposes a two tier framework based on generic programs and customization via constraints.
Roman Model perspective • This involves automated composition of multi-step services. • Basically, there is a finite alphabet of activity names, but no internal structure is modeled. • In the most general case, these are potentially infinite trees, where each branch corresponds to a permitted sequencing of executions of the activities. • For the theoretical results they restrict attention to finitely specifiable transition systems; in particular on systems that can be specified as deterministic finite-state automata, where the activities act as the input alphabet
Conversations and Mealy Services • The OWL-S and Roman focus on what a service does in terms of input/output and their impact on world or sequencing the activities, neither address how component services should interact with each other. • We assume an infinite set of message classes, where each class mc has service name as source and target. • A compositions schema is a pair (P,M) where P is finite set of service names and M finite set of message classes.
FLOWS • FLOWS – It includes objects of type service. These can be related to several types of object, including non-functional properties and also its activity. • Flow of information between services can occur in two ways • Message Passing • Shared access to same “real world” • It is a very open-ended concerning process or data flow between atomic processes inside a services.
COLOMBO • A formal model it combines • A world state, representing the \real world", viewed as a database instance over a relational database schema • Atomic processes in the spirit of OWL-S, • Message passing, including a simple notion of ports and links, as found in web services standards (e.g., WSDL, BPEL) • An automata-based model of the internal behavior of web services, where the individual transitions correspond to atomic processes, message writes, and message reads.
Contd… • A “local store” for each web service, used manage the data read/written with messages and input/output by atomic processes • a simple form of integrity constraints on the world state
Conclusion • To Find appropriate models and abstractions for representing Web services and their “behaviors”, which are suitable to the web services paradigm, and can support efficient querying and manipulation as needed by web service composition and analysis algorithms. • How to bring data manipulation more clearly into web services paradigm and their associated standards. • Are there specialized models of Web service composition that will be more suitable for applications that are targeted primarily at data processing ?