1 / 17

Architecture Working Group

Architecture Working Group. Pasquale Pagano CNR-ISTI pasquale.pagano@isti.cnr.it All WGs Meeting , Rome, 26-28 May 2010. Interoperability from the Architecture Perspective 1/2. The place where every concept materialises. Architecture View. Restore Service. Repository A Service.

yeva
Télécharger la présentation

Architecture Working Group

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. Architecture Working Group Pasquale Pagano CNR-ISTI pasquale.pagano@isti.cnr.it All WGs Meeting, Rome, 26-28 May 2010

  2. Interoperability from the Architecture Perspective 1/2 The place where every concept materialises All WGs Meeting, Rome, 26-28 May 2010

  3. Architecture View Restore Service Repository A Service Restored Video Scanned Data Algorithm Video Summary Service MAP Web Service 3D Model Generator Service VideoShots Map 3D Models VideoShots Map Repo Luxemburg Service Select Video Scenes Compound Query Annotate Map Regenerate3D Model 3D Model Document Generator Service All WGs Meeting, Rome, 26-28 May 2010

  4. Provenance Graph Two persons, two perspectives, same concepts and same structure All WGs Meeting, Rome, 26-28 May 2010

  5. Architecture View: centralised component Repo Luxemburg Service Repository A Service Restore Service Restored Video Scanned Data Algorithm MAP Web Service 3D Model Generator Service Video Summary Service VideoShots 3D Models Compound generator Map Map Auth PEP PDP Select Video Scenes Compound VideoShots Query 3D Model Document Generator Service Regenerate3D Model Annotate Map All WGs Meeting, Rome, 26-28 May 2010

  6. Architecture View: distributed system Restore Service Repository A Service Restored Video Scanned Data PEP PEP Algorithm PDP PDP Video Summary Service 3D Model Generator Service MAP Web Service Auth Auth VideoShots Map 3D Models PEP VideoShots Map PDP Repo Luxemburg Service Select Video Scenes Auth Compound Query Annotate Map Regenerate3D Model 3D Model Document Generator Service All WGs Meeting, Rome, 26-28 May 2010

  7. Architecture View: distributed system Restore Service Repository A Service Restored Video Scanned Data PEP PEP Algorithm Video Summary Service 3D Model Generator Service PDP PDP Video Summary Service 3D Model Generator Service MAP Web Service Auth Auth VideoShots Map 3D Models PEP VideoShots Repo Luxemburg Service Map PDP Repo Luxemburg Service Select Video Scenes Auth Compound Query Annotate Map Regenerate3D Model 3D Model Document Generator Service All WGs Meeting, Rome, 26-28 May 2010

  8. Architecture • Are two components with a different bandwidth interoperable? • Different handshaking solutions: • Broadcast information (e.g. P2P) • Propagation • Registry • Mandatory • Architectural Component Discovery; • Architectural Component Get Capabilities; • Architectural Component Monitor; All WGs Meeting, Rome, 26-28 May 2010

  9. Should I assume to get an open compound object or should I assume a mechanism to navigate a close compound object? • If it is open, is the compound object structured and is the structure verifiable ? • Can I assume that a compound object contains a metadata, a video item, a map, and a list of 3D models? • Can I assume that each part is enriched with provenance information? • Should I assume that other (not listed above) parts are included in the compound object? • Does each part enriched with policy description? • Does each part addressable with a URI? • If the part are not included in the compound object but they are linked to the compound object should I consider broken links? All WGs Meeting, Rome, 26-28 May 2010

  10. The DL.org Architecture Working Group • Mission • Identify interoperability issues from the perspective of Architecture • Identify possible approaches to mitigate/resolve the issues identified • Propose effective patterns towards their resolution • Scope • Enable the use of Architectural Components belonging to one system (the provider) from another system (the consumer): • Software Components, i.e. artefacts implementing a set of functions, • System Components, i.e. running elements contributing to the operation of the overall system All WGs Meeting, Rome, 26-28 May 2010

  11. Interoperability from the Architecture Perspective 2/2 Provider Consumer Component Architecture reuse requires a common understanding of some component features Component Architecture reuse requires communicationbetween provider and consumer All WGs Meeting, Rome, 26-28 May 2010 11

  12. Architecture Interoperability Approach Common understanding and communicationfacets of a component are represented in the Reference Model: Component Profile, i.e. the “metadata” characterising the resource to share Application Framework, i.e. the “context” characterising the operational environment: roles, interaction patterns, interfaces and protocols All WGs Meeting, Rome, 26-28 May 2010

  13. Architecture Interoperability Approach: component profile • Profile is used for • present the interface • represent the state • list the dependencies • represent the existence and support discovery • improve the QoS by including run-time status • represent the behavior • Common approaches are based on • syntax definition in XML and XML Schema • Varieties of standards (WSDL, WSDL-S, WSRF, …) All WGs Meeting, Rome, 26-28 May 2010

  14. Architecture Interoperability Approach: application framework • Component interoperability is based on • an exchange of meaningful and context driven data. This exchange aims to allow a system to use functionality implemented in other systems • Component Integration aims to • the creation of a unique logical unit derived from linking together heterogeneous components in a concrete system • Component interoperability among two systems happens when: • two application frameworks are interoperable • two application frameworks are reconciled to some extent All WGs Meeting, Rome, 26-28 May 2010

  15. Architecture Interoperability Approach: application framework • Two application frameworks are interoperable when they use an agreed standard (or a combination of them) that achieves a certain amount of homogeneity between the involved systems • Messaging • Description and Discovery • Reliability, Transaction, and Security • Management • Application-oriented All WGs Meeting, Rome, 26-28 May 2010

  16. Architecture Interoperability Approach: application framework • Two application frameworks are reconciled to some extent through component mediating between the involved systems: • Blackboard-based • asynchronous communication between components in a system • one protocol to R/W and one language to specify messages • Connector / Adaptor-based • translates one interface for a component into a compatible interface • Proxy-based • exposes the same interface but allows additional operation over received calls • Mediator-based • provides a unified interface to a set of other components interfaces and encapsulates how this set of objects interact • Broker-based • Specialises a mediator by coordinating communication All WGs Meeting, Rome, 26-28 May 2010

  17. Time for questions • WG Coordinates: • Site https://workinggroups.wiki.dlorg.eu/index.php/Architecture_Working_Group • Surveyhttps://workinggroups.wiki.dlorg.eu/index.php/Architecture_Interoperability_State-of-the-art/Approaches • Mailing Listarchitecture_wg@dlorg.eu • Scientific ChairPasquale Pagano – pasquale.pagano@isti.cnr.it • WG Leader & RapporteurLeonardo Candela – leonardo.candela@isti.cnr.it All WGs Meeting, Rome, 26-28 May 2010

More Related