Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CHOReVOLUTION at GSSI April-2017

83 views

Published on

Automatic Synthesis of Adaptable and Evolving Choreography-based Service-oriented Systems. This lecture was given at GSSI Center for Advanced Studies, April 11-12, 2017 in L'Aquila, by Marco Autili, Assistant Professor, Department of Information Engineering Computer Science and Mathematics, University of L'Aquila, in collaboration with Massimo Tivoli, Associate Professor, DISIM, University of L'Aquila.

Published in: Software
  • Be the first to comment

  • Be the first to like this

CHOReVOLUTION at GSSI April-2017

  1. 1. Tools for Software Architecture Seminar Lectures GSSI - Center for Advanced Studies 11-12 Apr. 2017 – L’AQUILA (IT) Marco Autili University of L’Aquila in collaboration with Massimo Tivoli Automatic Synthesis of Adaptable and Evolving Choreography-based Service-oriented Systems
  2. 2. Where do we come from? Automated Synthesis of Dynamic and Secured Choreographies for the Future Internet (H2020 project) (FP7 project) (H2020 project) 13/04/17 Marco Autili - Seminar Lectures @GSSI 2
  3. 3. CHOReVOLUTION • Title: Automated Synthesis of Dynamic and Secured Choreographies for the Future Internet • Follow up FP7 EU project CHOReOS • Period: January 2015 - January 2018 • Site: http://www.chorevolution.eu 13/04/17 Marco Autili - Seminar Lectures @GSSI 3
  4. 4. Outline • (must have) Advanced Software Engineering ingredients (a quick introduction) • Setting the context • Development scenario (high-level view) • Synthesis process • CHOReVOLUTION Platform • CHOReVOLUTION Studio Demo 13/04/17 Marco Autili - Seminar Lectures @GSSI 4
  5. 5. Outline • (must have) Advanced Software Engineering ingredients (a quick summary) • Setting the context • Development scenario (high-level view) • Synthesis process • CHOReVOLUTION Platform • CHOReVOLUTION Studio Demo 13/04/17 Marco Autili - Seminar Lectures @GSSI 5
  6. 6. Distributed systems • Virtually all large computer-based systems are now distributed systems • “… a collection of independent computers that appears to the user as a single coherent system” • Information processing is distributed over several computers rather than confined to a single machine • Distributed Software Engineering is therefore very important for enterprise computing systems 13/04/17 Marco Autili - Seminar Lectures @GSSI 6
  7. 7. Distributed system characteristics • Resource sharing • Sharing of hardware and software resources • Openness • Use of equipment and software from different vendors • Concurrency • Concurrent processing to enhance performance • Scalability • Increased throughput by adding new resources • Fault tolerance • The ability to continue in operation after a fault has occurred 13/04/17 Marco Autili - Seminar Lectures @GSSI 7
  8. 8. Distributed systems issues • Distributed systems are more complex than systems that run on a single processor • Complexity arises because different parts of the system are independently managed as is the network • There might be no single authority in charge of the system so top-down control is impossible 13/04/17 Marco Autili - Seminar Lectures @GSSI 8
  9. 9. RPC communication 13/04/17 Marco Autili - Seminar Lectures @GSSI 9
  10. 10. Message passing • Message-based interaction normally involves one component creating a message that details the services required from another component • Through the system middleware, this is sent to the receiving component • The receiver parses the message, carries out the computations and (if needed) creates a response message for the sending component with the required results • In a message-based approach, it is not always necessary for the sender and receiver of the message to be aware of each other. They simply communicate with the middleware 13/04/17 Marco Autili - Seminar Lectures @GSSI 10
  11. 11. Ports and sockets 13/04/17 Marco Autili - Seminar Lectures @GSSI 11
  12. 12. Synchronous messaging 13/04/17 Marco Autili - Seminar Lectures @GSSI 12
  13. 13. The evolution of computing paradigms 13/04/17 Marco Autili - Seminar Lectures @GSSI 13 - Req.mts Change - Dynamisms - Evolution Components Services Abstraction Modularity for Reuse & ROI Monolithic Functions/ procedures Objects SOC - Static - Frozen - Frozen Req.mts Towards Service-oriented Computing (SOC)
  14. 14. Software reuse • Software Engineering has been more focused on original development but ... • it is now recognised that to achieve better software, more quickly and at lower cost, we need a design process that is based on systematic software reuse • Nowadays, in most engineering disciplines, systems are designed by composing existing “software” that have already been used/experimented in other systems 13/04/17 Marco Autili - Seminar Lectures @GSSI 14
  15. 15. Software reuse • There has been a major switch to reuse-based development over the past 10 years. • Indeed, over the past 20 years, many techniques have been developed to support software reuse • The move to reuse-based development has been in response to demands for • lower software production costs • lower maintenance cost • faster delivery of systems • increased software quality • More and more companies see their software as a valuable asset • Companies are promoting reuse to increase their return on software investments • One of the more recent trends is that standards, such as Web Service standards, have made it easier to develop general services and reuse them across a range of applications 13/04/17 Marco Autili - Seminar Lectures @GSSI 15
  16. 16. Reuse-based software engineering Software units that can be reused may be of radically different sizes System reuse • Complete systems, which may include several application programs may be reused. Application reuse • An application may be reused either by incorporating it without change into other or by developing application families. Service reuse • Standards, such as Web Service standards, have made it easier to develop general services and reuse them across a range of applications. Component reuse • Components of an application from sub-systems to single objects may be reused. Object and function reuse • Small-scale software components that implement a single well-defined object or function may be reused. This form of reuse, based around standard libraries, has been common for the past 40 years. 13/04/17 Marco Autili - Seminar Lectures @GSSI 16
  17. 17. Implementing software reuse 13/04/17 Marco Autili - Seminar Lectures @GSSI 17 Design patterns Architectural patterns Application frameworks Software product lines Application system integration ERP systems Systems of systems Configurable application systems Legacy system wrapping Component-based software engineering Model-driven engineering Service-oriented systems Aspect-oriented software engineering Program generators Program libraries
  18. 18. The Encyclopedia of SOA FACTS • SOA is being used in the developing world to solve hunger. Entire populations will be fed on future business value • SOA can write and compile itself • SOA is not complex. You are just dumb • SOA in a Nutshell is 7,351 pages spread over 10 volumes • One person successfully described SOA completely, and immediately died • Another person successfully described SOA completely, and was immediately outsourced • Larry Ellison once died in a terrible accident, but was quickly given SOA. He came back to life, built a multibillion dollar software company, and now flies fighter jets • SOA is the only thing Chuck Norris can't kill http://www.guj.com.br/t/soa-facts/6917 13/04/17 Marco Autili - Seminar Lectures @GSSI 18
  19. 19. Web services • A web service is an instance of a more general (higher level) notion of a service: • “An act or performance offered by one party to another. Although the process may be tied to a physical product, the performance is essentially intangible and does not normally result in ownership of any of the factors of production” • The essence of a service, therefore, is that the provision of the service is independent of the application using the service • Service providers can develop specialized services and offer these to a range of service users from different organizations 13/04/17 Marco Autili - Seminar Lectures @GSSI 19
  20. 20. Reusable services • In its simplest acceptation (only provider) • a service is a reusable component that is independent (no required interface) and is loosely coupled • In its more complex acceptation (prosumer), • a service can also have required interfaces, still being reusable, loosely coupled, and still keeping independence (e.g., using late binding to “attach” required interfaces) • Services are platform and implementation-language independent • A web service is: • A loosely coupled, reusable software component that encapsulates discrete functionality, which may be geographically distributed and programmatically accessed • It is a service that is accessed using standard Internet and XML-based protocols 13/04/17 Marco Autili - Seminar Lectures @GSSI 20
  21. 21. Service-oriented software engineering • Building applications based on services allows companies and other organizations to cooperate and make use of each other’s business functions • Service-based applications may be constructed by linking/composing services from various providers using: • either a standard programming language (e.g., JAVA) • or a specialized workflow language (e.g., WS-BPEL) 13/04/17 Marco Autili - Seminar Lectures @GSSI 21
  22. 22. Service-oriented architectures • A means of developing distributed systems where the components are stand-alone services • Services may execute on different (geographically distributed) computers from different service providers • Standard protocols have been developed to support service communication (e.g., SOAP) and information exchange (e.g., WSDL) • Services are platform and implementation-language independent 13/04/17 Marco Autili - Seminar Lectures @GSSI 22
  23. 23. Service-oriented Interaction Pattern Service registry Service requestor Service provider Service Find Publish Bind (SOAP) (WSDL) 13/04/17 Marco Autili - Seminar Lectures @GSSI 23
  24. 24. Service-oriented Interaction Pattern 13/04/17 Marco Autili - Seminar Lectures @GSSI 24
  25. 25. Benefits of SOA • Services can be provided locally or outsourced to external providers • Services are language-independent • Investment in legacy systems can be preserved • Inter-organisational computing is facilitated through simplified information exchange 13/04/17 Marco Autili - Seminar Lectures @GSSI 25
  26. 26. Key standards • XML Schema • A schema describes the structure of an XML document • SOAP • A message exchange standard that supports service communication • WSDL (Web Service Definition Language) • This standard allows a service interface and its bindings to be defined • WS-* • A variety of specifications associated with web services (e.g., WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security, and WS-Trust) • WS-Policy It is a specification that allows web services to use XML to advertise their policies (on security, quality of service, etc.) and for web service consumers to specify their policy requirements • WS-BPEL • A standard for workflow languages used to define service composition 13/04/17 Marco Autili - Seminar Lectures @GSSI 26
  27. 27. Key Web service standards Transport (HTTP, HTTPS, SMTP, ...) Messaging (SOAP) Service definition (UDDI, WSDL) Process (WS-BPEL) Support (WS-Security, WS-Addressing, ...) XML technologies (XML, XSD, XSLT, ....) 13/04/17 Marco Autili - Seminar Lectures @GSSI 27
  28. 28. The most important aspects of SOA 13/04/17 Marco Autili - Seminar Lectures @GSSI 28 Service Implementation and Service Provider Service Contractual Description HOW WHAT Do not worry about HOW … … only expect that it will STOP STOP STOP
  29. 29. Outline • (must have) Advanced Software Engineering ingredients (a quick introduction) • Setting the context • Development scenario (high-level view) • Synthesis process • CHOReVOLUTION Platform • CHOReVOLUTION Studio Demo 13/04/17 Marco Autili - Seminar Lectures @GSSI 29
  30. 30. Application context (cont’d) We are in the Future Internet (FI) era distributed computing environment large number of available software systems that can be composed to meet user needs * European Commission. Digital Agenda for Europe - Future Internet Research and Experimentation (FIRE) initiative, 201513/04/17 Marco Autili - Seminar Lectures @GSSI 30
  31. 31. dynamic evolution according to... ... changing user preferences ... changing environmental context ... new business needs Application context 13/04/17 Marco Autili - Seminar Lectures @GSSI 31
  32. 32. Growth of innovative and revolutionary everyday-life scenarios within smart cities 32 Smart Mobility ecosystems the future smart mobility ecosystem scenario different users different environments different stakeholders fully connected fully connected • Dynamism • Heterogeneity • New value added services e.g., route guidance, speed advisory, parking availability, POI suggestions13/04/17 Marco Autili - Seminar Lectures @GSSI
  33. 33. Composition approaches Orchestration (centralized) Choreography (fully distributed) Local centralized view from the perspective of one participant Global decentralized view from a multi-participant perspective (albeit without a central controller) 13/04/17 Marco Autili - Seminar Lectures @GSSI 33
  34. 34. Why choreographies? • Services will be increasingly active software entities • Communicating in a peer-to-peer style • Autonomously take decisions • Proactively engage in (business) tasks • Owned by different organizations • It is not possible (or desirable) to centralize responsibilities • Multi-participant specification perspective is more appropriate • Fully distributed deployment and execution of the composition code • No single point of information flow • No single point of failure 13/04/17 Marco Autili - Seminar Lectures @GSSI 34
  35. 35. The need for automated support Building applications by reusing existing (third-party) services (often black-box) Composing services in a distributed way Support for automation is needed (time-to-market, correctness by construction, etc.) Aiding software producers to realize, deploy, execute, and monitor choreography-based systems by reusing existing services 13/04/17 Marco Autili - Seminar Lectures @GSSI 35
  36. 36. Desirable Development Support • Automated tool support for, e.g., • making easier the creation of smart apps on top of existing things/services/systems • “easily” dealing with distributed workflow management • taking care of service/data binding and protocol adaptation • enforcing security policies • ... ... 13/04/17 Marco Autili - Seminar Lectures @GSSI 36
  37. 37. Outline • (must have) Advanced Software Engineering ingredients (a quick introduction) • Setting the context • Development scenario (high-level view) • Synthesis process • CHOReVOLUTION Platform • CHOReVOLUTION Studio Demo 13/04/17 Marco Autili - Seminar Lectures @GSSI 37
  38. 38. Development scenario (cont’d) Choreography modelers cooperate each other to set business goals, e.g., - assisting travelers from arrival, to staying, to departure 13/04/17 Marco Autili - Seminar Lectures @GSSI 38
  39. 39. Development scenario (cont’d) Reserve TaxiFind POI Reserve Table Check Flight … ... … ... … ... Identify tasks and participants required to achieve the goal, e.g., - reserving a taxi from the local taxi company, - purchasing digital tickets at the train station, - performing transactions through services based on near field communication in a shop 13/04/17 Marco Autili - Seminar Lectures @GSSI 39
  40. 40. Development scenario (cont’d) Reserve TaxiFind POI Reserve Table Check Flight … ... … ... … ... Specify how participants must collaborate as admissible workflows of the identified business tasks Model 13/04/17 Marco Autili - Seminar Lectures @GSSI 40
  41. 41. Development scenario (cont’d) Admissible workflows specified as: - BPMN2 Choreography Diagrams Model BPMN2 Specification - http://www.omg.org/spec/BPMN/2.0/13/04/17 Marco Autili - Seminar Lectures @GSSI 41
  42. 42. inventory contains services/things published by providers, e.g., - transportation companies - airport retailers Development scenario (cont’d) Model Inventory 13/04/17 Marco Autili - Seminar Lectures @GSSI 42
  43. 43. • Out of the specified business goal, and • the set of services available in the inventory ... ime Synthesis time 3 s r Software engineer End users CHOReOSynt Coordination delegates Enactment engine Service providers Model refi nement Model trans formation 2 Execution time 4 1 5 1 6 Running choreography Cloud middleware Publish Register Standard communication (I/O messages) Additional communication (coordination informa Registry Services and things 1 5 ime Synthesis time 3 s r Software engineer End users CHOReOSynt Coordination delegates Enactment engine Service providers Model refi nement Model trans formation 2 Execution time 4 1 5 1 6 Running choreography Cloud middleware Publish Register Standard communication (I/O messages) Additional communication (coordination information) Registry Services and things 1 5 erview of automatic choreography synthesis, using a scenario involving the coordination of business services, s, and stakeholders from air transportation, customer relationship management, and intelligent transportation. eb Services Description Language; BPEL stands for Business Process Execution Language. Synthesis Processor Step 1. Software producers cooperate with domain experts and business managers to • set the business goal (for exam- ple, assist travellers from arrival, to staying, to departure), • identify the tasks and partici- pants required to achieve the constructs and quality-of-service constraints. In particular, CHOReOS uses both the Q4BPMN notation— an extension to BPMN2—to specify nonfunctional properties and dedi- cated automated tools to assess the choreography specification’s quality. Step 2. MagicDraw exports the mod- Services Description Langu w3.org/TR/wsdl). To desc interaction behavior, BPE Process Execution Langu fies the flow of messages with the environment. T also contains the registrat interested in exploiting th raphy through their mobil Design time Synthesis time 3 Business manager Software engineer End users CHOReOSynt Coordination delegates Enactment engine Service providers Domain expert Choreography diagram Model refi nement Model trans formation 2 1 Execution time 4 1 5 1 6 Running choreo Cloud middlewar Publish Register Standard communication (I/O messages) Additional communication (coordination Registry Services and things 1 5 FIGURE 2. An overview of automatic choreography synthesis, using a scenario involving the coordination of business s thing-based services, and stakeholders from air transportation, customer relationship management, and intelligent transp WSDL stands for Web Services Description Language; BPEL stands for Business Process Execution Language. Choreography developer Synthesis Processor automatically produces (if possible) a choreography- based application achieving the specified goal Synthesis phaseModelling phase CHOReVOLUTION Cloud Infrastructure Model Inventory 13/04/17 Marco Autili - Seminar Lectures @GSSI 43
  44. 44. BPMN2 Choreography Diagrams Prosumer Services Third-party REST Services Third-party SOAP Services Authenticated transactions 13/04/17 Marco Autili - Seminar Lectures @GSSI 44
  45. 45. 45 SEADA: Choreography diagram Prosumer services • To integrate core business logic • SEADA-SEARP for route planing • SEADA-SEATSA for eco-evaluation • SEADA-TRAFFIC for traffic information preparation Third-party SOAP services • To provide route info • DTS-Google • DTS-Here Third-party REST services • To get real-time traffic info • DTS-WEATHER • DTS-ACCIDENT • DTS-CONGESTION • DTS-BRIDGE • Need binding components to deal with service heterogeneity 13/04/17 Marco Autili - Seminar Lectures @GSSI
  46. 46. A Use Case in the Smart Tourism Domain We started identifying available local and global services in the Smart Tourism Domain in our town (Genoa)... Then, we designed a choreography using the CHOReVOLUTION Studio The synthetised choreography has been deployed on a OpenStack cloud environment We built a simple android app to let tourists select POIs in the nearby and get best routes 13/04/17 Marco Autili - Seminar Lectures @GSSI 46
  47. 47. Main ingredients of our method Distributed Protocol Adaptation Layer Distributed Business Logic Layer Goal specification S1 S2 S4 S3 Existing services selected as good candidates to realize the required business logic Distributed Protocol Coordination Layer Goal specification S1 S2 S4 S3 Existing services selected as good candidates to realize the required business logic GAP interfaces exposed by concrete services VS abstract roles modeled by the choreography specification 13/04/17 Marco Autili - Seminar Lectures @GSSI 47
  48. 48. Choreography coordination Problem Automatic enforcement of choreography realizability • How to externally coordinate the interaction of existing services so to fulfill the global collaboration prescribed by the choreography specification? Assumption BPMN2 Choreography Diagrams • A choreography-based specification of the system to be realized Our solution Automated synthesis of Coordination Delegates (CDs) • Automatically produce the code of additional software entities that proxify and coordinate the services’ interaction so to guarantee the specified global collaboration Focus Automatically realizing a choreography by reusing and suitably coordinating third- party services 13/04/17 Marco Autili - Seminar Lectures @GSSI 48
  49. 49. The In-store Marketing and Sale Parallel flows - fork - join Alternative branches - inclusive - exclusive When dealing with third-party services, if left uncontrolled, their collaboration can exhibit undesired interactions a Client is allowed to perform the Add Product task in order to add products to the Smart Cart However, after the payment has been accomplished and before actually exiting the shop, a “malicious” client may attempt at adding further products, hence avoiding to pay for them Task in BPMN2 - atomic activity - two participant roles (one is initiating) - XML Schema used internally, e.g., for discovery purposes
  50. 50. CD2 CD4CD3 CD1 Task1 R1 ––m1à R2 Task2 R3 ––m2à R4 State machine based specification S4: R4S3: R3 S1: R1 S2: R2 May I? May I? Yes Yes YesNo No No R1 ––m1à R2 Yes No m1 m2 Standard Communication (I/O Messages) Additional Communication (Coordination Information) CDi Coordination Delegate (Service Proxy) Enforcing choreography realizability
  51. 51. CD2 CD4CD3 CD1 Enforcing choreography realizability S4: R4S3: R3 S1: R1 S2: R2 May I? May I? Yes Yes YesNo No No Yes No m1 m2 Standard Communication (I/O Messages) Additional Communication (Coordination Information) CDi Coordination Delegate (Service Proxy) 13/04/17 Marco Autili - Seminar Lectures @GSSI 51
  52. 52. Choreography adaptation Problem Enforcement of service-role bindings • How to externally adapt the interaction of existing services so to “match” the specification of the choreography roles to be played? Assumption LTS-based or BPEL+WSDL-based specification • A specification of the externally observable behavior of both services and roles in terms of types and sequences of message exchanges Our solution (Partially) automated synthesis of Adapters • Produce adapters that mediate the interaction Service ßà CD Focus Realizing correct service-role binding by solving interoperability issues 13/04/17 Marco Autili - Seminar Lectures @GSSI 52
  53. 53. CD2 CD4CD3 CD1 Enforcing service-role bindings S4: R4S3: R3 S1: R1 S2: R2 May I? May I? Yes Yes YesNo No No Yes No m1 m2 Standard Communication (I/O Messages) Additional Communication (Coordination Information) CDi Coordination Delegate (Service Proxy) A Adapter A Marco Autili - Seminar Lectures @GSSI 53 m1! m1.1! LTS-based specifications R1 S1 m1.2! m1 is an aggregate of m1.1 and m1.2
  54. 54. Adopted architectural style S1 S2 S3 CD1.2 A2A1 Standard Communication (e.g., request/response messages) Additional Communication (coordination information for coordination purposes) CD Protocol Coordination Layer (CDs) A Protocol Adaptation Layer (Adapters) S Business Logic Layer (Services) S4 CD1.3 CD2.3 A3CD2.1 CD3.1 CD4.1 A4 A5 13/04/17 Marco Autili - Seminar Lectures @GSSI 54
  55. 55. Focusing on adapters generation • We exploit Enterprise Integration Patterns (EIP) The generated adaptation logic is realized as a composition of Message Routing patterns that realize I/O data mappings Adapters are able to • map message data types • reorder/merge/split the sequence of operation calls and/or related I/O messages 13/04/17 Marco Autili - Seminar Lectures @GSSI 55
  56. 56. Considered EIP: Message Routing patterns 13/04/17 Marco Autili - Seminar Lectures @GSSI 56
  57. 57. Adapters at work Adapter1 CDClient_SmartCart addProduct (product,quantity) addProduct (product,quantity) Adapter2 addItem(item) setAmount(amount) SmartCart addProduct(product) setQuantity(quantity) setPromotionCode (promotioncode) Client Aggregator + Filter Splitter+ Resequencer 13/04/17 57
  58. 58. Choreography evolution Problem Choreography evolution • How to enable choreography evolution in response to goal and context changes? Assumption Specification of variation points in terms of Call Choreographies • Each variation point specifies behavioral alternatives in term of (set of) sub-choreographies Our solution Automated synthesis of autonomic CDs (aCDs) • Automatically produce the code of CDs that are now are external controllers realizing multiple interacting feedback loops Focus Enabling (a form of) choreography evolution to face well-confined goals and context changes 13/04/17 Marco Autili - Seminar Lectures @GSSI 58
  59. 59. Choreography evolution Variation point behavioral alternative 1 in context x behavioral alternative 2 in context y behavioral alternative 3 in context y and context z13/04/17 Marco Autili - Seminar Lectures @GSSI 59
  60. 60. Adopted architectural style S1 S2 S3 CD1.2 A2A1 Standard Communication (e.g., request/response messages) Additional Communication (coordination information for coordination purposes) CD Protocol Coordination Layer (CDs) A Protocol Adaptation Layer (Adapters) S Business Logic Layer (Services) S4 CD1.3 CD2.3 A3CD2.1 CD3.1 CD4.1 A4 A5 13/04/17 Marco Autili - Seminar Lectures @GSSI 60
  61. 61. Goal changes Choreography specification changes • Source: choreography modelers and service providers • Changes are restricted to the extent of the already specified variation points (quiescent state) • the modeler can however add/remove behavioral variations, or modify existing ones at run-time • Restricting to variations points is a reasonable choice since completely altering the specification may “distort” the business- level goal the choreography was originally specified for: • a complete alteration of the specification naturally requires to re- synthesize the choreography from scratch 13/04/17 Marco Autili - Seminar Lectures @GSSI 61
  62. 62. Context changes • Source: the dynamically “sensed” choreography context • At run time, context changes drive the activation/deactivation of variation points, provided that the specified context conditions are exclusive • Conditional expressions over “facts” that has to be evaluated at run time • On the practical side, each Call Choreography requires a suitable context evaluator: • A message context is described in terms of data contained in the messages exchanged among the involved services up to a given point in time. • An execution context is described by using information about possible computational resources. Thus, in order to “sense” an execution context, dedicated functionalities should be provided by the needed run-time support. • A domain/application context is characterized by conditions on the surrounding environment, given that dedicated functionalities (e.g., supported by dedicated sensors) are provided to sense it. 13/04/17 Marco Autili - Seminar Lectures @GSSI 62
  63. 63. Outline • (must have) Advanced Software Engineering ingredients (a quick introduction) • Setting the context • Development scenario (high-level view) • Synthesis process • CHOReVOLUTION Platform • CHOReVOLUTION Studio Demo 13/04/17 Marco Autili - Seminar Lectures @GSSI 63
  64. 64. Synthesis Process Choreography Specification Validation Choreography Projection Selection BC Generation SF Generation Adapter Generation BC Service/Thing Description Inventory Participant Model (BPMN2 Choreography Diagram) SF A CD Generation CD BPMN2 Choreography Diagram Messages XML Schema Choreography Architecture Generation BCService/Thing SF A Choreography Deployment Generation Choreography Architecture Description Choreography Deployment Description CD OVERALL GOAL provide automatic support to the realization of choreography-based systems by realizing a synthesis process 13/04/17 Marco Autili - Seminar Lectures @GSSI 64
  65. 65. Synthesis Process (cont’d) Choreography Specification Validation Choreography Projection Selection BC Generation SF Generation Adapter Generation BC Service/Thing Description Inventory Participant Model (BPMN2 Choreography Diagram) SF A CD Generation CD BPMN2 Choreography Diagram Messages XML Schema GOAL check the choreography realizability and its enforceability by the process 13/04/17 Marco Autili - Seminar Lectures @GSSI 65
  66. 66. Synthesis Process (cont’d) Projection of "Tourist Agent" participant Choreography Specification Validation Choreography Projection Selection BC Generation SF Generation Adapter Generation BC Service/Thing Description Inventory Participant Model (BPMN2 Choreography Diagram) SF A CD Generation CD BPMN2 Choreography Diagram Messages XML Schema GOAL derive a (sub-) BPMN2 Choreography Diagram that contains only the choreography flows involving the considered participant 13/04/17 Marco Autili - Seminar Lectures @GSSI 66
  67. 67. Synthesis Process (cont’d) Service/Thing specification process Participant Model (BPMN2 Choreography Diagram) Choreography Specification Validation Choreography Projection Selection BC Generation SF Generation Adapter Generation BC Service/Thing Description Inventory SF A CD Generation CD BPMN2 Choreography Diagram Messages XML Schema Interface Specification Interface Description Interaction Protocol Specification Interaction Protocol Description QoS Specification QoS Description Security Specification Security Description Inventory GOAL querying the Service Inventory in order to select concrete services (or things) that can play the roles of the choreography participant 13/04/17 Marco Autili - Seminar Lectures @GSSI 67
  68. 68. Synthesis Process (cont’d) Participant Model (BPMN2 Choreography Diagram) Choreography Specification Validation Choreography Projection Selection BC Generation SF Generation Adapter Generation BC Service/Thing Description Inventory SF A CD Generation CD BPMN2 Choreography Diagram Messages XML Schema GOAL generate BCs when the interaction style (e.g., REST) of a selected service (or thing) is different from SOAP S1 S2 CD1 CD2 BC1 BC2 13/04/17 Marco Autili - Seminar Lectures @GSSI 68
  69. 69. Synthesis Process (cont’d) Participant Model (BPMN2 Choreography Diagram) Choreography Specification Validation Choreography Projection Selection BC Generation SF Generation Adapter Generation BC Service/Thing Description Inventory SF A CD Generation CD BPMN2 Choreography Diagram Messages XML Schema GOAL generate SFs to filter the services interactions according to the specified security requirements (e.g., different authentication & authorization attributes) S1 S2 CD1 CD2 BC1 BC2 SF1 SF2 13/04/17 Marco Autili - Seminar Lectures @GSSI 69
  70. 70. Synthesis Process (cont’d) Choreography Specification Validation Choreography Projection Selection BC Generation SF Generation Adapter Generation BC Service/Thing Description Inventory Participant Model (BPMN2 Choreography Diagram) SF A CD Generation CD BPMN2 Choreography Diagram Messages XML Schema GOAL generate adapters that bridge the gap between the abstract interface and concrete interface of a selected service (or thing) S1 S2 BC1 BC2 SF1 SF2 CD1 CD2 A1 A2 13/04/17 Marco Autili - Seminar Lectures @GSSI 70
  71. 71. Synthesis Process (cont’d) Choreography Specification Validation Choreography Projection Selection BC Generation SF Generation Adapter Generation BC Service/Thing Description Inventory Participant Model (BPMN2 Choreography Diagram) SF A CD Generation CD BPMN2 Choreography Diagram Messages XML Schema GOAL generate CDs that coordinate the interactions among the selected services (or things) in order to fulfill the global collaboration prescribed by the choreography specification, in a fully distributed way S1 S2 BC1 BC2 SF1 SF2 CD1 CD2 A1 A2 13/04/17 Marco Autili - Seminar Lectures @GSSI 71
  72. 72. Synthesis Process (cont’d) Architectural description of the use case GOAL generate an architectural description of the choreographed system Choreography Architecture Generation BCService/Thing SF A Choreography Deployment Generation Choreography Architecture Description Choreography Deployment Description CD 13/04/17 Marco Autili - Seminar Lectures @GSSI 72
  73. 73. Synthesis Process Choreography Deployment Description of the use case Choreography Architecture Generation BCService/Thing SF A Choreography Deployment Generation Choreography Architecture Description Choreography Deployment Description CD GOAL generate the Choreography Deployment Description 13/04/17 Marco Autili - Seminar Lectures @GSSI 73
  74. 74. Outline • (must have) Advanced Software Engineering ingredients (a quick introduction) • Setting the context • Development scenario (high-level view) • Synthesis process • CHOReVOLUTION Platform • CHOReVOLUTION Studio Demo 13/04/17 Marco Autili - Seminar Lectures @GSSI 74
  75. 75. CHOReVOLUTION platform CHOReVOLUTION Front-end provides 1. CHOReVOLUTION Studio • design a choreography with BPMN2 • guide the generation of the additional artifacts exploiting the Synthesis Processor 2. CHOReVOLUTION Console • manage running services and choreographies • monitor the execution of the choreography • monitor the resources of the cloud infrastructure 13/04/17 Marco Autili - Seminar Lectures @GSSI 75
  76. 76. CHOReVOLUTION platform CHOReVOLUTION Back-end • Generation of the Concrete Choreography specification and all the required BCs, As, CDs, SFs (Synthesis Processor) • Deployment, configuration and control of BCs, As, CDs, SFs on the CHOReVOLUTION cloud infrastructure (Enactment Engine) • Management of authentication and authorization for those services that, at run-time, use different security mechanisms at protocol level (Identity Manager) • Propagation/synchronization of service/user profiles to/from external resources and provision of managed services (Federation Server) 13/04/17 Marco Autili - Seminar Lectures @GSSI 76
  77. 77. CHOReVOLUTION platform Execution on the CHOReVOLUTION cloud • Running different choreographies • Running different instances of a choreography, each having its own execution states • A set of virtual machines executing a custom- tailored mix of services and middleware components to serve different parts of the choreography 13/04/17 Marco Autili - Seminar Lectures @GSSI 77
  78. 78. Outline • (must have) Advanced Software Engineering ingredients (a quick introduction) • Setting the context • Development scenario (high-level view) • Synthesis process • CHOReVOLUTION Platform • CHOReVOLUTION Studio Demo 13/04/17 Marco Autili - Seminar Lectures @GSSI 78
  79. 79. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 79
  80. 80. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 80
  81. 81. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 81
  82. 82. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 82
  83. 83. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 83
  84. 84. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 84
  85. 85. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 85
  86. 86. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 86
  87. 87. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 87
  88. 88. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 88
  89. 89. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 89
  90. 90. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 90
  91. 91. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 91
  92. 92. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 92
  93. 93. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 93
  94. 94. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 94
  95. 95. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 95
  96. 96. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 96
  97. 97. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 97
  98. 98. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 98
  99. 99. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 99
  100. 100. CHOReVOLUTION Studio 13/04/17 Marco Autili - Seminar Lectures @GSSI 100
  101. 101. Conclusions üPut the bases to support dynamic choreography evolution in response of goal and context changes • Separation of concerns between application, coordination, and adaptation logic • Adapters as a composition of different EIP depending on a notion of I/O data mappings inference (Message Filter, Aggregator, Splitter, and Resequencer) üRelevance of exploiting EIP • Modular adapters • Dynamic evolution • Automatic generation and easier maintenance of adapters’ code 13/04/17 Marco Autili - Seminar Lectures @GSSI 101
  102. 102. Future research directions üExtension of the approach to deal with governance issues • Multiple systems belonging to different security domains/federations governed by different authorities • Usage of different identity attributes that are utilized in their access control polices üHow to support dynamic evolution via the automated and on-the-fly synthesis of, e.g., more complex adapters realized by combining additional classes of EIP, e.g., • Message Transformation Patterns such as Content Enricher, Content Filter, and Transformer • Semantic interoperability • Enabling a finer form of adaptation concerning mismatches at the level of the semantics of the exchanged messages 13/04/17 Marco Autili - Seminar Lectures @GSSI 102
  103. 103. References • Web Site http://www.chorevolution.eu • Twitter https://twitter.com/CHOR_eVOLUTION • Source Code (GIT repositories) https://goo.gl/kQUXgk • OW2 JIRA https://goo.gl/9FxVSj • Useful text books • Software Engineering, 10th Edition, Ian Sommerville • Web Services & SOA, Principles and Technology, 2nd Edition, Michael P. Papazoglou 13/04/17 Marco Autili - Seminar Lectures @GSSI 103
  104. 104. THANK 13/04/17 Marco Autili - Seminar Lectures @GSSI 104 YOU

×