technical consultancy and analysis of 25 business experimentsdimitrakos+%28bt… · introduction:...

Technical consultancy and analysis of 25 Business Experiments

Theo [email protected]

Scientific & Technical Manager

Index

1. Objectives and structure of technical cross-activities

2. Global programme strategy and phases

3. Common Technical Requirements Elicitation

4. Common Capability Definition

5. Design Patterns & Component Reference Implementation

Business Experiments in GRID2

5. Design Patterns & Component Reference Implementation

6. Validation of results

Introduction: roles in the project

Scientific & Technical Manager

• Define the scientific and technical strategy for BEINGRID

• Ensure that the scientific & technical objectives are achieved

• Generate a technical assessment of completed and running activities

• Scientific & technical risk management

• Chairman of the technical board


• Chairman of the technical board

• Identify trends and technologies of interest to the project

• Co-ordinate the work of teams of technical consultants – their interactions with the Bussiness Experiments

– their joint tasks with the Business Consultants

• Identify and initiate the joint exploitation of technical results from – The BEinGRID technical activities

– The BEinGRID Business Experiments

– Other liaising research and commercial projects

Structure of Activity 1

WP1.1 Trust & Security ...

WP1.3 Service Management

WP1.2 Architecture & Interop

WP1.4 Data Management

WP3.1 = BE1 BE2 BE3 BE4 BE5 BE18WP3.1 = BE1 BE2 BE3 BE4 BE5 BE18

Repository


Mdw-1 Mdw -2 Mdw -n

WP1.7 Components dev.

WP1.5 VO Management

WP1.4 Data Management

WP1.6 Portals

Selected branches: GTv4, UNICORE/GS, g-lite, .NET, GRIA, WS-*

Repository

BEinGRID project website


Q7 – Use of generic components outside the BE’s

RepositoryRepository

Global Global

Cross Technical

Cross Technical

CrossBusiness

CrossBusiness

Internal External


Global TransferGlobal

Transfer

2nd Waveof BEs

2nd Waveof BEs

RepositoryRepository

BusinessBusiness

StandardsForums

StandardsForums

FP projectsFP projectsBEINGRIDpartners

BEINGRIDpartners

EUcitizen

EUcitizen

EUBusiness

EUBusiness

Stakeholders

Main Products (1/2)

Common Use-Cases &

Validation Scenarios

Common Technical

Requirements


CommonCapabilities

Best PracticeReports

Design Patterns

Main Products (1/2)

Common Use-Cases &

Validation Scenarios

Common Technical

Requirements

Simplified vision of the outcome:

A book / series on design patterns & Case

Simplified vision of the outcome:

A book / series on design patterns & Case


CommonCapabilities

Best PracticeReports

Design Patterns

A book / series on design patterns & Case Studies on SOA, WS and Grid computingA book / series on design patterns & Case Studies on SOA, WS and Grid computing

Generic Reference Implementation

Ready-to-deploy components per implementation pattern


DocumentationImplementation Patterns

Common approach for WP1.7

• A set of implementation patterns sketching an implementation of selected design patterns

– Depend on the execution platform selected

– Explain how the platform specific components selected match the design

pattern

– Explain how the problem description is addressed

– Detail interoperability issues


– Detail interoperability issues

• A set of ready to deploy components per implementation pattern

– Detail installation guidelines

– Detail deployment configuration

– Use common code repository

– Use common commit and versioning mechanism

• Consistent and visible documentation

– Use common documentation mechanism

– Include simplified unit testing & integration testing information

`

TECHNICAL CROSS TEAMPrior Knowledge

Problems

Platforms

Patterns

Solutions

Templates

ReqEng

Procedures

Elicited

Reqs

Design Patterns

Guidelines

Revised

Design Patterns

Feedback

Ref. Implementation

Design Patterns

Flow knowledge flow

BUSINESS MODELS BUSINESS MODELS


EXPERIMENTS

TOOLSET REPOSITORY

Prior Knowledge

Problems

Business Models

Application Design

Core App. Tech.Core Components (� Ph2)

Design Patterns (� Ph2)Processes (� Ph2)

Domain Specific ComponentTechnology DemoSW DocumentationCase Studies (Business Model, Architectures, etc.)

Design Patterns

Component Profiles

Best Practice Guidelines

Prior Knowledge

Core Grid/WS Tech.

FP6 Results (Ph2)

Baseline Technology (Ph1/2)

A mechanism to facilitate exchange of information between BEs and cross technical activitie:

- Analyse design and solutions (aligned in timing and form)

- Identify / check use of components (produced by Activity 1)

- Focus the business orientation of the results

- Assess the correct evolution of BE

Control points

CP1 Use

cases

CP3 Design – Identification

/use of generic components

CP4 Development

CP5 End integration


MA

RC

H

AP

RIL

MA

Y

JU

NE

JU

LY

AU

GU

ST

SE

PT

EM

BE

R

OC

TO

BE

R

NO

V

DE

CE

MB

ER

JA

NU

AR

Y

FE

BR

UA

RY

MA

RC

H

1 2 3 4 5 6 7 8 9 10 11 12

LEADER 22 23 24 25 26 27 28 29 30 31 32 33 34

Activity 4: Business Experiments Phase II ATOS ORIGIN

WP4.X = BEY (X=1 to 7, Y=19 to 25) LeaderY

Task4.x.1 Requirements and Design D D

Task4.x.2 Implementation and integration D

Task4.x.3 Test and validation D

Task4.x.4 Business models and exploitation D D D D

Task4.x.5 Common Disemination

Task4.x.0 Experiment Management d D d D

CP0 Management

- Detailed pilot workplan & risk manag

- Continuous Monitoring of pilot

(CP0.1, CP0.2, CP0.3, CP0.4)

cases

CP2 Business model

& market context

CP6/CP7 Result analysis.

Achievements report &

business case

CP8 Dissemination

…

Approach & ongoing work in AC1

Common approach

• Predefine selection criteria & problem areas [help unify input from BEs]

• Cluster BEs

• Use collaborative tools (e.g. BT Global meet-me & MS live-meeting) to interview BEs

• Use common templates for

• requirements gathering & elicitation

• design analysis & patterns

• Provide best-practice guidance for requirements-to-design process


• Use common notation for problem definition

• monitor dependencies across work areas

• ensure consistency of presentation across work areas

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

BE UseBE Use--CaseCase

TemplateTemplateBE definition BE definition

((DoWDoW) Template) TemplateInitial Cluster Initial Cluster

DefinitionDefinitionQuestionnaireQuestionnaire

& BE Interviews& BE Interviews

Review of BEReview of BE

Requirements Requirements

Deliverable (D3.x.1)Deliverable (D3.x.1)

Elicitation of Elicitation of

Common TechnicalCommon Technical

RequirementsRequirements

BE Design BE Design

Guidance & Guidance &

Design TemplateDesign Template

Common Common

Capability Capability

IdentificationIdentification

00 2211

Final restructuringFinal restructuring

of AC1 clusters of AC1 clusters

& BE assignment & BE assignment

33DD

June 2006 October 2006 December 2006 January 2007

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

DD

November 2007

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T












BE Design BE Design



Common Common



00 2211




33DD


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

DD

November 2007

Approach & ongoing work in AC1

• Weekly AC1 teleconference / web-meeting since August 2006• Close interaction with the BE• Over 36 reviews of BE DoW (at least 2 reviews per BE)• 18 letters from AC1 with BE-specific questions & 18 interviews of BE• 3 templates (BE fact sheet, requirements, design) • 6 thematically-oriented (sub)clusters• 2 general face-to-face meetings of all AC1 and all BEs• Over 36 reviews of BE requirements deliverable (at least 2 per BE)• Close interaction with AC2 on prioritisation of common tech. requirements• Over 36 reviews of BE design deliverable (at least 2 per BE)• Reviews of 18 Demonstrators• 32 deliverables (30 of them integrated in 3 meta-deliverables)


• 32 deliverables (30 of them integrated in 3 meta-deliverables)• Close interaction with Gridipeida and BEinGRID component repository

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T












BE Design BE Design



Common Common



00 2211




33DD


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

DD

November 2007

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T












BE Design BE Design



Common Common



00 2211




33DD


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

DD

November 2007

AC1

TS SM DM VOM PO

GS LMDM1

(distribution)VOC1

(VO policies)POC1

(Admin)

BEinGRID Technical Cluster Overview


VOC3(VO security)

SLAMDM2

(heterogeneity)

DM3(transfer)

VOC2(discovery)

VOC3(VO security)

POC2(data mgmt)

POC3(job mgmt)

BEinGRID Technical Cluster Overview

BEinGRID Cluster Topics Main contact

General Security Federated Identity Management

Distributed Access Management

Secure Service Exposure & Management

David Brossard (BT)

SLA Cluster Full SLA life-cycle support

(negotiation, monitoring, evaluation, accounting …)

Igor Rosenberg (Atos)

Licence Management Grid licence management models & architecture Christian Simmendinger

(T-Systems)

Data Management: Data disstributionCraig Thomson (EPCC)


Data Management: Data disstribution

Data heterogeneity

Data transfer

Craig Thomson (EPCC)

Kostas Kavoussanakis (EPCC)

Virtual Organization

Management

Policies and models for VO life-cycle management

Semantically enhanced discovery of services and

resources

VO security and federation infrastructure

Angelo Gaeta (CRMPA)

Portals Portals administration

Data Management portals

Job Management Portals

Stathis Karanastasis (NTUA)

Michael Russell (PSNC )

CTR elicitation approach in AC1

Technical Requirements Elicitation

• 39 technical requirements elicited

• Generic: Common technical innovation relevant to 2 or more BE

• Traceability – requirements were classified against:– Business drivers

– Technical challenges

– BE application context

• Analysis of dependences between common requirements– Dependences analysed across clusters

• Prioritisation of common technical requirements– Popularity:

– Technical novelty / Innovation potential


– Technical novelty / Innovation potential

– Business value & impact of solution

– Interdependences: how many other highly ranked requirements depend upon it.

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T












BE Design BE Design



Common Common



00 2211




33DD


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

DD

November 2007

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T












BE Design BE Design



Common Common



00 2211




33DD


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

DD

November 2007

Overview of the common technical requirements elicited (info-button links to specific area detail)

VOM-R7: Resource Annotation

VOM-R6: Policies and mechanisms for VO

membership and authorisation

VOM-R5: Secure Federation

VOM-R4: Management of VO policies

VOM-R3: Application deployment

VOM-R2: Separation of infrastructure mgmt

capabilities from application specific ones

VOM-R1: Virtualisation of resources of the Hosting

Environments

VO Management

Common Technical RequirementsArea


VOM-R6: Policies and mechanisms for VO

membership and authorisation




VOM-R2: Separation of infrastructure mgmt

capabilities from application specific ones

VOM-R1: Virtualisation of resources of the Hosting

Environments

VO Management


GS-R1: Trust and security through message-level

enforcement

SLA-R8: Accounting

SLA-R7: Evaluation

SLA-R6: Re-negotiation

SLA-R5: SLA Monitoring

SLA-R4: Optimisation of Resource Selection

SLA-R3: SLA Negotiation

SLA-R2: Publication and Discovery

SLA-R1: SLA (template) specification

SLA Mgmt


GS-R1: Trust and security through message-level

enforcement

SLA-R8: Accounting

SLA-R7: Evaluation






SLA-R1: SLA (template) specification

SLA Mgmt



LM-R3: Grid Licence Models

LM-R2: Limited LSP capability

LM-R1: Gridfication of currently used Licence Management systems

Licen

ce Mgmt

PO-R8: Job visualisation

PO-R7: Job monitoring and control

PO-R6: Job submission

PO-R5: Database Access

PO-R4: File management

PO-R3: Accounting

PO-R2: User management

PO-R1: Portals Security

Portals

VOM-R8: Automatic resources/services discovery



LM-R1: Gridfication of currently used Licence Management systems

Licen

ce Mgmt






PO-R3: Accounting


PO-R1: Portals Security

Portals


DM-R7: GridFTP Windows server

DM-R6: Federate a number of data sources

DM-R5: Replication of data for speed and

robustness

DM-R4: Accessing heterogeneous data

DM-R3: Accessing data from different locations

DM-R2: Fast transfer of large numbers of small files

DM-R1: Fast transfer of large files

Data M

anagement

GS-R5: Secure Service Management

GS-R4: Data protection & infrastructure security

GS-R3: Distributed access control methodologies

GS-R2: Adaptive enforcement systems architectures

enforcement

General S

ecurity

DM-R7: GridFTP Windows server


DM-R5: Replication of data for speed and

robustness




DM-R1: Fast transfer of large files

Data M

anagement





enforcement

General S

ecurity

Elicited common technical requirements




SLA-R7: Evaluation






SLA-R1: SLA (template) specificationSLA Mgmt


SLA-R7: Evaluation








SLA-R7: Evaluation








SLA-R7: Evaluation








VOM-R6: Policies and mechanisms for VO membership and authorisation




VOM-R2: Separation of infrastructure management capabilities from application specific ones

VOM-R1: Virtualisation of resources of the Hosting EnvironmentsVO

Management









Management









Management









Management




DM-R5: Replication of data for speed and robustness




DM-R1: Fast transfer of large filesData

Management





GS-R1: Trust and security through message-level enforcementGeneral

Security

SLA-R8: Accounting







Management






Security

SLA-R8: Accounting







Management






Security

SLA-R8: Accounting







Management






Security

SLA-R8: Accounting



LM-R1: Gridfication of currently used Licence Management systemsLicence Mgmt






PO-R3: Accounting


PO-R1: Portals SecurityPortals











PO-R3: Accounting













PO-R3: Accounting













PO-R3: Accounting







SLA-R7: Evaluation








SLA-R7: Evaluation








SLA-R7: Evaluation








SLA-R7: Evaluation














Management









Management









Management









Management


765432154321876543213218765432187654321

Data ManagementGeneral SecuritySLA ManagementLMPortalsVO management

765432154321876543213218765432187654321


SSSSSP8

SSP7

PSSPP6

SSP5

SP4

SSPP3

SSSPP2

SSPPP1

V

O

M

a

n

a

g

e

m

e

n

t

SSSSSP8

SSP7

PSSPP6

SSP5

SP4

SSPP3

SSSPP2

SSPPP1

V

O

M

a

n

a

g

e

m

e

n

t

PPPSS8

PPPSPSS7

PPPSPSS6

PPPPSS5

PPPSS4

SSSPPSSPS3

PSPS2

PSS1

P

o

r

t

a

l

s

PPPSS8

PPPSPSS7

PPPSPSS6

PPPPSS5

PPPSS4

SSSPPSSPS3

PSPS2

PSS1

P

o

r

t

a

l

s

SSSPS2

SSSSSS1

L

M

SSSPS2

SSSSSS1

L

M

765432154321876543213218765432187654321


765432154321876543213218765432187654321


SSSSSP8

SSP7

PSSPP6

SSP5

SP4

SSPP3

SSSPP2

SSPPP1

V

O

M

a

n

a

g

e

m

e

n

t

SSSSSP8

SSP7

PSSPP6

SSP5

SP4

SSPP3

SSSPP2

SSPPP1

V

O

M

a

n

a

g

e

m

e

n

t

PPPSS8

PPPSPSS7

PPPSPSS6

PPPPSS5

PPPSS4

SSSPPSSPS3

PSPS2

PSS1

P

o

r

t

a

l

s

PPPSS8

PPPSPSS7

PPPSPSS6

PPPPSS5

PPPSS4

SSSPPSSPS3

PSPS2

PSS1

P

o

r

t

a

l

s

SSSPS2

SSSSSS1

L

M

SSSPS2

SSSSSS1

L

M








Management






Security

SLA-R8: Accounting







Management






Security

SLA-R8: Accounting







Management






Security

SLA-R8: Accounting







Management






Security

SLA-R8: Accounting









PO-R3: Accounting













PO-R3: Accounting













PO-R3: Accounting













PO-R3: Accounting





PP7

PPSS6

PPPSS5

SPSS4

PSSS3

SPS2

PS1

D

a

t

a

M

a

n

a

g

e

m

e

n

t

SSPPSS5

SSSSPP4

SP3

PPS2

SSPS1

G

e

n

e

r

a

l

S

e

c

u

r

i

t

y

PSSS8

SPPS7

SPPPSS6

SPPPS5

SPPSS4

PPSSS3

SPS2

SSP1

S

L

A

M

a

n

a

g

e

m

e

n

t

PS3

M

PP7

PPSS6

PPPSS5

SPSS4

PSSS3

SPS2

PS1

D

a

t

a

M

a

n

a

g

e

m

e

n

t

SSPPSS5

SSSSPP4

SP3

PPS2

SSPS1

G

e

n

e

r

a

l

S

e

c

u

r

i

t

y

PSSS8

SPPS7

SPPPSS6

SPPPS5

SPPSS4

PPSSS3

SPS2

SSP1

S

L

A

M

a

n

a

g

e

m

e

n

t

PS3

M

PP7

PPSS6

PPPSS5

SPSS4

PSSS3

SPS2

PS1

D

a

t

a

M

a

n

a

g

e

m

e

n

t

SSPPSS5

SSSSPP4

SP3

PPS2

SSPS1

G

e

n

e

r

a

l

S

e

c

u

r

i

t

y

PSSS8

SPPS7

SPPPSS6

SPPPS5

SPPSS4

PPSSS3

SPS2

SSP1

S

L

A

M

a

n

a

g

e

m

e

n

t

PS3

M

PP7

PPSS6

PPPSS5

SPSS4

PSSS3

SPS2

PS1

D

a

t

a

M

a

n

a

g

e

m

e

n

t

SSPPSS5

SSSSPP4

SP3

PPS2

SSPS1

G

e

n

e

r

a

l

S

e

c

u

r

i

t

y

PSSS8

SPPS7

SPPPSS6

SPPPS5

SPPSS4

PPSSS3

SPS2

SSP1

S

L

A

M

a

n

a

g

e

m

e

n

t

PS3

M

Common Requirements Prioritisation process

Prioritization of common requirements – Criteria:

- Popularity: how many BEs have this requirement?

- Technical novelty: how challenging and otherwise unavailable the solution will be?

- Business value: what is the business case behind the requirement?

- Interdependency: how many other highly ranked requirements depend upon it?






Common Capabilities & Design patterns

Common requirements will be used to identify platform independent Common



Capabilities















Capabilities


Using the prioritized list of requirements and the available skills:

Implementation patterns: the application for an specific technology of a given

Design pattern

Development of generic components: development of the selected components

for the required platforms.



Design pattern



Capabilities

Design Patterns will exemplify use and architecture of common capabilities

This process will be guided by common technical concept ontology

Capabilities





Design pattern





Design pattern



Capabilities



Capabilities



Prioritisation of the common technical requirements

Thematic Area Requirement PopularityTechnical

Novelty

Business

ImpactDependences(of others on this)

Overall

User Access

(Portals)

Security High High High Med High

User Management High Low Med High High

Accounting Med High High Low Med

File Management High Low Med Med Med

Database Access Low Low Med Med Low

Job Submission High Low Low High High

Job Monitoring & Control High Low High Low Med


Job Monitoring & Control High Low High Low Med

Job Visualisation Med High Med Low Med

VO

Management

Virtualisation of Hosting Environment resources Medium Medium High Medium Medium

Mgmt capability separation (infrastructure –vs-

application)

Medium High High Medium High

Application Deployment High Medium Medium Low Medium

Management of VO policies Low Medium Medium Medium Low

Secure Federation Medium High High Medium High

VO membership & authorisation Medium Low Medium Low Low

Resource Annotation Low Medium Medium Medium Medium

Automatic discovery (resource/services) Low High High Low Medium



Novelty

Business


Overall

License

Management

Gridfication of currently used Licence

Management systems

High High High High High

Limited LSP capability High High High Medium High

Grid Licence models Medium High High Low Medium

SLA

Management

SLA template specification High Low High High High

Publication & Discovery Low Medium High Low Medium


Management Publication & Discovery Low Medium High Low Medium

SLA Negotiation Medium High High High High

Provider Resource Optimisation High Medium Medium Low Medium

Monitoring Medium Medium Medium Medium Medium

Re-negotiation Low High Low Low Low

Evaluation Medium High Medium Low Medium

Accounting Low Low Low Low Low



Novelty

Business


Overall

General

Security

Trust and security through message level

enforcement

High Medium High High High

Adaptive enforcement Medium High High Medium High

Distributed access control methodologies High High Medium Medium High

Data protection and Infrastructure security Medium Low Low Low Low

Secure Service Management High High Medium Low Medium

Fast transfer of large files High Low High Low Medium


Data

Management

Fast transfer of large files High Low High Low Medium

Fast transfer of large numbers of small files Low Low Medium Low Low

Accessing data from different locations High Medium High High High

Accessing heterogeneous data High Medium High Medium High

Replication of data for speed and robustness Medium High Medium Low Medium

Federate a number of data sources Medium Medium Medium Low Medium

GridFTP Windows server Low Low Low Low Low

Common Capability identification approach in AC1

Common Capability identification

• 36 common capabilities identified

• Generic: Common functionality relevant to several BE

• Traceability – common capabilities are classified against:

– Common technical requirements

– Design patterns describing the functionality and use of the common capability

– BE that see added value thought the common capability

• Analysis of dependences between common capabilities – Dependences analysed within each thematic area

– Dependences analysed across thematic areas

• Common concepts and terminology– Common concepts used across AC1

– Commonly used terms defined and standardised across all cross-activities.


– Commonly used terms defined and standardised across all cross-activities.

• Business value clarified– Motivation for each common capability is elaborated focusing on business value gained

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T












BE Design BE Design



Common Common



00 2211




33DD


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

DD

November 2007

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T












BE Design BE Design



Common Common



00 2211




33DD


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

DD

November 2007

Common Capability Identification process













Capabilities



Capabilities













Capabilities



Capabilities




Design pattern





Design pattern



Capabilities







Design pattern





Design pattern



Capabilities





Design Patterns in relation to Common Capabilities and Common Technical RequirementsThematic Area: User Access (Portals)

Thematic

Area

Common Capability Design Pattern Common Technical

Requirement

Security Portals Security PO-R1

User Management User Management PO-R2

Accounting Accounting PO-R3


User Access

(Portals)

Accounting Accounting PO-R3

File Management File Management PO-R4

Database Access Database Access PO-R5

Job Submission, Monitoring & Control JSMC PO-R6, PO-R7

Job Visualisation Job Visualisation PO-R8

Design Patterns in relation to Common Capabilities and Common Technical Requirements

Thematic Area: VO Management

Thematic Area Common Capability Design Pattern Common Technical

Requirement

Creation of instances on distributed

hosting environments

VHE Factory VOM-R1, VOM-R2

Application Virtualisation (or Exposure) &

Life-cycle Management

Application Virtualisation VOM-R2, VOM-R4


VO ManagementLife-cycle Management

Secure Federation Secure Federation VOM-R5, VOM-R6

Automatic Resource Discovery Automatic Discovery Façade VOM-R7, VOM-R8

VO Set-up VO Set-up VOM-R1, VOM-R2, VOM-R4,

VOM-R5

Thematic Area Common Capability Design Pattern Common Technical

Requirement

Licence

Management

LM related Extension of Job Description

and Submission

Generic Licence Management Architecture LM-R1, LM-R3

LM related Authorization Generic LM Architecture LM-R1

LM related Scheduler Extension Generic LM Architecture LM-R1, SLA-R4

LM related Resource Management Generic LM Architecture LM-R2


Thematic Area: Licence Management


ManagementExtension

Licence Proxy Resource Management based Proxy Pattern LM-R1

LM related Billing and Accounting Generic LM Architecture LM-R2, SLA-R8

Encapsulation of Licence Server Generic LM Architecture LM-R2

Thematic

Area


Requirement

SLA

Management

Optimisation of resource selection SLA optimisation SLA-4, PO-R6, PO-R7

Runtime monitoring Monitoring Evaluation SLA-5, SLA-7, PO-R6, PO-

R7

Negotiation SLA Negotiation Pattern SLA-3, SLA-6

Publication and Discovery N/A (See Automatic Discovery Façade) SLA-2



ManagementPublication and Discovery N/A (See Automatic Discovery Façade) SLA-2

SLA Template N/A SLA-1

SLA Accounting SLA Accounting SLA-8, PO-R3

Thematic

Area


Requirement

General

Security

Check validity of claims Security Token Service

Trusted 3rd party authentication

GS-R1, GS-R3, GS-R5,

PO-R1

Policy management system Policy Decision Point (PDP)

Policy Enforcement Point (PEP) Factory

GS-R1, GS-R2, GS-R3,

GS-R4, VOM-R6, LM-R2,

PO-R1

Secure end-to-end communication

within a federation

End-to-end Security in a Federation GS-R1, GS-R2, GS-R3,

VOM-R5, VOM-R6


Thematic Area: General Security


Security

Policy Engine

(Event-Condition-Action)

Event-driven Policy Engine GS-R2, GS-R3

Connection Bridge Connection Bridge GS-R2, GS-R5

Security Update Security Observer GS-R2

Encryption level Broker Encryption level Broker GS-R5


Thematic Area: Data Management

Thematic

Area


Requirement

Data

Management

Avoid Transferring Data Data Source Publisher Pattern DM-R1, DM-R2

Homogenise Data Sources Query Translator Pattern DM-R4, PO-R5

Access To A Remote Data Source Data Source Publisher Pattern DM-R3

Synchronise Multiple Data Sources Data Source Publisher Pattern

Query Translator Pattern

Primary-Secondary Replicator Pattern

DM-R4, DM-R3, DM-R6,

PO-R5


Primary-Secondary Replicator Pattern

Treat Multiple Data Sources As One Query Translator Pattern

Data Federation Pattern

Data Source Publisher Pattern

DM-R6, DM-R3, PO-R5

Common Capability presentation

Name and CC identifier Associated Design Patterns

Common capability name & identifier List and explain associated design patterns

Description Motivation and foreseen Business Value

Short description of the functionality covered The motivation for selecting this common


Short description of the functionality covered

by the common capability

The motivation for selecting this common

capability is explained.

Relevant Common Technical Requirements Related Common Capabilities

Relevant common technical requirements &

their relationship to the common capability

Explain relationship to other common

capabilities within and across thematic areas

Common capability interdependences: Overview

VOMCC2

VOMCC4

VOMCC5

SLACC4

SLA

CC5

SLA

SLACC3

SLASLA

LMCC1

LMCC3

LMCC4

LMCC2

LMCC7

LMCC5

LMCC6

VO Management General Security SLA

PortalsData ManagementLicense Management


VOMCC1

VOMCC3

GSCC1

GSCC2

GSCC3

GSCC4

GSCC5

GSCC6

GSCC7

PortCC1

PortCC2

PortCC7

PortCC4

PortCC5

PortCC6

PortCC3

PortCC8

SLACC2

SLACC6

SLACC1Data

CC1DataCC2

DataCC3

DataCC4

DataCC5

All other Port dep on All other Port dep on

Design Patterns production process















Capabilities















Capabilities




Design pattern





Design pattern



Capabilities



Capabilities





Design pattern





Design pattern



Capabilities



Capabilities



Design Pattern presentation

Name of the pattern Simple and descriptive name

Intent what is it intended to achieve?

Also Known As Alternative names (e.g. as part of other thematic areas)

Motivation / scenario Business Experiment scenarios that provide the context

Concrete usage examples help understand abstract patterns

Applicability When is it appropriate and useful to use the pattern?


Structure A graphical representation of the parts which make up the pattern.

Participants The components and actors which make up the pattern and their

responsibilities

Collaboration How do the components work together to achieve the pattern

Consequences The results of using the pattern, including potentially dangerous

outcomes

Related Patterns Other patterns that can be used with or are related to this pattern

Development of reference implementations


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T












BE Design BE Design



Common Common



00 2211




33DD


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

DD

November 2007

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T












BE Design BE Design



Common Common



00 2211




33DD


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

DD

November 2007

Development of reference implementations

Prioritization of common requirements. Criteria:-Popularity: how many BEs have this requirement. -Technical novelty: how challenging and otherwise unavailable the solution will be. -Business driver: what is the business case behind the requirement?

-Interdependency: how many other highly ranked requirements depend upon it.

Common Capabilities & Design patternsCommon requirements will be used to identify platform independent Design patterns to address common capabilities. This process will be guided by the unification criteria provided by WP1.2.

Using the prioritized list of requirements and the available skills in WP1.7:


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T












BE Design BE Design



Common Common



00 2211




33DD


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

DD

November 2007

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T












BE Design BE Design



Common Common



00 2211




33DD


AD

VIC

E T

O B

E

AD

VIC

E T

O B

E

BE

IN

PU

T

BE

IN

PU

T

DD

November 2007

Implementation patterns An Implementation pattern is the application for an specific technology of a given Design pattern.

Development of generic componentsDevelopment for the required platforms of the selected components.

We are We are HereHere

Common components

Development of generic components

GS cluster LM cluster SLA cluster VO cluster DM cluster PO cluster

Clusters:

�Common capabilities

�Design patterns

WP1.2:

� Support in interoperability aspects

� Support in decisions about components

Clusters:

�Common capabilities

�Design patterns

WP1.2:

� Support in interoperability aspects

� Support in decisions about components


Development of generic components following the cluster structure defined in Activity 1:

– Gap Analysis to develop a component per middleware

– Production of Implementation Patterns– Implementation of components

for selected middlewares– Production of Best practices and

Guidelines for developed components

BEinGRID

Repository

component 1

component n

component 2

.

.

.

Developed components

Best practices & Guidelines

Components Documentation

Common Capability

Clusters

WP1.1-WP1.6Component

Development Plan

Implementation Pattern

Development DocumentationDescribes: implentation

milestones, acceptance tests

as well as a validation

scenario for the component

Realization of the Design

Pattern in a particular

technology or middleware.


Activity 1 Component

Capability

Design Pattern

User Guide

InstallationGuide

Delivery

PackagedSoftware

technology or middleware.

Includes a Gap Analysis.

Instructions to use the

ComponentInstructions to install

the Component

Gridipedia: a knowledge repository


Examples

FIM

(STS)

AuthZ

(PDP)

STS

PDP

Shared source

closed source(open policies)


(PDP)

SSG

(PEP)

PDP

PEP

PEP

closed source(open policies)

Shared sourcePEP

Best Practices & Case studies

Validation scenarios

• Exemplar business

experiments

• Illustrate use of component

• Exemplify technical benefits

Impact analysis

• Illustrate innovation

• Exemplify business benefits

• Exemplify contribution to BE

business models


• Exemplify technical benefits business models

Relevance and success criteria for CC implementation

Relevance:– Being able to prove that the Generic Components implemented meet some Common Capability

functionality and satisfy one or more Common Technical Requirements

– Being able to illustrate that the solution implemented may add benefit to several BE

Success:– Being able to successfully demonstrate that the solution implements the functionality of one or

more common capabilities

– Being able to prove that the solution implemented is expected to add value to several BE. For example by either of the following:


example by either of the following:

• BE using the solution with proven benefit

• BE committed to use the solution for their future exploitation

• BE interested in the solution

• BE gaining provable value by suing the solution

– High scoring in terms of the Common Capability criteria, justified via input from AC1,2 and 3or4

• Popularity – BE]

• Innovation

• Business impact

• Usefulness – i.e. being directly or indirectly used by other solutions scoring high in the above

New wave of business experiments

Matrix structure– Dedicated BE technical

champion

– Operate in the scope a matrix structure within the technical cross-activities

Technical

Cluster

BE Champion


cross-activities

– Maximise personalised help and time spent on specific BE

– Minimise overhead of cluster participation

BE Champion member

New wave of business experiments

Operational strategy

2 lines of technical consultancy1. A BE champion is assigned � 1st LINE CONSULTANT

2. Clusters continue focusing on teams of technical theme experts on common

capabilities


Technical consultant team embedded into the BE– Participate in all BE teleconferences

– Explain the selected common capabilities to the BE

– Intermediate between the BE

• technical clusters of interest

• BEinGRID component developer teams

– Drive the validation of BEinGRID common capabilities within the specific BE

Thank you for your attention

technical consultancy and analysis of 25 business experimentsdimitrakos+%28bt… · introduction:...

Documents