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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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