Modeling the Dynamics of Web-based Service and Resource-Oriented Digital Ecosystems

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

……..

8

Service Retrieval Conceptual Model

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)

16

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

Service Space

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

Thank you!

http://debii.curtin.edu.au