interoperability
play

Interoperability Professors: Chantal Taconet Students: Hai Le Sophie - PowerPoint PPT Presentation

Middleware for Distributed Applications 2019-2020 Interoperability Professors: Chantal Taconet Students: Hai Le Sophie Chabridon Liarou Eleni Denis Conan 1 Content 1. Definition 2. Interoperability Maturity 3. Exchanging Information via


  1. Middleware for Distributed Applications 2019-2020 Interoperability Professors: Chantal Taconet Students: Hai Le Sophie Chabridon Liarou Eleni Denis Conan 1

  2. Content 1. Definition 2. Interoperability Maturity 3. Exchanging Information via Interfaces 4. Importance and Aspects of Interoperability 5. System of Systems (SoS) 6. Interoperability General Scenario 7. Tactics for Interoperability 8. Standards for Interoperability 9. A Design Checklist for Interoperability 10. Summary 2

  3. Interoperability Definition (1) Interoperability is about the degree to which two or more systems can usefully exchange meaningful information via interfaces in a particular context. A system can be interoperable but the context should be defined(with whom, what and under what circumstances the system is going to interoperate with another system). An interoperable system is highly affected by the system it is going to interoperate with. 3

  4. Interoperability Definition (2) The Interoperability of a system is divided into two categories Syntactic Semantic Interoperability Interoperability Semantic Interoperability is as critical for the system as syntactic interoperability. 4

  5. Interoperability “Maturity” (1) There are different ways for the systems to interoperate. Five levels of Interoperability are defined [1]: • No Data Exchange : no physical connection • Unstructured Data Exchange : exchange of human-interpretable, unstructured data (free text) 5

  6. Interoperability “Maturity” (2) • Structured Data Exchange : exchange of human-interpretable structured data intended for manual and/or automated handling, but requires manual compilation, receipt, and/or message dispatch • Seamless Sharing of Data : automated data sharing within systems based on a common exchange model • Seamless Sharing of Information : universal interpretation of information through cooperative data processing 6

  7. Exchanging Informations via Interfaces There are two critical concepts that need clarification: ● “Exchange of Information” : It can be done even if there is no communication between the components. ● “Interfaces” : the meaning of an interface extends far beyond the API. By interface, we mean the set of assumptions that you can safely make about an entity. 7

  8. Importance and Aspects of Interoperability We want our system to interoperate because 1. That way the system can provide a service to be used by many unknown systems. 2. Interoperability allows use to construct capabilities from existing systems. Discovery These lead to two important aspects Handling of the response 8

  9. System of Systems (SoS) SoS is a group of systems that interoperate in order to achieve a joint purpose. 9

  10. Interoperability general scenario (1) The portions of an interoperability general scenario include: Source of stimulus (1) System that initiate a request to interoperate with other system Response Response (5) Stimulus (2) Artifacts (3) measure (6) Results in the A request exchange information The systems that The percentage of exchange rejected, among the systems wish to interoperate information exchange accepted, logged correctly Environment (4) The system that wish to interoperate are discovered at runtime or know prior to runtime 10

  11. Interoperability general scenario (2) Example of the interoperability scenario: 11

  12. SOAP and REST Web-based applications to interoperate, there are two major off the shelf technology options today: Two majors Technologies WS* and SOAP REST Simple Object Access Protocol Representation State Transfer 12

  13. SOAP vs. REST: About SOAP SOAP (Simple Object Access Protocol) is a protocol specification for XML-based information that distributed application can use to exchange information. SOAP and WS* together define many standards: Infrastructure for service composition Transaction SOAP can be employ the BPEL (Business Process WS-AT, WS-BA, WS-CAF, WS-Transaction Execution Language) Service discovery Reliability UDDI (Universal Description, Discovery and Integration) language.Businesses publish services Does not insure reliable message delivery and discover each other 13

  14. SOAP vs. REST: About REST REST is a client-based architecture style that is structured by 4 principles: - URI: Resource, data - Operation: CRUD operation (POST, GET,PUT, DELETE). - Format: Support multiple types like XML, HTML, JSON. - Stateless REST interfaces are simple, so any HTTP client can talk to HTTP server. All REST API must have HATEOAS 14

  15. SOAP vs. REST: Comparison The decision of your implementation is depended on your concern, tradeoff. Each technology has strength, weakness. SOAP REST Standardized interoperability: More Standardized interoperability: Less Individual message: More characters Individual message: Fewer characters Quality of service (QoS): Greater Quality of service (QoS): Minimal require 15

  16. Tactics for Interoperability (1) The goal of the tactics implemented to control interoperability is the appropriate handling of an information exchange request. 16

  17. Tactics for Interoperability (2) Categories of tactics identified Manage Interfaces Locate Discover Service Orchestrate Tailor Interface By service we mean a set of capabilities that is accessible via the interface. ➢ 17

  18. Standards and Interoperability (1) What is a standard and why it can not guarantee the interoperability of a system? ● Standards are agreements made on the structure and function of the information to be shared, so that many different applications can use it. ● Standards provide a common interface that is supported by many vendors and application builders. 18

  19. Standards and Interoperability (2) 1. Standards undergo customizations when incorporated into products or tools. Every vendor wants to create a unique selling point as a competitive advantage. 2. Standards are often on purpose open-ended and let the development create a proprietary implementation. 3. As standards have a life cycle, they can evolve to compatible or noncompatible ways. So may be a risk for an organization to adopt a new one or loss due to unsupported products and incompatibilities if everybody uses the standard. 19

  20. Standards and Interoperability (3) 4. There are many bad standards which include underspecified, overspecified, inconsistently specified, unstable, or irrelevant standards. 5. Because of the competition among organizations many conflicting standards can show up. 6. In new emerging fields it is thought that standardization may hinder flexibility and that could be destructing. We need to architect systems first and then decide which standards can support desired system requirements and qualities. Solution This approach allows standards to change and evolve without affecting the overall architecture of the system. 20

  21. A design checklist for interoperability (1) Technologies (7) Binding time (6) Allocation of responsibilities (1) Checklist Resource management (5) Coordination model (2) Mapping among Data model (3) architectural elements (4) 21

  22. A design checklist for interoperability (2) Allocation of Requirement: Check your system responsibilities that will need to interoperate with other responsibilities system. Detect the request to interoperate with known and unknown external systems. Check the tasks : - Accept the request - Exchange information - Reject the request - Notify appropriate entities - Log the request (for interoperability in an untrusted environment_ Coordination Requirement: Ensure the coordination mechanism meet the quality attribute requirements. model Check the tasks : - Volume of traffic by under control, not under control - Timeliness of message being sent - Currency of the message being sent by our systems - Jitter of the message’s arrival times - Make sure all of the system under your control makes assumptions that are consist with the systems which are not under your control 22

  23. A design checklist for interoperability (3) Data model Requirement: Determine the syntax and semantics of the major data that can be exchanged among interoperating system. Check the items: Transformation, abstraction, private data Mapping among Requirement: Mapping component to processor: architectural Check the tasks : Meeting the requirements: security, availability, performance for elements communication Resource Requirement: Make sure the interoperation is never exhaust resource. management Check the tasks: - Resource for communication is acceptable - The operation requires that resource be shared among participating system. 23

  24. A design checklist for interoperability (3) Binding time Requirement: Determine the systems that may interoperate and when they become known to each other. Check the tasks: - Policy for binding to both known and unknown external system - Mechanism to reject unacceptable binding and log such request - In case of late binding, ensure that mechanism will support the discovery of the protocols or sending of information using chosen protocols Technologies Consider technologies that are designed to support interoperability. 24

Recommend


More recommend