remash! - Blueprints for RESTfulSituational Applications

738 views

Published on

Abstract: Situational applications enabled throughWeb service mashup technologies and lightweight protocols have attracted tremendous attention in the area of social computing, Web 2.0 and increasingly in the business context. Short-term tasks can be dealt with by ad-hoc building pipes of data services that together expose required capabilities. Nevertheless existing approaches such as Yahoo Pipes!, Google Mashup Editor and IBM Mashup Center are still in their infancy. Flexible binding of external third-party services and alternatives as well as collaborative mashup design is still not adequately supported by current solutions.
The contribution of this paper is threefold. First we provide a specification for blueprints for situational applications that incorporate policies about technical feasible service flows and user preferences. Secondly, we demonstrate a prototypical realization of a graphical blueprint planner, an adequate architecture design that enables mass collaboration and a policy language. Thirdly, we analyze performance issues that may arise during real-time validation and preference-based selection of situational applications using a simulation-based approach.

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
738
On SlideShare
0
From Embeds
0
Number of Embeds
35
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

remash! - Blueprints for RESTfulSituational Applications

  1. 1. remash! Blueprints for RESTful Situational Applications MEM 2009 – Madrid, 20.04.2009 Benjamin Blau1, Steffen Lamparter1, Steffen Haak2 1KarlsruheService Research Institute (KSRI) 2Research Center for Information Technology (FZI)
  2. 2. Agenda 1 Principles of Situational Applications & State-of-the-Art Specification and Realization of 2 Blueprints for Situational Applications 3 Conclusion & Future Work remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 2 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  3. 3. Principles of Situational Web Applications Principles of situational applications • Resource-oriented architectures • Services mostly expose data instead of algorithms • Unique and easy-to-use HTTP interfaces • Scope information important for data services (explicit in the URI) • Lightweight composition and flexible binding • Composition without integration issues (complex interfaces,…) • Well-defined building blocks with unique interfaces • Mass collaboration, customization and perpetual beta • “Living” applications that never reach a “final” state • Ad-hoc development analogue to agile development approaches • Addressing the long tail through individualization (choice generates demand) • Wisdom of the crowd paradigm remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 3 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  4. 4. State-of-the-Art – Overview Tool/Approach Usability Visualization Integration of Collaboration Technology External Services • Easy to use • Seperates flows • • Reuse/extension Yahoo! Pipes programming-like Standard Web • Dealing with data • from UI restricted to of existing (YUI) • User can decide flows and interfaces JSON/RSS data mashups through needs expertise between lists, maps formats copies/clones • Programming-like and data usage of data filters • Recommendation for • Appealing • Rich set of • Reuse/extension Microsoft PopFly Proprietary suitable service Silverlight predefined of existing (Silverlight) combinations apperance sources but not mashups through • Hides programming • Rich set of extensible copies/clones complexity visualization (photo galleries, 3D graphics) • Developer workspace • UI elements such as • Programming-like • Applications can Google Mashup Standard Web • XML-based mashup Editor gm:map, gm:list, integration of be published but language must be gm:text… external RSS/XML not extended coded manually sources • Rich support of UI • Programming-like • Planned but not IBM Swashup N/A RoR/Web [Maximilien et al. Guess: programming-like elements and user integration in yet realized 2007] usage customization mashup recipes (future work) • Easy composition of • Produces extra • Any Web site can • Any user can add Intel MashMaker Browser plug-in [Ennals et al. widgets through Web content embedded be sourced embedded 2007] site extraction in Web sites widgets to a site remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 4 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  5. 5. State-of-the-Art – General Shortcomings • Integration of individual 3rd-party services • Weak support for integration of individual external services • Tools do not incorporate knowledge about technical and semantic feasible service combinations • No approaches to support searching for external services (e.g. semantic annotations) • Robustness • No compensation for missing SLAs and quality guarantees • No remedy for failure of single service components (integrated services are not under the control of the mashup designer) • “Situational” does not mean people do not need robust applications! • Collaboration • Only supported in the form of copying/cloning of existing solutions • Collaboration is necessary for perpetual beta development process remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 5 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  6. 6. Agenda 1 Principles of Situational Applications & State-of-the-Art Specification and Realization of 2 Blueprints for Situational Applications 3 Conclusion & Future Work remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 6 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  7. 7. Specification of Blueprints for SAs Basic Idea Unit A Unit B Unit C Caption Interoperability relationship A1 B1 C1 1 1 1 aA1 aB 1 aC 1 Possible flow L L L aA1 aB 1 aC 1 instance v A2 B2 C2 Service 1 1 1 component aA 2 aB 2 aC 2 L L L aA 2 aB 2 aC 2 Unit Flow unit A3 B3 C3 containing service 1 1 1 aA 3 aB 3 aC 3 substitutes L L L aA 3 aB 3 aC 3 Blueprints are a compact representation of multiple instances of replaceable SAs • Nodes represent service components • Edges denote interoperability constraints (i.e. data formats, capability mismatch) • Each flow unit consists of service alternatives/substitutes • Each feasible flow from source to sink represents an instantiation of a SA • The representation allows for easy extensions without changing concrete flows remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 7 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  8. 8. Specification of Blueprints for SAs Example (1) • Wendy wants to blog links about horseback riding in Newsfeed Tagging Translation Iceland in German language Google Google Tagthe.net • Link list should be updated automatically as new articles Language Search are published on the Web • She wants to create a SA consisting of the following steps: Yahoo! 1. Search the Web for the terms “horseback riding” Yahoo! Yahoo! Term Babel Fish Search Extraction and “Iceland” 2. Automatically extract suitable tags from received articles Microsoft Zingo 3. Translate received tags into German Live Search Tag FInder remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 8 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  9. 9. Specification of Blueprints for SAs Example (2) • Wendy browses for existing blueprints fulfilling the required task • If she finds a similar blueprint she extends it with her knowledge about the domain • If she finds blueprints that exposes only parts of the required functionality she copies it and extends it with the missing parts and her domain knowledge • If she does not find an adequate blueprint she starts one from scratch • Wendy found a similar service as many community members use the same mashup • She adds Tagthe.net as a new service • She adds a (public) policy that states that Yahoo! Babel Fish is not capable of the Swedish language • She adds a (private) preference policy that states that she prefers translation services that are capable of the German language • The final blueprint is exposed as a RESTful service for seamless integration into her blog remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 9 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  10. 10. Specification of Blueprints for SAs Architecture remash! Server remash! Community Service KAON2 remash! Client Ontology Reasoner reasonConcreteFlow Domain Policy Ontology Rules Project Blueprint Zero Repository • Domain Ontology and Policy Rules are stored in a central repository • Users can add and manipulate blueprints, services and policies facilitating the KAON2 reasoner to access the blueprint repository • Blueprints are executed using a wrapper process based on the Project Zero Assembly Flow Language • The wrapper process is filled with concrete services retrieved from the reasoner remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 10 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  11. 11. Specification of Blueprints for SAs Ontology Framework (Service Ontology) Service Ontology Service Configuration substantiates Function defines hasStructure evaluatedBy PointBasedFunction AttributeValuePair Structure constitutedBy hasAttributeValue hasAttribute consistsOf weight Point relatesTo valuation policyValue ServiceComponent Attribute AttributeValue xsd:float xsd:float [Lamparter et al. 2007] • Static specification of a common conceptualization of the service concept • Services are substantiated by a Configuration that consists of multiple AttributeValuePairs • Services have a Structure that consistsOf multiple ServiceComponents • AttributeValuePairs are evalutedBy a Function assigning a valuation to an AttributeValue remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 11 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  12. 12. Specification of Blueprints for SAs Policy Based Ranking 1.0 Attribute: Language Attribute Value: ENG/GER Degree: 1.0 0.5 Weight: 0.7 ENG/FRA ENG/ESP ENG/GER 1.0 Attribute: ErrorRate Attribute Value: medium Degree: 0.3 0.5 Weight: 0.3 low medium high Overall Degree = 0.7 x 1.0 + 0.3 x 0.3 = 0.79 remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  13. 13. Service Ontology Policy Based Ranking Attribute/Value Inference ServiceComponent AttributeValue Attribute StructureAV* TranslationErrorRateAV LanguageAV StructureAttr LanguageAttr ValidStructure High InvalidStructure Medium Low EngGer EngGerSwe TranslationErrorRateAttr isConnectedTo English WebService GoogleLanguage -ajax.googleapis.com/... Translation German Language YahooBabelFish -babelfish.yahoo.com/... Swedish GoogleSearch -ajax.googleapis.com/... Newsfeed MicrosoftLiveSearch SOAP -search.live.com/... YahooSearch Ajax Structure Validation APIType -search.yahooapis.com/... REST Tagthe.net -tagthe.net/api/... Tagging YahooTermExtraction JSON -search.yahooapis.com/... DataFormat XML ZingoTagFinder -zingosoft.com/tagger/... Domain Ontology remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  14. 14. Specification of Blueprints for SAs Bite: Project Zero Assembly Flow Language Assembly Flow Language Example orderRcv <process name=quot;orderProcessquot;> <receiveGET name=quot;orderRcvquot;/> <POST name=quot;authorizequot; target=quot;${someURI}quot;> authorize <input value=quot;${orderRcv}quot;/> </POST> <sendMail name=quot;sendToMgrquot; address=quot;${someMail}quot;> <input value=quot;${authorize}quot;/> </sendMail> <replyGET name=quot;replyquot;> reply sendToMgr <input value=quot;${authorize}quot;/> </replyGET> </process> Why Assembly Flow Language? • Supports asynchronous messages, conditional branching, activity extensions and error handling • Simplifies the task of creating applications using the Representational State Transfer (REST) architectural style • Is part of IBM’s Websphere sMash Suite for easy integration in business related applications remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 14 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  15. 15. Specification of Blueprints for SAs Flexible Binding Using the Assembly Flow Language <process name=quot;exampleBlueprintquot; expressionLanguage=quot;Groovyquot;> <empty name=quot;transitionSynchronisationquot;/> <receiveGET name=quot;initialFlowDataquot;/> <while name=quot;whilequot; condition=quot;i &lt; numberOfUnitsquot;> <assign name=quot;assignInitialFlowDataquot;> <copy from=quot;initialFlowDataquot; to=quot;flowDataquot; /> ... </assign> <POST name=quot;${concreteFlow.unit[i].itemName}quot; outputVariable=quot;flowOutputquot;> <GET name=quot;concreteFlowquot; ... target=quot;http://example.com/reasonConcreteFlow/ <control source=quot;transitionSynchronisationquot;/> exampleBlueprint/quot;> <input value=quot;dquot;/> </GET> </POST> ... <variable name=quot;initialUnitquot; <assign name=quot;updateFlowDataquot;> value=quot;${concreteFlow.initialUnit}quot;/> <copy from=quot;flowOutputquot; to=quot;flowDataquot; /> <variable name=quot;numberOfUnitsquot; </assign> value=quot;${concreteFlow.numberOfUnits}quot;/> <empty name=quot;transitionSynchronisationquot;> <assign name=quot;assignInitialIquot;> <control <copy from=quot;initialUnitquot; to=quot;iquot; /> source=quot;${concreteFlow.service[i].itemName}quot;/> </assign> </empty> <assign name=quot;increaseIquot;> <copy from=quot;${i+1}quot; to=quot;iquot; /> </assign> Reasoner retrieves necessary flow </while> information through RESTful interface <replyGET name=quot;replyquot;> <input value=quot;flowDataquot;/> </replyGET> </process> Flexible binding of chosen service from each unit within the blueprint remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 15 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  16. 16. Specification of Blueprints for SAs remash! Client Application [http://remash.benjaminblau.de/] Open Issues • Only pre-designed domain ontology can be used (adding of new services and policies) • Connection to external ontology repository • Connection to Project Zero execution engine remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 16 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  17. 17. Specification of Blueprints for SAs Performance Evaluation Query execution time (in ms) depending on number of instances and number of rule literals (with uniformly distributed satisfiability) Solution to reduce time complexity cp. Lamparter et al. 2007 (CPLEX solver built-in for KAON2) remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 17 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  18. 18. Agenda 1 Principles of Situational Applications & State-of-the-Art Specification and Realization of 2 Blueprints for Situational Applications 3 Conclusion & Future Work remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 18 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009
  19. 19. Conclusion & Future Work Contribution • Specification of blueprints solving general shortcomings of existing SA approaches • System architecture and realization using the assembly flow language • Performance evaluation Future work • Connection to Project Zero execution engine • Integration with the NEON toolkit • Synergies with similar GMF/KAON2 tools • Re-development of remash! as a Web-based AJAX client application • Usability and GUI improvements • Concept for adding useful visualization elements for flow outcomes (not only maps…) remash! – Blueprints for RESTful Situational Applications | MEM 2009 | Steffen Haak 19 Research Center for Information Technology (FZI) | www.fzi.de | 14 May 2009

×