Dr. Hans-Peter Hoidn Executive Architect, IBM Distinguished IT Architect (Opengroup) Enterprise IT Architectures SOA (Service Oriented Architecture)
SOA Introduction 2
Agenda of this Session Enterprise IT Architectures Last Session: Introduction of BPM (Business Process Management) Focus on Capturing processes and automated execution This Session BPM needs to be augmented by integration to applications, components, services, data bases etc. SOA provides the mechanisms to do integration ( Integration Platform ) such that both sides of an integration are independent Methodology to structure distributed applications including business processes as well as user interfaces 3
Positioning of SOA Finance & Ops Invoice Reconciliation Teams Executive Management Customer Service Account Administration BPM Now focusing on the Integration Platform SOA Systems 4
What is SOA SOA is an architectural style or approach whose goal is to achieve loose coupling among interacting software agents All functions (that need to be used by more than one system) are defined as "services Service providers agree to a defined, implementation-independent interface with service clients Services oriented architecture is the policies, practices and frameworks that enable application functionality and IT services to be provided and requested as a set of services using a standards based form of interface. 5
Service Oriented Architecture Moves IT Logic Out of Services Information Factory Customers Web Orders Inventory Shipments Sales Orders Services defined as units of business logic separated from Flow of control and routing Data transformation and protocol transformation 6
SOA addressing IT as well as Business common shift 7
SOA is different things to different people A set of services that a business wants to expose to customers and clients an architectural style which requires a service provider, requestor and a service description. a set of architectural principles and patterns which address characteristics such as modularity, encapsulation, loose coupling, separation of concerns, reuse, composable and single implementation. A programming model complete with standards, tools, methods and technologies such as web services. Roles Business Architecture Implementation 8
SOA Key Concepts 9
Key Models and Methods for SOA Enabling greater flexibility in Enterprise IT Architectures SOA Lifecycle SOA Reference Architecture Business Services Development Services Interaction Services Partner Services Process Services Enterprise Service Bus Business App Services Infrastructure Services Information Services Access Services Apps & Info Assets Management Services The SOMA Method: Service-Oriented Modeling and Architecture Startup / Adoption << Input from: Business Analysis & Existing Assets>> Identification of Candidate Services and Flows Specification of Services, Components, and Flows Realization Decisions, Solution Templates & Patterns, Architecture, Technology Feasibility Implementation Build/Assembly, Testing Service Consumer Service Provider consumers business processes process choreography services atomic and composite service components operational systems The SOA Solution Stack: Layered solution view JService Portlet WSRP B2B Other Packaged Application Custom Application OO Application Integration (Enterprise Service Bus Approach) QoS Layer( Security, Management, and Monitoring Infrastructure Service) Data Architecture and Business Intelligence Governance 10 Deployment Packaging and Provisioning Composite Service Atomic Service Registry
SOMA (Service Oriented Modeling and Architecture) provides SOA Methodology SOMA is about identification, specification, realization, implementation, and deployment of services, components and flows SOMA Method SOA Solution Stack Startup / Adoption << Input from: Business Analysis & Existing Assets>> Identification of Candidate Services and Flows Specification of Services, Components, and Flows Realization Decisions, Solution Templates & Patterns, Architecture, Technology Feasibility Implementation Build/Assembly, Testing Service Consumer Service Provider consumers business processes process choreography services atomic and composite service components operational systems JService Portlet WSRP B2B Other Packaged Application Custom Application OO Application Integration (Enterprise Service Bus Approach) QoS Layer( Security, Management, and Monitoring Infrastructure Service) Data Architecture and Business Intelligence Governance Deployment Packaging and Provisioning Composite Service Atomic Service Registry 11
Data Architecture and Business Intelligence QoS, Security, Management, and Monitoring Infrastructure Service Integration (Enterprise Service Bus Approach) Enterprise IT Architectures SOA Layered View (Solution Stack) JService Portlet WSRP B2B Other consumers business processes process choreography Service Consumer services atomic and composite service components OO Application Custom Application Packaged Application operational systems Service Provider Composite Service Atomic Service Registry 12
IBM SOA Foundation Reference Model Strategy and Planning Services Business-driven Enterprise Architecture and Standards Business Services and Events Supports the specification of enterprise business solutions through business architecture Development Services Integrated environment for design and creation of solution assets Interaction Services Enables collaboration between people, processes & information Partner Services Connect with trading partners Process Services Orchestrate and automate business processes Enterprise Service Bus Business Application Services Build on a robust, scaleable, and secure services environment Asset and Registry Services Infrastructure Services Optimizes throughput, availability and utilization Lifecycle Services Information Services Manages diverse data and content in a unified manner Access Services Facilitate interactions with existing information and application assets Management Services Manage and secure services, applications & resources 13
The SOA Lifecycle (to be addressed in detail in Governance) Discover Services Construct & Test Services / UIs Compose Services Orchestrate Processes Integrate People Integrate Processes Manage and integrate Information Gather & Model Requirements Model & Simulate Model SW Architecture Financial Transparency Business/IT Alignment Process Control Manage Applications & Services Manage Identity & Compliance Monitor Business Metrics 14
Identification and Specification of Services (SOMA) 15
Top-Down (Ideal) Approach for SOA Start with Business Design Business Components (CBM) Service Modeling (SOMA) SOA Realization Step 1: Break down your business into components Decide what is strategically important, and what is just operations in the value chain domains Analyze the different KPIs attached to these components Prioritize and scope your transformation projects Step 2: Define a Service Model Identify your services based on your business components Specify the services and components accordingly Make SOA realization decisions based on architectural decisions Step 3: Implement a Service Model Develop a service-oriented architecture to support the Componentized Business Implement service based scoping policy for projects Implement appropriate governance mechanism Business-Aligned IT Architecture 16
Example: Business Context Diagram for Business Process Open Account (Solution Viewpoint) Customer CSR (Store) Account Manager (HQ) Account Open Request Account Open Request New Account Request Account On-Boarding eforms Account Requests Decision Portal Real-time Collaboration re: Account History Forms Account History Credit Scoring Partner Account Owner (HQ) 17
Business Process Reality and Plans Streamline Business Process Derive Requirements To Be Process Model Process Step As Is Process Model 18 Gap Overlapping
Example: Use Case for JKE s Open Account 19
SOA Modeling Constructs Enterprise IT Architectures Business Processes (Flows) Services Atomic and Composite Service Components <<Object>> <<Object>> <<Object>> SOMA was created to specifically address modeling of all three constructs. 20
Introducing SOMA (Service Oriented Modeling and Architecture) SOMA is a business-driven modeling and design method SOMA provides in-depth guidance on how to move from the business models to the IT models required by SOA SOMA adds new service-oriented aspects and techniques in intelligent ways to enable an SOA with services directly traceable to business goals and requirements 21
At the heart of SOMA is identification, specification, realization and implementation of services, components and flows Governance Startup Solution Template, Method Adoption Identification of Candidate Services and Flows Specification of Services, Components, and Flows Realization Decisions, Templates, Patterns, Feasibility Implementation Deployment Close Monitoring & Management Design is separated in Identification and Specification Realization are mainly decisions on how to implement, buy, or use existing assets Implementation and Deployment as classical Software Engineering 22
SOMA defines What we do and How we do it What we do? How we do it? 23 Identification of candidate services and flows, leverageable existing assets Specification of services to be exposed, flows, and components (for realization of functionality) Realization captures realization decisions, selects solution templates, details SOA Solution Ref. Arch. Implementation incl. construction/ generation, assembly, testing, deployment, monitoring and management Domain Decomposition Component Flow Specification Information Specification Solution Template & Pattern Selection Solution Template Unit Testing Input from: Business Analysis & Existing Asstes Subsystem Analysis Component Specification Governance Goal-Service Modeling Realization Decisions Technical Feasibility Exploration Construction Generation Integration Testing Service Specification Deployment (Packaging/Provisioning) Monitoring & Management Existing Asset Analysis Service Flow Specification Message & Event Specification Detail SOA Solution Architecture Assembly Integration User Acceptance Testing
Identifies Services Domain Decomposition (Top-down Analysis) Process Decomposition Functional Area Analysis Information Analysis, Modeling, and Planning Rule and Policy Analysis Variation-Oriented Analysis Existing Asset Analysis (Bottom-up Analysis) Goal-Service Modeling Additionally, Service Refactoring and Rationalization Service Litmus Tests Exposure Decisions, including Exposure Scope Identification Specification Realization Implementation Deployment Domain Decomposition Component Flow Specification Information Specification Governance Startup Selection of Solution Templates, Method Adoption Solution Template & Pattern Selection and Instantiation Construction Unit Testing Subsystem Analysis Component Specification Goal-Service Modeling Realization Decisions Technical Feasibility Exploration Generation Integration Testing Existing Asset Analysis Service Flow Specification Service Specification Message & Event Specification Deployment (Packaging/Provisioning) Close Monitoring & Management Governance Detail SOA Solution Architecture Assembly Integration User Acceptance Testing Id Services, Components, and Flows Build/Assembly Testing 24
Service Identification Through 3 main Complimentary Techniques Domain Decomposition Top-down Analysis Business Rules Business Use Cases Goal Service Modelling Service Candidates Variation Oriented Analysis Existing Asset Analysis Data Analysis 25 Bottom-up Analysis
Service Design via SOMA Service Identification p p JK Enterprises Process Decomposition Functional Area Process Sub - Process Domain Decomposition Techniques: Process Modeling Tools Design of KPIs/Metrics Services Identified Open Account Account Activation Account Verification Goal Service Modeling Techniques Requirements Planning Tools Design of KPIs/Metrics Services Identified Determine Applicant Eligibility Address Verification Existing Asset Analysis Techniques Asset Analysis Tools Interviews/Documentation Services Identified Account Inquiry (CICS 2.2) AR Setup (CICS 2.2) Account Setup (CICS 3.1) Create Account (SAP) 26
JK Enterprises Service Exposure Decisions Example: Domain Decomposition Business Process Modeling for JKE s Open Account 0.Open Account 1.1 Account Inquiry 1.2 Account Verification 1.3 Account Activation 1.2.1 Determine Eligibility 1.2.2 Address Verification 1.3.1 AR Setup 1.3.2 Account Setup 1.3.3 Create Account 27
SOMA Specification uses comprehensive techniques to specify Services, Flows, and Service Components that Realize Services 28 Information Specification Data Model, Message Model, Business Glossary Existing Asset Analysis Fine Grained Determine the technical viability of existing applications and approaches to realize services Service Specification Elaborates the Service Model, for example, service dependencies, service composition and flow, rules and policies, event specification, service operation, service message specification, QoS requirements, design decisions, and so on Subsystem Analysis Partitions subsystems into service components that will be responsible for service realization Component Specification Details component modeling, flow, information architecture, messages Identification Specification Realization Implementation Deployment Domain Decomposition Component Flow Specification Information Specification Solution Template & Pattern Selection and Instantiation Construction Unit Testing Governance Startup Selection of Solution Templates, Method Adoption Subsystem Analysis Component Specification Goal-Service Modeling Service Specification Realization Decisions Technical Feasibility Exploration Generation Integration Testing Deployment (Packaging/Provisioning) Close Monitoring & Management Governance Existing Asset Analysis Service Flow Specification Message & Event Specification Detail SOA Solution Architecture Assembly Integration User Acceptance Testing Build/Assembly Testing
Service Litmus Tests Are Gating Criteria Used to Determine If a Candidate Service Should Be Exposed Candidate Services Service Service Service Service Service Litmus Tests 1. Business Alignment 2. Composability 3. Consolidation (Redundancy Elimination) 4. Technical Feasibility 5. [Externalized Service Description] 6. Project Defined/Customer Specific SLTs Exposed Services Service Service 29
JK Enterprises Service Exposure Decisions Example: JK Enterprises Service Exposure Decisions 0.Open Account 1.1 Account Inquiry 1.2 Account Verification 1.3 Account Activation 1.2.1 Determine Eligibility 1.2.2 Address Verification 1.3.1 AR Setup 1.3.2 Account Setup 1.3.3 Create Account Legend = Service to be exposed 30
Service Model Service Identification Service Portfolio Service Hierarchy Service Exposure Service Dependencies Service Specification Service Composition & Flow Service Operations Service Messages Service Non-Functional Requirements State Management Decisions Service Realisation Service Implementation Solution Templates Technical Feasibility Mapping to Reference Architecture Assemble Deploy Manage 31
SOMA Realization (Includes SOA Solution Stack Instantiation) 32 Select and instantiate Solution Templates and Patterns Technical Feasibility Exploration Examine approaches to handle client requirements Examine legacy application specific considerations Detail SOA Solution Stack Realization Decisions Consider alternatives Select the alternative Provide justification Identification Specification Realization Implementation Deployment Domain Decomposition Component Flow Specification Information Specification Solution Template & Pattern Selection and Instantiation Construction Unit Testing Governance Startup Selection of Solution Templates, Method Adoption Subsystem Analysis Component Specification Goal-Service Modeling Service Specification Realization Decisions Technical Feasibility Exploration Generation Integration Testing Deployment (Packaging/Provisioning) Close Monitoring & Management Governance Existing Asset Analysis Service Flow Specification Message & Event Specification Detail SOA Solution Architecture Assembly Integration User Acceptance Testing Build/Assembly Testing
Iterative SOA Solution Design Process As SOMA is applied during an engagement, we incrementally populate an architectural overview ( dashboard view ) of the SOA Solution 1 2 Customer Portal Customer Order Entry FAA F A A SAP CRM P D P D cs1 s1 s1 s1 s1 s2 s1 s1 s3 s4 cmp1 Portal1 WAS P D Cust DB MsgBroker XI DataPower WSRR GetCustInfo 3 33
SOA Layered View Details 34
Layer 1: Operational Systems (Leverage Existing Investment) Operational Systems (Applications & Data) ISV SAP Outlook Custom Application OO Application Examples for illustration: specifics are not in the scope of the reference model. Custom Apps Supporting Middleware MQ DB2 Recognizes the value of existing IT investment Use of existing legacy applications (e.g. COBOL application) and / or packages (e.g. SAP) Some SOA Related Activities: Asset Inventory Refactor existing applications to unlock business value 35
Layer 2: Service Components Enterprise IT Architectures Service Components Application B WS Client The Service Component Layer: Enables IT flexibility by strengthening the decoupling in the system. Decoupling is achieved by hiding volatile implementation details from consumers. Often employs container based technologies like EJBs Each Service Component: XML via HTTP. Service A Service Component A Package X Application Y Provides an enforcement point for service realization Offers a facade behind which IT is free to do what they want/need to do 36
Layer 3: Services (Decouple Business and IT) Services atomic and composite The Services Layer forms the basis for the decoupling of Business and IT. Captures the functional contract (incl. QoS Quality of Service) for each standalone business function or each task in a business process The assumption is that (within an SOA) IT responsibility is to realize/manage service implementations that faithfully conform to the set of services in the service model. This layer contains all the exposed services in the SOA Each service is a contract between the consumer(s) and the provider(s) 37
Layer 4: Business Processes (Business process alignment of IT) Business Process Composition; choreography; business state machines This layer contains operational IT artifacts that implement business processes as a choreography of services The set of services that are composed is restricted to those services that are defined in Layer 3 The choice of technology depends on a set of realization decisions that must be made when establishing a physical Reference Model for a given SOA 38
Layer 5: The Consumer Layer (Channel independent access to business processes ) Consumers Portal WSRP Ajax B2B <other> This layer exists to recognize that the technology chosen to expose Business Processes/Services must permit access from a wide set of interaction channels. It is important to populate this layer with the set of channels types that are required in a solution. 39
Cross-cutting concerns/capabilities 5 6 7 8 9 4 3 2 1 Integration (Enterprise Service Bus) Quality of Service (Security, Management & Monitoring Infrastructure Services) for illustration: this is not saying that SOA requires an ESB. Data Architecture (meta-data & services) & Business Intelligence Governance Several concerns are not restricted to a single layer in the Reference Model, these concerns are captured in Layers 6-9 These are not really layers but treating them as such gives us the ability focus discussions/decisions, for example What is found where Governance intersects Services? i.e. what are the Governance concerns specific to Services? Clearly there is interaction among these layers also. For example, it is likely that most data architectures will be subject to governance 40
Example JK Enterprise a virtual company with an Open Account Process Consumers Sales Application Central Office Sales Application Regional Office Open Account Business Process Composition; choreography; business state machines Account Activation Account Verification Determine Applicant Eligibility Address Verification Services atomic and composite Account Inquiry indirect exposure AR Setup indirect exposure Account Activation Account Setup direct exposure Create Account Determine Eligibility create from scratch Address Verification third-party reuse Service Components EJB Message Flow SCA EJB Operational Systems (Applications & Data) Customer (CICS 2.x) Billing (CICS 3.1) GL (SAP) 41
Designing BPM / SOA Application: Process Modeling Funktionaler Sollprozess Entstörung CS Residential Customers - Diagnose Optionale Schritte entsprechend Diagnoseablauf Channel (IVR/ACD/CTI) Unified GUI Diagnosemanagement Ticketing CRM Fieldforce Management Inventory Outage Impact Management Korrelation Messen und Prüfen Device Management Material Management Kundenanruf Anschlussidentifikation Anschlusskennung Diagnosestart Kundeninformation JA Netzstörung? NEIN Anschlusskennung Netzstörung Statistiksegement Anzeige Kundendaten Anzeige Ticket Kundendatenabfrage Ticketrequest Anschlusskennung Kunden-, Kundendaten, Verrechnungsdaten Verrechnungssperre Anschlusskennung Anschlusskennung Ticketerstellung Kundendaten Modeling Kundeninformation Anzeige Verrechnungssperre Verrechungssperre? JA NEIN Anschlusskennung Technische Servicedaten Servicedaten Anzeige Meßwerte Initiale Messungen Meßrequest (Messung, Ressource) Meßwerte Messungen, Prüfungen Verarbeitung Messwerte Kundeninteraktion Servicedatenabfrage Kundeninteraktion Anzeige/ Eingabe Anzeige Meßwerte Spezifische Messung Meßrequest (Messung, Ressource) Meßwerte Messungen, Prüfungen Anzeige Konfigurations daten Abfrage Konfiguration 1/1 Abfragerequest (Resource, Service) Konfigurationsdaten Konfigurations daten Abfrage Konfigurations daten 42
Designing BPM / SOA Application: Layered View Architecture Integration of Legacy 43
Home Work: Exercise Layered View Usually a diagram (or set) which is used as a basis for discussion and explanation. Assume you will create many iterations of this document. Should contain processes, services, components, and operational systems 44
Exercise SOA Solution Layer Perspective Add Missing Components Among the missing artifacts from this diagram, the Service Components (service realization) Also missing are To-Be supporting operational systems 45
SOA Reference Model 46
IBM SOA Foundation Reference Model Strategy and Planning Services Business-driven Enterprise Architecture and Standards Business Services and Events Supports the specification of enterprise business solutions through business architecture Development Services Integrated environment for design and creation of solution assets Interaction Services Enables collaboration between people, processes & information Partner Services Connect with trading partners Process Services Orchestrate and automate business processes Enterprise Service Bus Business Application Services Build on a robust, scaleable, and secure services environment Asset and Registry Services Infrastructure Services Optimizes throughput, availability and utilization Lifecycle Services Information Services Manages diverse data and content in a unified manner Access Services Facilitate interactions with existing information and application assets Management Services Manage and secure services, applications & resources 47
Separation of Concerns: Example Open Account Process The SOA Reference Architecture in Action Business Dashboard Open Account Development Services Business Services and Events Business-driven Enterprise Architecture and Standards Interaction Services Process Services Information Services Enables collaboration between Portal people, processes & information Orchestrate and automate business processes Manages diverse data Federated in a unified manner Query IT Service Management Integrated environment Approval for design and creation of solution assets Partner Services Business App Services Access Services Build on a robust, CICS Facilitates interactions DB Connect Community with trading scaleable, EJBs and secure Access with existing Siebelinformation Access Manager partners Facilitates communication ESB between services services environment Apps & Info Assets and application Adapter DB assets Access Manage and secure services, applications & resources Infrastructure Services Optimizes throughput, availability and performance IT Management Console 48
ESB (Enterprise Service Bus) 49
ESB (Enterprise Service Bus) Definition and Purpose An Enterprise Service Bus (ESB) is an architectural pattern defining a flexible connectivity infrastructure for integrating applications and services. The architecture pattern is a guiding principle to enable the integration and federation of multiple service bus instantiations. An ESB performs: Routing messages between services Converting transport protocols between requestor and service managing multiple protocols Transforming message content between requestor and service Handling business events from disparate sources 50
ESB (Enterprise Service Bus) Service Virtualization ESB acts as an intermediary (proxy) between requestor and provider ESB provides service virtualization of Location and identity Interaction protocol Interface Interactions are decoupled, supporting separation of concerns 51
ESB is today s technology Enterprise IT Architectures Lines of maintainable code Direct Connectivity (No middleware) Connectivity, mediation & custom adaptation logic Application Message Queuing / CORBA Connectivity logic Mediation & custom adaptation logic Application Enterprise Application Integration Connectivity and mediation logic Custom adaptation logic Application Enterprise Service Bus Connectivity, mediation & custom adaptation logic Application as a service All connectivity, mediation and custom logic buried within the application. Removes the connectivity logic from the application Removes the connectivity + mediation logic from the application Reduces application to its core business functions (i.e. a service) Reduced development and maintenance; increased flexibility and reuse 52
ESB Pattern in Action Retail Scenario Enterprise Business Functions Adapter Adapter Adapter App Server SWO POS JMS ESB Message Queuing Store i ESB Mediations (routing) SWO SOAP/HTTP, Other SWO App Server POS Terminals Services POS SOAP/HTTP 53
Standard SCA (Service Component Architecture) for Common Invocation Interface: How to call this component Component Uniform Representation of encapsulated Implementation Reference: What this components calls Encapsulate components for reuse All components (e.g., services, rules, human interactions) are represented consistently and invoked identically 54
Standard SCA (Service Component Architecture) Component Assembly Business Rule: Get Customer Status doorder Process: Order Human Task: Approve Order Interface Map Convert to DB2 Adapter for Relational DB DB2 55
SCA (Service Component Architecture) Example Part 1 Modules: Encapsulate and Reuse Functionality Libraries: Share common definitions Customer Status Business Rule: Get Customer Status Module: Customer Status Get Customer Status doorder Process: Order Approve Order Approve Order Human Task: Approve Order Module: Approve Order Manually Module: Process Order Store Order BO:Order IF: StoreOrder Library: OrderLib Store Order Interface Map Convert to DB2 Module: Update Order Database Adapter for Relational DB DB2 56
SCA (Service Component Architecture) Example Part 2 Store Order in SAP instead of DB2 No effect on common objects or consumers doorder Process: Order Get Customer Status Approve Order Customer Status Business Rule: Get Customer Status Module: Customer Status Approve Order Human Task: Approve Order Module: Approve Order Manually Module: Process Order Store Order BO:Order IF: StoreOrder Library: OrderLib Store Order Interface Map Convert to SAP Module: Update Order SAP Adapter for SAP 57
Expanded View of the Enterprise Service Bus Interaction, Interaction, Process, Process, Information, Information, Partner, Partner, Business Business App, App, Access Access Services Services Business Logic Enterprise Service Bus Interaction Patterns Message Flows Flows Mediation Patterns Message Models Models Transport Protocols Security Management IT Management Services Registry 58
ESB Multi-protocol Exchange Intermediary decoupling heterogeneous consumers and suppliers Tooling Domain of interest - Intranet Exchange WebSphere (WAS/Portal) SOAP/JMS SOAP/JMS WebSphere provider.net Client SOAP/HTTP SOAP/HTTP.NET provider Some Client XML/HTTP ESB XML/HTTP Some provider XML/MQ COBOL Copybook/MQ XML/MQ Client CICS Text/MQ Text/MQ Client 59
Example of ESB use Consumers Sales Application Central Office Sales Application Regional Office Open Account Business Process Composition; choreography; business state machines Account Activation Account Verification Determine Applicant Eligibility Address Verification Services atomic and composite Account Inquiry indirect exposure AR Setup indirect exposure Account Activation Account Setup direct exposure Create Account Determine Eligibility create from scratch Address Verification third-party reuse Service Components EJB Message Flow SCA EJB Operational Systems (Applications & Data) Customer (CICS 2.x) Billing (CICS 3.1) GL (SAP) 60
Example A of ESB use: Multiple Channel Access to Backend Service Integration Developer Review Export and Import Review Export and Import Build mediation flows Build mediation flows Deploy Service Module Deploy Service Module ESB Account System Java Client Appl High Value Accounts J2EE Appl SOAP/ HTTP XML/ JMS Service Export (ACT) Service Export (HVA) Service Component Eligibility Mediation Transform Request/Response Business Transform Objects Log Message Infos Request/Response Determine Eligibility Service Module Service Import HQ Eligibility SOAP/ HTTP Applicant Eligibility Service J2EE Appl 61
Example B of ESB Use: Create SAP Service Websphere Integration Developer (WID) Test Client Enterprise Service Discovery Deploy Deploy Adapter Adapter Discover Discover Enterprise Enterprise Service Service Generate Generate BAPI BAPI Business Business Objects Objects Deploy/Test Deploy/Test Service Service Import Import ESB Service Import SAP Outbound Business Objects WebSphere SAP Adapter RFC/ BAPI SAP Create New Customer Record Create Account Service Module 62
Interaction Services 63
Interaction Services: Using Portal As the Front End of SOA Presentation Services Web Browser Rich Clients Mobile Client MS Office & Windows eforms Xforms 64
What is an Interaction Service? UI Portlets 1 2 3 4 Portlets can be A Service Consumer (1) A Service Provider (3) Portlets can Initiate processes (1) Act as a Participant in a process (3) Communicate with each other Enterprise Service Bus Service A Service B Service C Service D WMQ SOAP/HTTP SOAP/JMS HTTPS 3 1 Request/Response Coarse Grained Request Fine Grained Request/Response Fine Grained Request/Response Coarse Grained 65 The Portal Framework Provides Service Aggregation
Information Services 66
Information Services in SOA Reference Architecture Delivering actionable information to people and processes Connect, enhance and deliver in-context information across diverse operating systems, applications and legacy systems through reusable services The Information Services enables consistent views and maintenance of data and content, providing a single view of the truth to people and processes 67
Information Services: Several Patterns Account Open Process Account Open Process Account Open Process Account Open Process Store/Retrieve Application Lookup Customer Store/Update Customer Request Documentation XML Account Application Database 1 Account Data 2 Customer Master MDM 3 Account Documents 4 Information Service Enablement Integrated information services Master Data Management Content Management 68
Information Services: Pattern Deliver Your Data Virtualized Through Services As-Is Environment Data resides in disparate sources Manual & redundant integration of data by multiple consumers results in high costs and inconsistent/inaccurate data Slow response time due to inefficient real-time access Federated Data Service Review current accounts (Reporting) Application Solution Characteristics On demand integration instead of redundant data Transparent & optimized access to distributed, heterogeneous sources Results Real-time access to distributed information, fast response time Scalable approach for adding more data sources SOA context Data Virtualization Through Data Federation Server Legacy Database account data traditional context Legacy Database Metadata 69
Closing Remark 70
Just remember the future might bring more than you think I think there is a world market for maybe five computers. Thomas Watson, chairman of IBM, 1943 Computers in the future may weigh no more than 1.5 tons. Popular Mechanics, 1949 There is no reason anyone would want a computer in their home. Ken Olsen, founder of DEC,1977 71 Prediction is difficult, especially about the future Niels Bohr, 1957 640K ought to be enough for anybody. Bill Gates, 1981
72