remash! - Blueprints for RESTfulSituational Applications

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)

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

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



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



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



Agenda


2




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



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



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



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



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



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


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


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


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



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)



Agenda


2




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 RESTfulSituational Applications

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (7)

Similar a remash! - Blueprints for RESTfulSituational Applications

Similar a remash! - Blueprints for RESTfulSituational Applications (20)

Último

Último (20)

remash! - Blueprints for RESTfulSituational Applications