SOA Architecture and Design Principles

Transcription

1 SOA: Enterprise Architecture TRAIN. LEARN. SUCCEED. SOA Architecture and Design Principles Copyright 2008, OnsiteSeminar LLC All rights reserved, no unauthorized duplication For information on this course or other many seminar offerings, please contact OnsiteSeminar LLC Direct: (817) i

2 SOA: Enterprise Architecture Copyright 2008 by OnsiteSeminar LLC. All rights reserved. No part of this publication may be reproduced, transmitted, transcribed in any form or by any means including; electronic, mechanical, optical, manual or otherwise without the expressed written consent of this firm. This course,, was developed by the staff of OnsiteSeminar LLC for use in technical seminars. It has been licensed expressly for use by our clients for internal training only. Copyright 2008, OnsiteSeminar LLC All rights reserved, no unauthorized duplication IMPORTANT NOTICE The sole purpose of this student manual is to serve as a supplement to an instructor-based technical presentation. The combination of information contained in this manual with the detailed insights of the instructor leads to the most positive educational experience for all students. It is not intended to be used solely as a stand alone reference manual. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where these designations appear in this seminar, and OnsiteSeminar LLC is aware of a trademark claim, the designations have been printed in initial capital letters or all capital letters. OnsiteSeminar LLC has taken care in the development of this seminar, but make no expressed or implied warranty of any kind or assume any responsibility for errors or omissions. Java, Java Development Kit, J2ME, J2SE and J2EE are a registered trademarks of Sun Microsystems Inc. Rational Application Developer, WebSphere Application Server, WebSphere Studio, WebSphere Studio Application Developer, MQSeries, WebSphereMQ, WebSphere Site Developer, VisualAge, VisualAge for Java, Visual Composition Editor, VisualAge Debugger and DB2 are registered trademarks of IBM Corporation. Microsoft, Microsoft.NET, MS-DOS, Windows NT, Windows 2000, Windows 98, Windows ME and SQLServer are registered trademarks of Microsoft Corporation Oracle, JDeveloper, Oracle BPM Suite, Oracle SOA Suite are registered trademarks of Oracle Corporation. For information on this course or other many seminar offerings, please contact OnsiteSeminar LLC Direct: (817) marketing@onsiteseminar.com ii

3 SOA: Enterprise Architecture Audience This course is designed for Java developers, project leaders, IT architects and other technical individuals that need to understand how to develop and implement SOA and event-driven architectures. Duration 2 Days Course Abstract This course will provide each student with an overview of key concepts and issues associated with the adoption of a service-oriented architecture, including SOA principles, service design and infrastructure. It will explore the definitions and principles of each type of fundamental shared service to include presentation, business, and data services. Additionally, the course explores SOA runtime governance, service bus, service registry, security and service monitoring issues. This course trains students to apply key Service- Oriented Architecture (SOA ) principles to their current SOA adoption plans, understand the scope and characteristics of SOA service infrastructure and understand the design principles associated with SOA common infrastructure and shared services. All aspects of this class will illustrate the architecture and design of an efficient and effective SOA environment. Objectives Upon conclusion, each participant will have acquired these skills: Understand the architecture of an SOA environment Illustrate the components of a SOA architecture Depict the structure and architecture of web services Define the role of orchestration and choreography Understand the different service layers Depict the differences between application and business layers Illustrate the SOA delivery lifecycle phases Understand the role of service-oriented analysis, benefits of business-centric SOA Depict the benefits of business process modeling and Entity modeling Define the differences between task-centric and process-centric services Illustrate the basic service modeling guidelines Understand the role of SOA governance Class Format Prerequisites Lecture/Lab Each student should have an understanding of application development and basic design methodologies. For information on this course or other many seminar offerings, please contact OnsiteSeminar LLC Direct: (817) marketing@onsiteseminar.com iii

4 SOA: Enterprise Architecture Course Objectives Understand the role of Service-Oriented Architecture Depict the components of an SOA environment Depict the structure and architecture of web services Define the role of orchestration and choreography Understand the different service layers Depict the differences between application and business layers Illustrate the SOA delivery lifecycle phases Understand the role of service-oriented analysis, benefits of business-centric SOA Depict the benefits of business process modeling and Entity modeling Define the differences between task-centric and process-centric services Illustrate the basic service modeling guidelines Understand the role of SOA governance For information on this course or other many seminar offerings, please contact OnsiteSeminar LLC Direct: (817) iv

5 SOA: Enterprise Architecture Table of Contents I. SOA Architecture A. SOA Business Challenge SOA Business Challengea s: Billion Dollar Lock-In. 1-5 Integration Tools Appearing. 1-6 Point-to-Point Approach. 1-7 New $200B Lock-In: Big Apps. 1-8 Frozen Enterprise Asset Concept. 1-9 Liquid Asset Transformation SOA: Frozen to Liquid Assets Service Infrastructure Layer Web Services Based Approach Service Infrastructure Application vs. Service Layer SOA Challenges Service Infrastructure Approach IBM Product Solutions SOA Development Actors SOA Deployed Products SOA Product Family ESB Target Environments Composition vs. Coding Process Server Service Registry Data Services SOA Enterprise Security SOA BPM Suites SOA Environment II. Getting Started with SOA A. Overview Flexible Business = Flexible IT. 2-4 SOA & Web Services. 2-5 Web Services are a Good Start. 2-6 ESB Shrinks Interfaces. 2-7 SOA Reference Architecture. 2-8 IBM SOA Foundation. 2-9 Customer View of SOA End-to-End Process Capabilities For information on this course or other many seminar offerings, please contact OnsiteSeminar LLC Direct: (817) marketing@onsiteseminar.com v

6 SOA: Enterprise Architecture SOA Software Platform Roles WebSphere Software Platform Why do Business Process Modeling? Business Process Modeling SOA Business Modeler Assembly Concepts Eclipse-Like Integration Developer Testing and Debugging Deployment Enterprise Service Bus Capabilities Define ESB Offerings Process Server Components Common Data Model: Business Objects Invocation Model: Service Components III. Standard SOA Implementation A. SOA Usage What is SOA?. 3-4 View of SOA. 3-5 SOA Entry Points. 3-6 People Centric Approach. 3-7 People Entry Point with SOA. 3-8 Process Centric Approach. 3-9 Process Entry Point in SOA Information Centric Approach Information Entry Point to SOA Business Centric SOA Value through SOA Connectivity Entry to SOA Creating and Reusing Services Business Centric in Action SOA Management & Security Align Business with IT Governance B. Platform Overview Business Domains Software Architecture IBM and SOA WebSphere Application Server WebSphere MQ Overview WebSphere ESB & Application Server WebSphere ESB & Process Server WebSphere ESB & Message Broker SOA and Component Model For information on this course or other many seminar offerings, please contact OnsiteSeminar LLC Direct: (817) vi

7 SOA: Enterprise Architecture SDO and SCA ESB and SCA Tooling Mediation SDO and business objects Message Transformation IV. Message Exchange Patterns A. Overview Message Exchange Patterns. 4-4 Request-Response MEP..4-5 Message Exchange Patterns..4-6 Fire-and-Forget..4-7 Publish-and-Subscribe..4-8 WSDL Coordination Coordination Composition Coordinator Service Composition WS-Coordination Registration WS-Coordination Completion Coordination SOA V. Atomic Transactions A. Overview Atomic Transactions. 5-4 Atomic Transaction Protocols..5-5 Atomic Transaction Coordinator..5-6 Atomic Transactions..5-7 WS-Atomic Transactions..5-8 Business Activity..5-9 Business Activity Protocols Business Activity Coordinator Atomic Transaction Business Activity and SOA VI. Orchestration and Choreography A. Orchestration Overview Orchestration. 6-4 Process Service Coordination..6-5 Orchestration and SOA..6-6 For information on this course or other many seminar offerings, please contact OnsiteSeminar LLC Direct: (817) vii

8 SOA: Enterprise Architecture B. Choreography Overview Choreography. 6-9 Defining Choreography Roles and Participants Relationships and Channels Interactions and Work Units Reusability, Composability and Modularity Complete Choreography Choreography and SOA Technical Requirement VII. Service Layers A. SOA Service Layers Service-Orientation and Contemporary SOA. 7-4 SOA Characteristics..7-5 Primary Service Layers..7-9 Application Service Layers Application Service Characteristics Business Service Layers Orchestration Service Layers Agnostic Services Agnostic Reusable Services Hybrid Application Services Only Hybrid and Utility Application Services Task-Centric and Utility Application Services Task-Centric, Entity-Centric and Utility Application Services Process Services, Hybrid Application Services and Utility Application Services Process Services, Task-Centric Business Services and Utility Application Services Process Services, Task-Centric Business Services, Entity-Centric Business Services and Utility Application Services Process Services, Entity-Centric Business Services and Utility Application Services VIII. Introduction to SOA Analysis A. SOA Delivery Strategies SOA Delivery Lifecycle Phases. 8-4 SOA Delivery Lifecycle..8-5 For information on this course or other many seminar offerings, please contact OnsiteSeminar LLC Direct: (817) viii

9 SOA: Enterprise Architecture SOA Delivery Strategies..8-6 The Top-Down Strategy..8-7 The Bottom-Up Strategy..8-8 The Agile Strategy..8-9 B. Overview Service-Oriented Analysis Process Benefits of a Business Centric SOA Business Process Management (BPM) Models The BPM Lifecycle What is a Model? Entity Models Business Services and Orchestration IX. Service Modeling A. Overview Service-Oriented Analysis Process. 9-4 Benefits of a Business-Centric SOA..9-5 Business Services Build Agility into Business Models..9-6 Business Services Prepare a Process for Orchestration..9-7 Business Services Enable Reuse..9-8 Only Business Services Can Realize the Service- Oriented Enterprise..9-9 Business Process Management (BPM) Models Entity-Centric Business Services Business Services and Orchestration X. SOA Governance A. Overview What is SOA Service oriented architecture SOA: observations Defining SOA governance Governance definitions Changing IT governance SOA adoption challenges SOA: What s needed Evolving SOA technology Evolving standards (WS-*) SOA governance infrastructure What needs to be governed SOA entry points For information on this course or other many seminar offerings, please contact OnsiteSeminar LLC Direct: (817) marketing@onsiteseminar.com ix

10 SOA: Enterprise Architecture Service visibility Service lifecycle SOA security challenges Identity management Security services SOA governance challenges SOA challenges Governance models SOA interactions For information on this course or other many seminar offerings, please contact OnsiteSeminar LLC Direct: (817) x

11 Section I: SOA Architecture Section I: SOA Architecture All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-1 Revision: January 15, 2007

12 Section I: SOA Architecture Section I. SOA Architecture Unit Description In this unit, the student will be introduced to the business challenges facing IT applications todays, the migration to SOA systems, evolution from vendor bound apps, role of SOA products, the role of different individuals, use of the ESB and the overall business process modeling from SOA. The instructor-led lecture is supplemented with a series of hands-on exercises to reinforce all of the Business Process Modeling concepts discussed in this section. Unit Objectives After successfully completing this section, you should be able to: Understand SOA business challenges Depict the evolution away from vendor bound applications Illustrate the emergence of the Service infrastructure Understand the products for SOA implementations Define the SOA components and their individual roles Demonstrate the use of the Enterprise Service Bus Depict the integration of the components Illustrate the usage of the Business Process Modeling suite All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-2 Revision: January 15, 2007

13 Section I: SOA Architecture Section I: SOA Architecture SOA Business Challenge All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-3 Revision: January 15, 2007

14 SOA Business Challenges Section I: SOA Architecture Increase operational efficiency Improve productivity from existing systems Streamline and optimize business process Built-in re-use and adaptation, no starting over Turn IT into a competitive business asset Provide customers a unified view of the business Eliminate silos and create end-to-end visibility for customers into and across the business Provide customers specific views of processes and information While Achieving faster time to value That focus on process rather than on specific technology is what lets an SOA deliver on its promise of true IT-business alignment. But it also introduces new challenges for CIOs challenges that stretch IT's abilities in areas that have been chronically underdeveloped: process and architectural planning. The importance of process in SOA means CIOs should be addressing architectural issues at the same time that they consider purchasing or implementing SOA infrastructure. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-4 Revision: January 15, 2007

15 The 90s: Billion Dollar Lock-In Section I: SOA Architecture In the 1990 s application development followed a pattern of binding our systems to specific vendor and architecture patterns Application Application Application Application Application Application HPUX AIX Solaris Windows Linux Mainframes Any organization implementing an SOA should create a basic architectural model for a manageable piece of the business, and then apply that model opportunistically to individual projects, using them both to test the model and to deploy the SOA in pieces. As the 1990 s progressed, corporations increasingly began to find that they were locked into supporting specific applications that were linked to certain vendors, their associated products and specific types of operating environments. With the advent of Linux, we began to see the ability to breakaway from these types of foundational links. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-5 Revision: January 15, 2007

16 Integration Tools Appearing Section I: SOA Architecture After the 1990 s, a variety of products appeared that focused on the ease of integration of different systems Applications Application Infrastructure Real- Time Edge SIP SOA Product Family.NET MQSeries WebLogic CICS Product Family HPUX AIX Solaris Windows Linux Mainframes All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-6 Revision: January 15, 2007

17 Point-to-Point Approach Section I: SOA Architecture Point-to-Point architecture lead to tightly coupled and brittle connections Presentati Logi Data Clients Porta EJB Identity/ Policy Browser Portle Mainframe Application Client Portle Databases Legacy Mobile Web App Point-to-Point Approach Business logic is often replicated and tightly coupled Security, messaging, management are hard-wired in each connection Applications are brittle and difficult to maintain or upgrade Vendor SOA platforms have been built from the ground up for SOA. It provides automation for creating and maintaining enterprise data services which can help customers achieve greater productivity, business optimization and faster time to value. These platforms offer a single location to capture logic that is relevant to data access and data updates. A data services layer provides reusable, simplified access to relevant, real-time heterogeneous data. vendor ESB/Proces Server is based on a metadata-driven approach with a declarative definition of services. This helps eliminate the need for application developers to build workflows or code Java by hand, resulting in the automation of data service creation and maintenance. Furthermore, the declarative approach helps optimize data access, improving overall system performance. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-7 Revision: January 15, 2007

18 New $200B Lock-In: Big Apps Section I: SOA Architecture In the 2000 s, we saw the implementation of large scale vendor packages and customized applications Packaged Applications Custom Applications SAP ORCL CA MANU BEA IBM MSFT ORCL Application Infrastructure Real- Time Edge SIP SOA Product Family.NET MQSeries CICS HPUX AIX Solaris Windows Linux Mainframes All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-8 Revision: January 15, 2007

19 Frozen Enterprise Asset Concept Section I: SOA Architecture Division B Division A Division C CR ER D All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-9 Revision: January 15, 2007

20 Liquid Asset Transformation Section I: SOA Architecture Division B Division A Division C Businesses most pressing issues today include: o Improving Operational Efficiency, to make what you already have achieve higher productivity, which in turn means improving the way you do business, and thus your overall business procedures or processes. In particular, preserving and expanding new strategic development efforts, amidst shrinking budgets and ongoing expensive maintenance costs. o It is a game of: Doing more with less (the days of do less with more have gone), in virtually every area of the business. Secondly, we see the need to be more responsive to those stakeholders that support your business, whether that s internal customers or external customers. That rests largely on your ability to gather and use the information flowing through your business no matter where it is, and make it available to the people who can do the job. The third point is about Change and agility of the business. We see businesses emphasizing more and more the need to build in the ability to rapidly adapt the business and your internal and external touch points as the business changes. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-10 Revision: January 15, 2007

21 SOA: Frozen to Liquid Assets Section I: SOA Architecture In the 2000 s, we saw the implementation of large scale vendor packages and customized applications Services Packaged Applications Custom Applications SAP ORCL CA MANU BEA IBM MSFT ORCL Application Infrastructure Real- Time Edge SIP SOA Product Family.NET MQSeries CICS HPUX AIX Solaris Windows Linux Mainframes MQSeries to take high end transactions into distributed environments and Web service enable legacy environments, the award-winning platform that unlocks legacy applications and extends them to a Service-Oriented Architecture. SOA Standards: The industry s leading SOA platforms to create, blend and run applications and services: SP-enabled, Ege-Aware and Real-Time. Process Server: An Industry standard for cross-platform product family optimized for scaling, securing and managing SOA throughout the enterprise. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-11 Revision: January 15, 2007

22 Service Infrastructure Layer Section I: SOA Architecture Providing A Uniquely Business-Aligned Approach To The Design and Delivery of Applications Sales Engineering Service Customers Role-based Composite Applications B2E B2C Partners connect to business services, built and managed with an integrated suite on open standards, with supporting infrastructure using content from Vanilla ERP and application engines Presentation Services Shared Business Services Information and Access Services Enterprise Information Systems Custom Applications Third Party Products (Erp, CRM, etc.) Composite Applications Data and Middleware Databases MiddleWare Interactions (TUXEDO, MQ Series,ect.) Services Management Service Bus Common Services Service Infrastructure Layer Non-Functional Requirements Standards Development Tools Configuration Management System Management Network Management Provisioning Business Activity Monitoring Directories Patterns Because SOA is ultimately about creating and managing IT processes in support of business processes, governance is critical. The architecture of SOA takes a lot of the control away from individual developers, so you can expect to receive a considerable amount of resistance. A way to enforce the SOA principle of reuse is to have a review board that evaluates new applications to ensure they are really needed. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-12 Revision: January 15, 2007

23 Web Services Based Approach Section I: SOA Architecture Presentation Process Logic Data Clients Browser Application Client Mobile Portal WSR WSR Web App Process Process Web Services Web Services Web Services Web Services Identity/ Policy Mainframe Databases Legacy App Web Services Based Approach Services are directly connected and tightly coupled Security, messaging, management are hard-wired in each connection Applications are brittle and difficult to maintain or upgrade Vendor platforms have been built from the ground up for SOA. It provides automation for creating and maintaining enterprise data services which can help customers achieve greater productivity, business optimization and faster time to value. The ESB/Process Server architecture offers a single location to capture logic that is relevant to data access and data updates. A data services layer provides reusable, simplified access to relevant, realtime heterogeneous data. A Process Server is based on a metadata-driven approach with a declarative definition of services. This helps eliminate the need for application developers to build workflows or code Java by hand, resulting in the automation of data service creation and maintenance. Furthermore, the declarative approach helps optimize data access, improving overall system performance. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-13 Revision: January 15, 2007

24 Section I: SOA Architecture Service Infrastructure The Next Software Category Service Infrastructure Packaged Applications Custom Applications SAP ORCL CA MANU BEA IBM MSFT ORCL Application Infrastructure Real- Time Edge SIP SOA Product Family.NET MQSeries CICS HPUX AIX Solaris Windows Linux Mainframes All of these challenges underscore how different SOA is from traditional enterprise technology efforts. The CIO must put the technologist hat to the side and become an advocate for business processes. Better knowledge of those processes leads to better technology design, which reduces the cost of maintaining existing systems something that now accounts for 70 percent to 80 percent of IT budgets. We've been talking for years about IT-business alignment, an SOA lets you actually achieve that goal if you can develop the architectural vision and execute on it over the long term. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-14 Revision: January 15, 2007

25 Application vs. Service Layer Section I: SOA Architecture Application Infrastructure Service Enablement Execution Environment Reliability Service Infrastructure Cross-platform management Governance and control Service discovery and publishing Service security Message routing and transformation Resource allocation Open: Application infrastructure and service infrastructure provide different scopes of service o Application infrastructure is a required resource to service enable enterprise components o Service infrastructure takes a broader view of enterprise resources, understanding their relationship to each other o Service infrastructure serves long term goals for making enterprise IT more responsive to the business Transition: The two infrastructures also provide different operations in the lifecycle of a service Proposed analogy? i.e. Application Infrastructure = building design and Service Infrastructure = city planning. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-15 Revision: January 15, 2007

26 Section I: SOA Architecture SOA Challenges SOA Challenge Infrastructure Needs Heterogeneity Proliferation Point-to-Point Data Silos Security Silos Scalable Agility Service-enabling Lifecycle Management Service Bus Data Service Layer Security Service Layer Composition Tools Service-Oriented architecture is reshaping the way companies think about their IT. Our customers have been moving from their initial SOA pilots to aggressively ramp these pilots into production. The challenge everyone is facing is driving very clear and specific software Infrastructure needs. Application infrastructure software has done a very good job in addressing heterogeneity by exposing application capabilities as services. Java, XML, WSDL and SOAP have become the standards to build, describe, expose and discover Web services using platforms like application infrastructure software. But once you start exposing more and more capabilities as services, you will need to manage their proliferation. The need for an infrastructure emerges that helps to support the entire service lifecycle from creation to discovery to management. Initially most services are interacting in a point-to-point fashion with security, messaging and management hard coded connection by connection. As a consequence, applications become brittle and difficult to manage, something that can be avoided by having a common backplane, or Bus. Data integration, transformation, and updates should be accomplished via core infrastructure as well vs. hand-coding integration over and over again to each data silo. The same is true for security it would be too complex and risky for enterprise wide SOA implementations to rely on hand-coded security. Instead, security services must be core infrastructure. Finally, by putting the control in the hand of the application specialist to compose and modify applications, you gain speed and agility while preserving the integrity of core enterprise data assets. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-16 Revision: January 15, 2007

27 Service Infrastructure Approach Section I: SOA Architecture Presentation Proces Logic Data Clients Browser Application Client Porta WSR WSR Proces Web Services Web Services Data Data Identity/ Policy Mainframe Databases Process Web Service Data Legacy Mobile Web App Web Service Service Infrastructure Service Management Messaging Services Data Services Security Services User Interaction Services Business Process Services Custom Services Service Registry Meta-data Repository Monitoring Composition Tools Today, Service Oriented Architecture (SOA) is significantly improving the value IT brings to mid-size companies by providing the flexibility that makes business change easier to implement. Incorporating SOA into the IT environment can increase the speed and lower the cost of supporting critical business demands while saving money by reusing existing applications and data. SOA is an open-standards approach to IT architecture that creates a more modular and reconfigurable IT environment. SOA allows you to isolate discrete IT components or tasks and configure them as services. These services can be combined quickly and easily, in order to create optimized business processes. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-17 Revision: January 15, 2007

28 Section I: SOA Architecture IBM Product Solutions SOA Leads the Way Again Internal Services External Services Acquire Customer Portfolio Devel. Quote to Collect Customer Support Auction Call Center Design Services Commerce Service Infrastructure Enterprise Service Bus Packaged Applications Custom Applications SAP ORCL CA MANU BEA IBM MSFT ORCL Application Infrastructure Real- Time Edge SIP SOA Product Family.NET MQSeries CICS HPUX AIX Solaris Windows Linux Mainframes With SOA, your entire infrastructure is agile, scalable and ready to grow. Application development time is faster and costs are lower due to the flexibility of the building block approach. Most companies choose to start with a few small SOA projects in order to build their skills and earn a return on their investment before expanding to enterprise-wide implementations. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-18 Revision: January 15, 2007

29 SOA Development Actors Section I: SOA Architecture Actors in the SOA Development and Deployment Cycle Service virtualization, visibility, compliance Business IT Architect #$%! bugs I need a Diet Coke Developer The main drivers for SOA adoption are that it links computational resources and promotes their reuse. Enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to changing market conditions. This style of architecture promotes reuse at the macro (service) level rather than micro level (objects). It can also simplify interconnection to - and usage of - existing IT (legacy) assets. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-19 Revision: January 15, 2007

30 SOA Deployed Products Section I: SOA Architecture Roles of Vendor SOA and ESB in SOA ESB: Defining Service Infrastructure Service virtualization, visibility, compliance Business IT Architect Developer #$%! bugs I need a Diet Coke Vendor SOA: Leading infrastructure for development and deployment of services An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system which allows integration architects to exploit the value of messaging without writing code. Contrary to the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary. ESB does not implement a service-oriented architecture (SOA) but provides the features with which one may be implemented. Although a common belief, ESB is not necessarily web-services based. ESB should be standards-based and flexible, supporting many transport mediums. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-20 Revision: January 15, 2007

31 Section I: SOA Architecture SOA Product Family Service Infrastructure: Cross-Platform, and Composition-based Process Orchestration Vendor Business Process Process Management Business Server Rules Enterprise Connectivity Business Activity Management Security Services Distributed Application Security Management Data and Information Business Services Intelligence Message Services User Interaction Portal Vendor Portal Multi-channel Server Collaboration Interaction Management Federated Identity Management Security Architecture BPEL Composite Business Data Management Modeler Unified Meta Data Repository Unified Data Modeling Service Manager Message Broker Message Management Service Registry Now it is time to look at the SOA product family. Since its initial announcement, Each vendor has been aggressively executing on its Service Infrastructure vision. Today, vendors deliver the broadest line of Service Infrastructure products for successful SOA deployment. The first product family built from the ground up for SOA, it currently consists of these product lines and products. The Business Service Interaction product line includes software that automates, executes, and monitors the entire lifecycle of a business process by connecting people to people, applications to applications, and people to applications software. The product line includes the Enterprise Sevice Bus which supports the complexity and heterogeneity of today s leading businesses, and extends the promise of SOA by helping customers achieve organizational agility through process efficiency and optimization. Integrated Composition Environment Compose U p d at e M o ni to r P re vi e w C o m p o s e All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-21 Revision: January 15, 2007

32 ESB Target Environments Section I: SOA Architecture ESB is targeted at organizations who: Are embracing Service-Oriented Architecture (SOA) Are rolling out new projects and applications to meet the needs of the business and are experiencing pain around time-consuming programming that slows the ability to respond to the needs of the business Have deployed multiple services o Trying to track, discover, deploy, secure, and manage services is becoming unmanageable o Are using point-to-point integration Have heterogeneous environments o Multi-OS, multi-vendor, multi-development language Have distributed environments o multi-department, multi-site, multi-geography All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-22 Revision: January 15, 2007

33 Composition vs Coding Section I: SOA Architecture vs public String getemployeename( long employeeid ) throws javax.ejb.createexception, java.rmi.remoteexception { Connection conn = null; PreparedStatement ps = null; try { conn = this.getconnection(); ps = conn.preparestatement("select name from employees_files where idnumber =?"); ps.setlong(1, employeeid); ResultSet rs = ps.executequery(); if (rs.next()) { return rs.getstring(1); } return "Unknown"; } catch (SQLException sqe) { return sqe.getmessage(); } finally { if (ps!= null) { try { ps.close(); } catch (SQLException se) { throw new RemoteException("SQL Error.", se); } } Application Composition Metadata driven configuration, composition and business rules For application specialists (requirements experts) not developers Apps composed from existing services built by developers You can see here that the right hand side represents the traditional world view. This approach provides for lots of code, rigid. Inflexible and higher costs to develop and maintain. On the left hand side is the new world view. More about configuration and composition. More flexible and agile for meeting the needs of the business. Lower overall cost of ownership. In this world, application composition can be performed by application specialists, such as business process analysts, instead of developers using more of a composition and configuration driven paradigm. People who better understand business requirements and how to map those to business processes are now in better control and this reduces the need to translate those requirements to developers for implementation. As a result, we re working through this paradigm to reduce the current gap between business and IT and therefore deliver better business agility and increased IT efficiency. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-23 Revision: January 15, 2007

34 Section I: SOA Architecture Process Server Service Coordination ESB Heterogeneous platform support Service Monitoring Features Heterogeneous service integration Dynamic routing and transformation Service registration and discovery Operational service management Flexible configure, deploy, production capabilities Built on a time-tested foundation for enterprise-class messaging, performance and availability Differentiators Fully configuration based Comprehensive SOA integrity Life-cycle management Proven abilities: R-A-S-P Process Server converges the functionality of an Enterprise Service Bus with service management functionality in a single unified product targeted at deploying SOA with configuration-driven integration of services and applications. This converged approach delivers a scalable, intelligent messaging, routing and transformation layer supporting heterogeneous end-points, integrated with capabilities for service registration, monitoring, and lifecycle management. Enterprise Service Bus delivers the connectivity and management infrastructure required for configuration, deployment and on-going operations of integrated shared services and Service- Oriented architectures in heterogeneous IT environments. Specifically, AquaLogic Service Bus delivers: multi-protocol messaging, dynamic rules-based routing, transformation capabilities and all characteristic of an Enterprise Service Bus coupled with: service registration, service discovery, service versioning, security, policy enforcement, message tracking and monitoring, alerting and performance monitoring. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-24 Revision: January 15, 2007

35 Section I: SOA Architecture Service Registry The most complete and proven business service registry Fully supports the latest UDDI V3 specification Provides a mechanism by which services can be published, discovered and consumed. Contains metadata about services that provides everything a consumer needs to know about using a service. Provides a centrally managed, reliable and searchable location for service descriptions, making it the System of Record for SOA. Provides a foundation for SOA governance and service lifecycle management Complements AS, ESB, Web Services, and BPEL in the service lifecycle All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-25 Revision: January 15, 2007

36 Section I: SOA Architecture Data Services Data Services via Process Server Service Clients Mgmt Dashboard ESB Customer Portal BPM J2EE, Web Service, XQuery, JMS Data Services on Logical Model Programming Model (SDO) Customer Order Payment Repository Model Driven Integration (XQuery) JDBC Web Srvcs Adapters Custom Addresses Orders Physical Model History Customer Profile Pending Payments Credited Payments Enterprise Data Logical models capture data access & integration complexity once Same data model, programming model, & API for all enterprise data All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-26 Revision: January 15, 2007

37 SOA Enterprise Security Section I: SOA Architecture Web Server Centralized Administration of Policy and Configuration Data Security Service Module Distribution of Incremental Policy Updates App Server Security Service Module Legacy/ Custom App Security Service Module An application security product that provides Fine grained entitlements Security as a service Define access policy that control entitlements to business objects and application resources Provides a set of standard security services for a variety of application environments Consists of two components Administrative application centrally manage security configuration and policy SSMs - plug into various application environments to enforce security Enterprises can quickly put together composite applications that combine the capabilities of existing applications in different ways to meet the changing business models of an enterprise. But in doing so, enterprises run into the problem of security. Traditionally, security models have been hardcoded into applications and when capabilities of an application are opened up for use by other applications, the security models built into each application may not be good enough. Several emerging technologies and standards address different aspects of the problem of security in SOA. Standards such as WS-Security, SAML, WS-Trust and WS-SecurityPolicy address the security problem for SOA implementations that use Web Services. All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-27 Revision: January 15, 2007

38 Section I: SOA Architecture Vendor BPM Suites Business Analysts Process Modeling, Simulation Process Analyst Process Development and Systems Integration Business Owners Vendor BPM Enterprise Process Participants HiPer Workspace Process Management and Real-Time BAM Historical & Trend Analysis Tools Process Server and Monitoring Repository Business Systems As with every IT project, the Systems Analysts interview the Business Owners to understand the use cases, requirements, etc. Uniquely in the model is that a business process model is used to gain understanding and agreement not just between the Business Owners and Systems Analysts, but even between individuals in the Business Owners group (we would all be surprised how often there is real disagreement about how our processes actually work). That process model (along with the documentation you embed directly within it) becomes the contract between the Business and IT. Once the Systems Analysts complete the model and future Test Cases, they share the model with the Development Team who will complete the detailed work of connecting the model to the systems and human interfaces required to complete the Process Application. As the diagram indicates, this is very often an iterative process that serves to further solidify that contract between the Business and IT. Once the Developers are finished, the completed Process Application is deployed in the vendor SOA process server for execution. The BPM system manages the interaction of humans and systems in the process and stores every event in its state repository. Since this repository contains process AND business data, it provides management interfaces and dashboards to the Business Owners. These are real-time displays showing status at any level of the process. For example, one executive may be viewing a Balanced Scorecard while a business operations expert may have a dashboard depicting adherence to Service Level Agreements. DB CRM ERP All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-28 Revision: January 15, 2007

39 Section I: SOA Architecture SOA Environment IT Architects Logical Service Assembly Business Users Business Process Business Application / Service Access for Application topology IT Management CMDB Management & Monitoring Correlation Engine, Business Activity, etc. Events Federated Service Catalog AL Infrastructure DSP Eng BPM Eng ESB Eng IT Developers IT Operators Integrated Service Development Env. DSP, ESB, Java,.. Design tools Deployment Model AL Deployment Administration & Configuration Business Application deployment Run time Access Run Time Service Binding Business Users Information Workers Sync Service Registry Portal Applications (Mash Up) Portlet services, collaborations, etc. Sync Design Off-line Production Off Line Design Environment Support by all AL Design All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-29 Revision: January 15, 2007

40 Section I. SOA Architecture Section I: SOA Architecture Unit Summary After successfully completing this section, you should be able to: Understand SOA business challenges Depict the evolution away from vendor bound applications Illustrate the emergence of the Service infrastructure Understand the BEA products for SOA implementations Define the AquaLogic components and their individual roles Demonstrate the use of the AquaLogic Enterprise Bus Depict the integration of the AquaLogic Data Services components Illustrate the usage of the Business Process Modeling suite All rights reserved, no unauthorized duplication Unit 1. SOA Architecture 1-30 Revision: January 15, 2007

41 Section V: Atomic Transactions Section V: Atomic Transactions All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-1 Revision: June 15, 2007

42 Section V: Atomic Transactions Section V. Atomic Transactions Unit Description In this unit, the student will be introduced to the concepts of Atomic Transactions, influences of WS-AtomicTransaction, different protocols associated, use of WS- BusinessActivity coordination and depict abilities of SOA atomic transactions. The instructor-led lecture is supplemented with a series of hands-on case studies to reinforce all of the SOA analysis and design concepts discussed in this section. Unit Objectives After successfully completing this section, you should be able to: Understand the use of atomic transactions Illustrate the different protocols with WS- AtomicTransactions Discuss WS-BusinessActivity coordination Depict the capabilities of atomic transactions with SOA architecture All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-2 Revision: June 15, 2007

43 Section V: Atomic Transactions Section V: Atomic Transactions Overview All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-3 Revision: June 15, 2007

44 Atomic Transactions Section V: Atomic Transactions Transactions have been around for almost as long as automated computer solutions have existed. When managing certain types of corporate data, the need to wrap a series of changes into a single action is fundamental to many business process requirements. Atomic transactions implement the familiar commit and rollback features to enable cross-service transaction support. Service A I m gonna ask you two to do some work, but if either of you screw up, we re gonna forget it ever happened. Service B Service C All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-4 Revision: June 15, 2007

45 Atomic Transaction Protocols Section V: Atomic Transactions WS-AtomicTransaction is a coordination type, meaning that it is an extension created for use with the WS-Coordination context management framework. To participate in an atomic transaction, a service first receives a coordination context from the activation service. It can subsequently register for available atomic transaction protocols. The following primary transaction protocols are provided: A Completion protocol, which is typically used to initiate the commit or abort states of the transaction. The Durable 2PC protocol for which services representing permanent data repositories should register. The Volatile 2PC protocol to be used by services managing non-persistent (temporary) data. All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-5 Revision: June 15, 2007

46 Atomic Transaction Coordinator Section V: Atomic Transactions Activation Service Registration Service Participants Atomic Transaction Coordinator Completion Volatile 2PC Durable 2PC This specification describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome of distributed activities. The framework defined in this specification enables an application service to create a context needed to propagate an activity to other services and to register for coordination protocols. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-6 Revision: June 15, 2007

47 Atomic Transactions Section V: Atomic Transactions loose coupling business activities can encompass atomic transaction composability interoperability reusability defines protocols for provides transaction features for extensibility vendor diversity discoverability coordination quality of service web services All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-7 Revision: June 15, 2007

48 WS-Atomic Transactions Section V: Atomic Transactions WS-Atomic Transaction is a coordination type that supplies three coordination protocols that can be used to achieve two-phase commit transactions across multiple service participants. The atomic transaction coordinator makes the ultimate decision to commit or rollback a transaction. This decision is based on votes collected from participants. Contemporary SOAs can incorporate cross-service, ACID-type transaction features by using WS- AtomicTransaction. This specification provides the definition of the atomic transaction coordination type that is to be used with the extensible coordination framework described in the WS-Coordination specification. The specification defines three specific agreement coordination protocols for the atomic transaction coordination type: completion, volatile two-phase commit, and durable two-phase commit. Developers can use any or all of these protocols when building applications that require consistent agreement on the outcome of short-lived distributed activities that have the all-or-nothing property. All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-8 Revision: June 15, 2007

49 Section V: Atomic Transactions Business Activity Plan A Service A Let s try plan A. If that doesn t work, we ll try plan B. Service B Plan B Plan A Service C Plan B This specification provides the definition of the business activity coordination type that is to be used with the extensible coordination framework described in the WS-Coordination specification. The specification defines two specific agreement coordination protocols for the business activity coordination type: BusinessAgreementWithParticipantCompletion and BusinessAgreementWithCoordinatorCompletion. Developers can use any or all of these protocols when building applications that require consistent agreement on the outcome of long-running distributed activities. All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-9 Revision: June 15, 2007

50 Business Activity Protocols Section V: Atomic Transactions WS-BusinessActivity is a coordination type designed to leverage the WS-Coordination context management framework. It provides two very similar protocols, each of which dictates how a participant may behave within the overall business activity. The BusinessAgreementWithParticipantCompletion protocol, which allows a participant to determine when it has completed its part in the business activity. The BusinessAgreementWithCoordinatorCompletion protocol, which requires that a participant rely on the business activity coordinator to notify it that it has no further processing responsibilities. Business activity participants interact with the standard WS-Coordination coordinator composition to register for a protocol All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-10 Revision: June 15, 2007

51 Business Activity Coordinator Section V: Atomic Transactions Activation Service Registration Service Participants Business Activity Coordinator BusinessAgreementWithParticipantCompletion BusinessAgreementWithCoordinatorCompletion All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-11 Revision: June 15, 2007

52 Section V: Atomic Transactions Atomic Transaction Atomic Transaction Service B Service C Atomic Transaction Service A Service D Service E Service F Service G All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-12 Revision: June 15, 2007

53 Business Activity and SOA Section V: Atomic Transactions atomic transaction can encompass defines protocols for business activities manages longorchestrations can implement protocols defined in provides transaction features for loose coupling composability interoperability reusability extensibility vendor diversity discoverability quality of service coordination complex activities web services All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-13 Revision: June 15, 2007

54 Section V. Atomic Transactions Section V: Atomic Transactions Unit Summary After successfully completing this section, you should be able to: Understand the use of atomic transactions Illustrate the different protocols with WS- AtomicTransactions Discuss WS-BusinessActivity coordination Depict the capabilities of atomic transactions with SOA architecture All rights reserved, no unauthorized duplication Unit 5. Atomic Transactions 5-14 Revision: June 15, 2007

55 Section IX: Service Modeling Section IX: Service Modeling All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-1 Revision: June 15, 2007

56 Section IX. Service Modeling Section IX: Service Modeling Unit Description In this unit, the student will be introduced to the basics of SOA service modeling, the basic steps of modeling, decomposing business processes, identifying agnostic services, analyzing processing requirements, basic service modeling guidelines, locating task-centric business services, incorporating orchestration, intra-process and cross-process reusability, creating a balanced model, establishing standards and denoting roles The instructor-led lecture is supplemented with a series of hands-on case studies to reinforce all of the SOA analysis and design concepts discussed in this section. Unit Objectives After successfully completing this section, you should be able to: Understand the basic steps for SOA analysis Illustrate decomposition of business processes Define agnostic services Perform analysis of processing requirements Denote basic service modeling guidelines Locate task-centric business services Utilize the principles of orchestration Understand cross and intra-process reusability Create a balanced SOA model All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-2 Revision: June 15, 2007

57 Section IX: Service Modeling Section IX: Service Modeling Overview All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-3 Revision: June 15, 2007

58 Section IX: Service Modeling Service-Oriented Analysis Process Service-oriented analysis Step 1 Define analysis scope Step 2 Service-oriented design Identify automation systems Step 3 Service development Model candidate services Service testing Service deployment Service administration All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-4 Revision: June 15, 2007

59 Service Modeling Steps Section IX: Service Modeling All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-5 Revision: June 15, 2007

60 Service Modeling Steps Section IX: Service Modeling All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-6 Revision: June 15, 2007

61 Service Modeling Guidelines Section IX: Service Modeling Take into account potential cross-process reusability Consider potential intra-process reusability of logic Fact in process-related dependencies (taskcentric business services) Model for cross-application use Speculate on further decomposition Identify logical units of work with explicit boundaries Prevent logic boundary creep Emulate process services when not using orchestration (task-centric services) Target a balanced model Allocate appropriate modeling resources Create and publish business service modeling standards All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-7 Revision: June 15, 2007

62 Service Modeling Guidelines Section IX: Service Modeling Take into account potential crossprocess reusability Consider potential intra-process reusability of logic Fact in process-related dependencies (task-centric business services) Model for cross-application use Speculate on further decomposition Identify logical units of work with explicit boundaries Prevent logic boundary creep Emulate process services when not using orchestration (task-centric services) Target a balanced model Allocate appropriate modeling resources Create and publish business service modeling standards All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-8 Revision: June 15, 2007

63 Cross-Process Reusability Section IX: Service Modeling Identifying an opportunity for reuse is an important consideration when grouping operations into service candidates Identifying a real opportunity for reuse is an important consideration when grouping operation candidates into service candidates. It introduces the potential of leveraging existing units of business logic and creating a modularized enterprise business model. A knowledge of other business processes in existence or in development within an enterprise is required to recognize reuse opportunities for task centric business service candidates. All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-9 Revision: June 15, 2007

64 Intra-Process Reusability Section IX: Service Modeling The ability for a unit of business logic to be reused within a single business process is very valuable as complex workflows repeat processes This is the ability for a unit of business logic to be reused within a single business process. Larger, and more complex workflows will sometimes repeat collections of process activities. If this redundancy is consistent and if the logic represented by these process steps is sufficiently atomic, then you can consider wrapping them in to a business service candidate. All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-10 Revision: June 15, 2007

65 Prevent Logic Boundary Creep Section IX: Service Modeling Boundary creep can happen due to: Services in different business processes are created at different times Services in different business processes are created at different times. The logic encapsulated overlaps but is not the same. Services are derived from the same business process at different times, common when variations of the process exist. Steps to reduce risk Check available metadata documentation of existing services prior to defining new service candidates Implement a set of standards to be used by all model services Raise awareness among those involved in modeling All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-11 Revision: June 15, 2007

66 Emulate Process Services Section IX: Service Modeling The introduction of the orchestration service layer changes the complexion of business and application service layers, as it establishes one or more parent controller services that pretty much control the show. If you are building business services without the use of process services, you can take steps to minimize the impact of a future move to an orchestration-based model. The best way to prepare taskcentric services is to have them emulate the process service. This means creating and positioning parent business service candidates to like the process services that would normally form the orchestration service layer. All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-12 Revision: June 15, 2007

67 Balanced Model Target Section IX: Service Modeling Services are rarely modeled to perfection and we should accept this reality instead of wasting effort attempting to achieve an unrealistic goal By integrating these different modeling components we will often introduce conflcting modeling requirements. Thus, it is important to achieve a balance in you service candidates that accomplishes your goals, as you ve prioritized them. The quality of a service candidate can be measured by how well its model will address an organization s short-term and long-term goals. All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-13 Revision: June 15, 2007

68 Allocate Modeling Resources Section IX: Service Modeling A service-oriented enterprise is characterized by how the business end of an organization relates to the technology responsible for its automation. Service-orientation fully supports and enforces the vision of business-driven solutions, where automation technology is designed to be inherently adaptive so that it can respond to changes in the governing business logic. Limiting the application of service-orientation principles to the technical staff can inhibit SOA s potential of realizing our vision. Technical architects and developers do not possess the depth of business knowledge required to model our services with quality. All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-14 Revision: June 15, 2007

69 Publish Modeling Standards Section IX: Service Modeling Standards provide a guideline for implementing service modeling within your organization that should be formalized as official standards All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-15 Revision: June 15, 2007

70 Section IX: Service Modeling SOE Model The building blocks in the initial layer classify logic encapsulated by business service candidates only. They provide an abstract representation of a service-oriented enterprise s business intelligence, independent from the underlying technology platform where they are implemented. If we ever wanted to replace our technology platforms, we can do so while continuing to preserver our abstract, service-oriented perspective of enterprise business logic. All rights reserved, no unauthorized duplication Unit 9. Service Modeling 9-16 Revision: June 15, 2007