Service Oriented Architecture 10 0
Click here to load reader
-
date post
21-Oct-2014 -
Category
Documents
-
view
1.835 -
download
3
description
Transcript of Service Oriented Architecture 10 0
Solution Design
how to design software solutions for business transformation …..
Solution Architecture Topics
6. Software Product Line Development6.1. Carnegie Mellon University Software Engineering Institute Architecture Framework6.2. Agile Model Driven Design6.3. Model Driven Testing
7. Serviced-oriented Architecture Frameworks7.1 Enterprise Services7.2 Enterprise Service Bus7.3 Enterprise Application Integration
8. Solution Architecture8.1. Service-oriented Architecture Frameworks and the Enterprise Service Bus8.2. COTS Package Implementation 8.3. EAI, Collaboration and Process Orchestration
9. Solution Design and Systems Integration9.1. Solution Seeking – COTS Package evaluation and selection9.2. Solution Definition, – Package Module / Function / Service / Process Mapping9.3. Process Integration – Process Orchestration, Workflow, Collaboration9.4. Messaging – Domain Independent Message Design, Formatting, Queuing, Transport, Persistence
10. Business Continuity10.1. Business Continuity Planning – Transition, Capacity. Performance, Resilience, Reliability, Scalability.
11. Service Management Framework11.1. Service Planning & ICT Demand / Supply Model11.2. Service Virtualisation, Integration and Automation11.3. Service Design-Build-Operate11.4. On-demand Service Model
12. System Management Framework
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Software Product Line Development
how to architect Enterprise Business Services…..
Software Product Line Development
• Carnegie Mellon University Software Engineering Institute
– Architecture Framework– Objectives– Approach– Scoping– Understand the relevant Application Domains– Process Definition– Architecture Definition– COTS Utilisation– Model Driven Development– Marketing– Customer Interface Management– Operation– Data Collection, Metrics and Tracking– Structuring the Organisation
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Enterprise / Solution Architecture Framework• In order for our Enterprise / Solution Architecture Framework to deliver
tangible results on a daily basis - we need an Architecture Framework and IS/IT Management Structure acting as a common, shared vision of what we are collectively aspiring to, seeking out and driving towards. Key aspects include: -
– Strategic Enterprise Management (SEM) Framework– IS/IT Strategy and Architecture– Enterprise Architecture Framework
• Carnegie Mellon SEI, TOGAF, Zachman– Development Methods
• Agile, Scrum, RUP, DSDM, Prince, PMP– Enterprise Repository
• Adaptive, ARIS, Computas Metis, PlanningIT, Promise, Provision, System Architect– Visualisation Tools
• Magic Draw, PlanView, Rational Suite, VersionOne, Visual Paradigm, Visual Studio– E2E Requirements Traceability Model– Business Operating Model (BOM) – Technology Operations Model (TOM)– Service-oriented Architecture Framework (SoA / ESB)– Enterprise Service Catalogue / Service Registry
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Architecture Principles
• Understand and capture the rationale behind every Design Decision
• Opt for simple heuristics where a complex generic solution is inappropriate
• Capture important information and experience in a structured Repository
• Provide saleability and promote simplicity through the use of Configuration Management
• The Architecture is stateless; the system can always recover irrespective of when an abnormal termination occurs
• There is no single point of failure; redundancy is supported across the network, database and infrastructure layers
• COTS software components are deployed wherever possible
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Architecture Standards• Front-end Tier (OAG BOM)
– OAG Business Objects Model– Presentation Layer– Process Orchestration Layer
• Core Asset Tier (J2EE, EJB’s, CORBA , JNDI, XML)– Business Application Layer – ERP / CRM / DWH / BI– Collaboration Layer - Workflow, Office, Enterprise Content Management– Enterprise Services (Business Services)– Integration Layer – Messaging, Enterprise Service Bus
• Persistence Tier (JDBC, SQL)– Data Layer– Enterprise Document Management
• Infrastructure Tier– Security Framework (Security Model)– Utilities and Technology Services– System and Application Monitoring, Intelligent Agents and Alerts
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Architecture Diagrams
• Context View – which states the high-level context and scope of the system
• Logical View – which shows the logical description of the system, functional decomposition and functional mapping of the system to process and data
• Use Case View – which presents all the Use Cases, Scenarios, Actors, Objects and Messages supported by the System
• Process View – which captures the concurrency, synchronisation, process orchestration and process execution aspects of the system
• Object View – which models the object attributes / methods / collaboration / messages / interaction / sequence characteristics of the system
• Application View – which describes the physical modules / components / services ofthe system
• System View – which outlines the actual distribution and deployment of software across the Development, Test and Production environments
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Business Operating Model (BOM)
• Requirements are often too ambiguous to accurately develop complex systems - so we use Functional Requirements to design the Business Operating Model, get this signed off by users, and use the BOM as a Design Template for the High Level Design (HLD).
• The High Level Design (Business Architecture or Business Operating Model - BOM) demonstrates our Functional Requirements and consists of the following object types: -
– Organisation Units– Processes– Functions– Business Services– Data Stores– Documents– Messages
• The Enterprise Architecture Framework guides us through Business Model design and specification, helping us to confirm our understanding of the functional requirements - and optimise design pattern re-use.
Technology Operations Model (TOM)
• The Low Level Design (Technical Architecture or Technology Model) consists of defining and aggregating together various Technical Services in order to execute our high-level Business Services as described in the BOM - and also meet our Non-functional Requirements: -
– Presentation Services (GUI, Graphics Engine)– Process Orchestration Services (Process Execution)– Collaboration Services (Workflow, E-mail, MS Office)– Application Services– Integration Services (Messaging)– Data Services (Persistence)– Utility Services– Infrastructure Services
• Our IS/IT Architecture, Service-oriented Architecture Framework and Enterprise Service Catalogue guides us through this complex, iterative architecture design and development activity - helping us to maximise Technical Service re-use.
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Software Product Line Objectives
• Development of Core Assets– Software Product Line Architecture
• Business Operating Model - BOM– Core Asset Components Development
• Technology Operations Model - TOM
• Development of Software Products– Identify Front-end Tier and Core Asset Tier Components– Perform Component Variation and Extension
• Management of the Software Product Line– Enterprise Level Product Management
• Enterprise Repository– Technology Level Product Management
• Enterprise Service Catalogue / Service Registry
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Proactive Software Product Approach
• Proactive Approach
– Development of Core Assets• Product Line Scope / Product Set / Product Space• Product Line Architecture• Core Asset Components
– Development of Products• Identify Core Asset Components• Perform Component Variation and Extension
– Generic Configuration of Core Asset Tier Components– Specific Customisation of Front-end Tier Components– Source or Build New Components
• Assembly and Test• Package and Deliver
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Reactive Software Product Approach
• Reactive Approach
– Initial Stage• Find a Customer / Sponsor / Identify a Template• Build a Prototype / Proof-of-concept System• Harvest Re-useable Components
– New Customer• Identify Common Components• Identify New Components• Perform Component Variation
– Configuration of Harvested Components– Customisation of Harvested Components– Build New Components
• Assembly and Test• Package and Deliver
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Scoping
• A Product Line Scope is a statement of which systems are in and out-of-scope for the Product Line’s declared Business Area
– Proactive – Product Line System Set / Space v. Core Assets– Reactive – Product Line Component Variation v. Harvested Assets
• Product Line Component Variation Objects– Workflow– Forms and Screens– Reports and Data Extracts– Bulk Data Load Requirements
• Perform Component Variation– Configuration of Harvested / Core Asset Components– Customisation of Harvested / Core Asset Components– Build New Components
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Understanding Application Domains
• Application Domain Model - develop a rich set of well-documented Business Use Cases and Scenarios
• Data Domain Model – develop stable core schemas
• Customer Business Object Model - develop a Domain Repository containing the following objects: -
– Business Processes Model– Business Services Catalogue– Technology Services Registry– Canonical Data Models / Schemas / Documents / Message Formats– Forms and Screens– Report Formats and Data Extract and Transformation Definitions– Components / Objects / Attributes– Infrastructure Asset Register
• Embrace any appropriate Domain Reference Models
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Process Definition
• RUP – Rational Unified Process
• VRAPS –– Vision– Rhythm– Anticipation– Partnering– Simplification
• Variation – Façade Design Pattern– Configuration– Customisation– Localisation– Personalisation
• Extreme Agile Programming – twice daily builds
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Architecture Definition
• Stakeholder Drivers– Performance - Runtime Efficiency– Reliability - High Availability– Security - Data Asset Protection– Scalability - Core Asset Exploitation– Configuration Management (CVS)
• Architecture Tiers– Front-end Tier (Customer-specific Business Process Layers)
• Presentation Layer, Process Orchestration Layer– Core Services Tier (Application Layers – ERP / CRM / DWH / BI)
• Application Layer, Integration Layer– Persistence Tier (Storage Layers)
• Database Layer, Content Layer– Infrastructure Tier (Technology Layers)
• Security Framework, Utilities, Technology Services
COTS Utilisation
• COTS Utilisation is about commitment to simplicity without compromising quality: -
– Performance - Runtime Efficiency– Reliability - High Availability– Security - Data Asset Protection– Scaleability - Core Asset Exploitation
• Where any COTS functionality is in doubt and there is no obvious work-around, then do not hesitate to build the required components in-house: -
– If generic functionality will be sufficient – use a COTS product – If a COTS product meets the de-facto standard – use COTS– Otherwise, build the necessary components in-house
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Model Driven Development
• Model Driven Development (MDD) is an area where we can be both innovative and agile - particularly in the areas of: -
– Application Portfolio Management– Redundancy Scanning and Cloning Detection– Configuration Management
• The advantages of the Model Driven Development approach are: -
– Simplifies code– Simplifies build process– Associates all related artefacts– Enforces single Software Product Line
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Stakeholder Management
• Stakeholder Drivers– Performance - Runtime Efficiency– Reliability - High Availability– Security - Data Asset Protection– Scalability - Core Asset Utilisation / Exploitation
• Performance – responsiveness of system
• Security – capability of system to resist security threats
• Availability – the time system is functionally available v. SLA’s
• Usability – support for personalisation / customisation features and functions
• Modifiability – extent to which functionality can be modified or extended by standard configuration features
• Testability – extent to which system supports testing requirements
The Non-functional Requirements
1. Performance Requirements (PR)2. Security Requirements (SR)3. Maintenance and Support Requirements (MS)4. Operational Requirements (OR)5. Usability Requirements (UR)6. Common Look and Feel Requirements (CLAF)7. Environment Requirements (ER)8. Cultural and Political Requirements (CP)9. Compliance Requirements (CR)
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
1. Performance Requirements (PR)
• Performance – the responsiveness of the system under different workload patterns / transaction volumes
• Performance Targets / SLA’s– Target v. Actual Average (Normal Operations) Transaction Volume / Response Time– Target v. Actual Maximum (Peak Operations) Transaction Volume / Response Time– Client / Server - Processor Utilisation - average / maximum– Client / Server - Memory Utilisation - average / maximum– NAS / SAN Storage I/O - average / maximum– Database Read / Write - average / maximum– Network Utilisation - average / maximum– Application Throughput – Concurrent Users / Transaction Throughput
• Performance Model – Response Time– Client / Server - Processor Component– NAS / SAN Storage Component– Database Component– Network Component– Application Components
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
1. Performance Requirements (PR)
• Performance – the responsiveness of the system under different workload patterns / transaction volumes
• Performance Monitoring and Diagnostics– Response Time / Resource Utilisation– Client / Server - Processor Component – no. nodes / processors / utilisation– NAS / SAN Storage Component – Mirroring / RAID Strategy / I/O Waits– NAS / SAN Storage Component – Extents / Working Storage– Database Component - paging & buffers hotspots & contention / parallelism– Database Component – indices & access paths / threads (processes)– Network Component – bandwidth / contention– Application Components – concurrent users / throughput– Dynamic Resource Allocation / Intelligent Agents / System Alerts
• Capacity Model– Resource Sizing / Allocation – Client / Server - Processor Component– NAS / SAN Storage Component– Database Component– Network Component– Application Components
2. Security Requirements (SR)
• Security - the capability of a system to resist unauthorised access attempts and enforce denial of service access to intruders - whilst still providing a full services portfolio to identified, authenticated, authorised and entitled users
• Security Model– Security Policy– Security Principles– Security Standards– Security Process Model– Security Function Model– Security Data Model
• Information Security– Systems and Services– User Security– Resources Security– Security Monitoring and Reporting
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
2. Security Requirements (SR)
• Security - the capability of a system to resist unauthorised access attempts and enforce denial of service access to intruders - whilst still providing a full services portfolio to identified, authenticated, authorised and entitled users
• User Administration– User Identity Management and multi-factor authentication– User (Single) Sign-on and authorisation - LDAP– User Accounts and permissions– User Groups / Roles– User Access Control– User Activity Logging
• Global Asset Conservation and Protection– Enterprise Asset Management– Data Asset Management
• External Threat Management– Threat Identification and Assessment– Threat Avoidance and Mitigation
3. Maintenance and Support Requirements (MS)
• Scalability – how scaleable is the system (Current volume / demand v. Future anticipated growth)
• Extensibility – can the application logic be extended without the need to re-write code / use of industry standard development tools
• Serviceability – can the system operate in a Modular / Component-based / Service Oriented Architecture (SOA) Environment
• Compatibility – does the system support industry standard synchronous / asynchronous transport standards and protocols (JMS, MQ etc.)
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
3. Maintenance and Support Requirements (MS)
• Flexibility – to what extent is the system configurable using standard features and functions / is the code-base available / accessible / understandable / transparent
• Comprehensibility – how consistent / complete / comprehensive is the system documentation
• Upgradeability – ease of application of fixes, patches, upgrades and new releases, configuration management / change management
• Inter-operability – compatibility with industry / open standards, data exchange formats and third-party component versions: -
– Front-end Tier (J2EE, EJB’s, CORBA)– Core Asset Tier (JNDI, XML, OAG BOM)– Persistence Tier (JDBC, SQL)
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
4. Operational Requirements (OR)
• Availability – the time that the system is functionally available (Actual v. Target SLA’s)
• Operability – ease of service design and service delivery / system monitoring and diagnostics, intelligent agents and system alerts
• Supportability – ease of global support, help desk / trouble ticket / support integration (issue / problem register, support knowledge base, known issues bulletin board, global support forum)
• Maintainability – ease of planned and unplanned maintenance, concurrent development (application repository, check-out / check-in / merge / update)
• Upgradeability – ease of implementation of scheduled application upgrades, versions and releases
• Application and System Monitoring – Intelligent Agents and Alerts
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
4. Operational Requirements (OR)
• Configurability – ease of maintenance of “Gold Standard” Configuration Packages / Documentation
• Robustness – error management - error trapping, handling and reporting features and functions
• Reliability – defect management - error incident identification, recording and reporting, causal analysis and rectification features and functions
• Restorability – archive, backup and housekeeping routines, failover and recovery procedures, multi-phase transaction commits / rollback, checkpoint / restart capabilities
• Business Continuity – standby and disaster recovery features and functions
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
5. Usability Requirements (UR)
• Usability – support for personalisation / localisation / customisation application features and functions
• Personalisation - support for personalisation so that users can personalise screens and applications pertinent to their needs (e.g. colours) and be presented with relevant data
• Localisation – support for standard country requirements / languages / character sets
• Customisation – support for features / functions to customise the application to meet the specific needs of different workgroups (e.g. only display those menu functions which are available to that User Group). Accessibility - support for disadvantaged / disabled users.
• Guidance – provide on-line guidance and context-sensitive help and full error messages along with context-relevant process execution and procedure information
• Relevance – system should recognise human cognitive capabilities and limitations, re-present and reinforce key identification / user input data. Filter bulk data for presentation in logical / ergonomic segments and blocks for intuitive recognition and assimilation
• Consistency – support of common standards for GUI look-and-feel to give a consistent user experience within and across applications and / multi-media channels with intuitive (natural, logical, cognitive) mapping and predictability of navigation paths and operations
6. Common Look and Feel Requirements (CLAF)
• Branding, Corporate Image and Group / Company Identityrequirements should be fully supported via muti-media features - the Graphical User Interface (GUI) and Print Output (PO)
• Portability – the User Interface should run on a variety of Web Browsers (Web Browsers, PDA, Mobile Phone etc.)
• The User Experience and Journey must be of a constantly high quality irrespective of how or where the application is accessed (Web Browsers, PDA, Mobile Phone etc.)
• Application Navigation should be simple, logical, seamless and intuitive
• The User Interface should be simple, elegant, informative and intuitive
• Multi-language User Interface support should be provided
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
7. Environment Requirements (ER)
• Environment Management– Are Development, Testing, Integration, Acceptance, Pre-production, Model Office
(Gold Standard / Regression) and Production Environments supported from a software licensing perspective
• Configuration Management– Are Development, Testing, Integration, Acceptance, Pre-production, Model Office
(Gold Standard / Regression) and Production Environments supported from a versioning and control perspective
• Testing Environments– Can the Testing Environments be configured to replicate / mirror the Model office or
Production Environment with minimal effort?
• Test Data– How easily can Test Data be restored / refreshed using standard Application /
Database features and functions?
• Fire Walls– Is the Test Environment completely isolated from the Production Environment to
prevent Transaction Leakage (e.g. external connectivity) from Testing into Production?
8. Cultural and Political Requirements (CP)
• Configuration– Can the System be configured / varied to support the Global Template or “Gold
Standard” Configuration Variation Requirements with minimal effort?
• Customisation– Can the System be configured to support further Division, Segment, Business Unit,
Workgroup and User Customisation Variation Requirements with minimal effort?
• Localisation– Can the System be configured to support Localisation Variation Requirements
(national currency, language, date/time format, double byte characters) with minimal effort?
• Personalisation– Can the System be personalized to support further Division, Segment, Business
Unit, Workgroup and User Personalisation Variation Requirements with minimal effort?
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
9. Compliance Requirements (CR)
• Statutory Compliance– Does the system support federal / state Statutory Requirements?
• Regulatory Compliance– Does the system support federal / state Regulatory Requirements?
• Enterprise Governance– Does the system support Enterprise Governance, Control, Risk and
Financial Reporting Requirements?
• Architecture Governance– Does the system support Enterprise Architecture Strategy, Policy,
Principles and Standards Requirements?
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Agile Model Driven Design
how to design Enterprise Business Services…..
Agile Model Driven DesignSolution Architecture – Part 8Service-oriented Architecture Methodology and Standards V10.0
Qui ne risque rien n'a rien…..
Approaches to AMDD
• There are three basic approaches to applying AMDD on an agile project: -:
– Manual. Simple tools, such as whiteboards and paper, and inclusive modelsare used for modelling. This is likely to represent 70-80% of all business application modelling efforts.
– Design Tool. Inclusive models are used to explore requirements with stakeholders, and to analyze those requirements. Developers then use sophisticated modelling tool for detailed design, generating source code from the models. This is likely to be 20-30% of all business application modelling efforts.
– Agile MDA. Very sophisticated, MDA-based modelling tools used to create extensive models from which working software is generated. At best this approach will be used for only 5-10% of business application modelling efforts.
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Agile Model Driven Design
Figure 1. The AMDD lifecycle: Modelling activities throughout the lifecycle of a project.
Guideline 1 Through initial, high-level modelling you can gain the knowledge that you need to guide the project but choose to wait to act on it.
Agile Sprint Activities
Figure 2. AMDD Through the Agile Development Lifecycle.
Guideline 2 With initial iteration modelling you explore what you need to build so that you can estimate and plan the work for the iteration effectively.
Agile Work Management
Figure 3. Agile requirements change management process.
Why Does AMDD Work?
• AMDD works for several reasons: -• We meet our "project planning needs". By identifying the high-level requirements
early, and by identifying a potential architecture early, you have enough information to produce an initial cost estimate and schedule.
• We manage technical risk. Your initial architecture modelling efforts enable you to identify the major areas of technical risk early in the project without taking on the risk of over modelling your system. It's a practical "middle of the road" approach to architectural modelling.
• We minimize wastage. A JIT approach to modelling enables you to focus on just the aspects of the system that you're actually going to build. With a serial approach, you often model aspects of the system which nobody actually wants.
• We ask better informed questions. The longer we wait to model storm a requirement, the more knowledge we'll have regarding the domain and therefore we'll be able to ask more pertinent questions and elicit better informed, more relevant answers.
• Stakeholders give better answers. Similarly, our stakeholders will have a better understanding of the system that we're building because we'll have delivered working software on a regular basis and thereby provided them with concrete feedback.
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Model Driven TestingSolution Architecture – Part 9Service-oriented Architecture Methodology and Standards V10.0
Il faut le voir pour le croire…..
System Design models v. Test Design models
Test Design model development
Model Transformation
Test Component Transformation
SoA Frameworks
how to design Enterprise Services…..
The Service-oriented Architecture describes the Solution as a set of Services and populates the Topology and Landscape of the Enterprise Architecture with major features and landmarks
Service-oriented Architecture Framework
Service-oriented Architecture Frameworks
• Service Oriented Architecture (SoA) Frameworks. Leading companies are tackling the complexity of their application and IT environments with Service-oriented Architecture (SoA) Frameworks – which facilitates the development of modular business services that can be easily integrated and reused – thus creating a truly flexible, adaptable IT infrastructure. Within an SoA framework, the IT organization will focus more resources and budget on business innovation and on delivering new business services to support the newly transformed, streamlined and enhanced Business Process Stack.
• Service Oriented Architecture (SoA) is a solution architecture implementation for creating, maintaining and using business processes, packaged as business services. SoA also defines and provisions the IT infrastructure to allow different applications to exchange data and participate in business processes. These functions are loosely coupled with the operating systems and programming languages underlying the applications. Enterprise SoA is a framework for an adaptable, flexible, and open IT architecture for developing services-based, enterprise-scale business solutions.
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Types of SoA Framework
• SoA Lite is the Service-oriented Architecture (SoA) Framework for organisations that are primarily deploying simple Web Services - which do not therefore require mission-critical capabilities such as high-volume scalability, high availability, business continuity and fail-over, nor Enterprise Service management, governance, or security.
• SoA ERP is the SoA Framework used by organisations that are choosing to deploy a SoA Framework surrounding their ERP and CRM application software (Microsoft, SAP, Oracle e-Business Suite, PeopleSoft, JDE etc.).
• Enterprise SoA is the Service-oriented Architecture (SoA) Framework for those organisations that require full mission-critical global Enterprise Service deployment capabilities - featuring performance such as high-volume scalability, high availability, business continuity and fail-over, Enterprise Service management, governance, and security, all delivered via a SoA middleware suite - the Enterprise Service Bus.
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
SoA Lite
• SoA Lite is the Service-oriented Architecture (SoA) Framework for organisations that are primarily deploying simple Web Services: -
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
SoA ERP• SoA ERP is the SoA Framework used by organisations that are choosing to deploy a SoA
Framework with Connectors and Adaptors surrounding their ERP and CRM application software: -
• Integrators, Connectors and Adaptors: - SAP Business API and NetWeaver Adaptors, Oracle e-Business Suite, PeopleSoft ETP, JDE Master Business Function, ATG Dynamo and BEA WebLogicAdaptors, Microsoft MSMQ Adaptor, IBM MQSI Adaptor, Sun JMS, JCA and SeeBeyond Adaptors
Enterprise SoA
• Enterprise SoA is a SoA framework for an adaptable, flexible, and open IT architecture designed for developing and supporting services-based, enterprise-scale business solutions which is implemented via a strategic SoA middleware suite - the Enterprise Service Bus: -
ESB Adapter Types
• ESB Adapter types include: -– Database access including relational (e.g. SQL, Oracle, DB2, MySQL etc.),
hierarchical (e.g. IMS), network (e.g. IDMS) and file based (e.g. FTP, SFTP, ADABAS, VSAM, etc.) data sources
– COTS Application Package adapters - using native low level APIs to connect most efficiently (e.g. SAP Business API and NetWeaver Xi, Oracle e-Business Suite, PeopleSoft ETP Adaptor, JDE Master Business Function, etc.)
– Object oriented technology adapters (e.g. CORBA, Enterprise JavaBeans™, COM etc.)
– Web and SoA Protocols (e.g. SOAP 1.2, WSDL 1.2, UDDI 2.0, BPEL4WS / WSBPEL, BPMN, HTTP, CGI, XML, JMS, ADO.NET, RNI, JDBC, EJB, ESB etc.)
– Messaging (e.g. IBM MQSI, JMS, JCA, Sun SeeBeyond eGate, Microsoft BiztalkMSMQ, Information Builders iWay etc.)
– Enterprise Services (e.g. ATG Dynamo, BEA Weblogic, IBM WebSphere, WebMethods, Encina etc.)
– Communication adapters (e.g. SNA, TCP/IP, etc) and Email (e.g. SMTP, POP3, IMAP etc.)
– Screen based integration and HLAPI (e.g. 3270, 5250, VT100, Wise, etc.)
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Enterprise Services
• Enterprise Services. Business Services support the execution of Business Processes. Common function Business Services that are re-useable across the whole enterprise, and are not restricted to one business area or domain, are Enterprise Services. For example, in using “customer”data, the context of “customer” will vary, depending on the role of the consumer of that data. An implementer may manipulate low-level services to support a customer service application that provides call centre agents with a total view of customers’ relationships with the business. The same implementer will manipulate services differently to support a product shipping and tracking application. Common business services inclusive to both of these applications are “Identify Customer” and “Get Customer Details”.
• Technology Services. Business Services are constructed from multiple, elementary Technology Services that may be deployed across multiple computer platforms and environments. The way that these services communicate across enterprises is critical. Each of these services provide a message that is required by some other service. This would mean that these messages have to be transported to these services asynchronously as well as provide a high level of fault tolerance. Moreover any new service should be able to subscribe or be able to publish using the existing Enterprise Service Bus without creating the need for any new transport mechanism.
Enterprise Service Bus
• Service Aggregation. It is rare that one low-level service, such as an SAP Business API or JDE Master Business Function, will produce enough data, in a rich enough context to be useful by itself. At the same time, using too many low-level services directly requires additional interactions betweenservice providers and consumers, which will have a negative effect on application performance. Aggregating low-level services to higher levels helps developers and implementers avoid overly complex, difficult-to-use systems. An implementer will aggregate multiple individual services in ways that vary depending on how the application or process must support the organization.
• Enterprise Service Bus. 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 enterprise services. This construct is typically implemented by technologies found in a category of Middleware, the Enterprise Application Integration product family, which is based on recognized standards, that provide foundation services for more complex architectures via an event-driven and standards-based messaging engine (the bus).
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Enterprise Service Bus
An Enterprise Service Bus (ESB) should provide a standard routing mechanism for a loosely coupled asynchronous Service-oriented Architecture (SoA). It would also allow complex transformation of the messages as needed, as well as provide an interface to integrate across different non standard interfaces.
Figure 1: Diagram showing an ESB with different services connected in a message flow.
Services and Adapters for SOA
ESB
SoA Integrators, Connectors and Adaptors• Legacy applications
– written in a variety of procedural languages that typically do not have well-defined Application Program Interfaces (API’s) for collaborative processing, but functions may be “wrappered” as Remote Procedure Calls
• Object-oriented applications– many different applets developed as components for other applications, such as Enterprise JavaBeans™, COM
Application Servers or CORBA objects etc.• Transaction processing systems
– applications that run under the control of transaction processing monitors such as distributed customer information control system (CICS), IMS Transaction Manager (IMS/TM), BEA Tuxedo, and other TPMS software whose transactions are well suited for incorporation into collaborative business processes
• Packaged application systems– Vendor-supplied, proprietary systems with well-defined, often completely proprietary, collaborative interfaces
such as SAP Business API / NetWeaver Xi Adaptors, Oracle e-Business Suite Adaptor, PeopleSoft ETP Adaptor, JDE Master Business Function Adaptor, etc.
• Databases and file systems– Vendor-supplied, proprietary relational database management systems (RDBMSs), legacy database
management systems (DBMSs), and file systems with varying degrees of standard and proprietary interfaces including relational (e.g. SQL, Oracle, DB2, MySQL etc.), hierarchical (e.g. IMS), network (e.g. IDMS) and file based (e.g. FTP, SFTP, ADABAS, VSAM, etc.) data sources
• Communication transport protocols and message formats– Industry-standard transports such as hypertext transport protocol (HTTP), file transfer protocol (FTP), and
simple mail transfer protocol (SMTP), Sun Enterprise Java Suite Adaptor, SoA Protocols such as XML, SOAP, WSDL, JMS, ADO.NET, RNI, JDBC, EJB, ESB etc.
– Vendor proprietary messaging and queuing systems in a variety of formats for exchanging data between applications, such as IBM WebSphere MQSI, Sun JMS, JCA and SeeBeyond eGate, Microsoft BizTalk MSMQ, BEA e-link (Tuxedo) adaptors
• e-Business exchanges– Proprietary and standards-based public and private exchanges through which businesses collaborate– Proprietary data interchange systems in a variety of formats for exchanging data between collaborating
enterprises, such as Electronic data interchange (EDI), Society for the Worldwide Inter-bank Financial Telecommunication (SWIFT),.
• Application server platforms– application and integration servers that host all manner of Application Service Provider (ASP) applications and
On-demand Services that facilitate collaboration within and between enterprises
Service-oriented Architecture
how to deliver Enterprise Services…..
Enterprise Architecture Context
Organisation Process Data Function Application InfrastructureEnterprise Vision & Mission StatementsBusiness Strategy
Business Transition Strategy
Data Management Strategy
Business Agility Strategy
Information Systems Strategy
Information Technology Strategy
Strategic EA Framework Business Process Re-engineering
Data Architecture Framework
SoA Framework Systems Framework Technology Framework
Enterprise Performance Management Framework
Data Principles, Policies Methods & Procedures
Agile Methods Application Blueprint Infrastructure Blueprint
Application Roadmap Infrastructure RoadmapOperational Strategies & Desired Outcomes,
Process Architecture Data Architecture Service-oriented Architecture
Information Systems Architecture
Information Technology Architecture
Organisation Hierarchy, Establishment Model
Process Model Conceptual Data Model Application Inventory Technology Portfolio
Enterprise Performance Management Strategy
Process Catalogue Data Catalogue Function Catalogue System Regimes Infrastructure Regimes
Data Management Functions
Service Library Asset Hierachy
Process Hierarchy Logical Data Model Function System Asset Meta Data Repository, Business Glossary
Service Module Device
Process Descriptions Data Management Services
Collaborations and Contracts
Unit
Organisation Locations, Posts & Post Holders,
Elementary Business Process
Physical Data ModelData Storage Strategy
Components
KPI’s and Metrics Data Placement Strategy ObjectsPerformance Targets Process Step Data Management
Modules Sites and Addresses, Data PlacementJobs and Employees, Training and Education, Competancies and Skills, Qualities and Capabilities
Database Instances DDL, Tables, Indices, Table Space, Storage Groups
Planned Objectives & Actual Achievements
Data Audit, Data Profiling, Data Quality Reporting
Resources Procedures Information Services Systems Facilities
ComponentACTUAL Procedure Instantiated Objects (Classes)
Executables, Applets
Assembly
Enterprise Architecture Context
STRATEGIC
CONCEPTUAL
Goals, Objectives CSF’s, Organisation Units,Roles & Responsibilities, Performance Plans
PHYSICAL Component
LOGICAL
Service-oriented Architecture Framework
Service Categories
Enterprise Service Principles
• Enterprise Services are : -– Pragmatic to design, create, maintain and use– Serviceable, resilient and robust– Useable and supportable– Traceable, auditable, and recoverable– Scaleable, performant and portable– Cross Platform (Wintel – Solaris – UNIX – Linux)– Extensible and adaptable– Agile, efficient and productive
• Enterprise Services support: -– Business Process Model / Use Case Model / Business Scenarios– Canonical Data Model / Domain Independent Message Formats– Service-oriented Architecture Framework– Application Inventory / Function Library / Service Catalogue– Model Driven Design / Re-useable Design Patterns / Service Re-use– Infrastructure Portfolio
Business Benefits of SoA Framework
• Integrated business systems: -– reduced cycle times / time-to-market, improved customer service– reduced TCO – development, maintenance and operating costs– easier and more accurate decision-making based on up-to-date business
information for "single version of the truth"
• IT cost reduction and control– through standardization of reusable business components (Business Services)
• Improved responsiveness to provide support for new and changed business processes - quickly and effectively
• The ability to respond to special business circumstances and conditions as they occur: -
– Statutory and Regulatory Compliance– Mergers and Acquisitions– Business Transformation– New Product Launch
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Technology Benefits of SoA Framework
• Reduces time and effort to integrate new and existing applications – Supports new business processes through the reuse of existing channel access,
collaboration and orchestration services – Creates new business services through the reuse of existing service catalogue –
presentation, application and data services– Provides Message Management via Messaging Services– Provides Service Management via the Enterprise Service Bus
• Increases flexibility to change complex system behaviour by minimizing the hidden dependencies among applications, services and middleware in a distributed environment
• Reduced Total Cost of Ownership (TCO) and greater flexibility to accommodate future needs through use of industry-standard interfaces and protocols
• Reliably delivers messages across the Enterprise Service Bus, even after software, network or hardware failure – “the message always gets through”
• Provides a service hosting & management infrastructure that is highly distributed, yet centrally managed
• Enables rapid Platform Replacement and Technology Refreshment
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
SoA Strategy, Goals, Principles
SOA Governance Context
UPSTREAMProcesses
AREA IN SCOPE
DOWNSTREAMProcesses
EXTERNAL Entities
INTERNALOrganisation
The purpose of SOA Governance is to balance the goals of Security, Manageability, Maintainability, and Reuse against those of Simplicity, Ease of Use, and Cost Reduction
Systems Integrators
Software Companies
Development Partners
Architecture Team Project
IT Governance
Responsible For
Systems DevelopmentBusiness Analysis
Support, Operations & Decommissioning
SOA Governance
Service Usage
Business Service Discovery
Business Analyst INBOUND - Collection Processes
OUTBOUND - Presentational Processes
Business Analysis Collateral Signed-Off
Analysis Approved
Gather Initial Collateral
Capture Business Requirements
Another Iteration required
Specify 'To Be' Business Solution
Present ProductsXOR
Business Analysis Activity Triggered through Business Case
Enterprise Model Usage
All Business Analysis should involve close interaction with the Enterprise Model - this is facilitated by the Business Architect.
Guiding Principle:6Ps: Proper Planning and Preparation Prevents Poor Performance
SOA Service Usage
Insert Short Description Here. This should be the first couple of sentences of the diagram description property
Project
Potential for Service Identified
Consult Enterprise Model to identify appropriate candidate Services
XOR
Need to Develop New Service
No Candidate Services Identified
Examine UDDI to identify operational parameters of candidate services
XOR
Need to Modify Existing Service
Candidate Service Requires Modification
Use Existing Service
Service Re-Used
Enterprise Service Design
SOA Governance Process - Service Development
Insert Short Description Here. This should be the first couple of sentences of the diagram description property
Architecture Team
Business Design Team
Project
Need to Develop New Service
Need to Modify Existing Service
OR
Consult with BDT to understand current Service Environment
Produce Initial Design of Service
Provide Relevant Collateral from Enterprise Model
Discuss Proposed Design with Architecture Team
Evaluate Design
Modifications to Design Required
Build and Test Service Subject Service to Automated Certification
Modifications Required
Sign-Off Service
Modifications Required
Service Ready for Roll-Out
Service Signed-Off
Model Security Threat and Identify Appropriate Countermeasures
Design Approved
Enterprise Service Development
Service-oriented Architecture
how to implement Enterprise Services…..
Enterprise Services Derivation
ProcessGroup
BusinessProcess 1
Elementary Business Process
BusinessProcess 2
Process Step 1
ProcessGroup
BusinessProcess 1
Elementary Business Process
BusinessProcess 2
Process Step 1
Enterprise ServiceCustomer
Identification Service
Data Model
Subject Area 1
Domain Independent Messages
Subject Area 2
Message Format 1
Data Model
Subject Area 1
Domain Independent Messages
Subject Area 2
Message Format 1
ApplicationGroup
BusinessApplication 1
Application Module 1
ApplicationObject 1
ApplicationComponent 1
ApplicationGroup
BusinessApplication 1
Application Module 1
ApplicationObject 1
ApplicationComponent 1
ApplicationGroup
BusinessApplication 1
Application Module 1
ApplicationObject 1
ApplicationComponent 1
Technology Portfolio
Unit 1
Device 1
Component 1
Assembly 1
Technology Portfolio
Unit 1
Device 1
Component 1
Assembly 1
Technology Portfolio
Unit 1
Device 1
Component 1
Assembly 1
Process Model Data Model
Function Catalogue
Infrastructure Portfolio
Enterprise Services
Enterprise Services Composition
Enterprise Service
Business Service
Presentation Services
Process Orchestration Services
Application Services
Utility Services
Integration Services
Data Services
Infrastructure Services
Channel Access Services
Presentation Services
Process Orchestration Services
Application Services
Utility Services
Integration Services
Data Services
Infrastructure Services
Channel Access Services
Enterprise Services
Technology Services
The Service-oriented Architecture describes the Solution as a set of Services and populates the Topology and Landscape of the Enterprise Architecture with major features and landmarks
Service-oriented Architecture Framework
Segment Architecture Layers
Channel Access
Presentation
Collaboration
Resources
Services
BPMS
Segment Architecture Mapping to Service Layers
Channel Access
Presentation
Collaboration
EnterpriseResources
CommonServices
BPMS
Presentation Services
Process Orchestration Services
Application Services
Utility Services
Integration Services
Data Services
Infrastructure Services
Channel Access ServicesTechnology Service LayersSegment
Architecture
Service Groups Mapping to Service Layers
Presentation Services
Process Orchestration Services
Application Services
Utility Services
Integration Services
Data Services
Infrastructure Services
Channel Access Services
APPLICATION
BUSINESS PROCESS
COARSE-GRAINED SERVICES
FINE-GRAINED SERVICES
ENTERPRISE COMPUTING ASSETS
Technology Service Layers
Service Groups
Service-oriented Architecture
Presentation Services
Process Orchestration Services
ApplicationServices
Utility Services
Integration Services
Data Services
Infrastructure Services
Planning / Forecast
Purchase / Procure
Provision / Replenish
Merchandising / Retail / POS
Analysis / Insight
Marketing / Advertise
Planning / Forecast
Purchase / Procure
Provision / Replenish
Merchandising / Retail / POS
Analysis / Insight
Marketing / Advertise
‘Plan’ ‘Buy’ ‘Move’ ‘Sell’ ‘Report’‘Promote’‘Plan’ ‘Buy’ ‘Move’ ‘Sell’ ‘Report’‘Promote’
PO
PIMS EPS
PortalPortal PortalPortalPortal
P/R
MDMMDM MDMMDMMDM
EPM
D/W
Analytics ERP MIS
SCM
POPOPOPO
M /R Space
POS
Site
CRM
F/C
Portal
MDM
EAIEAI EAIEAIEAI EAI EAIEAI EAIEAIEAI EAI
D/W
Analytics
PO
F/C
ERP MIS
CRM
EPM
Analytics
EPMEPM ERP
P/R
Channel Access Services
CCCC CCCCCC CC CCCC CCCCCC CC
PP PPP P PP PPP P
Service Architecture Mapping to SoA Framework Layers
Channel Access Layer
Presentation Layer
Collaboration Layer
Resources Layer
Services Layer
Business Process Management Layer
Presentation Services
Process Orchestration Services
Application Services
Utility Services
Integration Services
Data Services
Infrastructure Services
Channel Access ServicesService-oriented Architecture Layers
Technology Service Layers
Enterprise Services
how to implement strategic change…..
Estimating - CRM v. ERP
• Estimating Method 1: Number of Services Delivered x Complexity = 320 man days Effort– 111 Services – 18 Business Services unique to CRM, 93 Common Services shared with ERP– 320 Man Days Effort – CRM Business Services 96 days + Common Services = 224 days
• Presentation, Business Rules and Application Services are unique to the CRM Project (30% of total development effort = 96 man days)
• Data, Integration, Generic and Utility Services are shared with ERP Bespoke Phase 2 (70% of development effort = 224 man days)
• Estimating Method 2: Number of Agile Sprints x Sprint Duration = 4 months Elapsed Time– 8 Sprints x 2 weeks (10 working days) = 4 months, average 3.5 Resources Deployed– 320 Man Days Effort – CRM Effort 107 days + Common Services Effort =163 days, P&P = 50
days• GUI, Business Rules, Application and Reporting Sprints are unique to the CRM Project
(40% of total development effort = 127 man days)• Data, Integration, Generic and Utility Sprints are common with ERP Bespoke Phase 2
(60% of development effort = 193 man days)
Planning is the management of uncertainty…..
• Variable Estimating Factors– Scope – there is some uncertainty surrounding the exact complexity and scope of CRM functions– Development Productivity – the greater the utilisation of BizTalk, the greater the productivity– Shared Services Split – the greater the re-use of Common Services with ERP, the lower CRM
effort– Issues, Risks, Internal Constraints – Business Requirements, Architecture, Design Clarifications– Impact of External Constraints – Availability of Resources, Environments, System Dependencies
• High Estimate – 320 man days– Scope - High, Development Productivity – Low , Shared Services - Low, Constraints - High
• Mid Estimate – 270 man days– Scope - Mid, Development Productivity – Mid , Shared Services - Low, Constraints - High
• Low Estimate – 256 man days– Scope - Low, Development Productivity – Mid , Shared Services -High, Constraints - Low
• Target Estimate – 192 man days– Scope - High, Development Productivity – High, Shared Services - High, Constraints - Low
CRM Sprints
CRM Work Streams
CRM Sprint Profile
Product ID Deliverable
Linked to TRM Phase Stream Sprint Benefit to the Project
Target Start Date
Target Delivery Date
No. of System Engineers
Estimate Effort (days)
Acceptance Criteria
Sign Off Responsibility
1 BEGEN Transfer - 1st Iteration - Happy Day Use Case (Simulators)
Phase 2 -Strategic
Stream 1 - Application
Stream
Sprint 1BEGEN Happy Day Scenario
(with Stubs)
Used to prototype and build 1st Iteration core BEGEN Transfer components with simulators / stubs 3.0 30
2 BEGEN Transfer - 2nd Iteration - enhanced Use Case with Reference Data
Phase 2Strategic
Stream 1 - Application
Stream
Sprint 2PMF Project
Reference Data
Used to prototype and build 2nd Iteration BEGEN Transfer components with Reference Data Connectors 3.5 33
4 BEGEN Transfer - 3rd Iteration - enhanced Use Case with Business Rules
Phase 2Strategic
Stream 1 - Application
Stream
Sprint 3PMF Project
Business Rules
Used to prototype and build BEGEN Transfer Framework Business Rules components
2.5 253 BEGEN Transfer -
Data Integration Components - 4th Iteration
Phase 2Strategic
Stream 2 - Integration
Stream
Sprint 41 - PMF Project Data Integration
Used to prototype and build BEGEN Transfer Framework Data Mapping components to replace simulators and stubs
2.5 245 BEGEN Transfer -
Data Integration Components - 5th Iteration
Phase 2Strategic
Stream 2 - Integration
Stream
Sprint 52 - PMF Project Data Integration
Used to extract and load external bulk data to BEGEN Transfer Framework in Canonical Data Format 3.0 30
6 PMF Generic Services / Generic Components - 6th Iteration
Phase 2Strategic
Stream 3 - Utility /
Reporting
Sprint 6PMF Generic
Services
Used to prototype and build BEGEN Transfer Framework Message Format and Queue Connector components 6.0 61
7 PMF Generic Services Components - 7th Iteration
Phase 2Strategic
Stream 3 - Utility /
Reporting
Sprint 7PMF Strategic
Reporting
Used to prototype and build BEGEN Transfer Framework Generic Services components
5.0 488 PMF Utility / Reporting
Components - 8th Iteration
Phase 3Tactical
Stream 3 - Utility /
Reporting
Sprint 8PMF Generic & Data Services Enhancements
Used to extend and package BEGEN Transfer Framework generic components
2.0 19TOTAL 3.5 270
ANALYSIS Manpower Profile PMF Project 2 Months 4126 PMF Component Effort DA Team 1143 Common Component Effort BA Team 1
N.B. - Estimate based on strategic development environment - Microsoft C#, ASP.NET, BizTalk, SQL/Server
CRM Project – Framework Services
CRM Project – Framework Components
Enterprise Service Bus
how to manage Enterprise Services…..
ESB Principles
• ESB Principles– Pragmatic to enable service
design, create, maintain and use– Scaleable, efficient and portable– Serviceable and resilient– Useable and supportable– Auditable and recoverable– Cross Platform (Wintel – Solaris –
UNIX – Linux)– Extensible and adaptable– Supports the following: -
• Agile Methods• Canonical Data Model• Domain Independent Message
Formats• SoA Design Patterns• Service Re-use
• Centralised Logging Service– Public Message Queues on
logging machine– Can create queues to suit
reliability and security requirements
– BizTalk MSMQ runtime required on senders / connectors
– Need to consider clustering– Writes to SQL database– ESB Consumer and Server log to
CLS– SOAP Extension for XML Web
Services (ASMX)
EAEA--envision:envision: The Enterprise Framework for Business TransformationThe Enterprise Framework for Business Transformation
Enterprise Service Bus
An Enterprise Service Bus (ESB) should provide a standard routing mechanism for a loosely coupled asynchronous Service-oriented Architecture (SoA). It would also allow complex transformation of the messages as needed, as well as provide an interface to integrate across different non standard interfaces.
Figure 1: Diagram showing an ESB with different services connected in a message flow.
Services and Adapters for SOA
ESB
SoA Integrators, Connectors and Adaptors• Legacy applications
– written in a variety of procedural languages that typically do not have well-defined Application Program Interfaces (API’s) for collaborative processing, but functions may be “wrappered” as Remote Procedure Calls
• Object-oriented applications– many different applets developed as components for other applications, such as Enterprise JavaBeans™, COM
Application Servers or CORBA objects etc.• Transaction processing systems
– –applications that run under the control of transaction processing monitors such as distributed customer information control system (CICS), IMS Transaction Manager (IMS/TM), BEA Tuxedo, and other TPMS software whose transactions are well suited for incorporation into collaborative business processes
• Packaged application systems– Vendor-supplied, proprietary systems with well-defined, often completely proprietary, collaborative interfaces such as SAP
Business API / NetWeaver Xi Adaptors, Oracle e-Business Suite Adaptor, PeopleSoft ETP Adaptor, JDE Master Business Function Adaptor, etc.
• Databases and file systems– Vendor-supplied, proprietary relational database management systems (RDBMSs), legacy database management
systems (DBMSs), and file systems with varying degrees of standard and proprietary interfaces including relational (e.g. SQL, Oracle, DB2, MySQL etc.), hierarchical (e.g. IMS), network (e.g. IDMS) and file based (e.g. FTP, SFTP, ADABAS, VSAM, etc.) data sources
• Communication transport protocols and message formats– Industry-standard transports such as hypertext transport protocol (HTTP), file transfer protocol (FTP), and simple mail
transfer protocol (SMTP), Sun Enterprise Java Suite Adaptor, SoA Protocols such as XML, SOAP, WSDL, JMS, ADO.NET, RNI, JDBC, EJB, ESB etc.
– Vendor proprietary messaging and queuing systems in a variety of formats for exchanging data between applications, such as IBM WebSphere MQSI, Sun JMS, JCA and SeeBeyond eGate, Microsoft BizTalk MSMQ, BEA e-link (Tuxedo) adaptors
• e-Business exchanges– Proprietary and standards-based public and private exchanges through which businesses collaborate with other
businesses– Proprietary data interchange systems in a variety of formats for exchanging data between collaborating enterprises, such
as Electronic data interchange (EDI), Society for the Worldwide Inter-bank Financial Telecommunication (SWIFT),.• Application server platforms
– application and integration servers that host all manner of Application Service Provider (ASP) applications and On-demand Services that facilitate collaboration within and between enterprises
Web Client Software Factory
Logical ESB Architecture
Service Registry
Consumer
Service
Message Queuing
Contract & Policy
Repository
Message Format
Repository
Audit & Logging
Message Formatting
Message Persistence
Network Deployment
Logical Service Registry Structure
Contract: Guid -> Contract WSDL
Binding: Binding WSDL (Policy)Address
Binding: Binding WSDL (Policy)Address
Binding: Binding WSDL (Policy)Address
Centralised Logging Service
Enterprise Library (out of the box)
ESB Consumer
Service Registry
Contract Model Cache
Binding Model Cache
Service Cache
Uddi
Interface
ESB Channel Factory
Channel
Factory Builder
Contract & Policy
Repository
Instance ListFactory &
ProxyCache
Create Channel
Abort
CloseWSDLCache
Persistence
Queuing
FormattingMessages
Message Stack
Persistence
Queuing
FormattingMessages
Message Stack
Transport
Encoding
ProtocolsChannels
Channel Stack
Transport
Encoding
ProtocolsChannels
Channel Stack