• Like
SOA_Ch3.ppt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,087
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
41
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 介绍一个流程
  • 对顶级流程的分解,发现所有的服务候选者 强调顶级流程 重点分析创建帐户的流程,仅仅是为了详细解释整个过程
  • 业务目标的分解,验证前面发现的服务候选者。 更加重要的是,可能会发现遗漏的服务
  • 结合上面三个步骤的结果,结合服务暴露的决定(重用性、具备明确的业务语义、有明确的业务规则、可组合成新的业务逻辑)
  • 介绍服务建模与流程建模是一个迭代的过程,服务的发现和规约出来以后,可以最后确定流程建模 业务数据:可以从企业的 Data Model 导入 业务流程 组织结构:映射企业的组织结构到 IT 建模工具,确保模型的真实有效 业务监控模型:定义关键业务指标,以及度量关键业务指标的方式,在运行和管理阶段利用这些模型,保证建模、执行、管理的一致性
  • 既然定义了组织结构,每个任务的执行者,抑或是系统、抑或是人工,以及这些资源的成本,我们可以进行有效的流程模拟 发现流程的瓶颈 分析流程的运行成本,确保有效的资源配置 好处:在部署以前发现流程的问题

Transcript

  • 1. Service-Oriented Analysis and Modeling Xiaoying Bai Department of Computer Science and Technology Tsinghua University March 2007
  • 2. Outline
    • Model Driven Architecture
    • Service-Oriented Analysis and Modeling: Methods and Process
    • CASE tool: IBM WebSphere
    • Case study
  • 3. Service-Centered System Development SOA Project Team Service Registry Service Submission Service Audit Center Of Excellence Deployment & Governance Implementation & Composition Analysis & Modeling SOA Planning and Governance SOA Values 0 Modeling 2 Design 3 Development 4 Integration 5 Deployment & Management 6 Monitoring 1 Service Reuse System Reconfiguration Service Change Management
  • 4. IBM Foundation Architecture
  • 5. Model Driven Architecture
  • 6. Modeling Motivations
    • Varieties of Platforms
      • Varieties of Hardware Architecture
        • Pentium, PowerPC, PA-RISC, Sparc, 370, …
      • Variety of Networks
        • Ethernet, ATM, IP, SS7, Applealk, USB, Firewire, …
      • Variety of Programming Languages
        • C/C++. Java, VB, C#,…
      • Variety of Operating Systems
        • Unix, Windows, NT/XP. Mainframe, Mobile, …
      • Variety of Middlewares
        • JAVA/CORBA, COM+/.NET, Web Services, ….
  • 7. Modeling Motivations
    • Integration challenges
      • Integration across middleware
      • System design across middleware
    H/W OS App. H/W OS App. H/W OS App. H/W OS App. Middleware H/W OS App. H/W OS App. H/W OS App. H/W OS App. Middleware H/W OS App. H/W OS App. H/W OS App. H/W OS App. Middleware
    • Cross Middleware
    • Integration
    • System Design
  • 8. Modeling Motivations
    • To allow definition of machine-readable application and data models which allow long-term flexibility of
      • Implementation
        • New implementation infrastructure can be integrated or targeted by existing designs
      • Integration
        • Automate the production of data integration bridges and the connection to new integration infrastructures
      • Maintenance
        • The design is available in a machine-readable form
      • Testing and simulation
        • The developed models can be validated against requirements, tested against various infrastructures and can used to directly simulate the behavior of the system being designed.
  • 9. Role of Models
    • Capture design information that is usually absent from code and lost during development
    • Basis for
      • System generation
      • Analysis
      • Simulation
      • Test generation
      • Documentation generation
      • … .
    • Domain-specificity of a modeling language strengthens its capabilities for generation, optimization, early error detection, etc.
  • 10. OMG Modeling Activities
    • 1989: OMG established
    • Standardization of Distributed Object Middleware
      • 1995: CORBA 2; 2002: CORBA 3
    • Modeling Standardization
      • 1997: UML (Unfied Modeling Language)
      • 1997: MOF (Meta Object Facility)
      • 1999: XMI (XML Metadata Interchange)
      • 2001: Application-Specific UML Profiles (EDOC, EAI)
    • Architecture (Reference Model)
      • 1990: OMA (Object Management Architecture)
      • 2001: MDA (Model Driven Architecture)
    • 2001-: starting standardization based on MDA
  • 11. OMG Modeling Standards
    • UML: Unified Modeling Language
      • Address the modeling of architecture, objects, interactions between objects, data modeling aspects as well as the design aspects including construction and assemble.
    • XMI: XML Metadata Interchange
      • A standard interchange mechanism used between various tools, repositories and middleware.
    • MOF: Meta Object Facility
      • Provides the standard modeling and interchange constructs.
    • MDA: Model Driven Architecture
      • Build upon and leveraging the value of OMG’s established modeling standards
      • Can be realized using any major open or proprietary platform, including CORBA, Java, .NET, XMI/XML, and Web-Based platforms.
  • 12. OMG Model-Driven Architecture
    • Provides an open, vendor-neutral approach to the challenge of business and technology change.
    • Separates the specification of the operation of a system from the details of the way that system uses the capabilities of its platform
    • Provides an approach for, and enables tools to
      • Specify a system independently of the platform that supports it
      • Specify platforms
      • Choose a particular platform for the system, and
      • Transform the system specification into one for a particular platform
    • The goals
      • Portability, Interoperability, Reusability through Architectural Separation of Concerns
  • 13. MDA in the Context
  • 14. MDA Models
    • CIM: Computation Independent Model
      • A computation independent view of the system
      • Articulates the requirements, but hides the details of implementation and system implementation
      • Bridges the gap between domain experts and technology experts
    • PIM: Platform Independent Model
      • A platform independent view of the system
      • Exhibits a sufficient degree of independence so as to enable its mapping to one or more platforms
      • Achieved by defined a set of services in a way that abstracts technical details.
    • PSM: Platform Specific Model
      • A platform specific view of the system
      • Combines the specifications in PIM with the details that specify how that system uses a particular type of platform
    CIM PIM PSM
  • 15. Model Transformation
    • Model transformation is the process of converting one model to another model of the same system.
      • Marking
      • Metamodel Transformation
      • Model Transformation
      • Pattern Application
      • Model Merging
    CIM PIM PSM Transformation
  • 16. The MDA Story Platform Independent Model (PIM) Implementation In EJB ebXML message Definition Bridge Platform Specific Model (PSM) In ebXML Platform Specific Model (PSM) In CORBA
  • 17. Impact of MDA on the Development Process Mostly text Diagram & text Diagram & text code code Iterative Process Programmer’s shortcut Traditional Lifecycle Process MDA Lifecycle Process CIM PIM PSM code code MDA Process Requirement Analysis Desing Coding Testing Deployment Requirement Analysis Desing Coding Testing Deployment
  • 18. Benefits of MDA
    • Preserving the investment in knowledge
      • Independent of implementation platform
      • Tacit knowledge made explicit
    • Speed of development
      • Most of the implementation is generated
    • Quality of implementation
      • Experts provides transformation templates
    • Maintenance and documentation
      • Design and analysis models are not abandoned after writing
      • 100% traceability from specification to implementation
  • 19. Service-Oriented Analysis and Modeling: Method and Process
  • 20. The SOA Layers
  • 21. The SOA Layers
    • Layer 1: Operational systems layer
      • Existing custom built applications, called legacy systems
        • CRM and ERP packaged applications
        • older object-oriented system implementations,
        • business intelligence applications.
      • To leverage existing systems and integrate them using service-oriented integration techniques.
    • Layer 2: Enterprise components layer
      • Enterprise components that are responsible for realizing functionality and maintaining the QoS of the exposed services.
      • Managed, governed set of enterprise assets that are funded at the enterprise or the business unit level.
      • T typically uses container-based technologies such as application servers to implement the components, workload management, high-availability, and load balancing.
  • 22. The SOA Layers
    • Layer 3: Services layer.
      • The services the business chooses to fund and expose
      • Can be discovered or be statically bound and then invoked, or possibly, choreographed into a composite service.
      • Mechanism to take enterprise scale components, business unit specific components, and in some cases, project-specific components, and externalizes a subset of their interfaces in the form of service descriptions.
      • Provide service realization at runtime using the functionality provided by their interfaces.
      • Exist in isolation or as a composite service.
    • Level 4: Business process composition or choreography layer
      • Services are bundled into a flow through orchestration or choreography, and thus act together as a single application.
      • These applications support specific use cases and business processes.
  • 23. The SOA Layers
    • Layer 5: Access or presentation layer.
      • SOA decouples the user interface from the components, the layer provides an access channel to a service or composition of services.
    • Level 6: Integration (ESB).
      • Enables the integration of services through the introduction of a reliable set of capabilities, such as intelligent routing, protocol mediation, and other transformation mechanisms, often described as the ESB.
    • Level 7: QoS.
      • The capabilities required to monitor, manage, and maintain QoS such as security, performance, and availability.
      • A background process through sense-and-respond mechanisms and tools that monitor the health of SOA applications.
  • 24. Service-Oriented Modeling & Analysis
    • Modeling, analysis, design techniques and activities to define the foundations of a SOA.
      • Define the elements in each of the SOA layers
      • Make critical architectural decisions at each level.
      • Hybrid approach
        • Top-down: business driven
        • Bottom-up: leverage legacy investments
    Software Skills & Support
  • 25. Why OOAD, BPM, EA are not enough OOAD: Object-Oriented analysis & Design BPM: Business Process Modeling EA: Enterprise Architecture Service-Oriented Modeling & Analysis
  • 26. Why OOAD, BPM, EA are not enough
    • OOAD
      • low level of granularity at the class level
      • low level of abstraction for business service modeling
      • Strong associations such as inheritance, resulting in tight coupling (and, consequently, a dependency) between the involved parties
    • BPM
      • a fragmented discipline in which there are many different styles, notations, and assets.
    • EA
      • No business-level process or service view
      • Generic architecture, and do not reach down to the design domain; a fundamental gap between enterprise and solution architectures
  • 27. Why OOAD, BPM, EA are not enough Object-Oriented Class Layer Component Layer Service Layer Component-Oriented Service-Oriented
  • 28. Why OOAD, BPM, EA are not enough Vacancy Component Application Component Emp. Record Component Career Component Recruitment Service Employee Service Recruitment Employee Manage Employees Human Resources Functional Domain Software Component Business Process Business Services Software Services Business Layer Service Layer Component Layer
  • 29. Service-Oriented Modeling & Analysis: Roles & Activities Service Identification Service Categorization Service Exposure Decisions Choreography Or Composition Quality of service Customer View Component Identification Service Allocation to Components Component Specification Layering the Component Service realization Technical Prototyping Service Management Product selection Standards implementation Architectural Decisions (state, flow, Dependencies) Provider View
  • 30. SOA Design Principles
    • Service categorization and aggregation
    • Policies and aspects
    • Process: meet-in-the-middle
    • Broking
  • 31. Service-Oriented Modeling & Analysis: Method & Process Domain Decomposition Goal-Service Modeling Existing System Analysis Component Flow specification Information specification Subsystem Analysis Component specification Service Flow specification Message & event specification Service realization decisions Service allocation to components Component layer Identification Specification Realization Service specification
  • 32. Service Identification
    • Identifies services through
      • Domain decomposition (Top down analysis)
      • Existing system analysis (Bottom up analysis)
      • Goal service modeling
    Domain Decomposition Goal-Service Modeling Existing System Analysis Service Repository Top-Down Analysis Bottom-Up Analysis Align Service with Business Goals Identification Specification Realization
  • 33. Service Identification
    • Top-down
      • Blueprint of business use cases provides the specification for business services
      • Domain decomposition: decompose of the business domain into its functional areas and subsystems
        • Flow or process decomposition into processes, sub-processes, and high-level business use cases
        • Use cases are good candidates for business services
          • Exposed at the edge of the enterprise
          • Within the boundaries of the enterprise across lines of business
    Domain Decomposition Goal-Service Modeling Existing System Analysis Component Flow specification Information specification Subsystem Analysis Component specification Service Flow specification Message & event specification Service realization decisions Service allocation to components Component layer Identification Specification Realization Service specification
  • 34. Service Identification
    • Bottom-up
      • Process or existing system analysis
      • Existing systems are analyzed and selected as viable candidates for providing lower cost solutions to the implementation of underlying service functionality that supports the business process
      • Analyze and leverage API’s, transactions, and modules from legacy and packaged applications.
      • Componentization of the legacy systems is needed to re-modularize the existing assets for supporting service functionality
    Domain Decomposition Goal-Service Modeling Existing System Analysis Component Flow specification Information specification Subsystem Analysis Component specification Service Flow specification Message & event specification Service realization decisions Service allocation to components Component layer Identification Specification Realization Service specification
  • 35. Service Identification
    • Middle-Out
      • Goal-service modeling
        • Identify Goals and Sub-Goals
        • Identify Services for Sub-goals
        • Identify key performance indicators & metrics for sub-goals and services
    Domain Decomposition Goal-Service Modeling Existing System Analysis Component Flow specification Information specification Subsystem Analysis Component specification Service Flow specification Message & event specification Service realization decisions Service allocation to components Component layer Identification Specification Realization Service specification
  • 36. Service Specification
    • Service categorization
    • Service flow specification
    • Message and events specification
    • Subsystem analysis
    • Component specification
    Identification Specification Realization
  • 37. Service Specification
    • Service Classification or Categorization
      • Classify services into a service hierarchy, reflecting the composite or fractal nature of services
        • Services can and should be composed of finer-grained components and services.
        • Classification helps determine composition and layering, as well as coordinates building of interdependent services based on the hierarchy.
        • Alleviate the service proliferation syndrome
    Domain Decomposition Goal-Service Modeling Existing System Analysis Component Flow specification Information specification Subsystem Analysis Component specification Service Flow specification Message & event specification Service realization decisCions Service allocation to components Component layer Identification Specification Realization Service specification
  • 38. Service Specification
    • Subsystem Analysis
      • Specify the interdependencies and flow between the subsystems.
      • Identify the exposed services on the subsystem interface based on use cases identified during domain decomposition
      • Create subsystem internal design models
      • Identify the implementation construct of large-grained components realizing the services
    Domain Decomposition Goal-Service Modeling Existing System Analysis Component Flow specification Information specification Subsystem Analysis Component specification Service Flow specification Message & event specification Service realization decisCions Service allocation to components Component layer Identification Specification Realization Service specification
  • 39. Service Specification
    • Component Specification
      • Specify the details of the component that implement the services
        • Data
        • Rules
        • Services
        • Configurable profile
        • Variations
      • Specify and manage the messaging and events
    Domain Decomposition Goal-Service Modeling Existing System Analysis Component Flow specification Information specification Subsystem Analysis Component specification Service Flow specification Message & event specification Service realization decisions Service allocation to components Component layer Identification Specification Realization Service specification
  • 40. Service Realization
    • Decision making of service realization approach
    • Allocation services to components
    • Allocation components to SOA layers
    Identification Specification Realization
  • 41. Service Realization
    • Service Allocation
      • Assign the services to the subsystems that have been identified so far, which have enterprise components that realize their published functionality.
      • Assign the services and the components that realize them to the SOA layers.
        • Documentation and resolution of key architectural decisions
          • The application architecture
          • The technical operational architecture
          • Designed and used to support the SOA realization at runtime.
    Domain Decomposition Goal-Service Modeling Existing System Analysis Component Flow specification Information specification Subsystem Analysis Component specification Service Flow specification Message & event specification Service realization decisions Service allocation to components Component layer Identification Specification Realization Service specification
  • 42. Service Realization
    • Service Realization Decision
      • Realize services and components, choose from realization alternatives
        • selected from existing library
        • custom built
        • Integration
        • transformation
        • subscription and outsourcing
      • Other realization decisions for services other than business functionality include: security, management and monitoring of services.
    Domain Decomposition Goal-Service Modeling Existing System Analysis Component Flow specification Information specification Subsystem Analysis Component specification Service Flow specification Message & event specification Service realization decisions Service allocation to components Component layer Identification Specification Realization Service specification
  • 43. CASE Tool: IBM WebSphere
  • 44. IBM WebSphere Integration Reference Architecture Business Application Services Process Services Information Services Development Services Interaction Services Partner Services Connectivity Services Business Innovation and Optimization Services Architect Developer Dashboards Portlets Business Processes Data Models Partner Profiles App Components Adapters Application & Information Assets IT Services Management WebSphere Business Modeler Rational/WebSphere Tools Tester Business Analyst Integration Developer
  • 45. WebSphere Business Modeler
    • A business process modeling tool that
      • model, design, analyze and generate reports for business processes
      • integrate new and revised workflows
      • define organizations, resources, and business items
    • Objectives
      • Documenting existing procedures
      • Determining requirements for staff, systems, and facilities
      • Planning changes to existing processes and systems
      • Testing and analyzing existing and proposed processes
  • 46. Business Modeling
    • Model, simulate, and measure business processes
      • Process modeling
      • Business item modeling
      • Resource modeling
      • Organization modeling
      • Structure modeling
      • Analysis
      • Process simulation
  • 47. Business Modeling Modes
    • Basic Business Modeling mode
      • business analyst , high-level view of a business process model.
      • Create and display sequence flows
    • Intermediate Business Modeling mode
      • More technically focused user
      • Specify and view additional details of process and data models.
        • For example, business rules and logic, data attributes.
    • Advanced Business Modeling mode
      • Most comprehensive level of detail for process models and data models.
      • Models that will be used as the basis for software applications.
        • For example, invocation characteristics, static fields, instance correlations, and a larger set of simulation parameters.
  • 48. Business Item Modeling
    • Any business document, work product, or commodity that is used for a particular business operation.
    • Anything that is created, assembled, inspected, tested, modified, or worked upon.
    • Business items can also undergo changes as they are passed from one step to the next in the process models.
      • For example, a customer order could be specified as open, working, verified, and finally closed as it is passed from task to task in a particular process model.
  • 49. Resource Modeling
    • Model each of the company's resources, such as employees, computers, vehicles, or electricity.
    • Any person, equipment, or material used to perform a task or a project can be represented and used in the process models.
    • Depending on the level of complexity required in the process models, one can also specify roles, costs, and timetables for the resources.
  • 50. Process Modeling
    • Business Process Diagram
      • Processes describe a sequence of tasks and processes linked by connectors.
      • A process can contain multiple branching paths based on decisions made during the process execution.
      • A process can also contain sub-processes.
    • Two modeling modes
      • The free-form layout: maximum flexibility to arrange the process diagrams.
      • The swimlane layout: arranges elements in rows according to characteristics that you specify, such as organization unit, location, resource definition, role or classifier.
  • 51. Business Process Model Task Decision Branches Merge Stop Task Classification
  • 52. WebSphere Business Modeler Project Tree Outline View Process Editor Attribute View
  • 53. Case Study
  • 54. 汽 车 贷 款 流 程
  • 55. SOA Values 业务目标 SOA 价值 现有问题 降低成本 降低欺诈风险 建立集中的企业服务总线,屏蔽具体的服务实现,保持 IT 系统的柔性 流程自动化,提供实时的流程监控和管理 客户专员获取客户历史记录,然后人工计算风险等级 由于各地的业务差别,计算风险等级的政策不一致 在申请过程中,客户以及客户代表无法了解申请进度并及时反馈 引入业务规则作为服务实现方式,保证系统灵活性的同时,提高工作效率
  • 56. Modeling Inputs Business Components Business Goal Business Process
  • 57. Business Process Decomposition 1.1 存款 0 存贷款流程 1.2 汽车贷款 1.2.1 申请贷款 1.2.2 确认申请 1.2.3 评估信用等级 1.2.4 核定期限 1.2.5 审批 1.2.6 担保 1.2.7 发放贷款 1.2.3.1 获取存款记录 1.2.3.2 获取贷款记录 1.2.3.3 计算信用等级 1.2.6.1 申请担保 1.2.6.2 提供担保
  • 58. Key Performance Indicator Analysis 业务目标 关键业务指标 相关服务 BG.1 降低成本 BG.2 降低欺诈风险 销售成本降低 10% 坏账率到 3% 以下 用户自服务比率提高到 85% 1.2.1 申请贷款 1.2.2 确认申请 1.2.3 评估信用等级 1.2.3.1 获取存款记录 1.2.3.2 获取贷款记录 1.2.3.3 计算信用等级 1.2.4 核定期限 1.2.5 审批 1.2.6 担保 1.2.6.1 申请担保 1.2.6.2 提供担保 1.2.7 发放贷款
  • 59. Existing System Analysis Fax/Call Web Service Windows .NET 提供担保 保险公司担保系统 APP3 Terminal CICS/390 获取存款记录 核心系统 APP2 EJB AIX WAS v5 获取贷款记录 贷款系统 APP1 接口类型 平台 相关服务 系统名称 系统编号
  • 60. Service Identification, Composition and Categorization
    • 客户服务
      • 1.2.1 申请贷款
      • 1.2.2 确认申请
      • 1.2.3.1 获取存款记录
      • 1.2.3.2 获取贷款记录
      • 1.2.4 核定期限
      • 1.2.5 审批
      • 1.2.6 担保
      • 1.2.6.1 申请担保
      • 1.2.6.2 提供担保
      • 1.2.7 发放贷款
    • 风险管理
      • 1.2.3 评估信用等级
      • 1.2.3.3 计算信用等级
  • 61. Business Modeling Business Data Modeling Business Process Modeling Organization Modeling Simulation Report Business Monitoring
  • 62. Process Simulation
    • To find bottleneck before system deployment
    • Optimize resource allocation based on the statistical analysis of the sources consumption
    Simulation Control Real Time Simulation Statistics Simulation Time Current Process Bottleneck Queue
  • 63. Summary
    • Analysis and modeling is a critical process in business-driven, service-centered system development.
    • SOA follows the model driven approach, which defines an automated transformation process from computation independent model to platform independent model to platform specific model.
    • SOMA identifies the key activities of service identification, specification and realization.
  • 64. Reference
    • Frank Truyen, “The Fast Guide to Model Driven Architecture”, Cephas Consulting Corp., 2006.
    • OMG, “MDA Guide Version 1.0.1”, 2003.
    • Krzysztof Czarnecki, “Model Driven Architecture”, 2004.
    • Olaf Zimmermann, Pal Krogdahl, and Clive Gee, “Elements of Service-Oriented Analysis and Design”, June 2004.
    • Ali Arsanjani, “Service-Oriented Modeling and Architecture”, Nov. 2004.
    • Keith Leve and Ali Arsanjani, “A Goal-driven Approach to Enterprise Component Identification and Specification”, Communications of the ACM, Oct. 2002.