A Dynamic Orchestration Model for Future Internet Applications

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