simplengineeringService Oriented Architects                                                               ICSSEA 2010     ...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                               simpleSOAD® 2.0Service Orie...
simplengineering                                                                                simpleSOAD® 2.0Service Ori...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                                                          ...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                                                          ...
simplengineering                                                                                                          ...
simplengineering                                                                                               simpleSOAD®...
simplengineering                                                                                                          ...
simplengineering                                                                                                          ...
simplengineering                                                                                                          ...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
simplengineering                                                                             simpleSOAD® 2.0Service Orient...
Upcoming SlideShare
Loading in...5
×

simpleSOAD 2.0 Architecture and Governance

159

Published on

This presentation introduces the simpleSOAD® methodological framework for design and implementation of services and services architectures, founded upon a contract-based, model-driven (MDA) approach and the OMG standards. Contract-based service orientation is presented first. The service contract is a first-class object, is independent from the systems that endorse it, and acts as a functional and behavioral specification for these systems. Furthermore, the principles of application of the model-driven engineering approach to service design are given. A service contract is a layered set of models: BMM (motivational), BM (conceptual), PIM (logical) and Interoperability PSM (physical). They are all based upon largely accepted OMG standards. The service contract is designed top-down with the help of methods and tools of model mapping and transformation. The Implementation PSM of a system that intends to provide the service can be partially generated by the contract model. Future work will concern phases and activities of the SOA life cycle till now poorly covered, such as Validation &Verification, Test and Governance.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
159
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

simpleSOAD 2.0 Architecture and Governance

  1. 1. simplengineeringService Oriented Architects ICSSEA 2010 simpleSOAD® 2.0 Architecture & 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© simple engineering 2004 - 2010 – Some rights reserved. Maesano&DeRosa_2010_ICSSEA_sS_2_0_Archi&Gov
  2. 2. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Table of contents Business automation Functional specification Service orientation Platform Independent Contract-based Model Model-driven PI Functional Model Service contract PI Interaction Model Services architectures PI Sample Model Contract modeling Interoperability PSM Motivation model Implementation PSM Business model Conclusion© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 2
  3. 3. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & 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© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 3
  4. 4. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Service orientation System = 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© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 4
  5. 5. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Contract-based service orientation The 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 !)© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 5
  6. 6. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Model-driven Engineering A service contract is a layered set of formal models MDA Model Service Model Business Motivation Model (BMM) Service Motivational Model - Service Service contract BMM (BMM) Business Model (BM) or Service Conceptual Model – Service BM / Computationally Independent Model Service CIM (SBVR) (CIM) Platform Independent Model (PIM) Service Logical Model - Service PIM (UML 2, SoaML, QFTP, UML Testing Profile) Interoperability Platform Specific Service Physical Model(s) - Service Model (Interoperability PSM) Interoperability PSM Platforms: Web services, REST, (Web services platform: XSD, WSDL, CORBA,... UDDI, WS-SecurityPolicy, WSRM Policy, ...) Implementation Implementation Platform Specific System Physical Model(s) – System System Model (Implementation PSM) Implementation PSM Platforms: JEE, .NET, … Contract design = Modeling, model mapping and transformation© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 6
  7. 7. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance References BMM BMM Business Motivation Model Version 1.1 - OMG Document Number: formal/2010-05-01 - Standard document URL: http://www.omg.org/spec/BMM/1.1/ BM / SBVR Semantics of Business Vocabulary and Business Rules (SBVR), v1.0 - OMG Available CIM Specification - OMG Document Number: formal/2009-01-02 - Standard document URL: http://www.omg.org/spec/SBVR/1.0/PDF PIM UML 2 SoaML 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 QFTP UML™ 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 UMLTP UML Testing Profile - http://www.omg.org/technology/documents/formal/test_profile.htm© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 7
  8. 8. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & 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 ?© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 8
  9. 9. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Service Oriented Architecture Distributed 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© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 9
  10. 10. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance simpleSOAD® 2.0 Contract modeling Strong 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 Business Motiv ation Serv ice Motiv ational Modeling Model :BMM Serv ice Contract Modeling Business Modeling Platform Interoperability Implementation Independent Platform Specific Platform Specific Modeling Modeling Modeling Serv ice Contract Serv ice Conceptual Serv ice Logical Serv ice Physical System Physical Model :BM Model :PIM Model : Model : «map» «map» Interoperability «map» Implementation PSM PSM© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 10
  11. 11. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Motivational model IT 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© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 11
  12. 12. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Business Model The 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 Vocabulary concepts 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 sunt multiplicanda praeter necessitatem” (Occam‟s razor) Business rules structural vs. operational rules invariants, preconditions, postconditions, questions Business rule = a rule that is under business jurisdiction Business rules are not business routines© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 12
  13. 13. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance BM - Service functionality All services, as activities performed by a provider that engenders effects carrying value for a consumer, can be classified in two categories: State/transition services the service performance is a transition - valuable to the consumer - between states of resources managed by the provider Pure informative services delivery 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© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 13
  14. 14. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance BM Functional model State/transition service: contract clauses (precondition, postcondition) as SBVR business rules Supporting concepts (object types, roles, fact types) are defined in the service business vocabulary 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© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 14
  15. 15. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance BM Functional model (II) Pure informative service: contract clauses (question) as SBVR concepts Supporting concepts (object types, roles, fact types) are definied in the service business vocabulary 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 class BOM - sustainable v ocabulary First step: creation of the service vocabulary (body of shared account code date/time positiv e integer meanings) Business rules are stated on the +number basis of the vocabulary +code +date/time The service vocabulary is augmented, without semantic account w ithdraw al w ithdraw al state shift, with complementary +state formulations (sustainable is on conceptual model), to allow mapping to the service logical model (PIM) +state +balance +amount Examples of such complementary account state decimal formulations are the objectifications of n-ary (n > 2) fact types (ex.: withdrawal)© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 15
  16. 16. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Platform Independent Model Service Logical Model act Platform Independent Modeling Functional Interaction Security Modeling Quality of Serv ice Sample Modeling Modeling Modeling Modeling PI functional model from 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) model service conversation, interfaces, service interfaces, service choreography (SoaML + simpleSOAD® profile) PI security model security annotations on the functional and interaction models (QFTP + simpleSOAD® profile) PI quality of service model quality of service annotations on the functional and interaction models (QFTP + simpleSOAD® profile) PI sample model samples – cross-verification of the model – oracles (UMLTP + simpleSOAD® profile)© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 16
  17. 17. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance PI Functional model class Obj ect Types «ObjectType» «ObjectType» Object model from Account Withdraw al the sustainable «PropertyFactType» «PropertyFactType» vocabulary + code: AccountCode +account +withdrawal + number: PositiveInteger + dateTime: DateTime + balance: Real + state: AccountState 1 «FactType» 0..* + amount: Real + state: WithdrawalState OCL specification of IsOn tags service operation tags id = code id = Tuple{account=account.id(),number=number} state = state from business rules state = state State/transition “atomic” service: withdraw 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() result.balance = account.balance and account.balance = account.balance@pre - p.amount Pure informative “atomic” service: getBalance 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() in Tuple(balance = account.balance, now = Clock::now())© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 17
  18. 18. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Service conversation PI Interaction Model Ideally, service stm Withdraw Conv ersation WithdrawDeclined conversation passes through three phases: 1. Deliberation «Provider» declineWithdraw 2. Execution «Consumer» «ConversationState» Withdraw Requested «Provider» 3. Reporting requestWithdraw reportWithdraw WithdrawInitial tags WithdrawReported lease = withdrawRequestedMaxDuration «Timeout» Conversation pattern: «Provider» timeoutWithdrawRequestedMaxDuration withdrawWithdraw SynchronousRequest «Text» WithdrawWithdrawn w ithdraw RequestedMaxDuration : Duration 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, …© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 18
  19. 19. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Withdraw service PI Functional & Interaction Model composite structure Withdraw Serv ice Model «Conversation» «Choreography» Withdraw Choreography «Serv iceContract» Withdraw Conv ersation Withdraw Serv ice «Consumer» «Provider» :AccountHolder :Bank 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 = «interface» p.account)->asOrderedSet()->first() in BankInterface result.balance = account.balance and + requestWithdraw(RequestWithdraw, account.balance = account.balance@pre - p.amount RequestWithdrawError*) : void «use» «Consumer» «Provider» AccountHolder Bank «interface» AccountHolderInterface One functional model + declineWithdraw(DeclineWithdraw, «use» Several interaction models + DeclineWithdrawError*) : void reportWithdraw(ReportWithdraw, • Conversation patterns + ReportWithdrawError*) : void withdrawWithdraw(WithdrawWithdraw, • Exchange modes WithdrawWithdrawError*) : void • MessageTypes • Choreography© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 19
  20. 20. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance PI Sample model Fact 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© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 20
  21. 21. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & 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© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 21
  22. 22. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Implementation PSM Mechanical 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, …)© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 22
  23. 23. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Conclusion Today - 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 dInformatique de Paris 6 (LIP6) and the Centre National de la Recherche Scientifique (CNRS).© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 23
  24. 24. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & 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 2004 Jan L. G. Dietz: Enterprise ontology: theory and methodology; Springer, 2006 B. Meyer: Object-oriented software construction; Prentice Hall, 1997 G. M. Nijssen, T. A. Halpin: Conceptual schema and relational database design: a fact oriented approach; Prentice-Hall Inc. 1989 J. R. Searle: Speech Acts; Cambridge University Press, 1969 SIMPLE ENGINEERING - Stochastic Decision Aid for SOA Testing - Interim Report - R2010073101 SIMPLE ENGINEERING - simpleSOAD® 2.0 Reference Manual - R2010070101 T. Winograd, F. Flores: Understanding Computers and Cognition - A New Foundation for Design; Ablex Publishing Corporation, 1996© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 24
  25. 25. simplengineering simpleSOAD® 2.0Service Oriented Architects Architecture & Governance Thanks Questions ?© simple engineering 2004 - 2010 – Some rights reserved. Maesano & De Rosa – ICSSEA 2010 9/12/2010 - 25
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×