Post on 17-Nov-2014
description
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved.
simpleSOAD® 2.0Architecture & Governance
Paris, December 8, 2010
Libero Maesano & Fabio De Rosa
libero.maesano@simple-eng.com
fabio.de-rosa@simple-eng.com
22° International Conference on Software & Systems
Engineering and their Applications - Paris – Dec 7-9 2010
www.simple-eng.com
Maesano&DeRosa_2010_ICSSEA_sS_2_0_Archi&Gov
ICSSEA 2010
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 2
simpleSOAD® 2.0Architecture & Governance
Table of contents
Business automation
Service orientation
Contract-based
Model-driven
Service contract
Services architectures
Contract modeling
Motivation model
Business model
Functional specification
Platform Independent Model
PI Functional Model
PI Interaction Model
PI Sample Model
Interoperability PSM
Implementation PSM
Conclusion
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 3
simpleSOAD® 2.0Architecture & Governance
Business Automation
Tens, hundreds, thousands,… applications, systems, devices will be connected and will collaborate without human intermediation…
…allowing the automation of business processes that support daily activities
Dependability and security requirements will reach levels until now reserved to critical sectors
Current design methods and tools are challenged
Service orientation and Service Oriented Architecture are the breakthroughs
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 4
simpleSOAD® 2.0Architecture & Governance
Service orientationSystem = entity that interacts with other entities, i.e. other systems, including hardware, software, humans, organizations and the physical world (Avizienis et al. 2004)
A system has function, structure and behavior
Systems have boundaries:
internal vs. external (interface) structure
internal vs. external behavior
Service = activity performed by a system (provider) that engenders effects carrying value for another system (consumer)
Service = function + interface + external behavior
Service orientation is a design and implementation approach that separates
the service specification – function, interface and external behavior -from
the system(s) specification(s) – internal structure(s) and behavior(s) of the system(s) that provide (and consume) the service
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 5
simpleSOAD® 2.0Architecture & Governance
Contract-based service orientationThe service is fully described in a service contract
Avizienis et al. (2004) state: "correct service is delivered when the service
implements the system function"
Service orientation reverses this point of view: a system acts correctly if it provides – and consumes – services in compliance with the corresponding service contracts
Service contract = set of clauses detailing
Functionality (function)
Interaction between service parts (provider and consumer)
Security constraints
Quality of service constraints
The service contract doesn‟t include any specification of
Function, interface and external behavior outside its scope
Structure and internal behavior of the service parties
The service contract is a first-class object
Contract-first approach: the service contract definition precedes the system
design and implementation (even for legacy systems !)
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 6
simpleSOAD® 2.0Architecture & Governance
Model-driven Engineering
MDA Model Service Model
Serv
iceco
ntra
ct
Business Motivation Model (BMM) Service Motivational Model - Service
BMM (BMM)
Business Model (BM) or
Computationally Independent Model(CIM)
Service Conceptual Model – Service BM /
Service CIM (SBVR)
Platform Independent Model (PIM) Service Logical Model - Service PIM (UML
2, SoaML, QFTP, UML Testing Profile)
Interoperability Platform Specific
Model (Interoperability PSM)Platforms: Web services, REST,CORBA,...
Service Physical Model(s) - Service
Interoperability PSM(Web services platform: XSD, WSDL,UDDI, WS-SecurityPolicy, WSRM Policy,
...)
Syste
mIm
ple
menta
tion
Implementation Platform Specific
Model (Implementation PSM)Platforms: JEE, .NET, …
System Physical Model(s) – System
Implementation PSM
A service contract is a layered set of formal models
Contract design = Modeling, model mapping and transformation
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 7
simpleSOAD® 2.0Architecture & Governance
References
BMM BMMBusiness Motivation Model Version 1.1 - OMG Document Number: formal/2010-05-01 - Standard document URL: http://www.omg.org/spec/BMM/1.1/
BM / CIM
SBVRSemantics of Business Vocabulary and Business Rules (SBVR), v1.0 - OMG Available Specification - OMG Document Number: formal/2009-01-02 - Standard document URL: http://www.omg.org/spec/SBVR/1.0/PDF
PIM UML 2SoaML
Service oriented architecture Modeling Language (SoaML) - Specification for the UML Profile and Metamodel for Services (UPMS) - OMG Adopted Specification -Finalisation Task Force Beta 2 document (FTF Beta 2) - OMG Document Number: ptc/2009-12-10 - Standard document URL: http://www.omg.org/spec/SoaML/20091101
QFTPUML™ Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms Specification - Version 1.1 - OMG Document Number: formal/2009-04-05 - Standard document URL: http://www.omg.org/spec/QFTP/1.1/PDF
UMLTPUML Testing Profile -http://www.omg.org/technology/documents/formal/test_profile.htm
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 8
simpleSOAD® 2.0Architecture & Governance
Service models
Service models are contracts
The Motivation Model is formulated by business strategists and can be understood and validated by high level management (thanks to BMM)
The BM/CIM is created by business analysts and can be understood and validated by business people (thanks to SBVR)
PIM is built by architects, from the BM, is cross-validated by business analysts and can be understood by implementers
PSM‟s (Interoperability and Implementation) are crafted by technical architects and engineers from the PIM
Service contract models are shared between parties
System constructive (implementation) models are private to parties
What about model mapping and transformation ?
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 9
simpleSOAD® 2.0Architecture & Governance
Service Oriented ArchitectureDistributed architecture design and implementation approach …
… in which the collaboration among systems is carried out through the exchange of services governed by contracts
A services architecture is a network of roles, connected by service contracts, enacted by participants, i.e. classes of systems that collaborate in order to achieve business goals
Each role is the result of the composition of the parts of the service contracts it plays (as a provider or as a consumer)
The specification of the functions, interfaces and external behaviors of a participant is the union of the service contracts it endorses (as a provider and as a consumer)
A participant is the class of system implementations that are compliant with the specified functions, interfaces and external behaviors
Business Automation enabler
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 10
simpleSOAD® 2.0Architecture & Governance
simpleSOAD® 2.0 Contract modelingStrong contract-based, model-driven service orientation
Methodological framework developed by simple engineering since 2004
Applied in manufacturing, railways, government … projects
simpleSOAD® 2.0: full adoption of OMG emerging standards - BMM, SBVR, UML 2,
SoaML, QFTP, UMLTP
simpleSOAD® 2.0 Profile and Metamodel extends and specializes the standards
analysis Serv ice Contract Modeling
Serv ice Contract
Serv ice Contract Modeling
Platform
Independent
Modeling
Interoperability
Platform Specific
Modeling
Business
Motiv ation
Modeling
Business Modeling
Serv ice Motiv ational
Model :BMM
Serv ice Conceptual
Model :BM
Serv ice Logical
Model :PIM
Serv ice Physical
Model :
Interoperability
PSM
Implementation
Platform Specific
Modeling
System Physical
Model :
Implementation
PSM
«map»«map» «map»
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 11
simpleSOAD® 2.0Architecture & Governance
Motivational modelIT systems are no more a posteriori designed supports of an a priori established business model
The mere adoption of the service orientation modifies the business practices
Motivational analysis allows to elicit and formalize (thanks to BMM and SBVR) the WHY of a service for the parties
Means-ends analysis – means-ends model (of the parties and of the service)
ends that motivate means
Impact analysis of business events (new regulations, changes in the environment, strategic change…) - upon the established means-ends model
events that motivate changes in the means-ends model
Bargaining and cooperative games equilibrium
The updated means model is the starting point of the design cycle
Motivation modeling is the fulcrum of the governance cycle
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 12
simpleSOAD® 2.0Architecture & Governance
Business ModelThe Business Model (Computationally Independent Model) is a declarative formal service model expressed in structured natural language (SBVR)
On the basis of a body of shared meanings, represented by a business vocabulary, it allows to enounce service functional clauses as business rules
Vocabularyconcepts and terms - object types, roles, fact types
Capturing the service “linguistic game” (Wittgenstein)
Fixing concepts: “Don‟t ask for the meaning, ask for the use” (Wittgenstein)
Making the conceptual body as simple as possible -“Entia non suntmultiplicanda praeter necessitatem” (Occam‟s razor)
Business rulesstructural vs. operational rulesinvariants, preconditions, postconditions, questions
Business rule = a rule that is under business jurisdiction
Business rules are not business routines
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 13
simpleSOAD® 2.0Architecture & Governance
BM - Service functionalityAll services, as activities performed by a provider that engenders
effects carrying value for a consumer, can be classified in two categories:
State/transition servicesthe service performance is a transition - valuable to the consumer - between states of resources managed by the provider
Pure informative servicesdelivery of valuable information by the provider to the consumer, without any state change
Functional description
State/transition service: operation, precondition, postcondition(thanks to B. Meyer “Design by Contract”)
Pure informative service: question
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 14
simpleSOAD® 2.0Architecture & Governance
BM Functional model
It is obligatory that a withdrawal that is on an account is accepted at a date/time if and only if the state of the account at the date/time equals Active
and the balance of the account at the date/time is greater than the amount of the withdrawal
Guidance Type: operative business rule
Note: withdrawal precondition
Supporting fact types: withdrawal is on account
withdrawal has amount
withdrawal is accepted at date/time
account has state at date/time
account has balance at date/time
amount[1] is greater than amount[2]
Supporting noun concepts: account withdrawal balance amount date/time Active
It is obligatory that if a withdrawal that is on an account is executed at a date/time[1] then the balance of the account at a date/time[2] that is
immediately after the date/time[1] equals the balance of the account at the date/time[1] minus the amount of the withdrawal
Guidance Type: operative business rule
Note: withdrawal postcondition
Supporting fact types: withdrawal is on account
withdrawal has amount
withdrawal is executed at date/time
account has balance at date/time
amount[1] equals amount[2]
date/time[1] is immediately after date/time[2]
Supporting noun concepts: account withdrawal balance amount date/time
State/transition service: contract clauses (precondition, postcondition) as SBVR business rulesSupporting concepts (object types, roles, fact types) are defined in the service business vocabulary
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 15
simpleSOAD® 2.0Architecture & Governance
BM Functional model (II)
Get Balance
General concept: question
Closed projection: What balance is of the account at the date/time
Supporting fact type: account has balance at date/time
Supporting noun concepts: account balance date/time
Pure informative service: contract clauses (question) as SBVR conceptsSupporting concepts (object types, roles, fact types) are definied in the service business vocabulary
First step: creation of the service vocabulary (body of shared meanings)
Business rules are stated on the basis of the vocabulary
The service vocabulary is augmented, without semantic shift, with complementary formulations (sustainable conceptual model), to allow mapping to the service logical model (PIM)
Examples of such complementary formulations are the objectifications of n-ary (n > 2) fact types (ex.: withdrawal)
class BOM - sustainable v ocabulary
withdrawal statewithdrawal
date/time
account
account code
decimal
positiv e integer
account state
+date/time
+number
is on
+amount
+state
+code
+balance+state
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 16
simpleSOAD® 2.0Architecture & Governance
Platform Independent Model
PI functional modelfrom the sustainable vocabulary to the object model (UML 2 + simpleSOAD® profile)from the business rules (service clauses) to operation signatures with OCL preconditions, postconditions (state/transition) and bodies (pure informative)
PI interaction (interface + external behavior) modelservice conversation, interfaces, service interfaces, service choreography (SoaML + simpleSOAD® profile)
PI security modelsecurity annotations on the functional and interaction models (QFTP + simpleSOAD® profile)
PI quality of service modelquality of service annotations on the functional and interaction models (QFTP + simpleSOAD® profile)
PI sample modelsamples – cross-verification of the model – oracles (UMLTP + simpleSOAD® profile)
act Platform Independent Modeling
Functional
Modeling
Interaction
Modeling
Security Modeling Quality of Serv ice
Modeling
Sample Modeling
Service Logical Model
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 17
simpleSOAD® 2.0Architecture & Governance
PI Functional model
context Bank::withdraw(p: TupleType(account:AccountCode, amount:Decimal)) : TupleType(number:PositiveInteger, dateTime:DateTime, balance:Decimal)
pre: let accountInSet = Account.allInstances()->select(a | a.code = p.account) inif accountInSet->notEmpty() then let account = accountInSet->asOrderedSet()->first() in
account.state = „active‟ and account.balance > p.amountelse false endifpost: let account = Account.allInstances()->select(a | a.code = p.account)->asOrderedSet()->first()
result.balance = account.balance andaccount.balance = account.balance@pre - p.amount
context Bank::getBalance(p:AccountCode) : TupleType(balance:Decimal, now:DateTime)pre: Account.allInstances()->collect(code)->includes(p)body: let account = Account.allInstances()->select(a | a.code = p)->asOrderedSet()->first() inTuple(balance = account.balance, now = Clock::now())
Pure informative “atomic” service: getBalance
State/transition “atomic” service: withdraw
Object model from the sustainable vocabulary
OCL specification of service operation from business rules
class Object Types
«ObjectType»
Account
«PropertyFactType»
+ code: AccountCode
+ balance: Real
+ state: AccountState
tags
id = code
state = state
«ObjectType»
Withdrawal
«PropertyFactType»
+ number: PositiveInteger
+ dateTime: DateTime
+ amount: Real
+ state: WithdrawalState
tags
id = Tuple{account=account.id(),number=number}
state = state
+withdrawal
0..*
IsOn
«FactType»
+account
1
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 18
simpleSOAD® 2.0Architecture & Governance
Service conversation
simpleSOAD® interaction patterns - thanks to Winograd & Flores (1986)
Communicative act patterns (performative verbs)
request, decline, undertake, report, query, inform, …
Conversation patterns (StateMachines)SynchronousRequest, SynchronousDeferredRequest, ConversationForAction, SynchronousQuery, …
stm WithdrawConv ersation
WithdrawInitial
«ConversationState»
WithdrawRequested
tags
lease = withdrawRequestedMaxDuration
WithdrawDeclined
WithdrawWithdrawn
WithdrawReported
«Text»
withdrawRequestedMaxDuration :
Duration
requestWithdraw
«Consumer»
declineWithdraw
«Provider»
withdrawWithdraw
«Provider»timeoutWithdrawRequestedMaxDuration
«Timeout»
reportWithdraw«Provider»
PI Interaction Model
Ideally, service conversation passesthrough three phases:1. Deliberation2. Execution3. Reporting
Conversation pattern:SynchronousRequest
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 19
simpleSOAD® 2.0Architecture & Governance
Withdraw servicePI Functional & Interaction Model
One functional modelSeveral interaction models
• Conversation patterns• Exchange modes• MessageTypes• Choreography
composite structure Withdraw Serv ice Model
«Provider»
Bank
«Consumer»
AccountHolder
«Serv iceContract»
WithdrawServ ice
«Consumer»
:AccountHolder
«Provider»
:Bank
«interface»
BankInterface
+ requestWithdraw(RequestWithdraw,
RequestWithdrawError*) : void
«interface»
AccountHolderInterface
+ declineWithdraw(DeclineWithdraw,
DeclineWithdrawError*) : void
+ reportWithdraw(ReportWithdraw,
ReportWithdrawError*) : void
+ withdrawWithdraw(WithdrawWithdraw,
WithdrawWithdrawError*) : void
context Bank::withdraw(p: TupleType(account:AccountCode, amount:Decimal)) :
TupleType(number:PositiveInteger, dateTime:DateTime, balance:Decimal)
pre: let accountInSet = Account.allInstances()->select(a | a.code = p.account) in
if accountInSet->notEmpty()
then let account = accountInSet->asOrderedSet()->first() in
account.state = 'active' and account.balance > p.amount
else false endif
post: let account = Account.allInstances()->select(a | a.code =
p.account)->asOrderedSet()->first() in
result.balance = account.balance and
account.balance = account.balance@pre - p.amount
«Conversation»
WithdrawConv ersation«Choreography»
WithdrawChoreography
«use»
«use»
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 20
simpleSOAD® 2.0Architecture & Governance
PI Sample modelFact model
Thanks to Nijssen & Halpin (1989), the object model is mechanically transformed (one shot) into a 5th normal form relational model
Fact (relational) bases are populated with facts of “possible worlds”
Samples : instances of service performance
A sample is:
A fact base representing the state before the service performance
An interaction diagram representing an instance of the conversation
The corresponding set of MessageType instances
Samples are:
Functional checking samples(the fact base verifies the precondition)
Robustness checking samples(the fact base does not verify the precondition)
Security checking samples
…
Samples are PIM first-class objects
Samples are templates for test cases
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 21
simpleSOAD® 2.0Architecture & Governance
Interoperability PSM Interoperability platforms: Web services, REST, CORBA, RMI,…
Mechanical generation of XSD from MessageTypes
Mapping of service interface to WSDL
Mapping of security QFTP annotations to WS-SecurityPolicy
Mapping of message reliability QFTP annotations to WSRM Policy
Mapping of services architectures to UDDI V3 data structures
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 22
simpleSOAD® 2.0Architecture & Governance
Implementation PSMMechanical transformation of the object model to Java & C# class models
Mapping of the object model to relational model
Class model automatic persistence (with Hibernate, Nhibernate and other frameworks)
Library of service wrapper/adapter patterns, covering a very large spectrum of legacy system architectures
Mapping to standard frameworks (Axis 2, …)
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 23
simpleSOAD® 2.0Architecture & Governance
ConclusionToday - simpleSOAD® 2.0
Contract-based, model-driven, service oriented methodological framework
Simple, straight, quick and complete design approach based upon standards
Tomorrow - Research project: Stochastic decision aid for SOA testing
In the contract-based, model-driven, service oriented approach the validation question ("Are you building the right system?") becomes: "Are you modeling the right service contract?“…
… and the verification question ("Are you building the system right?") becomes: "Are you building a system compliant with the contract?".
We are focusing our attention on system verification – i.e. black-box testing of participants and grey-box testing of services architectures
The starting point is the availability of service samples from the design phase that act as templates for test oracles
We are looking for automated test environments (test definition and execution) for SOA testing – TTCN–3 is a strong candidate
We are designing and developing a decision aid tool helping to optimize the testing strategy (“What is the next test?”) based upon stochastic reasoning and inference, in
partnership with the Laboratoire d'Informatique de Paris 6 (LIP6) and the Centre
National de la Recherche Scientifique (CNRS).
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 24
simpleSOAD® 2.0Architecture & Governance
Bibliography
A. Avizienis, Jean-Claude Laprie, B. Randell, and C. Landwehr: Basic Concepts and Taxonomy of Dependable and Secure Computing; IEEE Trans. on dependable and secure computing, Vol. 1, No. 1 January-March 2004Jan L. G. Dietz: Enterprise ontology: theory and methodology; Springer, 2006B. Meyer: Object-oriented software construction; Prentice Hall, 1997G. M. Nijssen, T. A. Halpin: Conceptual schema and relational database design: a fact oriented approach; Prentice-Hall Inc. 1989J. R. Searle: Speech Acts; Cambridge University Press, 1969SIMPLE ENGINEERING - Stochastic Decision Aid for SOA Testing - Interim Report - R2010073101SIMPLE ENGINEERING - simpleSOAD® 2.0 Reference Manual - R2010070101T. Winograd, F. Flores: Understanding Computers and Cognition - A New Foundation for Design; Ablex Publishing Corporation, 1996
simplengineeringService Oriented Architects
© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 25
simpleSOAD® 2.0Architecture & Governance
Thanks
Questions ?