” Sikkerhet ved endring”
- Fra en teknologs (arkitekts) ståsted –
Arne-Jørgen Berre, SINTEF og
Institutt for informatikk, UiO
Oslo, 24. juni, 2010
ICT
1
Innhold
 Sikkerhet ved Endring
 Fra en Arkitekts ståsted (Arkitekturperspektiv)
 Arkitekturmodeller / Arkitekturrammeverk (IEEE/ 1471/ISO
42010, ADL, UML 2.x, TOGAF, UPDM (DODAF/MODAF),
SoaML (SHAPE), DSLs)
 Sikkerhet og Modeller (SecureUML, ObjectSecurity,DSMLSecurity, AOM)
 Systemer og modeller (ADM og MDA) (REMICS)
 Modeller og Endring/Evolusjon (Subclassing,
parameterisation, templates, Role models/Coll.models
(SoaML), CVL (Common Variability Language) (MoSiS),
Traceability, Service Variability, Resemblance &
Replacement)
ICT
2
IEEE 1471, ISO 42010
ICT
3
Open
Group
ADM
ICT
4
ICT
5
Building block evolution
ICT
6
UPDM - – Unified Model for DODAF
and MODAF
ICT
7
UPDM – Unified Model for DODAF and MODAF
ICT
8
SHAPE project and SoaML
SoaML
UPMS
9
ICT
2010-06-27
Goals
Business rules
Business processes
Business services
E-contracts
…
CIM
Flexible
Flexible
flexible
business
models
business
Businessmodels
Models
Transformer
(engine)
according to
transformation
engine
Business
Business
Business
metamodels
metamodels
metamodels
EPC
POP*
BPDM, BPMN
BMM
…
Transformation
rules
PIM
Executable business
processes
Service interfaces
Service contracts
Service enactment
Business rules
SLAs
Parameterized
services
…
Flexible
Business Models
Web
Services
Semantically enabled
heterogeneous
SOA model
according to
Unified and
standardised
metamodel for
SOA & SHA
Service
Variability
UPMSHA
P2P
Transformer
(engine)
transformation
engine
Grid
Agents
Semantic Web
Services
Heterogeneous
Platforms
Transformation
rules
PSM
Executable artefacts
XSD, WSDL, BPEL
Teams and plans
Resource
management
Semantic Web
Services
…
Semantically Interconnected
enabled
Interconnected
heterogeneous
heterogeneous
heterogeneous
SOA
platform
SOA
platform
SOA
platform
models
models
models
according to
Semantically enabled
Heterogeneous
Heterogeneous
heterogeneous
SOA
platforms
SOAplatform
platforms
SOA
metamodels
metamodels
metamodels
Heterogeneous
service platforms
WSA
JXTA
OGSA
JACK, JADE
WSMO, WSMX
…
ICT
Which metamodels and languages to use
What service-oriented aspects to capture in models
CIM to PIM to PSM
10
CIM – PIM - PSM
CIM
BPMN
BPDM
BMM
EPC
Business Models
…
SoaML-SHA
PIM
System Models
Core
SoaML
PIM4
WS-A
PIM4
SWS
Service Variability
PIM4
Agents
PIMs for different
Architectural Styles
P2P/Grid/
Components
PSM
WSDL, WSMO, OWL-S, JACK, JADE, JXTA, OGSA, J2EE, CORBA
J2EE, NetWeaver, .Net, …
Implementation Models
Realization Technologies
ICT
11
CIM-PIM-PSM Reference Matrix
ICT
12
SoaML Historikk
(Service oriented architecture
modeling language)






OMG RFP – September 2006
3 initial submissions – June 2007
Merge process in 2008 and 2009
SoaML 1.0 ferdigstilt desember 2009
SoaML 1.0 adopteres av OMG i mars 2010
FTF chairs: Arne J. Berre, SINTEF og Jim Amsden, IBM
 http://www.soaml.org
13
ICT
Service Architecture
Modeling with SoaML
collaboration models
ICT
Services Architecture
Ship
Status
service
Purchasing
service
Shipping
service
A ServicesArchitecture (or SOA) is a network of participant roles providing and
consuming services to fulfill a purpose. The services architecture defines the
requirements for the types of participants and service realizations that fulfill
those roles.
The services architecture puts a set of services in context and shows how
participants work together for a community or organization without required
process management.
A community ServicesArchitecture is defined using a UMLICTCollaboration.
Inside the Seller/Manufacturer
Order
Conformation
Shipped
Order Processing
Service
Accounting
Ship Req
Shipped
Delivered
ICT
ServiceContract
A ServiceContract defines the terms, conditions, interfaces and
choreography that interacting participants must agree to (directly or
indirectly) for the service to be enacted - the full specification of a
service which includes all the information, choreography and any
other “terms and conditions” of the service. A ServiceContract is
binding on both the providers and consumers of that service. The
basis of the service contract is also a UML collaboration that is
focused on the interactions involved in providing a service. A
participant plays a role in the larger scope of a ServicesArchitecture
and also plays a role as the provider or user of services specified by
ServiceContracts.
ICT
Service Contract
Service
Contract
Role
within
service
Role
within
service
Service
interface
corresponding
to role
Information
processed by order
processor
type
type
Service
interface
corresponding
to role
Information
received by
orderer
The service contract specifies the details of the service – what
information, assets and responsibilities are exchanged and
under what rules
ICT
Simple Protocol Choreography for Ordering Service Contract
Could also be specified in BPMN, in principle
ICT
Service Modelling with SoaML
Port/Connector models – extending
UML 2.0 composite structure
models
ICT
Service ports and Service Participants
A Service port s the offer of a service by one participant to others using well defined
terms, conditions and interfaces. A Service port defines the connection point through
which a Participant offers its capabilities and provides a service to clients.
A Service port is a mechanism by which a provider Participant makes available
services that meet the needs of consumer requests as defined by ServiceInterfaces,
Interfaces and ServiceContracts. A Service port is represented by a UML Port on a
Participant stereotyped as a «Service, .
ICT
ServiceInterface
a ServiceInterface can be
the type of a service port. The
service interface has the
additional feature that it can
specify a bi-directional service –
where both the provider and
consumer have responsibilities
to send and receive messages
and events. The service
interface is defined from the
perspective of the service
provider using three primary
sections: the provided and
required Interfaces, the
ServiceInterface class and the
protocol Behavior.
ICT
Participant with Service and Request ports
The type of a Request port is also a ServiceInterface, or UML
Interface, as it is with a Service port The Request port is the
conjugate of a Service port in that it defines the use of a service rather
than its provision. This will allow us to connect service providers and
consumers in a Participant.
- Can be transformed to appropriate interface/implementation
code.
ICT
Phases
Roles
SHAPE Service Variability Process
Overview
Provider
Design, Development,
Publication
Artefacts
Service Metamodel
extends
Variability Modelling &
Pre-Configuration
Service Variability Metamodel
extends
1:n
Variability Variability Service Variability Specification
Specification
Model
described by
Service Interface
© SAP 2009 / Page 27
Customization
& Personalization
according to
according to
according to
Service Model
Consumer
Domain Expert
resolves
1:n
Service Variant Model
described by
consistent & valid subset
Service Variant Interface
ICT
© SAP 2009 /
REuse and Migration of legacy
applications to Interoperable Cloud
Services
ICT
REMICS Overall process – The ADM, (Architecture
Driven Modernisation), “SEI” Horse shoe
ICT
REMICS Metamodel extensions
ICT
Model Evolution and Variability
ICT
31
Architecture model of a simple
database server
From article: Evolving Architectural Descriptions of
Critical Systems, Mens/Magee/Rumpe,
IEEE Computer, May 2010
ICT
32
Resemblance: Architecture
description of managed database
server
ICT
33
Replacement: Replacing the
Database component
ICT
34
CVL overview and terms
ICT
35
Applying CVL
ICT
36
ICT
37
SINTEF Variability modeling tool
ICT
38
DIVA Adaptation model
ICT
39
CVL RFP Timetable
ICT
40