architecture working group

Architecture Working Group

Pasquale PaganoCNR-ISTI

pasquale.pagano@isti.cnr.it

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 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 17