170 likes | 284 Views
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.
E N D
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 All WGs Meeting, Rome, 26-28 May 2010
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
Provenance Graph Two persons, two perspectives, same concepts and same structure All WGs Meeting, Rome, 26-28 May 2010
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
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
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
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
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
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
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
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
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
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
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
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
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