1 / 26

Towards Zero-Code Composition

Towards Zero-Code Composition. Emre K ı c ı man, Laurence Melloul, Armando Fox Software Infrastructures Group, Stanford University. Zero-code Composition. Zero-Code == not writing any glue code to compose services into a system Zero-Code makes it easier to build static applications

jared-mason
Télécharger la présentation

Towards Zero-Code Composition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Towards Zero-Code Composition Emre Kıcıman, Laurence Melloul, Armando Fox Software Infrastructures Group, Stanford University

  2. Zero-code Composition • Zero-Code == not writing any glue code to compose services into a system • Zero-Code makes it easier to build static applications • Reuse of existing components • No need to write code to adapt components to each other • Zero-Code is necessary for building ad hoc and dynamic applications • Ad hoc  We don’t know what we need to build until we need to build it • Without zero-code composition, it takes too much time to build an application, ad hoc apps are not worth building…

  3. … and Ubiquitous Computing • Ubiquitous computing means: • Many heterogeneous devices (including legacy and COTS devices) • Many services in the infrastructure, providing varied and interesting functionality (but all developed separately, and not coordinated with one another) And these services and devices are all expected to work together! • A Zero-Code composition framework helps us to compose these devices and services together to perform tasks

  4. Composition Guidelines • General idea: Use loosely-coupled services • Component frameworks today impede composition • CORBA, JavaBeans, etc. • The methods used to build components do not work well for composing components. • Two major types of impediments • Control impediments relate to ordering of execution of components. • Interface impediments occur when components have dependencies on others’ interfaces.

  5. Control Guidelines • Make control flow between components explicit • Difficult to analyze and manipulate compositions because connections are spread out as function calls across the code • Explicitly specifying component interactions makes it easier to understand and change the composition • Separate control flow between services from the flow within a service • Control model (assumptions about which components control sequencing of operations). • Giving each service a separate locus of control. Only dependency is data dependency use data flow network between components

  6. Interface Guidelines • Use named inputs and outputs, and a level of indirection for component interaction • APIs force components to know in advance the interface/method names of other components • By using a level of indirection, we can compose any components without prior coordination • Example: Unix Pipes • Use evolvable, self-describing type systems • Semantically compatible components cannot work together because they do not agree on names of data types • By using self-describing type systems, we can get necessary sub-elements of data structures • Example: Named tuples, XML, …

  7. Putting it Together • Components are loosely-coupled, interact through an indirection of named, typed inputs and outputs • Within a composition, services are connected via coarse-grained data flow networks • A generic run-time system instantiates a composition based on an explicit description of the data flow network • Data types are described using an evolvable, self-describing type system

  8. Paths Prototype • Paths is a prototype zero-code composition framework that follows most of these guidelines • To create a composition, one writes a description of the data flow network, specifying services, connectors, queues, and the connections between them.

  9. Web Services Web services already follow many of these guidelines: • Control: They are autonomous, have their own separate loci of control, and do not expose their internal control model • Interface: They are accessible through a common protocol (HTTP), and because web forms only accept strings, there is no danger of artificial type mismatches But… There are semantic type mismatches, and no standard method of passing data between services…

  10. Exploiting Composition How can we take advantage of composition? • Building Ad Hoc applications • Application Templates • Providing more sophisticated Web Services • Customized services (e.g., comparison shopping with user-specified services and products, or “here is my profile, plan my evening”) • Subscription services (e.g., “let me know when a historian presents his/her new book in Downtown SF”) • Smart services (e.g., guess intelligent compositions of random services put in a basket by the user)

  11. Application Templates • Application templates describe the data-flow connections between a set of generic services. • Here is a simple template for data aggregation. • To build an application, fill-in the template with specific data source, aggregator, and formatter services

  12. Application Templates (cont.) • Application templates ease automatic application creation • It’s hard to decide how to connect arbitrary services together—the template puts that decision into a person’s hands • It’s easy to decide which services to compose together—search for services based on service type, and rank them based on context, user preferences, etc. • With zero-code composition, we don’t worry about mechanics of particular services • Can use application template concept in your projects without zero-code comp. by standardizing your interfaces

  13. The WeSCoS System • A general composition framework • Allows developers to add services and define composition requests • Relies on compact, descriptive XML service specification • Same interface used for composite and atomic services (transparent to the caller) • Once a specification is loaded into WeSCoS, requests are automatically executed by the system

  14. Architecture Walk-through • A composition example • Get restaurants nearby theaters playing “Men in black”, within given zipcode area • 2 HTTP atomic services • Get movie showtime info, by theater, for given zipcode (moviefone.com) • Get restaurant info, nearby given address (mapquest.com) • For given zipcode, invoke 1; for each found theater, extract its address and invoke 2

  15. The WeSCoS Architecture Converters (xml/html, xml/wml) User Service request Web Service Request/ Response document Request results XML data Front- End HTTP Http Service Processor Service Request Processor XML spec XML spec Web Service HTTP Database XML spec Composition Engine HTML data Service Processing Core

  16. The Service Specification • A compact, XML-based document • Includes identifier, input/output schemas, and execute node • The execute node contains invocation information, useful to the composition system • All HTTP invocation information (atomic service) • Or all composition execution steps (composite service) • Recommended: 1 specification per Web service functionality

  17. A Service Specification Example • <service version = “1.0”> • <identifier> • <name>Get CD list by author</name> • <provider>Amazon.com</provider> • <version>1.0</version> • <description>Return the list of CDs, with title and price, given the author name </description> • </identifier> • <input-schema> • <element name=“field-keywords” desc=“authorName” type=“String”/> • </input-schema> • <output-schema> • <element name=“info” minOccurs=“0” maxOccurs=“unbounded”> • <element name=“title” desc=“CDTitle” type=“String”/> • <element name=“price” desc=“CDPrice” type=“float” minOccurs=“0”/> • </element> • </output-schema> • <execute method=“http”> • … • </execute> • </service>

  18. The HTTP Execute Node • <execute method=“http”version=“1.0”> • <url>http://www.amazon.com/exec/obidos/search-handle-form/102-0977834-7085735 • </url> • <method>post</method> • <version>1.0</version> • <parse method=“html> • <result> • <![CDATA[<tr…<td…<a…>title</a>…~author<…Our Price:…$price<…</tr>]]> • </result> • </parse> • </execute>

  19. XPL: an XML Programming Language • Scripting language to define composition steps • Syntactically compatible with specification syntax • Restricts composition instructions, for more control over the system behavior • Could substitute other “integration” languages, e.g. Tcl

  20. The Composition Execute Node <execute method=“comp” version=“1.0”> <invoke ref=“A”> <identification name=“Get CD list by author” provider=“Amazon.com” version=“1.0”/> <param name=“field-keywords” source=“input/author”/> </invoke> <foreach ref=“res” data=“A/result”> <invoke ref=“B”> <identification name=“Get CD info by title” provider=“Buy.com” version=“1.0”> <param name=“qu” separator=“ “> <value source=“res/title”/> <value source=“res/author”/> </param> </invoke> <add element=“result”> <add element=“author” source=“res/author”/> <add element=“title” source=“res/title”/> <add element=“price1” source=“res/price”/> <add element=“price2” source=“B/result/price”/> </add> </foreach> </execute>

  21. Prototype Evaluation + Ease of service creation + Ease of composition + Simple system implementation and deployment Document exchange => easy, modular upgrade of the composition system - Naïve (and slow) implementation - Not so stable (see open challenges)

  22. Open Challenges • Correctness • Unstable servers (tracking changes): submit-and-scrape rules are fragile; plus independent evolution • Problem for deployment • Semantic mappings are user’s responsibility • Multi-step interactions • e.g. multi-screen sites, authentication, etc. • May be able to help with tools such as WebL • Failure semantics: if one service in the “chain” fails... • Retry whole chain? Or only the failed service? • What about side effects or non-idempotent services? • Currently limited to “lookup-like” services

  23. Open Challenges (cont.) • “Distributed systems challenges” • No guarantee/control on service availability/quality; trust • potentially low bandwidth and high latency • Time-out estimates (transparent nested compositions) • “Fundamental” Challenge: Lack of support for composition validation (due to lack of systematic typing) • Arguments are named, not necessarily typed • Observation: human knowledge is generally required at some level to “validate” compositions

  24. Related Work • CNET, comparison shopping => no composition framework • HP’s E-SPEAK => closest but not a zero-code composition framework • MICROSOFT’s .NET? • Arriba, Commerce One => specific service interface per application domain

  25. Future Work • Think a data flow model to specify compositions • Front-end to add and validate service specifications • Interface converters for wireless devices • Take advantage of composition to provide system-wide properties (dependability, etc.) • Time-outs & errors: retries can be specified as part of the composition specification • Availability vs. quality: less-quality, competitive services can be used as backup services; again specified in the composition

  26. Conclusion • Use loosely-coupled services: • Keep services autonomous, with flexible data types and named I/O • Use a data flow model to represent the composition • Question: Will the benefits of Web Service Composition outweigh its challenges?

More Related