1 / 31

A Dynamic Orchestration Model for Future Internet Applications

A Dynamic Orchestration Model for Future Internet Applications. Mike Boniface (mjb@it-innovation.soton.ac.uk) Giuseppe Avellino, Barbara Cantalupo (ElsagDatamat) Justin Ferris, Nikolaos Matskanis, Bill Mitchell, Mike Surridge (IT Innovation) ServiceWave 2008 10-13 Dec 2008. Contents.

barrington-kellan
Download Presentation

A Dynamic Orchestration Model for Future Internet Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Dynamic Orchestration Model for Future Internet Applications Mike Boniface (mjb@it-innovation.soton.ac.uk) Giuseppe Avellino, Barbara Cantalupo (ElsagDatamat) Justin Ferris, Nikolaos Matskanis, Bill Mitchell, Mike Surridge (IT Innovation) ServiceWave 2008 10-13 Dec 2008

  2. Contents • Motivation and need for adaptability • Architectural experimentation in NextGRID • Virtualised Infrastructure Model • Future Outlook

  3. Future Services Environment Dependable .................Uncertainty Trade Offs Conflict and Tension Trade Offs secure reliable available trustworthy commercial viable open world transient distributed ownership distributed control massive scale risky multidisciplinary complex Orchestration is a key component for resolving tussles

  4. Adaptability and Choice • Adaptability implies the need for choice and decision making • Decision making is the concern of different independent stakeholders • supporting perspectives critical • Orchestration models that adapt workflows dynamically are essential • binding of services to meet abstract goals • injection of business processes and policies at runtime • interoperability between heterogeneous infrastructures

  5. How can the requirements be satisfied? How much does each requirement cost? Example Discover services able to satisfy goal SLA for use of Computational Hardware SLA for use of Computational Hardware SLA for use of Computational Hardware SLA for use of Computational Hardware Determine requirements of candidate services Alternatives License tokens For simulation software License tokens For simulation software License tokens For simulation software License tokens For simulation software Service: Computational Airflow Simulation Service Goal: Aerodynamic Profile of Car Design Car design in CAD format Car design in CAD format Car design in CAD format New potential goals: each needs to be evaluated to determine overall cost of service Physical mock-up of Car design Service: Wind Tunnel Evaluation Questions: How can the service(s) be made executable? How much does each service cost? SLA for rental of wind tunnel

  6. NextGRID Experimentation • Applicationneeds • Existing BusinessModels • Existing standards • Expertise • Experience withGrid in production Conceptualisation Analysis Design • Architecture • Grid Business Models • Reference Implementations • Applications • Standards Feedback for next iteration Implementation Evaluation

  7. User SLA? SLA SLA SLA serviceprovider SLA Business layer Technology layer service NextGRID Service Configuration Policy Event SLA Event Monitoring Policy SLA SLA SLA SLA Federation

  8. Registry Get token assertions Register / Update / Query Register / Update Query Functional Orchestration Naming and Addressing Invoke Resolve Generate / Verify Get tokens Get token assertions Monitor/ Control Negotiate SLA Get token assertions SLA Management Trust and Security Get token assertions Administer policy Schemas Architecture

  9. Application User Application Developer Service Provider Procurement Manager Budget Holder Service Manager Workflow Life Cycle: Use Cases Editing Procurement Business Workflow Editing Application Workflow Define Application Editing Provision Business Workflow Execute Application <<include>> <<include>> Execute Procurement Process Execute Provision Process Deploy Service with Workflows

  10. Authoring Enactment Publication Application User Application Developer Service Provider Procurement Manager Budget Holder Service Manager Workflow Life Cycle: Phases Editing Procurement Business Workflow Editing Application Workflow Define Application Editing Provision Business Workflow Execute Application <<include>> <<include>> Execute Procurement Process Execute Provision Process Deploy Service with Workflows

  11. ISV Provider Consumer Application User Application Developer Service Provider Procurement Manager Budget Holder Service Manager Workflow Life Cycle: Organisations Editing Procurement Business Workflow Editing Application Workflow Define Application Editing Provision Business Workflow Execute Application <<include>> <<include>> Execute Procurement Process Execute Provision Process Deploy Service with Workflows

  12. Our Challenge • To define an architecture to handle all these use cases: • taking account of temporal aspects • taking account of organisational aspects • enabling “business” as well as applications • Requires a model of workflow • distributed (multi-actor) authoring • distributed (multi-actor) participation • Not just a ‘programming environment’

  13. Programming Environment Application User Application Developer Service Provider Procurement Manager Budget Holder Service Manager Workflow Life Cycle: Use Cases Editing Procurement Business Workflow Editing Provision Business Workflow\ Define Application Editing Application Workflow Execute Application <<include>> <<include>> Execute Procurement Process Execute Provision Process Deploy Service with Workflows

  14. Eval Apply Virtual Infrastructure Model • Supports independent actors • application developer • service provider • consumer organisation • application user • VIM for workflow • run-time process assembly • built into enactment model Workflows and Bindings Registries Bus/Security Services Business Process Discovery Tokens, SLA QoS estimates Scheduling priorities Evaluation decisions Application Process Decision Services Application Services Data

  15. Workflow Representation

  16. Application Workflow • Simple applications • image processing operations • deployed as services • Three step workflow • image transformations • different computational loads • No business steps • they are added at run-time by the VIM

  17. Evaluation Priority Order Execution Order Enactment Prioritisation

  18. Evaluation Process

  19. Evaluation Process Discover and select concrete implementation

  20. Evaluation Process Discover and select partially concrete implementation

  21. Evaluation Process Discover and select partially concrete implementation

  22. Evaluation Process Discover and select concrete implementations

  23. Input binding Business processes Application workflow Execution Process

  24. Enactor Implementation STS Services Registry Service Broker/QoS Services

  25. Architectural Lessons • VIM model itself is highly effective • independent authoring of business and application workflows • participation by multiple business actors in combined workflows • run-time behaviour can adapt to different business models • Implies a unified data and process model • data sets (including accounts) are service references • all can be expressed as abstract processes and as workflows

  26. Architectural Lessons • OWL-S/RDF global namespaces are bad • clashes occur when combining fragments from different authors • need a way to “scope” names • OWL-S/RDF is not good at dynamics • knowledge bases are relatively static • our relationships change quickly over time • e.g. dynamic binding of abstract processes • e.g. dynamic exception handling • Implications for “Semantic Web Services” being investigated

  27. Current Research Issues • How much to evaluate before executing? • Strategies can be from: • fully eager (complete evaluation); to • fully lazy (apply after each evaluation step) • How to reduce complexity of search tree? • Cut the search space down • e.g. use approved suppliers first • What other standard languages are more appropriate than OWL-S? • e.g. WSMO + BPEL

  28. Conceptual Architecture • Contribution to NEXOF-RA community process • part of the current conceptual architecture • Foundation for Resource Infrastructure scenario

  29. Regulators Competitors Suppliers Customers Investors stakeholder lifecycles system lifecycle Sales and Marketing Operations Finance Legal Quality/Audit Adaptive Service Based Assets system knowledge stakeholder knowledge Stakeholder Lifecycles Abstraction and Specialisation Non Functional Adaptability and Monitoring System Lifecycle Orchestration

  30. Conclusion • We have presented a dynamic orchestration model for dynamic inter-enterprise services • Architecture addresses key concerns for the future internet • runtime binding to services • secure and accountable dynamic procurement • infrastructure adaption • separation of stakeholder concerns • Approach and architecture model shows promising results • Current implementation being refined through further experimentation

  31. A Dynamic Orchestration Model for Future Internet Applications Mike Boniface (mjb@it-innovation.soton.ac.uk) Giuseppe Avellino2, Mike Boniface1, Barbara Cantalupo2, Justin Ferris1, Nikolaos Matskanis1, Bill Mitchell1, Mike Surridge1, ServiceWave 2008 10-13 Dec 2008

More Related