Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
Next Generation Management Next Generation Management
for Adaptive Environmentsfor Adaptive Environments
ManFIManFI 2010 Keynote2010 Keynote
Osaka JapanOsaka Japan19 April, 19 April,
20102010
l l kl l kJoel J. Fleck IIJoel J. Fleck IIHewlettHewlett-- PackardPackard
Office Office of Strategy & of Strategy & TechnologyTechnologygygy gygyHP Software and Solutions CTO OfficeHP Software and Solutions CTO Office
[email protected]@hp.com
Outline
• Background and Challengesg g• Domains• Domain Relationshipsp• Relationship Management• ConclusionsCo c us o s
page 219-Apr-10 - jjf2 ManFI - NOMS 2010
A Couple of Thoughts
No matter how adaptive/autonomic your application (and the network it runs on) is, it is still basically a static application unless:application unless:
• The network description used for management has been extended beyond the static semantic description of its y pcomposing elements,
• Your stimuli generation, analytic and decision/action system(s) d t ith th t it l ti d li ti adapt with the system as its solutions and applications
reconfigure,• The relationships between the domains composing the The relationships between the domains composing the
applications are dynamically managed.
19-Apr-10 - jjf2 page 3ManFI - NOMS 2010
Next Generation Management
• Put another way:y
The old way (legacy and current) of static, reactive y ( g y ) ,management won’t work in a highly distributed, multi-provider, multi-app environment. A new adaptable, pro-
ti t hit t t th t active management architecture must emerge that emphasizes management strategies for the “space between” connecting apps providers users and between connecting apps, providers, users and domains.
page 419-Apr-10 - jjf2 ManFI - NOMS 2010
Management Challenges for Adaptive Communications EnvironmentsCommunications Environments• New Communications Environments will be role-based and highly
distributeddistributed,• Much more emphasis on current or future role/task (what is or will
be happening) in management decisions/actions rather than past ( h h h d)(what has happened),
• Rather than slow and re-active (respond after-the-fact to undesireable events) mode, need to move to a fast and pro-active mode events) mode, need to move to a fast and pro active mode (reduce/prevent undesireable events),
• Ability to adapt to unknown elements (environmental, hardware and ftw ) i ti th tsoftware) impacting the system,
• Understand the relationships of distributed Domains:– Hierarchical relationshipsHierarchical relationships– Peer-to-peer relationships
• Need to manage the “space between” distributed Domains.
19-Apr-10 - jjf2 page 5ManFI - NOMS 2010
Current vs Next Generation Management
• Current:– End-to-end process based– Very large monolithic, static analysis systems– Reactive “limit damage once a bad event has occurred”– Reactive, limit damage once a bad event has occurred– Primary emphasis is on the management of the networki.e., the management environment reflects the traditional service delivery
i tenvironment
Future:– Domain, Relationship focused, policy-based– Adaptive collections of analytic components tailored to the triggering
stimuli and contextstimuli and context– Both reactive and pro-active, “reduce probability of bad events”– 3 Levels of Management focus: Local (intra-Domain), Relationship
(b t 2 D i ) d S i ( D i )(between 2 Domains) and Service (among many Domains)– Mission is to satisfy goals of system rather than follow a “process”
page 619-Apr-10 - jjf2 ManFI - NOMS 2010
Process Based Management (Current) vs. Adaptive Policy-Based Process ManagementAdaptive Policy-Based Process Management• Process Based Management:
F d f d d h h ( ll ) – Focus on static descriptions of end-to-end processes which (typically) span many domains and scopes of authority
– Top-down de-compositional approachp p pp– Rarely changes (either triggering events, analytics or even decision
support)
• Adaptive Policy-Based Process Management:– Driven by Business Goals/Rules, Ontologies and Policies that describe
the both intra and inter domain relationshipsthe both intra and inter-domain relationships– Context-aware– Balance of Structured (but adaptable) internal domain processes and
d d h d h hl d lun-Structured (ad hoc and highly adaptive) external processes– Control loops between and within domains provide feed-back and feed-
forward among both peer-to-peer and hierarchical relationshipsg p p p– Set of adaptive peer-to-peer relationships between Stimuli Generation,
Analytics and Decision/Action rather than monolithic silopage 719-Apr-10 - jjf2 ManFI - NOMS 2010
Outline
• Background and Challengesg g• Domains• Domain Relationshipsp• Relationship Management• ConclusionsCo c us o s
page 819-Apr-10 - jjf2 ManFI - NOMS 2010
Characteristics of Adaptive Management
• Declarative (Goal-based) rather than procedural (Process-( ) p (based),
• Domains defined by scope-of-authority of Role rather than bit “ d h ” d iarbitrary or “ad-hoc” domains,
• Adaptability both intra-domain and inter-domain on peer-to-peer (horizontal) and vertical (top-down and bottom-up),peer (horizontal) and vertical (top down and bottom up),
• Requires better modeling of environment “between the domains”,
• Requires an ontological understanding of relationships between domains,R i d i bilit t t / dif /d l t • Requires dynamic ability to create/modify/delete Relationships between domains,
• Process model within Role-based domainsProcess model within Role based domains,• Is Context-aware.
19-Apr-10 - jjf2 page 9ManFI - NOMS 2010
What is an Adaptive Environment Domain?
• Boundaries dictated by the scope of authority of the role of the Domain; l f h d h i.e., any policy governing a resource or artifact that is outside the scope
of authority of the role of the Domain is external to the Domain (i.e., it’s in another Domain or is governing an Relationship between Domains),
f l l• Contains a set of Internal Goals,• Contains a set of Internal Policies,• May have External Goals and Policies (which govern relationships with May have External Goals and Policies (which govern relationships with
other Domains),• May expose capabilities (Contracts) and data (via Contracts),• Exposed capabilities (and data) are governed by External Goals and • Exposed capabilities (and data) are governed by External Goals and
Policies,• External Goals and Policies must be consistent with Internal Goals and
P li iPolicies,• Processes must be contained within Domain (cannot span two or more
scope of authorities).
19-Apr-10 - jjf2 page 10ManFI - NOMS 2010
Adaptive Domain Structure
One Export/Import Pair per Relationship
RelationshipExport
Artifacts
RelationshipImport
Artifacts
DomainDomainDomainDomain
(scope of Authority of Role)(scope of Authority of Role)InternalPolicies
19-Apr-10 - jjf2 page 11ManFI - NOMS 2010
Additional Characteristics of a Domain
• All External Goals of a Domain must be consistent with the Internal Goals f h Dof the Domain,
• All External Policies exposed by a Domain must be consistent with the Internal Policies of the Domain,
• A Domain must be wholly contained within one horizontal layer (Tier),• A Domain must be wholly contained within one vertical slice (Concern),• A Domain may contain both Explicit (Documented) and Tacit (un• A Domain may contain both Explicit (Documented) and Tacit (un-
Documented) Policies,• Two Domains interact via a Relationship,
R l i hi b i h hi hi l • Relationships may be either hierarchical or peer-to-peer,• For each Relationship of which the Domain is a member, there exists a
layered Domain Relationship Map which describes the Domain’s f h l hperspective of the Relationship,
• Each Domain Relationship Map is described by an Ontology which captures the relationships and semantics of the Map.p p p
19-Apr-10 - jjf2 page 12ManFI - NOMS 2010
Managing “The Space Between”
• The problem is not how to manage the domains, but p g ,rather the space between (i.e., the relationship between domains),
d h h d d h h d h f– To do this we have to understand the “what and why” of software artifacts each side of the relationship:• Ontology of software artifacts• Ontology of software artifacts• Goals• Policies• Policies• Actions• Data• Data
19-Apr-10 - jjf2 page 13ManFI - NOMS 2010
Outline
• Background and Challengesg g• Domains• Domain Relationshipsp• Relationship Management• ConclusionsCo c us o s
page 1419-Apr-10 - jjf2 ManFI - NOMS 2010
What is an Inter-Domain Relationship?
• Sharing of capabilities and/or data between two g p /domains:
– Peer-to-peer relationship between domains (Federation),
– Hierarchical relationship between domains (Composition).
page 1519-Apr-10 - jjf2 ManFI - NOMS 2010
Characteristics of Inter-Domain Relationships
Current FutureCurrent FutureStatic Dynamic
S l d d (f l h d C d “b l ” f R l h M d l Specialized code (frequently hand-crafted) implementing ‘one-of’ interfaces
Code “built” from Relationship Model (i.e., derived from Business Rules that define reasons for Domain
ti i ti )participation)Require large amounts of resources to build and test
Model-driven approach to building and testing reducing handcrafting and testing
Frequently poorly documented Largely self-documented through Relationship Modelp
“One-of” nature requires significant management effort of each interface
Management by monitoring Relationship rather than specific interfaces
19-Apr-10 - jjf2 page 16ManFI - NOMS 2010
interfacesInflexible Flexible
Inter-Domain Relationships
Concern 1 Concern 2One Export/Import Pair per Association
Tier 1
AssociationExport
Artifacts
AssociationImport
Artifacts
Domain
(scope of Authority of Role)InternalPolicies
One Export/Import Pair per Association
AssociationExport
Artifacts
One Export/Import Pair per Association
AssociationImport
Artifacts
Domain
(scope of Authority of Role)InternalPolicies
Tier 2
AssociationExport
Artifacts
AssociationImport
Artifacts
Domain
(scope of Authority of Role)InternalPolicies
AssociationExport
Artifacts
One Export/Import Pair per Association
AssociationImport
Artifacts
Domain
(scope of Authority of Role)InternalPolicies
AssociationExport
Artifacts
One Export/Import Pair per Association
AssociationImport
Artifacts
Domain
(scope of Authority of Role)InternalPolicies
Tier 3
AssociationExport
Artifacts
One Export/Import Pair per Association
AssociationImport
Artifacts
Domain
(scope of Authority of Role)InternalPolicies
AssociationExport
Artifacts
One Export/Import Pair per Association
AssociationImport
Artifacts
Domain
(scope of Authority of Role)InternalPolicies
AssociationExport
Artifacts
One Export/Import Pair per Association
AssociationImport
Artifacts
Domain
(scope of Authority of Role)InternalPolicies
19-Apr-10 - jjf2 page 17ManFI - NOMS 2010
Characteristics of a Peer-to-Peer Domain RelationshipsRelationships
• Peer-to-Peer (Federations):( )– Are 1 Domain (peer) to 1 Domain (peer),– Each constituent Domain must be a member of the same Tier,
Domain Federations may span Concerns– Domain Federations may span Concerns,– Each constituent Domain provides two groups of Policies that
govern the Federation from the perspective of the constituent Domain: a set Export Policies and a set of Import Policies Each Domain: a set Export Policies and a set of Import Policies. Each group is visible to the Federation,
– The Export/Import pairs for each member of the Federation must be compatible with the other members Import/Export pairbe compatible with the other members Import/Export pair,
– The Federation Export and Import Policies must be consistent with the Internal Policies of the Domain.
19-Apr-10 - jjf2 page 18ManFI - NOMS 2010
Characteristics of Hierarchical Domain RelationshipsRelationships
• Hierarchical Domain Relationships (Compositions):p ( p )– Are 1 Domain (higher level) to 1 or more Domains (lower level),– Each Composition constituent Domain must be consistent with
upper/lower membersupper/lower members,– Domain Compositions may span two Tiers,– Domain Compositions may be within a single Tier,
E h tit t D i id t f P li i th t – Each constituent Domain provides two groups of Policies that govern the Composition from the perspective of the constituent Domain: a set Export Policies and a set of Import Policies. Each group is visible to the Compositiongroup is visible to the Composition,
– The Composition Export and Import Policies must be consistent with the Internal Policies of the Domain.
19-Apr-10 - jjf2 page 19ManFI - NOMS 2010
Adaptive Domain with Federation and CompositionComposition
One Export/Import Pair per Composition
CompositionExport
Artifacts
One Ex
CompositionImport
Artifacts
FederationExport
Artifacts
xport/ImporDomainDomain
FederationImport
Artifacts
rt Pair per F
DomainDomain
(scope of Authority of Role)(scope of Authority of Role)Artifacts Federation
Domain BusinessStrategy, Goals and Policies
19-Apr-10 - jjf2 page 20ManFI - NOMS 2010
Inter-Domain Relationships
Concern 1 Concern 2
CompatibleTier 1 Compatible
Tier 2 Compatible
Tier 3 Compatible
Consistent Consistent
19-Apr-10 - jjf2 page 21ManFI - NOMS 2010
Domain Business Strategy, Goals and Rules
RConsistent with
OutgoingOutgoingRelationshipRelationship
SS
Out
Relationsh
DomainDomainlogy
S b t f
•• StrategyStrategy
•• GoalsGoals
•• RulesRules
tgoing
hip Ontolo
•• Business StrategyBusiness Strategy
•• Business GoalsBusiness GoalsI iI i
Relmain Ontol Subset of
and consistent
with
RulesRules ogy
•• Business RulesBusiness RulesIncomingIncoming
RelationshipRelationship
•• StrategyStrategy
Incom
ationshipDom
with
•• GoalsGoals
•• RulesRules
ming
p Ontology
page 2219-Apr-10 - jjf2 ManFI - NOMS 2010
y
Consistent with
Inter-Domain Relationship Map
Domain Ontology
OWL 2.0
Subset of d
Inter‐Domain Relationship Map
Relationship Ontology
Owl 2.0
and consistent
with
SBVR Business Rules
SBVR Vocabulary• noun concepts
Consistent with
• fact types
SBVR Rules
Technology Neutral Policy Representations
Transformations
Technology Neutral Policy Representations
N3
Technology Neutral Contract Representations
19-Apr-10 - jjf2 page 23ManFI - NOMS 2010
gy p
Xpath 2.0 Assertions
Federation of Two Domains
Test for Consistency of Ontologies and Compatibility of all Levels
?Relationship Ontology
Owl 2.0
SBVR Business Rules
Inter‐Domain Relationship Map
Relationship Ontology
Owl 2.0
SBVR Business Rules
Inter‐Domain Relationship Map
?
??
SBVR Business Rules
SBVR Vocabulary• noun concepts• fact types
SBVR Rules
Technology Neutral Policy Representations
N3
Technology Neutral Contract Representations
Xpath 2.0 Assertions
SBVR Business Rules
SBVR Vocabulary• noun concepts• fact types
SBVR Rules
Technology Neutral Policy Representations
N3
Technology Neutral Contract Representations
Xpath 2.0 Assertions
Domain ADomain A Domain BDomain B? Federate ?? Federate ?
If Ontologies are inconsistent at any level of the mapthen
Modify or Reject Federation Proposal/Agreementthen
If Models are compatible at all Levelsthen
C F d iCreate FederationOtherwise Modify or Reject Federation Proposal/Agreement
19-Apr-10 - jjf2 page 24ManFI - NOMS 2010
Composition of Two Domains
Domain ADomain A Relatio
SBVR
SBV
SBV
Technology Neut
Technology Neutra
Xpat
Inter‐Dom
a
? Compose ?? Compose ?
onship Ontology
Owl 2.0
Business Rules
VR Vocabulary•noun concepts•fact types
R Rules
tral Policy Representations
N3
al Contract Representations
h2.0 Assertions
ain Relationship M
ap
? Compose ?? Compose ?
Test for Consistencyof Ontologiesand all Levels
If Ontologies and Maps are consistentthen
??? ?
and all LevelsCreate CompositionElse
Mediate or Abandon Composition
Relationship O
n
Owl 2.0
SBVR Business
SBVR Vocabu•noun co•fact typ
SBVR Rules
Technology Neutral Policy
N3
Technology Neutral Contrac
Xpath2.0 Asse
Inter‐Dom
ain Relati
Domain BDomain B
ntology
s Rules
laryonceptspes
y Representations
ct Representations
rtions
ionship Map
19-Apr-10 - jjf2 page 25ManFI - NOMS 2010
Outline
• Background and Challengesg g• Domains• Domain Relationshipsp• Relationship Management• ConclusionsCo c us o s
page 2619-Apr-10 - jjf2 ManFI - NOMS 2010
Managing a Multi-Domain Environment
• Each Domain manages itself and assures that its gexposed goals, rules and policies are consistent with internal goals and policies.
l h d d d• Relationships among Domains monitored and managed via external Inter-Domain Relationship Coordinator which manages cooperation between internal domain which manages cooperation between internal domain relationship managers.
• Requires capability and tools to document ContextRequires capability and tools to document Context.• IDRC will also be responsible for monitoring and
controlling feed-back and feed-forward loops among g p gRelationship participants and constructing and maintaining Contextual Information.
page 2719-Apr-10 - jjf2 ManFI - NOMS 2010
Distributed Domain Relationship ManagementManagement
Domain ADomain Management System
Domain Al h
Inter-Domain Relationship Coordinator
Relationship Ontology
Owl 2.0
SBVR Business R
ules
SBVR Vocabulary•noun concepts•fact types
SBVR Rules
Technology Neutral Policy Representations
N3
Technology Neutral Contract Representations
Xpath2.0 Assertions
Inter‐Dom
ain Relationship M
ap
Relationship Management Domain C
Relationship Management
Domain B R l ti hi
Domain ERelationship Management
Relationship O
ntology
Owl 2.0
SBVR Business Rules
SBVR Vocabulary•noun concepts•fact types
SBVR Rules
Technology Neutral Policy R
epresentations
N3
Technology Neutral Contract R
epresentations
Xpath2.0 Assertions
Inter‐Dom
ain Relationship Map
Domain BDomain Management System
Relationship Management
ManagementDomain D
Relationship Management
Relationship
Owl
SBVR Busin
SBVR Voc•nou•fact
SBVR Rules
Technology Neutral Po N
3
Technology Neutral Con
Xpath2.0 A
Inter‐Dom
ain Re p O
ntology
2.0
ness Rules
cabularyun conceptst types
s olicy Representations
3 ntract Representations
Assertions
elationship Map
Relations O
w
SBVR Bus
SBVR V •n •f
SBVR Ru
Technology Neutral
Technology Neutral Co
Xpath2.0
Inter‐Dom
ain R
?Relationship Ontology
O l 2 0
Inter‐Domain Relationship Map
Relationship Ontology
O l 2 0
Inter‐Domain Relationship Map ?Relationship Ontology
O l 2 0
Inter‐Domain Relationship Map
Relationship Ontology
O l 2 0
Inter‐Domain Relationship Map
Domain DDomain C Domain EDomain Management System Domain Management System Domain Management System
hip Ontology
wl 2.0
siness Rules
Vocabularynoun conceptsact types
ules
Policy Representations
N3
ontract Representations
0 Assertions
Relationship Map
?
??
Owl 2.0
SBVR Business Rules
SBVR Vocabulary• noun concepts• fact types
SBVR Rules
Technology Neutral Policy Representations
N3
Technology Neutral Contract Representations
Xpath 2.0 Assertions
Owl 2.0
SBVR Business Rules
SBVR Vocabulary• noun concepts• fact types
SBVR Rules
Technology Neutral Policy Representations
N3
Technology Neutral Contract Representations
Xpath 2.0 Assertions
?
??
Owl 2.0
SBVR Business Rules
SBVR Vocabulary• noun concepts• fact types
SBVR Rules
Technology Neutral Policy Representations
N3
Technology Neutral Contract Representations
Xpath 2.0 Assertions
Owl 2.0
SBVR Business Rules
SBVR Vocabulary• noun concepts• fact types
SBVR Rules
Technology Neutral Policy Representations
N3
Technology Neutral Contract Representations
Xpath 2.0 Assertions
page 2819-Apr-10 - jjf2 ManFI - NOMS 2010
Traceability Maps
• Traceability Maps are a combined directed and un-y pdirected graph that document the relationships between software artifacts (processes, policies, and contracts) thru th i lif l (b i t i l t ti d their lifecycle (business, system, implementation and instance).
• Key input for Contextual information providing capability • Key input for Contextual information providing capability to perform:– Impact analysis of altering, adding or deleting a software Impact analysis of altering, adding or deleting a software
artifact,– Equivalence analysis of different combinations of software
fartifacts,– “Look-ahead” for how will system appear in future.
page 2919-Apr-10 - jjf2 ManFI - NOMS 2010
Multi-Domain Distributed Solution Traceability Map
• Complex distributed solutions cover many Domain p yRelationships. Traceability Maps provide a key input to the understanding of current (and potential) Context. Th R l ti hi T bilit M t b b ilt f Thus, Relationship Traceability Maps must be built for each Relationship in a Solution.
• Full Domain View Traceability Maps for each domain • Full Domain View Traceability Maps for each domain can then be constructed through the Union of the Domain Traceability Map with the Intersections of the y pDomain Traceability Map with each Relationship Traceability Map for each Federated Domain.
b ll l l b l• Combining, a Full Multi-Domain Solution Traceability Map can be constructed.
3019-Apr-10 - jjf2 ManFI - NOMS 2010
Traceability Map for Solution of Federated DomainsDomains
Composition(d2,d4)
Business Run-time/DeploymentImplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
SN5
I3
I4
I2
I1
D4
D3
D2
D1
Business Run-time/DeploymentImplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
SN5
I3
I4
I2
I1
D4
D3
D2
D1
NGOSS Container Software Artifacts(Service, Component & Application)
Map between Container DNA Fingerprint and Core NGOSS Artifacts’ DNA Fingerprints
NGOSS Use Case(s)NGOSS Use Case(s)
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Policy
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Contract
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Process
reference
reference
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Policy
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Contract
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Process
reference
reference
referencereferencereference
Business Run-time/DeploymentImplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
SN5
I3
I4
I2
I1
D4
D3
D2
D1
Business Run-time/DeploymentImplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
SN5
I3
I4
I2
I1
D4
D3
D2
D1
NGOSS Container Software Artifacts(Service, Component & Application)
Map between Container DNA Fingerprint and Core NGOSS Artifacts’ DNA Fingerprints
NGOSS Use Case(s)NGOSS Use Case(s)
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Policy
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Contract
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Process
reference
reference
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Policy
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Contract
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Process
reference
reference
referencereferencereference
Domain4
Domain3
p ( )Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
referencereferenceFederation Use Case
in1/out2Federation Use Case
in1/out2
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
referencereferenceFederation Use Case
out1/in2
Federation Use Caseout1/in2
Federation Traceability Map
NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s)
NGOSS Use Case(s)NGOSS Use Case(s)
NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s)
Business Run-time/DeploymentImplementationSystem
B1 S1
I2
I1
D2
D1
Business Run-time/DeploymentImplementationSystem
B1 S1
I2
I1
D2
D1
NGOSS Container Software Artifacts(Service, Component & Application)
Domain2
Composition(d1,d3) Composition(d5,d4)Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
referencereferenceFederation Use Case
in1/out2Federation Use Case
in1/out2
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
referencereferenceFederation Use Case
out1/in2
Federation Use Caseout1/in2
Federation Traceability Map
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
referencereferenceFederation Use Case
in1/out2Federation Use Case
in1/out2
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
referencereferenceFederation Use Case
out1/in2
Federation Use Caseout1/in2
Federation Traceability Map
B2
B3
B4
B5
B6
S2
S3
SN4
SN5
I3
I4
D4
D3
D2B2
B3
B4
B5
B6
S2
S3
SN4
SN5
I3
I4
D4
D3
D2
Map between Container DNA Fingerprint and Core NGOSS Artifacts’ DNA Fingerprints
NGOSS Use Case(s)NGOSS Use Case(s)
Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem
B1
B 2B 3
B 4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I2
I1
D4
D3
D2
D1
Policy
Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem
B1
B 2B 3
B 4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I2
I1
D4
D3
D2
D1
Contract
Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem
B1
B 2B 3
B 4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I2
I1
D4
D3
D2
D1
Process
reference
reference
Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem
B1
B 2B 3
B 4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I2
I1
D4
D3
D2
D1
Policy
Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem
B1
B 2B 3
B 4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I2
I1
D4
D3
D2
D1
Contract
Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem
B1
B 2B 3
B 4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I2
I1
D4
D3
D2
D1
Process
reference
reference
referencereferencereference
NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s)
2Federation(d1,d2)
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
referencereferenceFederation Use Case
in1/out2Federation Use Case
in1/out2
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
referencereferenceFederation Use Case
out1/in2
Federation Use Caseout1/in2
Federation Traceability Map
Business Run-time/DeploymentImplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
SN5
I3
I4
I2
I1
D4
D3
D2
D1
Business Run-time/DeploymentImplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
SN5
I3
I4
I2
I1
D4
D3
D2
D1
NGOSS Container Software Artifacts(Service, Component & Application)
Map between Container DNA Fingerprint and Core NGOSS Artifacts’ DNA Fingerprints
NGOSS Use Case(s)NGOSS Use Case(s)
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Policy
Busines s R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D 4
D 3
D2
D1
Contract
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Process
reference
reference
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Policy
Busines s R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D 4
D 3
D2
D1
Contract
Business R un-time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I 2
I 1
D4
D3
D2
D1
Process
reference
reference
referencereferencereference
Business Run-time/DeploymentImplementationSystem
B1
B2
B3
B4
B5
B6
S1
S2
S3
SN4
SN5
I3
I4
I2
I1
D4
D3
D2
D1
Business Run-time/DeploymentImplementationSystem
B1
B2
B3
B4
B5
B6
S1
S2
S3
SN4
SN5
I3
I4
I2
I1
D4
D3
D2
D1
NGOSS Container Software Artifacts(Service, Component & Application)
Map between Container DNA Fingerprint and Core NGOSS Artifacts’ DNA Fingerprints
NGOSS Use Case(s)NGOSS Use Case(s)
Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem
B1
B 2B 3
B 4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I2
I1
D4
D3
D2
D1
Policy
Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem
B1
B 2B 3
B 4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I2
I1
D4
D3
D2
D1
Contract
Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem
B1
B 2B 3
B 4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I2
I1
D4
D3
D2
D1
Process
reference
reference
Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem
B1
B 2B 3
B 4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I2
I1
D4
D3
D2
D1
Policy
Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem
B1
B 2B 3
B 4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I2
I1
D4
D3
D2
D1
Contract
Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem
B1
B 2B 3
B 4
B5
B6
S1
S2
S3
SN4
S N5
I3
I4
I2
I1
D4
D3
D2
D1
Process
reference
reference
referencereferencereference
NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s)
Domain1
Domain5Federation(d1,d5)
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
referencereferenceFederation Use Case
in1/out2Federation Use Case
in1/out2
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
Business Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
PolicyBusiness Run- time/ DeploymentI mplementationSystem
B1
B2B3
B4
B5
B6
S1
S2
S3
SN 4
SN 5
I 3
I4
I2
I1
D 4
D3
D 2
D 1
Contract
reference
referencereferenceFederation Use Case
out1/in2
Federation Use Caseout1/in2
NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s)
3119-Apr-10 - jjf2 ManFI - NOMS 2010
Federation Traceability Map
Full Multi-Domain Solution Traceability Map
The Traceability Map for the full multi-domain solution can y pbe defined as:
FMDSTM = DVTMDomain1 ∪ DVTMDomain2 ∪ DVTMDomain3 ∪DVTMDomain4 ∪ DVTMDomain5
- or -
FMDSTM = (TMD1 ∪ (TMD1 ∩ TMF(D1,D2)) ∪ (TMD1 ∩TMC(D1,D3)) ∪ (TMD1 ∩ TMF(D1,D5))) ∪ (TMD2 ∪ (TMD2 ∩TM ) ∪ (TM ∩ TM )) ∪ (TM ∪ (TM ∩TMF(D1,D2)) ∪ (TMD2 ∩ TMC(D2,D4))) ∪ (TMD3 ∪ (TMD3 ∩TMC(D1,D3))) ∪ (TMD4 ∪ (TMD4 ∩ TMC(D2,D4)) ∪ (TMD4 ∩TMC(D5 D4))) ∪ (TMD5 ∪ (TMD5 ∩ TMF(D1 D5)) ∪ (TMD5 ∩
3219-Apr-10 - jjf2 ManFI - NOMS 2010
TMC(D5,D4))) ∪ (TMD5 ∪ (TMD5 ∩ TMF(D1,D5)) ∪ (TMD5 ∩TMC(D5,D4)))
Domain Relationship Management ArchitectureArchitecture
Domain Knowledge Domain Relationship MapDomain Knowledge Model
Local BusinessStrateg
Domain Relationship Map
Relationship Strategy, Goals and RulesCon
Generate
Strategy
Local BusinessGoals Technology
Neutral PolicyTechnology
Neutral Contract
strain TransformationRelationship Traceability
Map
Local BusinessRules
Neutral Policy Representations
Neutral Contract Representations
Generate Generate
Local ResourceModels
Incoming Relationship
Knowledge Model
Outgoing Relationship
Knowledge Model
Conflict Detection Knowledge
Local PoliciesGenerate
Trusted CBPMS Trusted CBPMS
DEN‐ng Knowledge Base
page 3319-Apr-10 - jjf2 ManFI - NOMS 2010
Trusted CBPMS Capability
Delegation Graph
Trusted CBPMS Capability Authority
Java/PHP Contract StubsAccess Control
Outline
• Background and Challengesg g• Domains• Domain Relationshipsp• Relationship Management• ConclusionsCo c us o s
page 3419-Apr-10 - jjf2 ManFI - NOMS 2010
In Summary
• New technologies (SaaS, PaaS, Cloud) require a g ( , , ) qdynamic means to build and maintain relationships between domains,
d d d d l k f• “On-demand or As-needed” linking of services/applications requires a high degree of confidence that the desired service/application will be confidence that the desired service/application will be available,
• There is a strong need to manage “the space between” There is a strong need to manage the space between domains/clouds,
• The Model must be adaptive!!p
A Model driven approach to managing inter-Domain A Model driven approach to managing inter Domain relationships provides a means to achieve all of these.
19-Apr-10 - jjf2 page 35ManFI - NOMS 2010
19-Apr-10 - jjf2 page 36ManFI - NOMS 2010