modeling the dynamics of web-based service and resource-oriented digital ecosystems 2nd june 2009...
Post on 19-Dec-2015
214 views
TRANSCRIPT
Modeling the Dynamics of Web-based Service and Resource-Oriented Digital Ecosystems
2nd June 2009
DEST 2009, Istanbul, Turkey
Keep it Simple and Scalable !!!
2
Agenda
Introduction – Agent, Services, Resource-Oriented DES
Web-based Service/Resource-Oriented DES Amazon.com Facebook.com
Abstract Structure of a DES
Issues in Web-based SO-DES and RO-DES Discovery Interaction Composition Mashups
BPEL-based Service Composition
Mashups
A Hybrid Approach
Semantics
Conclusions
3
Introduction
Basic Elements of a Digital Ecosystem Agent Service Resource
Agent Represents the early wave of Digital Ecosystems But, where are all those Intelligent Agents?
Services!
Service self-contained, ready-to-use, modular clearly specified standardized interface unique functions by receiving and sending messages at a certain network endpoint.
Resource A universal identifier Reasonable representations Owner
4
Web-based Service/Resource-Oriented DES
Amazon.com A very sophisticated e-commerce platform Key enabler: AWS (Amazon Web Services) Resource-Oriented View
- Exposed information models- User profiles/reviews- Allows the definition of workflows
Service-Oriented View - Flexible processes- Loosely-coupled: no restrictions on internal architectures- Participants can choose protocols
5
Web-based Service/Resource-Oriented DES
Facebook A extremely popular social networking platform
Connect with friends- Join groups of common interest- Send messages- Organize events, etc.
Key enabler: Facebook API Supports two-way integration
- Pushing information to Facebook from your Web space- Pulling information from Facebook to your Web space
An example - the Faceconnector Mashup- integrates Facebook profile information with Salesforce data in real
time- Allow managers to build instant customer relationships
6
Abstract Structure of a DES
Core Keystone players who provide the infrastructure
Extensions Allow other players to extend the scope, function of the
infrastructure
Value Collectively generated by many different small and medium
players
7
Issues with Web-based SO-DES and RO-DES
S/R Discovery Key for reusability, and paves the way for other issues Big WS – Discovery
- WSDL-centered vs. Ontology-centered Web 2.0 S/R Discovery
- Google and ProgrammableWeb.com
Text
Web Service Discovery
WSDL-centred Ontology-centred
WSDL-S
OWL-S Structure Semantics
Keyword Tree matching WordNet Concept lattice Text mining
Graph matching Signature
String comparison VSM IR model
……. …… …….
WSMO
……..
9
Issues with Web-based SO-DES and RO-DES
S/R Interaction SOAP-based REST-based
SOAP was originally aimed at “transport-independent” Therefore, SOAP is self-descriptive, self-contained, semantic-rich Good thing is it can be transported on top of many protocols such
as SMTP, JMS, TCP, other than HTTP However, this also brings some drawbacks:
- leaves the chance for “re-invent the wheel!”- Under-(or even counter-) optimised for the Web
HTTP0.9 – HTTP1.1 has solved a lot of distributed computing problems on the Web!
- Scalability, Loose-coupling- Cacheability, Reliability- Security
10
Issues with Web-based SO-DES and RO-DES
RESTful Web Services (Fielding 2000) REpresentational State Transfer Architectural Constraints
- Explicit resource identifier – URI (caching enabled)- Uniform and consistent HTTP interface (similar to UNIX pipe)- Stateless @ server, hence State needs to be transferred
Putting the “Web” into Web services (Vinoski 2002) Refresh RPC-based Web services
Response from W3C (WSA, 2004) acknowledged two classes of Web services
- REST-compliant Web services- arbitrary Web services
RESTful Web services vs. arbitrary Web services Resource-Oriented vs. Activity-Oriented (Snell 2004) REST vs. RPC CRUD interface vs. custom-defined interface HTTP is an application protocol vs. HTTP is an transport protocol HTTP is semantic rich for app. vs. HTTP is not adequate for app.
Keep it Simple and Scalable !!!
11
Issues with Web-based SO-DES and RO-DES
S/R Composition Holly-grail of SOA Essential tasks
- Service selection- Composite services- Service coordination
Validation and Verification
S/R Mashups A Web-based composition approach Lightweight, rapid Popular within the Web developers community Client-side scripting
Keep it Simple and Scalable !!!
12
BPEL-based Service Composition
Validation and Verification Issues in both Orchestration model and Choreography models
- Performance- Reliability- Fault-tolerance
Our previous work [18] - Colored Petri Net (CPN)- Representation of the multi-level behavioral abstraction- Place/transition refinement- Tokens, Predicates, and Guards to control transitioning- Avoid cluttering the representation, reduce dimensionality, express c
omplex predicates Three layers
- Individual component layer- Semantic Web services layer- System level
13
BPEL-based Service Composition
Issues Too difficult to use
- “looks like a huge Java source file with verbose XML representation”
- Simplified BPEL variants thus emerge like SimBPEL, BPEL4J, BPEL4Java, BPEL4*, etc. So why bother?
No tools that deal with high-level modeling- It is indeed “Drag and Drop”- But it, for example, drags <invoke>, then drops <switch>, so again, w
hy bother? No validation and verification Does not really support abstract processes
- If only used for executable processes within an organization, again, why bother?
Does not support services other than WSDL-based- Cannot natively integrate Microformats, Atom, JSON, RDF, etc.
14
BPEL-based Service Composition
Basics De facto standard for composing Web services Heavily WS-oriented: a BPEL process per se is also a Web service Aims to tackle complex business requirements across organizatio
ns Promises to support both
- executable processes (within one organization)- abstract processes (message exchange protocol)
15
Mashup-based Service Composition
Nature A (or part of a) webpage or a Web application that seamlessly co
mbines content from more than one source into an integrated user experience.
Represents a new Web development approach that allows users to 'remix' various Web services
Perhaps even a user-centered software development approach The prosperity of Mashups will in turn inspire service providers, f
orming a good cycle of a “Mashup ecosystem” Mashups Values ProgrammableWeb as of 21 May 2009:
- 1318 Services (extension)- 3981 Mashups (value)
17
Mashup-based Service Composition
Formal Specification – Computational Exchange a Web computing formalism shift
- Content exchange Computational exchange [4]- Code Mobility- Continuation
Code Mobility capability to dynamically change the bindings between code fra
gments and the location where they are executed Widely used: mobile agent, Java applet, etc. Mobility + openness (e.g. no binary code) is the key that allows AJ
AX (Mashup) to win over applet Reduced latency, more interactive, flexible, open
18
“Continuation”
A transient and abstract representation of the control state of a computation to be resumed right after the point where it was suspended
represents “the rest of the computation”
Ideal to deal with web-based page-centric software development a web application is no longer just different pages, but browser-server interaction becomes a single application program continuations deal with pieces of execution
Mashup continuation: including cross multiple servers interactions into a single application program
Continuation can be suspended/resumed at: Server-side server-side Mashups Client-side client-side Mashups
19
Five types of Mashup [8]
Presentation Mashup the simplest form of Mashup the underlying data and functionality do not really become integrated e.g.
Amazon Widgets, some Google Gadgets
Client-Side Data Mashup retrieves information from APIs, services, feeds, and Web pages and remix
it with data from another source within the browser Security issue is an limitation (e.g. cross-domain access)
Client-side Software Mashup manipulate both contextual data and processes are downloaded to the
browser, create new functionality on the fly
Server-Side Software Mashup Everything occurs at server side, less operational problems but may have
performance issues Yahoo Pipes, and many Mashups listed on the ProgrammableWeb
Server-Side Data Mashup Database integration, traditional EAI data solutions
20
Issues with Web-based Mashups
Lack of semantics, shared vocabulary Require intensive “hard coding” Customization means almost re-programming
No formal frameworks to support Enterprise Computing Creation, Versioning (DLL HELL still applies) Deployment QoS, Monitoring Governance
Does not address fundamental issues in Distributed Computing Environment (DCE) Concurrency Scalability fault tolerance
21
This leads to Enterprise Mashup
Enterprise Mashup Supports semantic-rich
data and information In-depth transformation
on format and relationships
Connects back to ERP, CRM, HR, etc. systems
Business plan driven QoS (reliability,
dependability, failover, fault-tolerance, etc.)
Policy-based security
Web Mashup Does not support
semantics unless hard-coding by developers
Supports shallow data and information transformation
Connects to various data sources exposed as resources or API
Community driven No QoS (good luck) Simple web-based
security
22
Mashup vs. Service Composition in SOA
The matrix table opportunistic
Opportunistic vs. Systematic
Situational vs. Well-planned
No typing vs. Strong Typing
What works vs. What is true
Low entry barrier vs. High entry barrier
Presentation and GUI
Applications
Opportunistic /Situational
Systematic / Well-planned
Presentation Mashups
Data Mashups
Software Mashups
Data
Enterprise Applications
EAI: data integration
Service composition
WS Service
Composition
23
Extreme workflow - Mashups
Extreme programming An agile software development methodology Coding Testing Listening Designing
Extreme workflow An agile workflow development methodology –
Mashups What are the steps in Mashup here?
24
Which one shall we use? – It really depends….
Things that Mashup perhaps can do better: Numerous and diverse sources of information
integration Real-time fast integration Model mapping and information quality augmentation
is relatively easy Need an integrated user view to support many
applications and business scenarios Need data search facility
Keep it Simple and Scalable !!!
25
A Hybrid Approach
Direct merge is nearly impossible Two paradigms with contrasting engineering principles
Both have strengths and weaknesses
It appears to us that For static, stable, (internal) business processes BPEL
- QoS, Security, - Validation, Fault-tolerance- Mission-Critical
For community-driven, multi-party, transient workflows Mashups
- need to access heterogeneous data- need to update on a frequent basis- user interaction plays an important role
26
A Hybrid Approach
A two-step methodology for Stable Workflows Step One
- Build situational and opportunistic Mashup Prototype- Trail-n-Error experiments
Step Two- Transitioning from Mashup to service composition
specification (Orchestration or Choreography)- Semi-automatic annotation (semantic-rich description)
Iteratively repeat Step one and Step two until it converges into a stable workflow
27
A Hybrid Approach
Opportunistic Mashup
Opportunistic Mashup
Emerged Mashup
Client-Side Data Mashup
Client-Side Software Mashup
Server-Side Software Mashup
Coalition
Fitted Mashup
Incubation
Stable Workflow
Maturation
Demand
Analysis
Continuation Review
Continuation Review
Release Review
1. API/Mashup Dependency 2. API/Tag Graph 3. API/Tag Classification 4. Retrieval (Search, Rank, Select) 5. Knowledge Extraction & Acquisition 6. Data Stream Pattern 7. Regression Analysis for API/Mashup Features 1. Process Augmentation 2. Semantic Annotation 3. Ontology Engineering 4. Interoperability Test 5. Reliability Test 6. Security Test 7. Goal Composition 1. Process Validation 2. Theorem Prove 3. Formalism 4. ……
Goal
Situation A
Situation B
Situation C
DES Open Community Generalise
28
Semantics
• Ontology vs Lightweight Annotation
• OWL vs RDF
• Linked Data
• Semantic Links
Keep it Simple and Scalable Stupid !!!
ASWEC 08 - 30
Semantic Space/OWL-S WSDL-S
WSDL based Internal Exploitation (e.g. text mining) External References (e.g. WordNet, Domain ontology, etc.)
OWL-S based Service profile Service model Service grounding
WSMO based Ontology Goal Mediator
WSDL-S based Annotation Extension to standard WSDL
ASWEC 08 - 31
Web-Oriented Style – Triple Space
Basic techniques Tuple Space (Gelernter, 1985)
- for Storage Publish/Subscribe model (Eugster et al., 2003)
- for Interaction RDF (Klyne and Carroll, 2004)
- for Service matching
Natural Confluence of Asynchronous Broker + RESTful Web services
ASWEC 08 - 32
Web-Oriented Style – Triple Space
Motivation The ‘Read and Write’ Web is a huge success Writers publish to the Web site, from where readers read Readers do not need to know Writers, and vice versa “Web services do not have much in common with the Web”
(Krummenacher et al., 2005)
ASWEC 08 - 33
The evolutionary CUBE
Three steering principles Simplification Loose-coupling Decentralisation
ASWEC 08 - 34
Our current work: Web-Aligned WS-Discovery
1. Write via HTTP
2. Publish via HTTP Blog/Atom publish protocol
3. Read/Notify via HTTP
4. Subscribe via RSS/Atom format specification
ASWEC 08 - 35
Our current work: Web-Aligned WS-Discovery
Aligning with the Web
Service mashup with Yahoo Pipes
ASWEC 08 - 36
Conclusion
We envision a full-fledged digital ecosystem A mixture of
- Service-Oriented- Resource-Oriented- Agent-Oriented
Issues of modeling the dynamics of them arise
we propose a hybrid approach that integrates both BPEL-based and Mashup-based methods to tackle the issues for Web-based digital ecosystems
Explore a web oriented service approach.
Guiding principle –Keep it simple and scalable!!!