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

1. Modeling the Dynamics of Web-based Service and Resource-Oriented Digital Ecosystems • Keep it Simple and Scalable !!! 2nd June 2009 DEST 2009, Istanbul, Turkey

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

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 complex 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, why 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 organizations • 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 combines 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, forming 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 fragments 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 AJAX (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 • 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 • 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

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

28. Semantics • Ontology vs Lightweight Annotation • OWL vs RDF • Linked Data • Semantic Links • Keep it Simple and Scalable Stupid !!!

29. Service Space

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

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

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)

33. The evolutionary CUBE • Three steering principles • Simplification • Loose-coupling • Decentralisation

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

35. Service mashup with Yahoo Pipes Our current work: Web-Aligned WS-Discovery Cluster@debii Aligning with the Web

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

37. Thank you!http://debii.curtin.edu.au