Service-Oriented Enterprise Integration: Tools and Techniques Chris Peiris .

Service-Oriented Enterprise Integration: Tools and Techniques

Chris Peiris

www.ChrisPeiris.com

11 Oct 2006 © ChrisPeiris.com 2

Agenda

Enterprise Architecture Demo 1

Enterprise Architecture Models Integration Technologies

EAI, ETL, EII Demo 2

Service oriented Architecture


Enterprise Architecture

“Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements interrelate”

“A logically consistent set of principles, practices, policies, models, standards and guidelines that are derived from business requirements, that guide decision-making and the engineering of an organization’s information systems and technical infrastructure.”

(WA. State ISB EA Committee )


Demo 1

Need to model Enterprise Architecture?

Key Takeaways Collaboration of 40 small companies 40 different software platforms /

technologies / “way of doing things” How do we models all these?


EA Model / Framework

A general Enterprise Architecture (EA) framework provides general high-level views for the separation of enterprise level concerns for use in any industry or project. In effect, the EA aims to provide the ability to view complex systems underlying organisations from a high-level to aid in analysis and understanding during strategic planning.


EA Models

Enterprise Architecture Frameworks Zachman Enterprise Architecture Model Federal Enterprise Architecture

Framework (FEAF) The Open Group Architecture Framework

(TOGAF) Treasury Enterprise Architecture

Framework (TEAF)


What do they discuss?

How an enterprise should function For an example Zachman addresses,

What (Data) How (Function) Where (Network) Who (People) When (Time) Why (Motivation)

Answers them in the context of Contextual (Scope) Conceptual (Business Model) Logical (System Model) Physical (Technology Model) (Zachman, 1987)


Zachman Model

The Zachman Framework first published in 1987, defines a logical structure for the classification and development of specific models (i.e. design artefacts) required in the management and operations of enterprises, including the development of supporting enterprise information systems. Together the inter-related models in the framework separate enterprise specific concerns (e.g. function, data, network e.c.t.), providing a holistic enterprise.


Based on work by John A. Zachman

VA Enterprise Architecture

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

SCOPE(CONTEXTUAL)

Planner

ENTERPRISEMODEL(CONCEPTUAL)

Owner

SYSTEM MODEL(LOGICAL)

Designer

TECHNOLOGYMODEL(PHYSICAL)

Builder

DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)

Sub-Contractor

FUNCTIONINGENTERPRISE

SCOPE(CONTEXTUAL)

Planner

ENTERPRISEMODEL

(CONCEPTUAL)

Owner


Designer

TECHNOLOGYMODEL

(PHYSICAL)

Builder


Sub-Contractor


Things Important to the Business

Entity = Class of Business Thing

Processes Performed

Function = Class of Business Process

Semantic Model

Ent = Business Entity Rel = Business Relationship

Business Process Model

Proc = Business Process I/O = Business Resources

Business LogisticsSystem

Node = Business Location Link = Business Linkage

Work Flow Model

People = Organization Unit Work = Work Product

Master Schedule

Time = Business Event Cycle = Business Cycle

Business Plan

End = Business Objectiv e Means = Business Strategy

ImportantOrganizations

People = Major Organizations

Business locations

Node = Major Business Locations

Ev ents Significantto the Business

Time = MajorBusiness Event

Business Goalsand Strategy

Ends/Means =Major Business Goals

Logical DataModel

Ent = Data Entity Rel = Data Relationship

Application Architecture

Proc = Application Function I/O = User Views

Distributed SystemArchitecture

Node = IS Function Link = Line Characteristics

Human InterfaceArchitecture

People = Role Work = Deliv erable

ProcessingStructure

Time = System Event Cycle = Processing Cycle

Business RuleModel

End = Structural Assertion Means = Action Assertion

Physical DataModel

Ent = Segment/Table Rel = Pointer/Key

SystemDesign

Proc = Computer Function I/O = Data Elements/Sets

TechnologyArchitecture

Node = Hardware/Softw are Link = Line Specifications

PresentationArchitecture

People = User Work = Screen Format

ControlStructure

Time = Ex ecute Cycle = Component Cycle

RuleDesign

End = Condition Means = Action

DataDefinition

Ent = Field Rel = Address

Program

Proc = Language Statement I/O = Control Block

Netw orkArchitecture

Node = Addresses Link = Protocols

SecurityArchitecture

People = IdentityWork = Job

Timing Definition

Time = InterruptCycle = Machine Cycle

RuleDesign

End = Sub-Condition Means = Step

Data

Ent = Rel =

Function

Proc =I/O =

Netw ork

Node = Link =

Organization

People = Work =

Schedule

Time = Cycle =

Strategy

End = Means =

Based on work by John A. Zachman

VA Enterprise Architecture

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

SCOPE(CONTEXTUAL)

Planner

ENTERPRISEMODEL(CONCEPTUAL)

Owner


Designer

TECHNOLOGYMODEL(PHYSICAL)

Builder


Sub-Contractor


SCOPE(CONTEXTUAL)

Planner

ENTERPRISEMODEL

(CONCEPTUAL)

Owner


Designer

TECHNOLOGYMODEL

(PHYSICAL)

Builder


Sub-Contractor


Things Important to the Business

Entity = Class of Business Thing

Processes Performed

Function = Class of Business Process

Semantic Model

Ent = Business Entity Rel = Business Relationship

Business Process Model

Proc = Business Process I/O = Business Resources

Business LogisticsSystem

Node = Business Location Link = Business Linkage

Work Flow Model

People = Organization Unit Work = Work Product

Master Schedule

Time = Business Event Cycle = Business Cycle

Business Plan

End = Business Objectiv e Means = Business Strategy

ImportantOrganizations

People = Major Organizations

Business locations

Node = Major Business Locations

Ev ents Significantto the Business

Time = MajorBusiness Event

Business Goalsand Strategy

Ends/Means =Major Business Goals

Logical DataModel

Ent = Data Entity Rel = Data Relationship

Application Architecture

Proc = Application Function I/O = User Views

Distributed SystemArchitecture

Node = IS Function Link = Line Characteristics

Human InterfaceArchitecture

People = Role Work = Deliv erable

ProcessingStructure

Time = System Event Cycle = Processing Cycle

Business RuleModel

End = Structural Assertion Means = Action Assertion

Physical DataModel

Ent = Segment/Table Rel = Pointer/Key

SystemDesign

Proc = Computer Function I/O = Data Elements/Sets

TechnologyArchitecture

Node = Hardware/Softw are Link = Line Specifications

PresentationArchitecture

People = User Work = Screen Format

ControlStructure

Time = Ex ecute Cycle = Component Cycle

RuleDesign

End = Condition Means = Action

DataDefinition

Ent = Field Rel = Address

Program

Proc = Language Statement I/O = Control Block

Netw orkArchitecture

Node = Addresses Link = Protocols

SecurityArchitecture

People = IdentityWork = Job

Timing Definition

Time = InterruptCycle = Machine Cycle

RuleDesign

End = Sub-Condition Means = Step

Data

Ent = Rel =

Function

Proc =I/O =

Netw ork

Node = Link =

Organization

People = Work =

Schedule

Time = Cycle =

Strategy

End = Means =

Zachman Framework


Zachman Framework Row 1 – Scope

External Requirements and DriversBusiness Function Modeling

Row 2 – Enterprise ModelBusiness Process Models

Row 3 – System ModelLogical ModelsRequirements Definition

Row 4 – Technology ModelPhysical ModelsSolution Definition and Development

Row 5 – As BuiltAs BuiltDeployment

Row 6 – Functioning EnterpriseFunctioning EnterpriseEvaluation

1

2

3

4

5

6

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How


Federal Enterprise Architecture Framework (FEAF)

The Federal Enterprise Architecture Framework (FEAF) aims to provide a comprehensive “business-driven blueprint” of the entire Federal government including its functions and IT infrastructure.


Treasury Enterprise Architecture Framework

The Treasury Enterprise Architecture Framework (TEAF) is framework developed specifically for the U.S. Department of the Treasury and its bureaus in order to aid in performing strategic planning / investment management, and to provide direction for the development of enterprise architectures tailored to the needs of the U.S. Treasury Department and its bureaus. The framework had been developed with the Federal Enterprise Architecture Framework (FEAF) and Zachman Framework as its basis


The Open Group Architecture Framework (TOGAF)

Originally designed as a way to develop the technology architecture for an organization, TOGAF has evolved into a methodology for analyzing the overall business architecture. The first part of TOGAF is a methodology for developing your architecture design, which is called the Architecture Development Method (ADM). It has the following nine basic phases:

Preliminary phase: Framework and principles. Get everyone on board with the plan.

Phase A: Architecture vision. Define your scope and vision and map your overall strategy.

Phase B: Business architecture. Describe your current and target business architectures and determine the gap between them.

Phase C: Information system architectures. Develop target architectures for your data and applications.

Phase D: Technology architecture. Create the overall target architecture that you will implement in future phases.

Phase E: Opportunities and solutions. Develop the overall strategy, determining what you will buy, build or reuse, and how you will implement the architecture described in phase D.

Phase F: Migration planning. Prioritize projects and develop the migration plan. Phase G: Implementation governance. Determine how you will provide oversight

to the implementation. Phase H: Architecture change management. Monitor the running system for

necessary changes and determine whether to start a new cycle, looping back to the preliminary phase.


Agenda






Enterprise Integration is required at all levels

Need for databases to exchange information Provides data consumers with an integrated

view of disparate data Need for applications to exchange

information Within organizations and between organizations Often times involves legacy technologies

Need for organizations to exchange information Structured and unstructured business process

dependencies Bulk data exchange Reporting


Integration Products Available

Category Enterprise Small to Medium

Product Data Mgmt/Demand Planning

Manugistics

Back Office (ERP) SAP, Oracle, JDE, Manugistics…

Axapta, Great Plains

Front Office (CRM) Siebel, SAP MS CRM, Salesforce.com

Connecting Partners (SCM)

ERP Vendors, I2 SMB ERP…

Legacy IBM Mainframe… Unix, VAX, AS/400

Vertical / Company Specific

ISVs, Build

Why build when you can buy? Build less and connect more


Integration Categories

Enterprise Application Integration Extract Transform and Load / Extract

Load and Transfer Enterprise Information Integration


EAI

Enterprise Application Integration (EAI) Message based High Frequency Real Time Application to Application

Vendor Implementations IBM Web Sphere Message Broker Microsoft Biztalk Server Web Methods BEA Web Logic MS, IBM, Java Web Services Implementations


ETL / ELT

Extract Load Transform (ELT) or Extract Transform and Load (ETL) Bulk Transactions / Batch Database to database Low frequency / high latency

Vendor Implementations IBM DataStage Microsoft SQL Server Integration Services Seibel EIM


EII

User Interface driven Person to Person – to assist senior

management. Real Time Vendor Implementations

Seibel Microsoft Workflow Foundation Biztalk Server Orchestration


Demo 2

Enterprise solution that uses multiple products to assist business processes.

It uses Microsoft InfoPath, BizTalk, ASP.NET Web Services, RPG on an AS/400, CICS on a Mainframe, J2EE on WebSphere, Pocket PC, SQL Server, Speech Server, and Microsoft MOM.

Question : Which integration strategies are we using?

Introduction to SOA…


Agenda






Changing Times

[i]

(Malveau & Mowbray, 2004)


PolymorphismPolymorphismEncapsulationEncapsulationSubclassingSubclassing

Message-basedMessage-basedSchema+ContractSchema+ContractBinding via PolicyBinding via Policy

Interface-basedInterface-basedDynamic LoadingDynamic LoadingRuntime MetadataRuntime Metadata

Object-OrientedObject-Oriented

Service-OrientedService-Oriented

Component-BasedComponent-Based

1980s1980s

2000s2000s

1990s1990s


What is SOA?

SOA is an emerging paradigm to integrate systems, applications, processes and businesses.

SOA delivers differentiated business capabilities or products through the assembly of autonomous business and technology capabilities (services).

SOA changes the way an enterprise is runby making the business process the focus.


The SOA Journey

Point-to-PointMessage Based


Example SOA Benefits

Application decoupling Share functionality rather than build it redundantly Improves Custom Development Improves Enterprise Integration Improves Information Management/Collaboration Improves Business Intelligence Protects Business Strategy

Increases agility Decreases costs Increases process transparency


Four Tenants of SOA

1) Boundaries are Explicit - Crossing boundaries is an expensive operation as it can constitute various elements such as data marshalling, security, physical location, etc. Some of the design principles to keep in mind vis-à-vis the first tenet are

2) Services are Autonomous - Services are self contained and act independently in all aspects such as deployment, versioning, etc. Any assumptions made to the contrary about the service boundaries will most likely cause the boundaries to change themselves.


Four Tenants of SOA 3) Service Share Schema and Contract, not

Class -Services interaction should be using policies, schemas and behaviours instead of classes which have traditionally provided most of this functionality. The service contract should contain the message formats (defined using a XML schema), message exchange patterns also known as MEPs (defined in WSDL)

4) Service Compatibility is based on Policy -At times one cannot express all the requirements of service interaction via WSDL alone, which is where policies can be used. Policy expressions essentially separate the structural and semantic compatibility. Or in other words, “what is communicated” and “how/whom a message is communicated”.


Service-Oriented Business Applications

Auditing and Logging

Monitoring & Detection

Authorization & Access

Service-Oriented Infrastructure

Configuration

Design & Modelling

Service-Oriented Implementation

Service-Oriented Integration

OrchestrationWorkflow

ApplicationIntegration

Existing Systems

Publication &Discovery

Service Management

MetadataManagement

Svc DevEnvironment

Service Provisioning

Transformation & Routing

Host Integration

ServiceRepository

Code & Testing

Management& Governance

Lifecycle Process

ServicePublishing

ServiceStandards

Hosted Svc Environment

Transport

Example of a SOA Implementation


Universal Business Integration Platform

(Integration Journal Online, 2003)

Service-Oriented Enterprise Integration: Tools and Techniques Chris Peiris .

Documents

Transcript of Service-Oriented Enterprise Integration: Tools and Techniques Chris Peiris .