architecture working group
DESCRIPTION
Architecture Working Group. Pasquale Pagano CNR-ISTI [email protected] 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. - PowerPoint PPT PresentationTRANSCRIPT
Architecture Working Group
Pasquale PaganoCNR-ISTI
All WGs Meeting, Rome, 26-28 May 2010
2
Interoperability from the Architecture Perspective 1/2
All WGs Meeting, Rome, 26-28 May 2010
The place where every concept materialises
3
Architecture View
All WGs Meeting, Rome, 26-28 May 2010
Restore Service
Video Summary Service
Repository A Service
3D Model Generator Service
MAP Web Service
Repo Luxemburg Service
Document Generator Service
Restored Video AlgorithmScanned Data
3D ModelsVideoShotsMap
Compound Query
Select VideoScenes
Regenerate3D Model
Annotate Map
3D Model
VideoShotsMap
4
Provenance Graph
All WGs Meeting, Rome, 26-28 May 2010
Two
pers
ons,
two
pers
pecti
ves,
sa
me
conc
epts
and
sam
e st
ruct
ure
5
Repo Luxemburg Service
Architecture View: centralised component
All WGs Meeting, Rome, 26-28 May 2010
Restore Service
Video Summary Service
Repository A Service
3D Model Generator Service
MAP Web Service
Compound generator
Document Generator Service
Restored Video AlgorithmScanned Data
3D ModelsVideoShots
Compound
Query
Select VideoScenes
Regenerate3D ModelAnnotate
Map
3D ModelVideoShots
Map MapPDPPEPAuth
6
Architecture View: distributed system
All WGs Meeting, Rome, 26-28 May 2010
Restore Service
Video Summary Service
Repository A Service
3D Model Generator Service
MAP Web Service
Repo Luxemburg Service
Document Generator Service
Restored Video Algorithm
Scanned Data
3D ModelsVideoShotsMap
Compound Query
Select VideoScenes
Regenerate3D Model
Annotate Map
3D Model
VideoShotsMap PDP
PEP
Auth
PDPPEP
Auth
PDPPEP
Auth
7
Repo Luxemburg Service
3D Model Generator Service
Video Summary Service
Architecture View: distributed system
All WGs Meeting, Rome, 26-28 May 2010
Restore Service
Video Summary Service
Repository A Service
3D Model Generator Service
MAP Web Service
Repo Luxemburg Service
Document Generator Service
Restored Video Algorithm
Scanned Data
3D ModelsVideoShotsMap
Compound Query
Select VideoScenes
Regenerate3D Model
Annotate Map
3D Model
VideoShotsMap PDP
PEP
Auth
PDPPEP
Auth
PDPPEP
Auth
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 8
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
Interoperability from the Architecture Perspective 2/2
• Component Architecture reuse requires a common understanding of some component features
• Component Architecture reuse requires communication between provider and consumer
ConsumerProvider
All WGs Meeting, Rome, 26-28 May 2010 11
12
Architecture Interoperability Approach
Common understanding and communication facets 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
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 [email protected]
– Scientific ChairPasquale Pagano – [email protected]
– WG Leader & RapporteurLeonardo Candela – [email protected]
All WGs Meeting, Rome, 26-28 May 2010 17