Integrating for Enterprise Support IST 421 Supplement

Integrating for Enterprise Integrating for Enterprise SupportSupport

IST 421 SupplementFall, 2005

Ed GreenLecturer – IST

The Pennsylvania State UniversityThe Abington College

[email protected]

www.personal.psu.edu/exg13

04/11/23 Integrating for Enterprise Support 2

Overview and Focus Assemble and integrate

Unified approach to contemporary integration issues

Discussion elements Service view of architecture Components and their use

Legacy elements COTS (traditional) Open Source cibsuderation

Messaging Grid computing Mobility edge


Some Terms in Common Use Service Oriented Architecture

(SOA) Customer Relationship

Management (CRM) Enterprise Relationship

Management (ERM) Middleware Grid Computing Web Services


Services View of Architecture


A Couple of Definitions Service Oriented Architecture

Application-based Delivery of business services to

users/customers Services

Architecture-based All elements of architecture

Engine components that produce business services


. . . and an analogy

Service Oriented Architecture is to Servicesas

Functional Requirements are to Technical Requirements


Integration Services

MessageQueue

Adapter

MessageQueue

Adapter

MessageQueue

MessageQueue

Staging

MessageQueue

IntranetFacilities

PersonalComputers

Messaging Services

OrganizationDirectory

SecurityServices

SystemManagement

KnowledgeManagement

MetadataRepository

ArchivingService

Enterprise Infrastructure

PortalsB2B

Messaging

EnterpriseCOTS

ApplicationBSD

LegacySystem

BSD

DistributedComponent-

basedBSD

DecisionSupportSystem

BSDPlant Control

System


Networking Model

Private Intranet

Private Intranet

Public Internet

Public Internet

External Users

MessageQueues

Web Server

Application(s)

Business SystemDomain

Directory Services Device Services

MessageBroker Services

Internal Users

OrganizationStructure Service

Trader Services

FirewallEmployee

Remote Access

Enterprise Web Server

PublicApplication(s)

MessageQueues

Public Web Applications

B2B Web Server(s)

B2B MessageQueues

BusinessPartners

RemoteEmployees

Internal Systems


Workflow Process Model

Personal Work List

Resource AssignmentFacilities

Process Manager

RequestorProcess Definition

Process Instance

Process Instance

Process Definition


Component-based BSD* Model


NameService

ExceptionService

SystemManagement

PersistenceService

ComponentContainers

BusinessProcesses

WebServer

TransactionService

MessageQueues

SecurityService

BusinessDocument

Archive

Business System Domain

* Business System Domain


Enterprise Data Storage Model

BusinessApplications

BusinessDocumentArchives

EnterpriseMaster

Database

DocumentManagement

OperationalData Stores

Meta Data

Data Warehouse Data Marts


Enterprise Architecture and Integration

Application architectures are good

Stovepipes may result Each application has its own

architecture Boolean intersection Null Set

except by accident Very common in legacy application

situations.


Business As Unusual No longer exists

“Business as usual” inadequate to survive in the current technology-driven business environment

Internet e-business no longer exists in only a technology domain

In 2001, Gartner Group

“e-commerce applications and technology elevated to a core competency”

Forrester – e-business market will exceed $1.3 trillion by 2005

IDC – enterprises will invest $10 billion by 2005 to create e-business infrastructure


Defining the “Extended Enterprise”

Automate electronic interfaces that link the computer systems of The ultimate selling businesses, Partners that finance or manage the transaction External suppliers, carriers, and support organizations

In turn these external partners connect with numerous internal systems that support Customer service Sales Logistics Manufacturing Procurement Accounting Human resources Corporate finance


Event-Driven Economy An economy where demand realized

translates into demand satisfied In near-real time

Demand realized Accomplished by extending capabilities

and reach of existing IT infrastructure so that enterprise applications are bound by a business event-driven paradigm

Inter-enterprise Intra-enterprise


Defining Characteristics of an Event-Driven Economy Almost instantaneous

Definitely occurs in real time ALL participating systems are able to communicate in any direction

With any other system Automatically In real time

Systems bound at both data and process levels More than exchanging information Business rules and processes shared Data processed with common integrity constraints enforced Common business model determine path and order of each business

event Spans business systems Defines properties of a business event

Order Behavior Information characteristics Public and private processes

All relevant information accessible by any other participating system


Component-based BSD* Model


NameService

ExceptionService

SystemManagement

PersistenceService

ComponentContainers

BusinessProcesses

WebServer

TransactionService

MessageQueues

SecurityService

BusinessDocument

Archive

Business System Domain



Local BSD Networking Included Servers

DirectoryServices

WebServer

DatabaseServer

ApplicationServer

ApplicationServer



Request Broker Connectivity

SecurityServices


WebServer

ExceptionService

NameService

TransactionService

MessageQueues

BusinessProcesses

ComponentContainers

PersistenceService

BusinessDocument

Archive

Message Broker


Message Structure

Message Header Includes destination Identifies source Identifies message (type)

Message Trailer Indicates end of message

Message Contents Must be defined in such a way that it is understood by BOTH sender AND receiver


Interface Definition Language (IDL) Used to define network interfaces of network-

accessible objects Object method signatures Attributes

CORBA and ISO standard Defines interfaces and not implementations

Different object classes can implement the same interface

Strongly typed Parameters Return values Attribute values

Basis for generating proxy objects on sending (client) server

found in method signatures


Interface Definition Language (IDL)

Object reference – information necessary and sufficient to locate the actual object Passed over the network using IIOP Includes return value requirements

Proxy object – represents the target object

Proxy Object

Skeleton Object

Target Object

Object Request BrokerObject Request Broker

Message

IIOP*

* International Interface Object Protocol


How Data Is Processed -Schematic

•Data has been entered onto a screen•ENTER, SUBMIT, etc. command has been given

•Screen contains fixed andvariable items•Screen also contains items that are non-visible but transmittable

ComputerProgram

Variable and othertransmittable itemssent to a computer program

Data from screen

Trailer (end of data)Header (identification)

Data is transmitted in the form of a message

Errors have been detected; user advised

Database

Data is stored in data base

ComputerProgram

Data is forwardedto another programfor further processing

Operation successful; user advised

DBMS

Computer programcontains a “template”that identifies data as well as the rules for interpreting thatdata. This program: - Identifies the data - Determines presence of required data - Validates data - Determines next action

SERVLET


Introduction to Components


Components A component is a software entity

that provides a cohesive set of functional capabilities through a specified interface

“Stand-alone” capability that supports one business function

Shareable Capability can be used by many

managed processes Needs may be different


Component GranularityGranularity represents a

component’s capabilities Size –

How large?How many included functions

Coarse versus Fine Grain

Scope – functionality includedConfigurability


Interfacing Enterprise-level architecture

components often too large to be viewed as single objects Can be entire systems decomposable

into separate functional modules Systems of their own

Enterprise architecture components do have well specified interfaces Best defined and controlled using

distributed object technology


Reuse Ability to use a software

element more than once ‘Create once, use often’ Provide a standard means for

Computation Validation Comparison Presentation


Component ReuseReusability is an important

characteristic of componentsWhat is reuse?

A (reusable) common service that persistently maintains some data of interest to multiple applications

The ability to use the same module of software code in separate executing instances


Component Layers Application-Specific Components

Application-unique services Business Domain Components

Fundamental business entities and processes of the enterprise

Shared across applications Extended Platform Components

ORB DBMS Web server Application server Transaction monitor

Platform/Network Components Basic services used by

applications to support business logic

Application-Specific Components

Business Domain Components

Extended Platform Components

Platform/Network Components


Dependency Outgrowth of vertical partitioning of

applications Components lower in the architecture are

independent of higher level ones Key architectural consideration to ensure

adaptability and modifiability With proper dependency relationships

Upper-layer components easily modified No changes to lower-layer components

Lower-layer components can be modified or replaced without impact to upper-layer components

Requires continuity of interface support


Dependency Commercial lower-layer almost

always independent of higher-level custom code

Dependency relationships must be considered Dependencies between platform and

extended platform components Dependencies between business domain

and application-specific components Layer skipping

Interfacing with a component further down in the architecture


Defining Architectural Layers

Architecture Layers DefinedExisting system Application ; Platform/network

Extensions to existing system Application ; Platform/network

New technology component Application ; Business domain; Extended platform; Platform/network

Connector Business domain; Extended platform; Platform/network

Security Application ; Business domain; Extended platform; Platform/network

Enterprise Application ; Business domain; Extended platform; Platform/network


Existing Applications as Components

Definition established applications as higher-level components Containing lower-level elements as objects

Architecture must be defined at enterprise level, not at application level

Legacy applications have two views Logical

Key software purposes of internal functionality Software interrelationships

Physical Software interfaces for interoperating with

applications


Extending Applications Frequently less expensive than

replacement Identify nature of extension

Additional functionality Additional data New processing logic

Data and functionality that extends capabilities

Architecture must detail extensions


Identifying Component Interface Specifications Interface specifications abstract

in nature at enterprise level Interface specifications should

state:Specific functionality that can be

invokedSpecific data supported by each

function Interface invocation sequence


Adding New ComponentsNew technology components

Deliver new functionality and data as part of legacy application extension

Allocate to layersClearly identify interconnectivity

between componentsWithin a layerBetween layers


Introducing Components – An Example

COTSERM

LEGACYREPORTER

USER Event Trigger Send Bill

Interface

Data Request

TransformData Delivery

DoD

Bill

Electronic

A COTS ERM product is introduced to replace a variety of legacymanagement applications. However, in order to do business with thefederal government DoD, billing must be sent electronically using a specified format. This format isnot included in the COTS ERM;hence the legacy application must be retained and integrated.


Summary (so far)Components are key elements

for enterprise application integration

Four discrete layers demand consistency and connectivity

Legacy applications will have a place in integrated application architectures for the foreseeable future


Component Containers Makes the component transactional Resolves access conflicts Provides for event management Sustains component-state

persistence Implements life-cycle operations Removes or simplifies consideration

of component complexities


Component Containers

Application software thatprovides the execution ofa single business processor function

•Inputs•Processes•Outputs

Out

In

Wrapper

Component

Provides outputto other componentsin a specified formatAccepts input form

other components ina specified format


Encapsulation and Abstraction Descriptions of interfacing with a

component Applies to both in and out interfaces An encapsulated interface is one where

the available knowledge about a component is limited to the information contained in the interface definition

An abstracted interface is one where the accessibility to a component is published in the interface definition but where it is possible to acquire further knowledge about the component via other means


SAP Overview

Operating System DBMS

AP

I an

d G

UI

BASIS

SAP Functionality

ApplicationModules and

BusinessProcesses*

Tools:

•ABAP Workbench•Computer Center Management - Database Administration•Configuration Management

•Data•Source Libraries•Data Dictionary•Repository•Temporary Data•Print Queues

Database* Object based end-to-end business process

Source: SAP R/3 System Administration Guide, ISBN 0-7821-2426-7


SAP Functional Architecture

SAPGUISAPGUIDatabase

Host

DatabaseHost

ApplicationServers

ApplicationServers

ApplicationServer

ApplicationServer

ExternalProcesses

ExternalProcesses

API


data

SAPGUISAPGUI

ExternalProcesses

ExternalProcesses

BusinessProcess

BusinessProcess

Application Servers

SAP ToolsSAP Tools

BusinessProcess

BusinessProcess.

.

.

DatabaseHost

DatabaseHost

DBMSDBMS

WF DD DB

Inte

rpre

tive

co

de

SAP Architecture - A Process View

Data which is

on the GUI

API

BAPI

•Batch, including real time•Best of breed (legacy)•Other COTS/NDI•Transitory applications•Bolt-ons

•Human Interface

Developed “applications” - BAPI APIs - ABAP WorkbenchALL else is SAP-provided


Example – Producing a Bill

COTSERM

LEGACYREPORTER

USER Event Trigger Send Bill

Interface

Data Request

TransformData Delivery

DoD

Bill

Electronic

Question: Using what you know, and the fact that contract costs are contained in SAP module “CM”, re-draw the example below (from chart 178) to reflect utilizing SAP.


Messaging Infrastructure


Messaging Infrastructure Design Objectives Messaging Structures Messaging Format Abstractions Design Considerations Example


Messaging Infrastructure – Design Objectives Store and forward Message broker Guaranteed

delivery Message sequence Symbolic routing Request-response

Event messages Message

transformation Ad hoc

destination Exception

resolution Standards File transfers


Message Infrastructure - Structures Message queues Basic messaging facilities Point-to-point messages Publish-and-subscribe messages Message format abstractions API object model


Messaging Infrastructure – Message Broker Concept

A

C D

B

C

B D

A

Point-to-Point (Without Message Brokering)

With Message Brokering


Message Structure

Message Header Includes destination Identifies source Identifies message (type)

Message Trailer Indicates end of message

Message Contents Must be defined in such a way that it is understood by BOTH sender AND receiver


Messaging Infrastructure – Message Format Abstraction

Destination

Delivery Mode

Message ID

Timestamp

Correlation ID

Reply To

Redelivered

Type

Expiration

Priority

Message Properties


Messaging Infrastructure – Design Considerations Product interoperability Transformation service File transfers B2B messaging Security Scalability Application execution Exception handling


Messaging Infrastructure Example Using everythingeverything to this point, let’s

consider the process with ordering something from a supplier.

Recall from IST 331, we discussed the process for creating a purchase order

Now, let’s look at the e-business aspects


Traditional IT Framework

Interface to Applications

. . .. . .

. . .. . .ClientsClients

IndependentIndependentApplicationsApplications

• Developed independently, frequently in a Developed independently, frequently in a vacuum in the absence of standardsvacuum in the absence of standards


Enterprise IT Framework

Application Integrator

. . .. . .

. . .. . .

User Interface

SecuritySecurity

ClientsClients

IndependentIndependentApplicationsApplications

Software thatSoftware thatprovides “commonprovides “commonview” capabilityview” capability

•AuthenticationAuthentication•AuthorizationAuthorization

WEB BrowserWEB Browser

•FinanceFinance•ManufacturingManufacturing•Sales/MarketingSales/Marketing•PersonnelPersonnel•EngineeringEngineering


e-World Concept of Operations e-Process begins with a

buyerbuyer and a sellerseller Goods/services wanted

and available GLOBAL EXCHANGE

facilitates the electronic transaction

Seller’s catalog reviewed by buyer

Needed items available Purchase order

prepared and transmitted to global exchange

Global exchange routes to seller

Order entry prepared

Production schedule established or updated

Inventory checked; replenishment ordered

Manufacturing resources assigned

Labor availability checked Resources assigned

ORHR to staff prepared

Sub-assemblies and other resources reserved

Production package prepared

Bill of materials Manufacturing/assembly

instructions Drawings/blueprints


e-World Concept of Operations (continued)

Production process is monitored

Labor time & attendance is recorded

Test results and quality analysis recorded

Shipping is scheduled Customer Service is

advised Billing is notified

Customer billing is prepared

Order is shipped

Order is received Receiving inspection

conducted; test results recorded

Bill is received Payment is made Questions arise Supplier customer

service is contacted Call is recorded Question is researched in

the product reference materials

Answer is provided


Trading Partner Challenge


. . .. . .

. . .. . .User Interface

SecuritySecurity


. . .. . .


SecuritySecurity


. . .. . .


SecuritySecurity


. . .. . .


SecuritySecurityApplication Integrator

. . .. . .


SecuritySecurity


Messaging What are the messages? What do each of the messages

contain? What are the implications?


Persistent Services Object Mapping Database Operations

Create Delete Update

Queries Connection Management


Security Service Supports authentication and authorization within

BSD Determines identity of user from

Digital certificates Userid and password

May be implemented in Web server Application server Both

Best outside of application server Reduces complexity

SSL protocol ensures integrity and confidentiality of data transmitted on network


Security Service

WebServer

DocumentArchive

ApplicationServer(s)

SecurityService

MessageQueue

OrganizationService

MessagingService

WebBrowser

HTTPS SSL


Transaction Services Serialization Deadlocks Concurrency services Locking services Transactional context Callback Transaction control services Phased commits Recovery Nested transactions


Example – The Systems Integration Challenge

AerospaceGlobal

TradingExchange

AerospaceGlobal

TradingExchange

Boeing

BAE

Lockheed Martin

Raytheon

Supplier Community

Opportunity: significant savings through economies of scaleProblem: everyone “does their own

thing”Challenge: find the common ground


What is B2B Application Integration

Controlled sharing of data and business processes

Leveraged assets All existing systems Bound within or between enterprises Support any and all business requirements

Access to perfect information on demand to outside trading partners Enables instant reaction to a business

eventBut, remember that a business transaction takes atleast as long as the slowest system in the loop


Issues – Leveraging Assets Ancient technology critical to

workings of enterprise Hard to impossible to adapt Communications and sharing

difficult (at best) Package applications

Natural stovepipes Clearly compound the problem


Applying Technology Traditional middleware

Built to integrate applications within an enterprise

Fails to account for B2B special needs Point-to-point solutions

Remote procedure calls Message queues

Significant alterations to both source and target system are required

May work within an enterprise;Out of control across enterprises


Traditional Middleware

ApplicationGreen

MD

TCT

EH

PSR

TXT

FMT

TSK

QM

DB

BM

S

WFM

MDM

BUF

DBMS

ApplicationOrange

DBMS

ApplicationRed

DBMS

ApplicationGreen

DBMS

API AbbreviationsAPI – Application InterfaceTCT – Task Control TableEH – Error HandlerPSR – ParserTXT – Transaction Control TableFMT – Response FormatterTSK – Task ManagerQM – Queue ManagerWFM – Workflow ManagerMDM – Metadata ManagerBUF – Buffer Pool MD – Metadata Data Base

Stovepipe business applications. Databases areapplication-centric and DBMS’s are not necessarilythe same

Interactive human users


B2B Application Integration

Focuses on integration of both business-level processes and data between organizations

Includes notion of reuse in addition to distribution of business processes and data across linked enterprises

Application-to-application concept Near real time Back end Minimal user interaction

Enables users with limited detail understanding of applications to integrate them

Incorporates notion of common agreements between trading organizations; support those agreements through information exchanges

Assumes most source and target systems cannot be altered and points of integration must be non-intrusive

Takes into account differences between integrating applications within and between enterprises; supports a single process model that spans both

Takes advantage of advanced security standards to protect information moving between companies


EAI versus B2B EAI – typically deals with the

integration of applications and data within an enterprise to solve a local problem

B2B Application Integration deals with the integration of applications between organizations to solve any business problem


EAI versus B2B


Middleware and B2B Application Integration

Middleware is a simple mechanism Accessible way to integrate external resources

using a common set of application services to move information and shared business logic between applications

Hides complexities of underlying operating system and network

Facilitates integration of various enterprise systems API’s –general purpose data movement or process

invocation mechanisms acting on behalf of an application Provides a means to connect distributed computing

elements Clients to servers Clients to clients Servers to servers


Retooling Middleware for B2B Support inter- and intra-process

integration Support for B2B standards

RosettaNet ebXML EDI

Support for Internet-enabled information exchange

Support for advanced security models


Approaching e-Business Business rules integration Information integration Process integration Collaboration


Business Rules Integration Binding of application logic between

two or more business partners Composite applications accessible to all

parties Exchange of information and business

rules fully automated CORBA standard implementation

mechanisms


Information Integration Platform for exchanging relevant data in

order to support e-Business initiatives Functions below Business Rules Integration

Requires few changes to participating systems Relatively inexpensive

Utilizes message brokers, data replication engines, and data migration engines

XML provides common information exchange format for incompatible applications and data sources


Process Integration Set of processes that function

above both business rules and information integration

Process model resides on top of middleware Provides logical and physical

information flows over existing business systems

Abstract business layer


Process Integration


Collaboration Providing geographically dispersed

workgroup with opportunity to share information in real time to support a business need

Greatest strength – supporting virtual communities of participating humans and computers “Information Anywhere” concept

Centralized set of middleware to manage information


Collaboration

•CRM

•Product Development

•Logistics

•Knowledge Management


Types of B2B Application Integration

Data-oriented Application interface-oriented Method-oriented Portal-oriented Method-oriented Process integration-oriented


Data Oriented Application Integration

Simple process Information extraction from one

database Processing as required Updating in one or more databases

as required Advantage – cost

Mostly leaving application code unchanged


Application Interface-Oriented Application Integration Leveraging of interfaces exposed

by custom or packaged applications Access both business processes and

simple information Bundle any number of applications to

share business logic and information Limitations

Specific features and functions of the application interfaces


Method-Oriented Sharing of business logic that exists within

the enterprise Numerous mechanisms

Distributed objects Application servers Transaction processing monitors Frameworks New applications

Two approaches Create shared set of application servers on

shared physical platform Share already existing methods using

distributed method-sharing technology


Portal-Oriented Expanding paradigm due to

increasing popularity and utility of web

Shared access to information through a common utility interface


Process Integration-Oriented

Abstract business-oriented layer on top of traditional B2B information movement techniques and mechanisms

Provides business-oriented, process-automation view of business information flow between trading partners

Deals with abstract and shared processes People Invoices Orders Companies Merchandise

Does not deal with physical integration flows or physical systems


Dimensions of B2B Application Integration

MethodMethod

Application InterfaceApplication Interface

DataDataPro

cess I

nte

gra

tion

Port

al

Interaction

Points of Integration


Data-oriented B2B Application Integration

Issues Coupling versus cohesion XML (Extended Markup Language) Example Database to database B2B

application integration Federated databases in B2B

application integration Consideration of data sources


Issues Entry point for B2B application

integration Allows for data to be moved between

data stores Numerous tools exist Few significant change to application

logic or database structure Understanding does not make this easy

Complexity of database world Information flow through an enterprise

How the data is used


Coupling versus Cohesion

Coupling Creates one application and database out of

many with tight dependencies Cohesion

Logical agreement among independent applications and databases

Greatest flexibility Systems can be added/changed/removed without

requiring significant changes to other systems in the problem domain

Message brokers provide infrastructure Resolve differences in application semantics within a

middle tier process

Cohesion generally more optimal than coupling


Grid Computing Tutorial


Grid Technology Abstract Emerging new field

Beyond distributed computing Focus

Large-scale resource sharing applications High-performance orientation

Requires Flexible, secure, coordinated resource sharing Involves dynamic collection of

Individuals Institutions Resources

Characterized by unique authentication, authorization, resource access, and resource discovery

The virtual organization


Introduction and Background

Term “grid” originated – mid 1990’s Proposed infrastructure for science and engineering Expanded to include broadest technology spectrum

From advanced networking To artificial intelligence And everything in between

Addresses real and specific problem space Distinct and separate from popular technology

trends Internet Enterprise computing Distributed computing Peer-to-peer computing

Symbiotic opportunities when popular technologies “grow into” the grid problem space


Grid Problem Space Coordinated resource sharing and problem solving in dynamic,

multi-institutional, virtual organizations Essential needs

Highly flexible sharing relationships ranging From client-server To peer-to-peer

Sophisticated and precise levels of control over use of shared resources Fine-grained and multi-stakeholder

Access control Delegation Application of local and global policies

Sharing of resources From programs, files, and data To computers, sensors, and networks

Diverse usage modes From single-user to multi-user From performance sensitive to cost-sensitive

Quality of service Scheduling Co-allocation Accounting

Not addressed by current Not addressed by current generation of distributed generation of distributed computing technologiescomputing technologies


What Grid Technology Offers Security solutions that support management

credentials and policies across multiple enterprises Resource management services and protocols to

support Secure remote access to computing and data

resources Co-allocation of multiple resources

Information query protocols and services that provide configuration and status information about Resources Organizations Services

Data management services that locate and transport datasets between storage systems and applicationsCompliment existing distributed computing technologiesCompliment existing distributed computing technologies

rather than competing with them!rather than competing with them!


Grid Technology Placement – a Perspective Virtual organizations

Set of collaborating enterprises Viewed as a single logical entity

Leverage collaborator Processes Policies Systems Resources

Single-enterprise viewpoint (s) Collaboration among diverse business units

Merger/acquisition/divestiture ramifications Cooperative processing among less-than-compatible systems

Multi-enterprise viewpoint (m) Collaboration among diverse enterprises m=sn where n is the number of enterprises

Global considerations


Virtual Organizations Collaboration to achieve a common goal An enterprise can participate in multiple virtual organizations

Domain-relevant Market-centric Industry-oriented

Problem-centric Opportunity-centric Economics-driven

Dynamic over time Resource sharing is managed

“Need to know” accessibility Conditional availability – who, what, when, how Discovery mechanism required to characterize the state of

relationships at some particular point in time Peer-to-peer considerations

Providers and consumers Subset relationships

Single resource, multiple sharing opportunities

Common Interest


Concept of Grid Architecture Grid architectures require establishment of

sharing relationships among potential participants Central issue interoperability protocols

Grid architecture is a protocol architecture Mechanisms for users and resources to

negotiate, establish, manage, and exploit sharing relationships

Standards-based open architecture Facilitates extensibility, interoperability,

portability, and code sharing Standard protocols enable definition of standard

services that provide enhanced capabilities Application Programming Interfaces (API) Software Development Kits (SDK)


Importance of Interoperability Need to initiate sharing relationships

among arbitrary partners Need to accommodate new partners

dynamically across different computing environments Hardware Software

Need to promote multilateral sharing arrangements Avoid bilateral resource sharing Ensure availability of sharing mechanisms in

a dynamic partnership environment


Importance of Protocols Protocol definition specifies

How distributed system elements interact with each other to achieve a specified behavior

Structure of information during interaction Virtual organizations compliment existing

enterprises/institutions Sharing mechanisms must avoid substantial changes to local

policies Sharing must preserve individual (institution) control of (their)

resources Protocols

Govern the interaction between components Do not govern implementation of components

Without standard protocols, interoperability requires Single implementation at the API level

or Having every implementation know details of every other


Grid Architecture Description

ApplicationApplication

CollectiveCollective

ResourceResource

ConnectivityConnectivity

FabricFabric

Gri

d P

roto

col

Arc

hit

ectu

re


TransportTransport

InternetInternet

LinkLink

Inte

rnet

Pro

toco

l A

rch

itec

ture

A relationship exists between the Grid ProtocolA relationship exists between the Grid ProtocolArchitecture and the Internet Protocol Architecture.Architecture and the Internet Protocol Architecture.


Fabric Layer – Local Control Interface

Provides resources to mediate shared access to system facilities by Grid protocols Physical system facilities require external

protocols – computational components, storage systems, catalogs, network and/or sensors

Logical system facilities require internal protocols – distributed file system, computer cluster, and/or distributed computer cluster

Implements local, resource-specific operations on specific (logical or physical) resources as the result of higher-level sharing operations

Interdependence between fabric-layer functions and sharing operations Tightly coupled


Delivering Functionality

Can be combined in a variety of ways to deliver functionality to applications


Co-reservation Service API & SDKCo-reservation Service API & SDK

Co-reservation ServiceCo-reservation Service

Co-Allocation API & SDKCo-Allocation API & SDKResource Mgmt API & SDKResource Mgmt API & SDK

NetworkNetworkResourceResource

NetworkNetworkResourceResource

ComputeComputeResourceResource

ComputeComputeResourceResource

Co-reservation ProtocolCo-reservation Protocol

Resource Management ProtocolResource Management Protocol

Collective LayerCollective Layer

Resource LayerResource Layer

Fabric LayerFabric Layer


Fabric Layer – Local Control Interface Minimum implementation

Enquiry mechanisms that permit discovery of resource structure, state, capabilities

Resource management mechanism that provide control of delivered quality of service

Capabilities Computational resources – starting, monitoring,

and controlling the execution of programs Storage resources – getting and putting of files Network resources – managing network

transfers Code repositories – managing versioned source

and object code Catalogs – implementing catalog query and

update capabilities


Connectivity – Communication and Authentication Protocols Communication protocols – enable exchange

of data between Fabric Layer resources Communications includes

Transport Routing Naming

Authentication protocols Build on communications services Provide cryptographically secure mechanisms

for identity verification Users Resources

Security aspects – standards based


Authentication Solutions for VO Environments Single sign on – one-time

authentication provides access to allowed Grid resources

Delegation – ability to endow a program to execute on the named user’s behalf

Interoperate with local security solutions

User-based trust relationships


Resources Layer – Sharing Single Resources Defines protocols, API’s, and SDK’s for

Secure negotiation Initiation Monitoring Control Accounting Payment processing

Call Fabric Layer functions to access and control local resources

Concerned entirely with individual resources Primary protocols

Information protocols – obtain information about state and/or structure of resources

Management protocols – negotiate access to a shared resource

Operations


Collective Layer – Coordinating Multiple Resources Protocols, API’s, and SDK’s

Not associated with any one particular resource

Global in nature Capture interactions across

collections of resources


Collective Layer Services Directory services – discover existence and/or

properties of VO resources Co-allocation, scheduling, and brokering services –

Allow VO participants to request allocation of one or more resources

Allow VO participants to schedule tasks on appropriate resources

Monitoring and diagnostics services – monitor VO resources for failure, adversarial attack, or overload

Data replication services – support placement of data to maximize data access performance with respect to metrics such as response time, reliability, and cost

Grid-enabled programming services – allow use of familiar programming models to be used in Grid environments to address resource discover, security, and resource allocation


Collective Layer Services Workload management systems and collaboration

frameworks – aka problem solving environments Provide for description, use, and management of multi-

step, asynchronous, multi-component workflows Software discovery services – discover and select

most appropriate implementation and execution platform based on parameters of problem being solved

Community authorization services – enforce community policies governing resource access, to generate access capabilities to community resources

Community accounting and payment services – gather resource usage information for accounting, payment, and/or resource usage management

Collaboratory services – supports information exchange among users


Applications Utilize services defined at any of the

other layers Construction Utilization

Implemented using SDK’s Exchange protocol messages with

appropriate services to perform desired actions

Utilize Frameworks Libraries

= Φ (well-defined protocols)


Applications

Language & FrameworkLanguage & Framework

ApplicationsApplications

Collective API’s & SDK’sCollective API’s & SDK’s

Collective ServicesCollective Services

Connectivity API’sConnectivity API’s

Resource API’s & SDK’sResource API’s & SDK’s

Resource ServicesResource Services

FabricFabric

Key

API/SDKAPI/SDK

ServiceService

Collective Service ProtocolsCollective Service Protocols

Resource Service ProtocolsResource Service Protocols

Connectivity ProtocolsConnectivity Protocols


Bilateral Relationships


Multilateral Relationships

GridGrid


Grid Architecture Services

Application 1 Application 2

Collective (application-specific)

Solver coupler, distributed data archiver

Check-pointing, job management, failover, staging

Collective (generic)

Resource discovery, resource brokering, system monitoring, community authorization, certificate revocation

Resource Access to computation, access to data, access to information about system structure, state, performance

Connectivity Communications, service discovery, authentication, authorization, discovery

Fabric Storage systems, computers, networks, code repositories, catalogs


An e-Business Process FlowPurchase Order/Order Entry Between Customer

and Supplier


In the beginning . . .

InventoryManagement

Process

InventoryDatabase

PreparePurchase Order

Recognizes EOQ/JIT level

SupplierCatalog

Purchase OrderMessage

Purchase Order Messagesent for review/approval

ReviewPurchase Order

Purchase OrderMessage

Purchase Order reviewed, approved,and submitted to supplier

FirewallSecurityCheck

•Authorized submitter•Authorized named personnel•Authorized supplier

Destination

Delivery Mode

Message ID

Timestamp

Correlation ID

Reply To

Redelivered

Type

Expiration

Priority

Heade

r sho

ws

dest

inat

ion

as re

view

er

Header shows destination as supplier

To Supplier

PurchaseOrder DB


Next, . . . From Purchaser


•Authorized submitter•Authorized named personnel•Authorized trading partner•Authorized recipient

OrderEntry System

InventoryDatabase

ManufactureDatabase

PurchaseOrder System

Fulfillment System

If in inventory, messageSent to fulfillment system

Fulfillment Message

ManufacturingSystem

InventoryDatabase

Manufacturing Message

Fulfillment Message

Purchase Order Message

If not in inventory, messageSent to manufacturing system

Manufacturing system uses data in inventory and manufacturing databases

If raw materials required, purchase order message is sent

When order has been completed, a message is sent to the fulfillment system

Order ReceiptMessage

Acknowledgement message sent

Purchase Order Message

Purchase order is admitted through firewall and passed to order entry system

OrdersDatabase


Continuing, . . .

Firewall


SecurityCheck•Authorized submitter

•Authorized named personnel•Authorized trading partner•Authorized recipient



Purchase OrderManagement


Stakeholder StatusMessage

Message is transmitted

Validated message sent to Purchase Order Management System

PurchaseOrder DB

Messages sent to named stakeholders


Meanwhile, . . .

Fulfillment System

Fulfillment Message

FulfillmentMessage

Billing Message

Fulfillment Message

Shipping System

Billing System

Firewall

Fulfillment Message

Inventory System

InventoryDatabase

Shipping Notice Message

Fulfillment System sends messages to Shipping and Billing Systems

Billing System prepares and sends bill


Fulfillment System

Fulfillment Message

FulfillmentMessage

Billing Message

Fulfillment Message

Shipping System

Billing System

Fulfillment Message

Inventory System

InventoryDatabase


Fulfillment System sends messages to Shipping and Billing Systems


SecurityCheck

•Authorized submitter•Authorized named personnel•Authorized trading partner•Authorized recipient

BillingDatabase

To Purchaser


And, . . .

Firewall

Billing Message


SecurityCheck

Accounts Payable

Electronic Payment

GeneralLedger DB

PurchaseOrder DB

Receiving System

PurchaseOrder DB

Firewall

ReceiptMessage

Billing message is sent to Accounts Payable



SecurityCheck

Shipping Notice message is sent to Accounts Payable

Receipt message is sent to Accounts Payable

Electronic Payment is sent to supplier

From Supplier

To Supplier


Finally

Firewall

SecurityCheck


Electronic Payment

PaymentsPaymentProcessing

GeneralLedger

OrdersDatabase

BillingDatabase

Payment is processed

From Purchaser


Considering the State of the Practice Service-Oriented Enterprise Integration Landscape Open Source Integration

Considerations Mobility


Service-Oriented Enterprise (SOE) Architectural strategy to improve the

integration of processes and data within an operational enterprise Enterprise definition separate and distinct from the

set of systems that comprise it (the enterprise) Enterprise is not a single, massively large system Optimized enterprise integration strategy is not

(necessarily) congruent with a “system of systems” strategy

Objective – service excellence for users and/or customers

Operational enterprise – the set of individual organizations that collaborate to conduct business


Structural Elements of SOE Smart Data Smart Grid Smart Services


Structural Elements of SOE – Smart Data Data equipped with semantic content

using metadata Characterization Model-based representation via defined

process Smartness – measurable quantity

Rigor Precision Accuracy Structure Abstraction


Structural Elements of SOE – Smart Grid Interface-driven interconnection across the enterprise

Physical structure Protocol routines

Corresponds to SOA implemented using shared-language paradigms Technology-neutral Defined independently

Smart grid characteristics Shared interconnection network architectures; common

entry and messaging methods Message management capability to insure reliable data

delivery and appropriate statusing (success and failure) Information assurance controls to prevent corruption of

enterprise communication process Intentional Unintentional

Adequate resources to support interconnectivity requirements


Structural Elements of SOE – Smart Services Synonymous with semantic services

Shared resources Configured as Web Services Assets available to the enterprise regardless of

physical ownership Enterprise Global Repository

Structured resource that provides access to Metadata Process and data models Metamodels Process and data constructs

Build-time resource Supports integrate-ability

Run-time resource Supports active data translations across systems


SOE Disciplines Data Engineering – developing and documenting

semantic content for enterprise data throughout the enterprise lifecycle

Grid Engineering – developing and evolving the smart grid architecture Selection of integration tools, processes and standard

protocols Establishes rules of engagement for application and

system participation Prescribes methods for integrating legacy systems and

applications Process Engineering – designing and documenting

enterprise processes Enables process improvement Develops rules for process interaction and associated

enforcement Includes associated elements of data


Enterprise Engineering

Data Engineering

Un

man

ag

ed

, ad

hoc

Form

alized

In

form

ati

on

M

od

elin

g

Syste

mati

c D

ata

Defi

nit

ion

s

Meta

data

-dri

ven

in

form

ati

on

in

teg

rati

on

Grid Engineering

Unmanaged, ad hoc

Encapsulation/object oriented

Capture of Business Intelligence

Externalization of Business Intelligence

Unmanaged, ad hoc

Business Rule Standardization

Process Modeling

Outcome-driven processes

Process Engineering


Integration Platforms - SOA Integration

Requirements Composite

applications Real-time business

intelligence and analysis

Internal collaboration

External collaboration

SOA Provides Message bus and

application integration as core features

Integrated process management capability

Presentation and other interaction features

Industry protocols and collaboration formats

Life-cycle management facilities


Integration Platforms - SOA Available from

vendors by class Application Enterprise

application Independent

integration Data integration

Key factors for determining the most appropriate platform1. Separate application

integration from data integration

2. Consider the context – application, enterprise, or data

3. Align architecture at the optimum level – product, vendor, standards, technology

4. Level of convergence


Open Source Integration Alternative way of building an infrastructure using

best-of breed components Complexity factors

Global sourcing Independent release schedules Frequent release schedules

Benefits Reduced cost and effort for installation and

configuration Increased confidence in reliability and stability Improved ability to troubleshoot applications Easier infrastructure management Infinite combination of components Multiple component use Different service models Enhanced value add


Open Source Integration Key elements for success

Common management tools Common security model Consistent and coordinated

maintenance Component compatibility Consistent licensing model for

utilized components


Mobility Ability of an individual to work

anywhere at any time utilizing all of the features and capabilities of the system environment

Includes Computing Communications

Benefits Availability Productivity Cost savings Cost avoidance


Historic Mobility Linked to

Portable computing Wireless telephony

Based upon “fixed port” accessing Required physical connectivity


New Mobility Outgrowths of wired technology Transcends enterprise network

perimeter Wherever the user needs information Voice and data

Key benefits Freedom of access to information Identity-based security Network economics


Capabilities for New Mobility1. Identity-based security to protect both network

and user2. Non-disruptive integration into existing networks3. Secure convergence for mobile VoIP and data

services4. Adaptive radio management for self-configuring

WLANs5. Remote extensions for instant enterprise hot

spots6. Enterprise-grade scalability, reliability, and

performance7. Open mobility platform for application

development and integration


Problem Scenario Purchasing Collaborative

As the result of a professional society survey initiative, a number of enterprises in some particular industry determine that they purchase similar items from a common set of suppliers. Upon reviewing the supplier’s terms and conditions, a cost saving benefit is recognized if the several industry enterprises can engage in a common procurement activity. From the enterprise perspective, there would be common pricing based on shared catalogs price with advantages for larger orders. From the supplier perspective, there would be fewer purchase orders to handle, thereby reducing labor-intensive activities and associated operating costs. Initial discussions with the supplier community are encouraging; the problem is that every participant has an individual information processing environment that offers minimal commonality.

Could this problem be solved using traditional computing methods?

What solution possibilities are offered by grid computing? SOE? Mobility?

Develop a schematic that illustrates a solution proposal.

Documents

Integrating for Enterprise Support IST 421 Supplement