Copyright © 1995-2006 Open Applications Group, Inc. All rights reserved 1 Open Applications Group OAGi 101 OAGIS Introductory Seminar

Copyright © 1995-2006 Open Applications Group, Inc. All rights reserved1

Open Applications Group

OAGi 101

OAGIS Introductory Seminar

http://www.openapplications.org


Introductions


Agenda

• OAGi Introduction• OAGIS® Introduction• XML Introduction• Application Integration• eBusiness Integration• OAGIS® Application Scope• OAGIS® Technology• Using OAGIS®

• OAGIS® Adoption• OAGIS® Case Study• Customer Examples


Purpose

• Introduction to OAGi and OAGIS specification

• XML Introduction• The XML World• Introduction to Data Interchange

beyond EDI• Familiarization with building OAGIS


This class won’t . . .

• Teach you all about XML• Teach you to be an XML developer• Teach you all about UML• Teach you to be a UML Modeler


Target Audience

• Managers• EDI Analysts• Business Analysts• Systems Analysts• Integration Architects• Software Architects• Data Analysts



OAGi 101

Open Applications Group Introduction


OAGi is a not-for-profit, independent, open standards development organization.

It was formed to promote interoperability among business software applications and to create or endorse one or more standards for easier business software interoperability.

The primary technical standard produced by OAGi is OAGIS, the OAG Integration Standard.

Open Applications GroupWho we are


The Open Applications Group

• OAGi is . . . The Open Applications Group, Incorporated

• OAGIS is . . . The Open Applications Group Integration Specification



• We represent the consumers of integration technologies

• Looking at this from application assembly point of view


Your Constituency

• Software Architects• Business Analysts• Project Managers• Development Managers• Product Managers• Industry Experts/Managers• Business Development


OAGi Activities

• Technical Activities – Standards Development

• Out Reach Activities – Working with Industry

• Interoperability Activities – NIST Test Bed– Semantic Integration

• Services and Training– OAGIS Help to Users


Fully Integrated Enterprise

E2E = B2B + A2A + A2ETMEverywhere to Everywhere Integration


OAGi Genesis

• Founded in November, 1994• Originally by ERP Vendors• Focused on how they can

integrate together better• Identified common content as

biggest missing piece


Original Membership

• American Software• CODA Financials• Dun & Bradstreet• Marcam• Oracle • SAP• PeopleSoft• Software 2000


By the Membership andfor the Membership

• OAGi is owned by its members• Open Membership• Anyone can join• Must be a member to join or form

a Workgroup• OAGIS work is supported by

membership fees


Umbrella

• OAGi is your umbrella organization for building business languages for interoperability


Some OAGIS Contributors

KildaraKim Liljeborg (Global Brewer)Lars Abrell (Scanova)Lockheed MartinLouis Davis / Earl Miller (GHX)Lucent TechnologiesMarcam=>Wonderware=>InvensysMega.comMenlo WorldwideMicrosoftMike Parks (Georgia Tech)NADA/STARNECNet Commerce Corp.Netfish Technologies=>IONANetonomyNexPrise=>VentroNextSet Software, Inc.NISTObjectSpace, Inc.ObTechOnDisplay=>VignetteOptio Software, Inc.OraclePaperExchange.com=>PaperSpace.comPCS Inc.PeoplesoftPricewaterhouse Coopers=>IBMPSDI=>MRO SoftwareQADQuadremRequisite Technology

Robocom SystemsSAGA SAGA SoftwareSand Hill SystemsSAPScalaSiemensSilverstreamSoftQuad SoftwareSoftware Technologies Corp.=>SeeBeyondSterling CommerceStreamServe, Inc.Sun MicrosystemsSupplierMarket.comSymbolic SystemsSynQuest, Inc.Teklogix=>Psion TeklogixTexas InstrumentsTibcoTilion, Inc.Toyota Motor SalesTradeAccess=>OzroTrilogyTSI=>MercatorU.S. Air ForceUnilever PLCUS DataVesta TechnologiesViewlocityVitria TechnologywebMethodsXML Global TechnologyXML Solutions=Vitria

STAR


Questions?


What is OAGIS?


OAGIS is Process Definitions and Payloads

• Scenario is process definition– Expressed in UML

• Business Object Documents (BODs) are messages within the Collaboration– Expressed in XML

• Freely downloadable at:


Customer Supplier

ProcessPurchaseOrder

AcknowledgePurchaseOrder

ShowDeliveryReceipt

ProcessInvoice

ConfirmBOD


OAGIS is . . .

• A business language• Defines a common data model for data

exchange between business applications

• Comprehensive specification defining a library of business processes

• Focused on extra-enterprise and inter-enterprise interoperability scenarios and;


OAGIS® Role

General LedgerGeneral Ledger

Business ObjectBusiness ObjectDocumentDocument

App1App1

Inventory ControlInventory Control

App5App5 App6App6App4App4 App7App7

App2App2 App3App3


OAGIS is expressed as XML

• The OAGIS® standard is expressed as XML Schema definitions

• Built this way to be machine readable

• OAGIS® also includes XML instance examples of each Schema definition


OAGIS 9 Scope

• 62 Business Scenarios• 434 Messages (BODs)• 77 Nouns (Common Objects) defined • 12 Verbs Defined• Seven Workgroups of new Content• More localization for more International support• UN/CEFACT/ISO compliant

– ISO 11179– CCTS 2.01/ISO 15000-5– TBG17 BIE/ABIE

• 10 Years in the Field


• Not building software • Not building a protocol • Not building middleware• Not choosing technology• Not defining objects

What The Group is NOT doing


Questions?


What is XML?

• eXtensible Markup Language is a text-based mark-up language

• It enables content into a self-describing wrapper• Development of XML started in 1996 and became

a W3C (World Wide Web Consortium) standard in February 1998.– XML is Simplified SGML– HTML is an SGML Application

• XML is not a business language, but requires a business language to be defined within it, like a programming language.


• XML is a successor to EDI• XML defines the data as it is

being transmitted• XML is technology neutral• More powerful capabilities

for integration• Emerging tools supporting it

XML Emerging


Why XML?

• XML provides a much richer data capability than other approaches

• XML enables more advanced types of eBusiness connections and application integration

• XML tools provide more options for interoperability

• XML is less expensive than EDI– Brings in your smallest trading partners at

a very low entry cost– EDI for the masses


“The issue of vocabulary is one of the most important questions surrounding XML today. Just because we obey the rules of XML doesn't mean we are creating messages that people outside our circles can understand.”

Why XML?


XML Segmentation

• Documentation constituency• Web constituency• Data constituency


The W3C XML Family


XML Layers

• XML Language itself• XML Frameworks• XML Payloads• XML Repository• XML Design and

Development Tools


• W3C• ebXML, OASIS• WS-I• RN• W3C• OAGi• RN• HR-XML• IFX• ebXML• HR-XML• HL7• IFX• etc.• WS-I• ebXML

Defining XML

Defining Content (vocabulary and process)

XML SegmentationStandards Groups

Defining Internet Service layer

Frameworks and infrastructure


XML Adoption Curve

• Out of experimental stage

• Fully into early adoption

• Less talk, more action

• It is not too late

We are about here


XML Payload Definition and Instance

• The XML Definitions are defined in XML Schema– Equivalent to Table or Record definition– ASCII Text– File names are .XSD

• The XML Instances are occurrences of the definitions– Based on the XSD definition– ASCII Text– Validated against .XSD definition– File names are .XML


XML Definition and Instance

Schema Definition

XML Instance


XML PayloadExample


XML Summary

• XML provides a much richer data capability than other approaches

• XML tools provide more options for interoperability

• XML enables more advanced types of eBusiness connections and application integration such as web-based or process-based integration

• XML is less expensive than EDI– Brings in your smallest trading partners at

a very low entry cost– EDI for the masses


How does this relate to EDI?


• EDI is not disappearing soon• 1st Generation B2B• Suited mainly for big companies• Still largest B2B environment• Organizations generally don’t

remove systems that work

EDI Views

EDI and OAGIS and Co-Exist!


OAGIS and EDI Example

End UserCustomer

PurchasingSystem

XML MessageProcessing

EDI 850PO

EDI 850ACK

WebFrontEnd

ProcessPO

AcknowledgePO

XML MessageBroker

Pricing

Order

ProcessPO

AcknowledgePO

OrderEntry

Processing

Java calls

EDI 850PO

CustomXML

Real EDI 850 ACK

OrderManagement

System

Legacy

Recent


• Long Start Up• Static Relationships• VANs and Proprietary

Technologies• Expensive• High Latency - Batch• Flat File Extracts• Non-Interactive• Document Based• Fixed Documents• Enforcement

• Fast Start Up• Dynamic Relationships• Internet and Open

Technologies• Less Expensive• Low Latency - Real-time• API Based• Process Enabled• Message Based• Meta Data Based• Collaboration

EDI Views


EDI to XML Reference

More examples at http://www.eidx.org/publications/xref_process.html#BPmodl-docs

Shipment Order Used by a depositor (the warehouse's client) to advise the warehouse to make a shipment, confirm a shipment, or modify or cancel a previously transmitted shipping order.

940 ShowShipmentStatus ORDERS 3B12

Warehouse Shipment Notification

Used by a warehouse to advise a client that the shipment has been made in response to a Warehouse Shipping Order.

945 ShowShipment DESADV 3B12

Warehouse Inventory Transfer Receipt Advise

Used by a warehouse to advise the depositor that inventory shipped to the warehouse has been received.

944 AcknowledgeDeliveryReceipt

RECADV 4C3


Back to OAGIS

• Scenarios• BODs


OAGIS is Process Definitions and Payloads

• Scenario is the process definition

• Business Object Documents (BOD) are messages in the Scenario

Customer Supplier



ShowDeliveryReceipt

ProcessInvoice

ConfirmBOD


OAGIS BODs are a Language

• OAGIS BODs use XML to define a common business language for businesses to use.

• This language is used to exchange information between business applications and businesses.


OAGIS BOD Definition

• The OAGIS Business Object Document (BOD) Architecture defines the common XML structure and behavior definition for all OAGIS Messages.

• The OAGIS BOD Definition defines the layout or structure of a specific message to be used.

• The OAGIS BOD Instance is an occurrence of a live message that contains real data in the format defined in the schema above.

• The term BOD is often used as a generic term used to describe either BOD Definitions or BOD Instances.


OAGIS BOD Definition

• The OAGIS BOD Architecture is defined in the OAGIS Design Guide – A Word Documentor on web site in HTML.

• The OAGIS BOD Definitions are defined in XML Schema, in a text file such as:– ProcessPurchaseOrder.XSD– Equivalent to 850 definition

• The OAGIS BOD Instances (occurrences) are defined in XML files that are pure text:– ProcessPurchaseOrder.XML– Equivalent to an 850 occurrence


BOD History

• BOD and Meta Data Invented– June 1995

• XML Prototyping Started– April 1997

• XML DTD Shipped– February 1998

• XML XDR Shipped– December 1999

• XML XSD Shipped– October 2001

• XML Next Gen XSD Shipped– March 2002


Back to Scenarios

Customer Supplier



ShowDeliveryReceipt

ProcessInvoice

ConfirmBOD


UML Introduction

• Universal Modeling Language• De facto standard for software modeling• Design Language with pictures• Developed and owned by OMG


UML Overview

• UML defines twelve types of diagrams, divided into three categories

• Four diagram types represent static application structure;

• Five represent different aspects of dynamic behavior; and

• three represent ways you can organize and manage your application modules.


UML Overview

• Structural Diagrams include the – Class Diagram, Object Diagram, Component Diagram,

and Deployment Diagram.

• Behavior Diagrams include the – Use Case Diagram (used by some methodologies

during requirements gathering); Sequence Diagram, Activity Diagram, Collaboration Diagram, and State Chart Diagram.

• Model Management Diagrams include– Packages, Subsystems, and Models


OAGIS use of UML for Scenarios

• Behavior Diagrams– Sequence Diagram– Collaboration Diagram


General Ledger

SyncChartOfAccounts

PostJournalEntry

AcknowledgeJournalEntry

Accounts PayableAccounts ReceivableBudgetProject AccountingManufacturingInventoryOrder ManagementBillingPurchasingAssetsHuman Resources

SubLedgers

Scenario 1 - General Ledger to Sub-Ledgers

ConfirmBOD

OAGIS® Scenario


OAGIS® Scenario

ProductionPurchasing Order ManagementManufacturing Execution

- MES Demand Planning

SyncProductionOrder

ConfirmBOD

SyncProductionOrder

ConfirmBOD

ConfirmBOD

ConfirmBOD

SyncProductionOrder

SyncProductionOrder

Production SynchronizationProduction Synchronization


OAGIS Scenarios are Processes

• The processes may include large or small– Processes, Activities, Tasks, etc.

• Scenarios are expressed in UML• Provide context for the messages• Serve as library of re-useable

processes• Organizations may modify to fit their

requirements


OAGIS Scenario Content

• All Scenarios in OAGIS Contain– Business Description– Component Definitions– Sequence– Dependencies– Sequence Diagrams


OAGIS Scenario Expressions

• Not Expressed in BPSS• Not Expressed in BPEL4WS• The above or others may be

built by OAGIS users• Machine readable format is

not required for base standard


OAGIS Scenarios

• 1.0 General Ledger to Sub-Ledger Scenario Description.. • 2.0 General Ledger to Budget.• 3.0 Order Management to Accounts Receivable• 4.0 Order Management to Accounts Receivable• 5.0 Order Management to Accounts Receivable• 6.0 Order Management to Accounts Receivable• 7.0 Purchasing to Accounts Payable• 8.0 Purchasing to Accounts Payable• 9.0 Project Accounting Synchronization• 10.0 Feeder Applications to Project Accounting• 11.0 Human Resources Integration• 12.0 Purchase Order Process• 13.0 Plant data Collection – Warehouse Management (Cycle Counts)• 14.0 Plant Data Collection – Warehouse Management (Issues)• 15.0 Plant Data Collection – Warehouse Management (Transfers)• 16.0 Plant Data Collection – Warehouse Management (Receipts)• 17.0 Plant Data Collection – Warehouse Management (Production Orders)• 18.0 Plant Data Collection – Warehouse Management (Work in Process)• 19.0 Plant Data Collection – Warehouse Management (Shipping)• 20.0 Plant Data Collection – Warehouse Management (Time and Attendance)

Page one of three


OAGIS Scenarios

• 21.0 Manufacturing to Purchasing – Receiving and Inspection in Manufacturing (Publish/Subscribe Model)• 22.0 Manufacturing to Purchasing – Receiving and Inspection in Manufacturing (Request/Replay and Publish/Subscribe)• 23.0 Manufacturing to Purchasing – Receiving and Inspection in Purchasing (Publish/Subscribe)• 24.0 Manufacturing to Purchasing – Receiving and Inspection in Purchasing (Request/Reply and Publish/Subscribe)• 25.0 Manufacturing to Order Management – Financials with Logistics, (Make to Order, Build to order)• 26.0 Manufacturing to Order Management – Financials with Logistics, (Engineer to Order, Configure to order)• 27.0 Manufacturing to Order Management – Financials with Logistics, (Mixed Mode Manufacturing)• 28.0 Manufacturing to Order Management – Financials with Manufacturing, (Make to Order, Build to Order)• 29.0 Manufacturing to Order Management – Financials with Manufacturing, (Engineer to Order, Configure to Order)• 30.0 Manufacturing to Order Management – Financials with Manufacturing, (Mixed Mode Manufacturing)• 31.0 Invoice Matching, Matching in Purchasing, Invoices entered in Purchasing• 32.0 Invoice Matching, Matching in Purchasing, Invoices entered in Accounts Payable (Publish/Subscribe)• 33.0 Invoice Matching, Matching in Purchasing, Invoices entered in Accounts Payable (Request/Reply)• 34.0 Invoice Matching, Matching in Accounts Payable, Invoices entered in Accounts Payable (Publish/Subscribe)• 35.0 Invoice Matching, Matching in Accounts Payable, (Request/Reply)• 36.0 Synchronize Sales Orders for Shipping• 37.0 Sales Force Automation to Order Management, Updating orders in Order Management• 38.0 Sales Force Automation to Order Management, Inquiring on orders in Order Management• 39.0 Sales Force Automation to Order Management and Shipping• 40.0 Supply Chain Integration, Manufacturing to Purchasing, Order Management, Billing, Shipping, and Financials

Page two of three


OAGIS Scenarios

• 41.0 Customer Service Integration, Field Service, No Returns• 42.0 Manufacturing to Order Management, Financials with Manufacturing, Make to Order with Credit Checking• 43.0 Manufacturing to Purchasing, Receiving and Inspection in Manufacturing, Request/reply Model• 44.0 Production Synchronization• 45.0 Purchase Order Integration• 46.0 Production Routing synchronization• 47.0 Human Resources Integration• 48.0 Hr to Time Data Collection• 49.0 Engineering Changes Scenario Description• 50.0 ERP to Finite Scheduling and Manufacturing Execution Scenario Description• 51.0 Computerized Maintenance Management System (CMMS) to Field Devices• 52.0 Catalog Exchange Scenario Description• 53.0 PriceList Exchange Scenario Description• 54.0 Item Unit-Of-Measure (UOM) Integration Scenario• 55.0 Buyer and Supplier RFQ - Quote Scenario Description• 56.0 Forecast Exchange Scenario Description - Revision 001• 57.0 Production to Manufacturing Execution Scenario Description• 58.0 Supply Chain Execution Scenario Description• 59.0 Ledger Actuals Scenario Description• 60.0 Vendor Managed Inventory (Consumption) Scenario Description• 61.0 Full Cycle Purchasing (non-production)

Page three of three


Value Chain CollaborationApplications

EnterpriseManagement Applications

EnterpriseExecution

Applications

Current Scope of OAGIS® 9.0 Content

• eCommerce– e-Catalog– Price Lists– RFQ and Quote – Order Management– Purchasing– Invoice– Payments

• Manufacturing– MES– Shop Floor– Plant Data Collection – Engineering– Warehouse Management– Enterprise Asset Mgmt.

• Logistics– Orders– Shipments– Routings

• CRM– Opportunities– Sales Leads– Customer– Sales Force Automation

• ERP– Financials– Human Resources– Manufacturing– Credit Management– Sarbanes/Oxley & Control


Questions?


Integration ApproachesIntegration Approaches

• Batch

• Asynch

• Synchronous

• EDI

• Import/Export

• Process/Workflow

• Desktop launching

• Cross product reporting


Payloads and Envelopes

Payloads

Envelopes


• Tightly coupled• Synchronous• RPC based

– CORBA– COM, DCOM

• Unique content

Previous Best Practices


Integration Topologies

• Request Reply– Point to Point– Spaghetti

• Hub and Spoke• Publish and Subscribe• Bus Topology• Exchanges


Point to Point

Connect

or

OrderMgmt

Connecto

r

MRPIntegration

ServerC

onnect

orC

onnecto

r

or . . .

Connect

or

OrderMgmtC

onnecto

rMRP


Point to Point

Order ManagementERP

CRM

Finance

eCommerce

Data Warehouse

Content Mgmt.

Logistics

Known as Spaghetti Diagram


Hub and Spoke

Connector

Data Warehouse

Connect

or

OrderMgmt

Connector

CRM

Connecto

r

MRPIntegration

Server

Connector

Connect

or

Connector

Connecto

r


Publish and Subscribe

Connector

Data Warehouse

Connect

or

OrderMgmt

Connector

CRM

Connecto

r

MRPIntegration

Server

Connector

Connect

or

Connector

Connecto

r


Bus Topology (SOA)

Message Bus

Connector

OrderManagement

Connector

Data Warehouse

Connector

CRM

Connector

MRP

Connector

Configurator

Connector

IntegrationServer


IBM SOA Definition

• What is an SOA? SOA is the blueprint for IT infrastructure of the future.

SOA extends the Web services value proposition by providing guidance on how enterprise IT infrastructure should be architected using services.

http://www-306.ibm.com/software/solutions/webservices/


IBM Definition of SOA

• Within a service-oriented architecture, applications, information and other IT assets are viewed as services or “building blocks.”

• Each of these services can be mixed and matched to create new, flexible business processes.


Microsoft Definition

• The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer.

• Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface.

http://msdn.microsoft.com/architecture/soa/default.aspx?pull=/library/en-us/dnmaj/html/aj1soa.asp#aj1soa_topic2


Microsoft and SOA

• What's important to recognize is that Web services are part of the wider picture that is SOA.

• The Web service is the programmatic interface to a capability that is in conformance with WSnn protocols.


Microsoft on SOA

• In fact Web services are not a mandatory component of a SOA, although increasingly they will become so.

• SOA is potentially much wider in its scope than simply defining service implementation, addressing the quality of the service from the perspective of the provider and the consumer.


History of SOA

• DCE• Object Orientation• COM/CORBA• Messaging• ebXML• Web Services


Distributed Computing Environment (DCE)

• The OSF Distributed Computing Environment (DCE) is an industry-standard, vendor-neutral set of distributed computing technologies.


History of DCE

• 1987 - The Open Software Foundation (OSF) is formed. Their purpose is to standardize the UNIX operating system and to promote the interoperability amongst computer systems. The organization is vendor neutral.

• 1988 - OSF issues a request for distributed computing technologies amongst its member companies.

• 1989 - After lots of tests, analyses and reviews a core set of technologies for a distributed computing environment (DCE) is finally selected.

• 1991 - DCE 1.0 is released. It has been developed by five companies in USA, Germany, Ireland and members of OSF.


Goals of DCE

• Network transparency • Location transparency • Location independence • User mobility • Fault tolerance • Resource mobility


Web Services Stack for SOA


The Importance of Content

• What if he is speaking French,• And she is speaking Mandarin?• They are connected,• But they are not communicating.


Typical SOA Depictment

Request

Web ServicesProviderResponse

InternetWeb ServicesProvider

J2EE™AppServer .NET

SOAP Messages

This is the WRONGPicture for SOA

This is the WRONGPicture for SOA


What is a Service?

General Ledger

OrderManagement

ReceivingInventory

HumanResources

CustomerService

AccountsReceivable

AccountsPayable

Production

SyncPersonnel

Load Receivable

Load Payable

Sync EmployeeWorkSchedule

Add SalesOrder

Sync SalesOrder

Sync Party

Sync I

temMas

ter

IssueInv

entor

yMov

emen

tCreate

ProductionOrderPost JournalEntry

Sync ChartOfAccounts

Sync ExchangeRateGet PickList

Update PickList

Show PickList

Update SalesOrder

Sync ItemMaster

Receive

Inven

toryM

ovem

ent

OAGIS 8.0 Scenario 41

This is A

Service

This is A

Service


Typical SOA Depictment

Request

Web ServicesProviderResponse

InternetWeb ServicesProvider

J2EE™AppServer .NET

SOAP Messages


OAGIS® and SOA

• SOAP standardizes the shape of the plugs

• WSDL standardizes the shape of the outlet (WSDL)

• OAGIS® provides the current that powers the service

OAGIS XML

SOAP

WSDL



Service Bus

CRM

`

ERP

`

SCM

`

PDM SALES

RECEIVING

B2B Portal


OAGIS® in the SOA Stack

• Real services are functions for the business

• The technology stack is important,• But the service is the End-in-Mind



OAGIS as a “Canonical” Business Language


Trends in Global Business Integration


Need for Integration

82% of IT Professionals say that integrating existing systems is theirway to improve business processes

Source: Information Week,


Demand for Integration

Customers’ top strategic software platform project over the next year

S ource : M organ S tanley C IO S urvey, M ay 2001N ote : M ultip le responses perm itted

35%

33%

30%

24%

23%

21%

19%

16%

15%

13%

12%

12%

8%

7%

5%

4%

A pp lica tion in te g ra tio ne -b us ine ss

C R MS C M /L og is tics

H RD a ta ba se up g ra de

In trane t im pro vem e n tsF in anc ia l (A cco un ting )

M arke ting app s on W eb s ite

e -p rocu rem en t W eb s iteS ys . m g m t in fras truc tu re

C om m e rce se rve r

B u ild ing In te rne t co m pa nyE ng in ee ring so ftw a re

M an u fac tu rin g so ftw a reO the r

D ereg u la tion

0% 10% 20% 30% 40%

% o f R esp o n d en ts

3%

S ource : M organ S tanley C IO S urvey, M ay 2001N ote : M ultip le responses perm itted

35%

33%

30%

24%

23%

21%

19%

16%

15%

13%

12%

12%

8%

7%

5%

4%

A pp lica tion in te g ra tio ne -b us ine ss

C R MS C M /L og is tics

H RD a ta ba se up g ra de

In trane t im pro vem e n tsF in anc ia l (A cco un ting )

M arke ting app s on W eb s ite

e -p rocu rem en t W eb s iteS ys . m g m t in fras truc tu re

C om m e rce se rve r

B u ild ing In te rne t co m pa nyE ng in ee ring so ftw a re

M an u fac tu rin g so ftw a reO the r

D ereg u la tion

0% 10% 20% 30% 40%

% o f R esp o n d en ts

3%


The Challenges

• Multiplicity of applications across enterprise fulfilling the same function

• No enterprise wide application and information architecture

• Inflexible architecture• Several versions of “enterprise-

objects” such as Product, Customer, etc


The Business Environment

Integration Back Bone

Business

Unit n

Su

pp

lier

Cu

stom

er

Business

Unit 1

Business

Unit 2

Enterprise


• Mostly at the data level• Mostly point to point• Custom program interfaces

or flat file exchange• Grows at exponential rate

Current State of Integration


Application Integration

• How can we break out of this?


Canonical Model

• CANON– Derived from the Greek and Latin

meaning a rule or standard

• CANONICAL– Reduced to the simplest and most

significant form possible without loss of generality; "a basic story line"; "a canonical syllable pattern


A Case for a Canonical Model

From <many to many> to <many to one>


The mathematics of scaling up

For traditional point to point or<many to many> integration:

The number of possible connectionsamong any number of items is n(n-1)for two way connections.

n = 5 5(4) = 20

n = 10 10(9) = 90

n = 15 15(14) = 210

n = 20 20(19) = 380

Number ofcomponentsto integrate

Apply traditionalformula

Cost of traditionalintegration @ 0.1 FTE

2 FTEs (200,000 USD)

9 FTEs (900,000 USD)

21 FTEs (2.1 million USD)

38 FTEs (3.8 million USD)


The mathematics of scaling up

For best practices integration:

The number of possible connections among any number is n * 2.0

Number ofcomponentsto integrate

Best practicesformula

n = 5 5 * 2.0 = 10

n = 10 10 * 2.0 = 20

n = 15 15 * 2.0 = 30

n = 20 20 * 2.0 = 40

1 FTE

2 FTEs

3 FTEs

4 FTEs

Cost of best practicesintegration @ 0.1 FTE


Side by side comparison

<many to many> growth <many to one> growth

4 FTEs38 FTEs


Case Study- Agilent Canonical Model


Agilent EAI : Linking the Way ...

• Create a common “glue” • Open up siloed applications• Establish a rapid integration framework• Realize middleware ROI within 3 years• Create economies of scale of a

development factory

…. Connecting the dots


To develop and institute a common framework to interconnect strategic applications across the enterprise, ensuring alignment of IT investments with Agilent’s business goals.

Measures of success include:• Reduced time-to-market for IT business solutions • IT cost alignment as a percent of revenue• Flexibility to accommodate changing business needs

•Metrics

•Time-to-market reduced ~40%

•IT cost reduction ~30-50%

•Decision making ability not available today

•Metrics

•Time-to-market reduced ~40%

•IT cost reduction ~30-50%

•Decision making ability not available today

Agilent Mission


Current Landscape(s): Point-to-Point Integration

BroadVision

BroadVision

MercuryMercury

Oracle Databas

e

Oracle Databas

eHP3000

HP3000

ERP Applicatio

ns

ERP Applicatio

nsCRM

Systems

CRM Systems

Agilent-Tech

Corporate Systems

Agilent-Tech

Corporate Systems

APS Applicatio

ns

APS Applicatio

ns

OFP Systems

Existing Systems

CORBA Server

CORBA Server

DOC-ITDOC-IT

Product Master

Customers


Initially Identified Solutions

• Batch Process– Oldest way known

• Point-to-Point Interfaces in Middleware– Do more faster

• Internal EDI


Issues and ConcernsWith These Solutions

• Batch Process:– Continued with P2P legacy ‘boat anchor’– Not real time

• P2P in Middleware:– Stuffing middleware infrastructure with

redundant messages– For all applications, a unique interface to

every other application

• EDI:– Old technology to support legacy batch

store-and-forward architecture


A Better Way

• Answer: Standardized internal messaging (an order is an order…)

• Use common messages which are understood by disparate applications– Legacy– New Enterprise Applications– B2B


Revelation:

Canonical!!Canonical!!Canonical!!Canonical!!

Shared common view of business information


So what was next?

• We were not experts in messaging standards, so…• Brought in outside team of experts:

– Looked at the market to see what was available– Standards: RosettaNet, OAGI, ebXML, EDI– Architectural implications

– Analyze standards in depth against ability to support desired canonical model

– Determined the optimal solution for the canonical model– Which messaging standard to be used– Determining toolset(s) needed to deploy– Operating model


Selected the Common Vocabulary: OAGIS

• Well-defined set of:– Message definitions – Process definitions

• Works well behind the firewall• Architecturally neutral

– B2B– Legacy– New enterprise architecture


POC Success

• Completed in 2 weeks (develop and deploy)– Prior methodology would have required 2

months

• Proved that existing, out-of-box OAGi business scenarios could be deployed in the Agilent environment


Agilent Enterprise Integration Model

Service & SupportService

& Support

eBusinesseBusinessOrder

GenerationOrder

Generation

Order Fulfillment

Order Fulfillment

Information Management

Legacy Systems

Broadvision

enCommerce

BladeRunner Oracle Apps

HRFinanceReference Systems

Product

Customer

Supplier

Price

Company Information

PeopleSoftSAP/Oracle

Data Warehousing

Reporting

Intranet ContentXpedio/

BladeRunner/

Filenet

FunctionalApplications

Legal, GTT, WPS ...

Merging Companies’ Applications


Packaged, Legacy

OAGi Canonical ModelTIBCO Bus (RVRD)


• ADP• Agilent• Goodyear• AT&T Wireless• Boeing• Cisco• Ford• General Electric Power• Lucent• Weyerhauser• U.S. Air Force• IBM

Sample of Customers using the OAGIS Canonical Model


A Single Horizontal Language

NeutralMarkup

Language(OAGIS)

S1

std1

Sn...

stdn

S2

std2Service Broker

Internal Systems External Systems

S1

std1

Sn...

stdn

S2

std2


Questions?


eBusiness and EDI

• EDI is flat files over private network• EDI has no process control• eBusiness assumes internet

technologies• eBusiness assumes more

sophisticated process and other capabilities


Most Recent B2B Technologies

• ebXML• Web Services


eBusiness Architectures Components

• Processes• Payloads• Frameworks• Repositories• Security• Transport• Business Agreements• Transactions


ebXML

• Started in November 1999• Sponsored by UN/CEFACT and OASIS• Deliverables include specifications

that define an electronic business framework

• “Completed” in May 2001• Ongoing at UN/CEFACT and OASIS


ebXML Specifications

• Requirements• Architecture• Registry and Repository• Transport and Routing• Business Process Collaboration• Collaborative Partner Protocol• Collaborative Partner Agreement• Core Components


ebXML Architecture

Package

Retrieval of Profiles & new or updated ebXML Models

TransportBiz ServiceInterface

Biz ServiceInterface

Internal Bus App

Shrink Wrap App

Repository

Implementers

Business Process and Information Models

Build

Registration

TPA

UML to XML conversion

Build

Retrieval of New or Updated ebXML Models

ebXML Transport

Retrieval of ebXML Specifications & Models


ebXML Usage Example

3 Build System

Profiles

Scenarios

Request ebXML specification

1

4 Register company profile

Query about Company X

5

Request Company X’s Scenario

9

DO BUSINESS!

11

Send Company X’s Scenario

10

ebXML BP Model

ebXML BO Library

Send Company X’s Profile

6

Submit TPA7

TPA Accepted8

Send ebXML specification 2

Specifications

ebXMLSoftware


OAGi fits with ebXML

• Communication Layer (T&R) ebXML Transport

• Partner Agreements (CPP, CPA) Format - ebXML

• Process Definitions (BPSS) Format – ebXML Content - OAGIS

• Syntax OAGIS Tags

• Meaning of Information OAGIS Dictionary


OAGIS and ebXML

OAGIS is the Payload

ebXML is the Envelope


Questions?


Web Services


Web Services Definition

• Web Services provide a means of integrating applications via the Internet.

• . . . Web services allow companies to link applications and do e-business regardless of the computing platforms and programming languages involved.

Source: InfoWorld


Core Standards for Web Services

• XML provides platform independent business language definition

• SOAP provides the platform independent envelope

• WSDL provides the platform independent connection

• UDDI provides platform independent definition

TCP/IPTCP/IP

HTTPHTTP

WSDLWSDLSOAPSOAP

XMLXMLUDDIUDDI

TCP/IPTCP/IP

HTTPHTTP

WSDLWSDLSOAPSOAP

XMLXMLUDDIUDDI


Web Services Benefits

• Web Services make integrating applications easier:

– Other distributed computing such as DCOM, RMI, and CORBA, require compatible architectures from all participants.

– Web services allow businesses to extend existing systems to those of trading partners and customers without having to re-architect existing back-end infrastructure.

– Web are universally accessible through Web-based directories that allow providers of Web services and potential customers to locate one another.

Source: InfoWorld


WS-I Basic Profile 1.0

• XML 1.0 (Second Edition) • XML Schema Part 1: Structures • XML Schema Part 2: Datatypes • SOAP 1.1 • WSDL 1.1 • UDDI 2.0 • RFC2246: The Transport Layer Security Protocol

Version 1.0 • RFC2459: Internet X.509 Public Key Infrastructure

Certificate and CRL Profile • RFC2616: HyperText Transfer Protocol 1.1 • RFC2818: HTTP over TLS • RFC2965: HTTP State Management Mechanism • The Secure Sockets Layer Protocol Version 3.0


What is SOAP?


SOAP EnvelopeArchitecture

POST /StockQuote HTTP/1.1Host: www.stockquoteserver.comContent-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "Some-URI"

<SOAP-ENV:Envelope

<SOAP-ENV:Header>

<SOAP-ENV:Body>

</SOAP-ENV: Envelope>

</SOAP-ENV:Header>

</SOAP-ENV:Body>

Authentication

etc.

Transaction

XML Payload

XML Payload

XML Payload

OAGIS BOD

OAGIS BOD

OAGIS BOD


WSDL


BOD WSDL Example

• ProcessPurchaseOrder• AcknowledgePurchaseOrder• ConfirmBOD


OAGIS PO WSDL


Web Services

• Web Services standardizes– Shape of the plugs– Shape of the outlet

• Technology neutral• Web Services needs a current

(Business Language) to travel over the wire

• OAGIS is a CANONICAL Business Language

WSDL

SOAP

OAGIS XML

Security


Barriers to Web Services

• Security• Conflicting Standards• Immature Technology

(and standards)• RPC only Mechanism

– Async is on the way


eBusiness Architectures

ebXML vs. Web Services


Example of Both

General Motors


Convergence

• Some convergence is appearing• ebXML is SOAP based• Customers are making their wants

known• Standards groups are talking• Will take time


OAGIS is Framework Independent

OAGIS is the payload

ebXML is the envelope

Web Services is the envelope

Your Envelope is the envelope


OAGIS Architecture

Message Architecture

UML, ebXML

Collaborations

Collaboration Architecture

Collaboration Content

Core Components

Elements

Component

Fields & CompoundsD

ata

Ar c

hit

ectu

re

Values

Mes

sag

e A

r ch

itec

ture

Pr o

cess

A

r ch

itec

ture

Collaborate with Industry

Tec

hn

ical

A

r ch

itec

ture

FrameworksSOAP, ebXML,

BizTalk, RNIF, Other

Message Content

Business Object Document

BOD Messages

SOAP, ebXML, BizTalk, RNIF, Other

SOAP, ebXML, BizTalk, RNIF, Other

UML, ebXMLUML, BPSS, BPEL



Industry Collaboration

OAGIS Specification

UML, ebXMLCollaborationDefinitions

UML, ebXMLBusiness Object

Documents

Component

Fields andCompound Fields

UML, ebXMLBOD Architecture


Questions?


Back to OAGIS


OAGIS BOD Architecture


Object Communication


• Loosely coupled• Asynchronous• Heterogeneous • Message based• Common content• Meta data based

Architecture Characteristics


ApplicationPrograms

API In/Out

Bod

Driver

Builder

Mapper

Parser

ProprietaryAPI Functions

ProprietaryAPI Functions

ApplicationPrograms

API In/Out

BOD

Bod

Driv

er

Builder

Mapper

Parser

Interface Architecture


The BOD Architecture


BOD Application Area


OAGIS DSIG

• Support of DSIG in Payload itself


BOD Data Area

Noun

Verb


BOD Architecture


Business View of a BOD


Core Components

(each box is a component)

OAGIS BOD – (Payload is entire

structure)

Business View of BOD

POORDERHDR

POTERM

ADDRESS

CONTACT

PARTNER

CHARGE

DISTRIBUTN

Diagram Note: - Required = Solid boxes - Optional = Dashed boxes

POORDERLIN

POSUBLINE

POLINESCHD

PARTNER

ADDRESS

CONTACT

POTERM

DISTRIBUTN

CHARGE

DISTRIBUTN


Technical View of a BOD


The BOD XML Instance

BOD Name

OAGIS Namespace

DataArea

Verb

NounBOD

DefinitionLocation

ApplicationArea

BODAttributes


The BOD XML Instance


OAGi XML Solution

• The OAGi XML solution was developed to conform to specific design requirements– Formally define the Integration Specification

– Provide a reference suitable for both analysts and developers

– Leverage standards and tools that can ease implementation effort

– Remain platform and architecture neutralNo ties to database, operating system, or integration

approach

– Establish a framework for ongoing enhancements


OAGi XML Solution

• The OAGi XML design is based on key considerations:– Provide as much specification information as possible in the XML– Support extensibility and other implementation needs– Use only formally released standards– Avoid deviation from the standards unless absolutely necessary

• It also is based on a number of assumptions:– Application vendors and customer organizations can (and will)

leverage 3rd party parsing and mapping tools in their solutions– 3rd party solutions will be robust and reliable for production use– Performance of available libraries (Java and C) will be acceptable– Validation will be used sparingly in production

Design Considerations and Assumptions


• The OAGi XML solution is comprised of a broad set of XML Definitions and sample files– Reference XML shared across all transactions

Data DomainsFields and Common Information Structures

– Each Transaction in the Specification

– Sample XML files are provided for testing and general structure

Solution Components

OAGi XML Solution


Navigating BODs


How BODs Work


BOD

BODBOD

BOD

BOD Interchange – What you send

Schema

B2B

A2A

Schema


Application

BOD Interchange – What you do with what’s sent to you

BOD Instance

Parser

Schema-Validating

XML Parser

BOD XML Schema


Questions?


Begin OAGIS Nouns


BOD Data Area

Noun

Verb


OAGIS Nouns

• Nouns are consistent like Common Objects• 78 in OAGIS 9• Can be Documents• Can be Control Data• Can be any content needed in a message• Behavior is affected by Verbs• Verbs are described in next section


Noun Example – Party


Let’s go look at Nouns


ALL OAGIS 9.0 Nouns


OAGIS Core Components

• OAGIS Building Blocks• Nouns Comprised of

Core Components• Used to “Assemble” the BODs


POORDERHDR

POTERM

ADDRESS

CONTACT

PARTNER

CHARGE

DISTRIBUTN

Diagram Note: - Required = Solid boxes - Optional = Dashed boxes

POORDERLIN

POSUBLINE

POLINESCHD

PARTNER

ADDRESS

CONTACT

POTERM

DISTRIBUTN

CHARGE

DISTRIBUTN

PO BOD Assembled

using Components


Component Example


Component Example


Components

• Lets go look at some more


Compounds

• OAGIS uses Schema types• Schema Types don’t do it all• Certain Business Fields require more• OAGIS invented Compound Fields• Contain primary Field and Context Fields• Examples would be

– Amount– Operational Amount– Quantity– Time Period– Temperature


Compound Example

Compound

Attribute

Details


Compound Example

Compound

Attribute

Details


OAGIS Fields

• Fields– Contain Simple Content – “Atomic Level” Data– Base building block for OAGIS BODs– All contained in <fields.xsd> file with OAGIS– Examples:

• Job Code• Priority• ID (Generic)• EmployeeId (specific)


Field Examples

<xs:simpleType name="JobCode"><xs:restriction base="Code"/>

</xs:simpleType>

<xs:simpleType name="Priority"><xs:restriction base="xs:string"/>

</xs:simpleType>

<xs:complexType name="EmployeeId"><xs:annotation>

<xs:documentation source="http://www.openapplications.org/oagis"> An Employee specific Identifier</xs:documentation></xs:annotation><xs:simpleContent>

<xs:extension base="xs:string"/></xs:simpleContent>

</xs:complexType>


OAGIS Architecture

Resources

Which Content

Includes


BOD Assembly Example

F ie ld F ie ld

C o m p ou nd

F ie ld F ie ld

C o m p ou nd F ie ld

C o m p o ne nt

F ie ld F ie ld F ie ld


N o un

F ie ld C o m p ou nd F ie ld

C o m p o ne nt F ie ld

C o m p o ne nt F ie ld C o m p ou nd

N o un


Begin OAGIS Verbs


Why Does OAGIS® Use Verbs?

• Nouns are Consistent as Common Objects• Nouns may need to be different at execution• The Verbs drive these constraints• Example

– SyncPurchaseOrder– CancelPurchaseOrder

• OAGIS constrains the Nouns with XPath portion of XSL (Not XSLT portion)


Get and Show Verbs

Plant Data CollectionTime and Attendance Data Gathering Process

Plant Data CollectionShop Floor Control, etc.

ERP HumanResources

Get Personnel

Show Personnel

Update PersonTime


Technical Implementation of the Verbs

• Nouns may need to be different at execution • Verbs constrain the Nouns• Enables Nouns to be consistent as Common Objects

(Canonical)• Constraints my be based on:

– Location– Business Process– Company– Etc.

• OAGIS constrains the Nouns with XPath portion of XSL – (Not XSLT portion)


A Constraint Rule

Rule Context

Test Message


Using Constraints to Add Context

Application

BOD Instance

Validating P

arser

BOD XML Schema

XS

L Processor

BOD Constraints


Simplified OAGIS® Transactions - Verb Use

VERB Request Verb Response

Process Acknowledge

Post Acknowledge

Sync ConfirmBOD

Load ConfirmBOD

Cancel ConfirmBOD

Change Respond

Get Show

Update Respond


Questions?


Extensibility

• What is it?• Why is it bad?• Why is it good?• Can it be made practical?


Types of Extensions

• UserArea Extensions – UserArea extensions provide an optional element with in each OAGIS defined component that may be used by an implementer to carry any necessary additional information.

• Overlay Extensions – Overlay extensions provide the ability to have extensions show up in-line with OAGIS defined fields, compounds, and components. This is not possible with DTDs.


Simple OAGIS Extensibility - UserArea


Simple OAGIS Extensibility: UserArea

• Each OAGIS Component can have a UserArea• Appropriate when

– OAGIS covers most of your needs – You don’t mind UserArea segregation

• UserArea can contain– Any OAGIS content– Any User-Defined content, just so long as

• It’s defined in a separate namespace• It’s validatable via a defined Schema


Limitations to UserArea Extensibility

• UserArea content is segregated– Content relegated to lower level

• Anything defined as an element can go into any UserArea– You will likely want to define a more controlled

vocabulary, by defining specifically what goes where


Recommended extensibility approach when using OAGIS;

Overlay Extensibility



• When you have too many extensions to be handled in UserAreas

• When you want your content to appear at “the same level” as OAGIS content

• When you want control of which extended content goes in which part of the BOD

• You need Overlay Extensibility



• Overlay Extensibility enables additions to OAGIS® BODs in a way that:– The overlay content appears in-line with OAGIS

content– The Non-OAGIS® content is distinguishable from

the OAGIS® content– Both are validate-able– The extended schema is managed separately

from OAGIS® Schema


Overlay Example

OAGIS®

Overlay

Your BOD


Things to Note About BODs

• Not all Verbs apply to all Nouns• BODs are designed according to

documented interchange scenarios• BODs are used in multiple scenarios


Questions?


But OAGIS® 9.0 is more than processes and messages


OAGIS® 9.0 is the basis for current and future for business language development


OAGIS® 9.0 is . . .

• Application Architecture– Common Object Model (Nouns)– Common Component (Class) Libraries

• UN/CEFACT and OAGIS® Components– Artifact Subsets for SOA Service Definitions

• Meta Model– Naming and Design Rules, UN/CEFACT Based– Document Typing– Document inheritance

• Transaction and Context Model– Nouns– Verbs

• Technical Architecture (BOD)– Common Look and Behavior– Extensions Architecture– Extrusions Architecture


BODs as Objects

• BODs are comprised of Nouns and Verbs

• Nouns are content• Verbs add “context”

Noun

Verb


OAGIS Meta ModelBOD Document Types

• Operational Document– Purchase Order– Production Order

• Financial Document– Journal– Invoice– Payable

• Table Document– Unit of Measure– Party


OAGIS Meta Model

• Document Date Time• Document Status (test/production)• Description and Notes capability• Attachments• Globally Unique Identifier• Digital Signatures• Core Components• Compound Fields


OAGIS 9 Naming and Design Rules

• Over 100 rules for building the vocabulary

• Naming conventions• Use of tag names• Typing• XML Design Constructs






The BOD Architecture


OAGIS® BOD Architecture Benefits

• Common look, feel, and behavior of messages

• Common dictionary across all messages

• Enables common components implementation

• Enables a high level of re-use• Enables the extensibility mechanisms• Provides a faster learning curve for

the user


Core Components Introduction

• Sponsored by the United Nations• Encourages all business languages to be

based on same concepts.• Defines grammar rules• Defines key naming conventions• Defines key common components

– Address, etc.


Scope for OAGIS® 9.0 - Core Components, The Idea

• Each standard builds their standard using same rules

• Each standard adds their “context”• Each language now has a better chance

of faster interoperability because their language basis is the same.


Core Components Are

• Core Components– ISO 11179 – Naming Conventions– Core Component Types 2.01 (CCTS)

• ISO 15000-5– Unqualified Data Types

• Currency, • MIME Encoding, • UnitCode,

– Qualified Data Type• Language

– Aggregate Core Component (ACC),– Aggregate Business Information Entity (ABIE)– ATG2 Naming and Design Rules


Core Component Harmonization

• UN/CEFACT encourages contributions from many groups.

• Analyze the contributions.• Harmonize the contributions.• Enable others to use the harmonized

components.• Everyone wins.


The Process of CC Harmonization

• Take candidate Core Components or Business Information Entities submitted by different domains

• Identify differences and similarities between the submissions and existing library entries,

• Produce a single, complete cross domain set, i.e. the Core Component Library

• Encourage Standards Development Organizations to use this library to build their standards.


OAGIS 9 Implementation of Core Components


BOD from Class Libraries

F ie ld F ie ld

C o m p ou nd

F ie ld F ie ld


C o m p o ne nt

F ie ld F ie ld F ie ld


N o un

F ie ld C o m p ou nd F ie ld

C o m p o ne nt F ie ld

C o m p o ne nt F ie ld C o m p ou nd

N o un


OAGIS® Component Libraries

• UN/CEFACT

• IST/ISO

• OAGIS®


Standards within theOAGIS® Standard

W3C - URI/URLW3C - XML Schema 1.0 Part 1W3C - XSL Schema 1.0 Part 2.0W3C - XML Style LanguageW3C - XML Path Language (XPath) Version 1.0ISO - ISO11179 ISO - ISO1500-5 Core Components Type SpecificationISO - ISO20022 (UNIFI Financial Standard)ISO - ISO4217 - Currency CodesISO - ISO639 - Language CodesUN/CEFACT ATG2 Naming and Design Rules - NDR UN/CEFACT Harmonized Core Components – TBG17MIME Media Type Code UNECE Unit CodeOMG UML 2.0


OAGIS® BOD Stack

Lite BOD

Lite BOD

Industry A Overlay

Industry B/Company A Overlay

UN/CEFACT/ISO Core Components

OAGIS® Types &Core Components

OAGIS® Business Object Documents

XML Schema (XSD)

UML Models

IST/ISO20022 Core Components

Meta

Model

Nam

ing a

nd

Desig

n R

ule

s

BO

D A

rchite

cture


Resources

• http://www.unece.org/cefact/ebxml/CCTS_V2-01_Final.pdf

• http://www.untmg.org/index.php?option=com_content&task=view&id=19&Itemid=62

• https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/a6c5dce6-0701-0010-45b9-f6ca8c0c6474


Value of Interoperability

Value ofDifferentiation

Value ofInteroperability

low

high

low

high

[Shaffner 1994]

Common Content ?


OAGIS® 9.0 is . . .

• Technical Architecture (BOD)– Common Look and Behavior– Extensions Architecture– Extrusions Architecture

• Application Architecture– Common Object Model (Nouns)– Common Component (Class) Libraries

• UN/CEFACT and OAGIS® Components– Artifact Subsets for SOA Service Definitions

• Meta Model– Naming and Design Rules, UN/CEFACT Based– Document Typing– Document inheritance

• Transaction and Context Model– Nouns– Verbs


“The OAGIS approach is arguably the most advanced in the industry, …”

Scott Hinkleman, IBM

Full text is here: http://www-106.ibm.com/developerworks/xml/library/x-biics/


Questions?


How to use OAGIS

• Installing OAGIS• Looking at OAGIS• Finding and using a Scenario• Finding and using a BOD


How to Begin:Get OAGIS

• Get OAGIS (if you do not already have it) from the www.openapplications.org site.1. Click “Free Downloads” 2. Click on OAGIS link3. Fill in the Registration Form; click the Submit button at

the bottom of the form.4. For OAGIS 8.x, simply click on the OAGIS 8.x link. (This

will retrieve a single zip file that contains all of OAGIS.)5. Once downloaded unzip the file maintaining the directory

structure contained in the zip file. (This is important because the OAGIS files are relatively linked.)


How to Begin:Get OAGIS


Find and Download OAGIS


Find and Download OAGIS


OAGIS Release 9.0

• Unzipped File in /OAGIS/9.0

• Documentation• OAGIS Release

– Scenarios– BODs– Instances

• Tools


Getting OAGIS 9 – What you get

• A large (12MB) zip file containing1. The OAGIS 9 XML Schema Definition (.xsd) Files

1. Developer version of all of the BODs2. Standalone version of all of the BODs3. Resource library containing all of the

Components, Fields, etc.2. Examples of OAGIS BODs


OAGIS BODs


Using BODs in a Project

• My project team is interested in using OAGIS…– How do we get started?– Where do we look first?– What BODs do I use to integrate?– How do I know what BODs to use to

integrate?– How do I know what I am integrating?– Etc?


How to Begin Implementing OAGIS - Steps for Integration

• As with any integration before you can start, you must know what you are integrating.– Identify the business applications and

components of each that are to be integrated. • What’s to be integrated with what?


Using OAGIS

• Step One– Identify the business applications and

components of each that are to be integrated.– This is really drawing the boxes and arrows


Using OAGIS

Order Management Credit Management Accounts Receivable

GetCredit

ShowCredit

UpdateCredit

ChangeCreditStatus

Cash Management in Accounts Receivable


Using OAGIS

• Step Two– Search OAGIS Scenarios for closest “fit”

• Use existing Scenario• Modify existing Scenario• Build new Scenario


Using the Scenarios


Using the Scenarios

• Once a scenario has been identified use it to direct you to the BODs needed.– Keep in mind the type of integration

environment you are using.• Publish/Subscribe – Systems subscribe to

receive info and it is published to them when it is available.

• Request/Reply – Systems request and receive information on an as needed basis.

• Both


• Define integration scenario reflecting business process requirements

• Identify components• Identify and normalize business processes• Build integration scenarios • Focus on application interfaces• Identify and normalize the data• Further develop the events and sequences within

the business process– Data Synchronization– Transaction processing– Inquiry and reporting– Security– Authentication….

Recipe for Integration


• Think through the business need• Think though all aspects of the overall scenario• Think about there may be several scenarios around

your problem domain to fulfill all the needs• Example of this is:

– Order Management; Available to Promise– Order Management; Make to Order

• Think about request – Replay and Asynchronous Processing

• Design for Asynchronous, then you can get Request – Reply

• If you design for only Request-Reply, you may not enable Asynchronous

Use of the Recipe for Integration


Using OAGIS

• Step Three– Identify the messages that need to flow

between the applications, along with the intent of the messages.

• Search OAGIS BODs for closest “fit”• Use existing BOD• Modify existing BOD• Build new BOD


Using the BODs


Steps 4 through 6

• Determine how to get access to the data. This requires knowledge of the given business application.

• If necessary map the information from the applications format to OAGIS and/or from OAGIS to the receiving applications format.

• Implement– Create the integration code to perform the mappings that

utilizes the applications mechanisms to access the data– Represent the Business Scenario in the orchestration tool


Don’t reinvent the wheel!!

• Think Re-Use• The Canonical is more

important that differentiation


Finding the BOD you need

• Search by Noun• Look at detail• Match to the data requirements

you have• Do a gap analysis• Let’s go look


Using the BODs

• Review the BOD message to identify the fields, compounds, components that you will need to use.– Which are required within your environment?– Which are required for the given application?– Map to/from the BODs– Capture this information in something (Spreadsheet, XML

Document, XSLT, etc.)

• Remember OAGIS is defined to be horizontal (across industries) in nature…– As a result the term(s) OAGIS uses may not be exactly the

term(s) you are accustomed to• Look at the definitions in order to compare apples to apples


Making the BOD work for you

• Use the BOD as is if you can• Extend the BOD if you must• Build your own Noun as a last resort


Deploying OAGIS

• When modifying or building new BODs– Use existing OAGIS content first– Add new content in your Namespace using Overlays– Build new messages as a last resort in you own Namespace

and Overlay• Try to submit new content back to OAGi for future release

of OAGIS• Use the following guidelines when identifying the need

for messages to insure all requirements for the Scenario are met:– Data synchronization– Validation– Transaction processing flows– Inquiry– Reporting– Security and authentication


Tools for Editing, Validating BODs

• IDEs (Integrated Development Environments)– For authoring new/extended BOD definitions– For experimenting with BOD instances– Examples

• GEFEG• XML Spy > v 4.3• Tibco Turbo XML > v 2.3.0.101• eXcelon Stylus• xmlArchitect

• Validating Parsers– For validating, using incoming BODs

– Examples• Xerces 2.0.1 • MSXML 4.0 SP1• Oracle


OAGi Free Resources

• OAGIS Specification download– Royalty Free

• ebXML Implementation Guide• Canonical Model White Paper

• Java and OAGI– Software Engineering Institute

• OAGIS 8 Design Guide– Free to Members

• End-User Case Studies• OAGIS Extensions Guide

– Free to Members



Questions?


Canonical Model Stewardship


• Stewardship principles• Stewardship functions• Usage tracking and revisions of each use• New release and migration planning• Education• Best practices• Community portal for sharing• Registry• Repository• Source code management• Tools for Repository• Tools for building

Stewardship Topics


Stewardship Topics

• Responsibilities and ownership• Development responsibilities

(mapping, new BODs, mods, etc.)• Tracking and management of Data Maps• Data Mapping Methodology• Data Design methodology• Ownership of each object• Revisioning of Objects• Tools acquisition and management• Project • Semantic Rules• Tracking and management of Rules• Extensions management, use, yes/no


OAGIS® Community and Adoption


Industry Collaborations

• UN/CEFACT – United Nations• ISO- International Standards Organization• MoU MG – Memorandum of Understanding Management Group• KIEC – Korean e-Commerce Consortium• NIST – National Institute of Standards & Technology• AIA – Aerospace North America• AECMA – Aerospace Europe• STAR – Auto Retail North America• AIAG – Auto Supply Chain North America• AAIA – Auto Aftermarket North America• Odette – Auto in Europe• RV Industry – North America• HR-XML – HR Content, world-wide• SP95 – Enterprise Controls• ARTS (Retail)• STEP – Engineering world-wide• IFX – Interactive Financial Exchange• EIDX – Electronics and Computer Industry• IEC TC57 WG14• Footwear Industry


UN/CEFACT Collaboration

• Focused on Core Components• Garret Minakawa (OAGi member) is

the lead for OAGi– TBG 17

• Contributions to CC• Adoption of Core Components Types

in OAGIS 9.0


ISO Coordination

• Class A Liaison to ISO TC154– eCommerce

• Liaison with ISO TC184– Engineering


OAGIS joins MoU Group

• The Open Applications Group was elected in PARIS Dec 4, 2002 to become part of a very elite group in the standards world.

• OAGi has joined the four international de jure standards organizations in a memorandum of understanding (MoU) on electronic business.

• The Open Applications Group will participate in implementation of the MoU as a registered international user group.


Payment Harmonization

• OAGi joined Payment Harmonization Group• Signed MOU• Members include SWIFT, IFX, TWIST, and OAGi• Developing a core “Payment Kernel”• All will use and extend for their constituency• Using UN/CEFACT CC as part of goal• Major announcement Nov. 7 with Gartner Webinar


OAGIS® Endorsement by UN/CEFACT


OAGIS® Endorsing Industry Groups

Aftermarket Industry Association of Canada

Automotive Aftermarket Industry

Association

Heavy Duty Distribution Association

American Body Parts Association

Motor and Equipment Manufacturers Association

Automotive Engine Rebuilders Association

Production Engine Remanufacturers

Association

Automotive Warehouse Distributors Association

Specialty Equipment Market Association

Automotive Parts Rebuilders Association


OAGIS Adoption

• Hundreds/Thousands of live and implementing sites around the globe

• Use includes– B2B, 80%– A2A, 64%– C2B, 15%

• Large and accelerating base• Grass roots


Knowledge of Adoption

• We believe we only know about 10 per cent of the actual users


OAGIS live users in over 40 industries

• Aerospace• Agri-Business• Automotive Manufacturing• Automotive Retail• Automotive Aftermarket• Banking• Brewing• CPG • Chemical• Computer Hardware• Computer Software• Consumer Goods – Electronics• Defense• Distributors• Federal Government• Food Manufacturing• Furniture Manufacturing• Medical Device Manufacturing• Mortgage• Pharmaceutical• Insurance

• Industrial Goods Manufacturing• Logistics• Medical Device Manufacturing• Mining• Oil • Natural Gas• Paint• Paper• Publishing• Retail• Shipping• Software• State Government• Local Government• Telecommunications• Tire Manufacturing• Tobacco• Trucking• Universities• Electric Utilities


OAGIS® is used by Oracle Applications

• OAGIS® is the base application API for Oracle applications

• Oracle is a major supporter of OAGIS®• You may be using OAGIS® in your

Oracle Apps and not know it.


Some Vendor Adoption

• SAP (partial)• IBM• ExpiditeBiz• Microsoft• iBASEt• iConnect• Covisint (Compuware)• HK Systems• Catalyst• Brooks Software• Compiere

• QAD• iWay• webMethods• Websphere• Camstar• Kaba Benzing• Wonderware• Baan• SSA• WiPro• EDS


OAGIS® Logistics Web Services Example


Compiere Open Source ERP

http://www.compiere.com.ar/technology/integration/import.html



OAGIS live users in 41 known countries

• Australia• Austria• Bahrain• Belgium• Brazil• Canada• Chile• China• Croatia• Czech Republic• Denmark• Ireland• Finland• France• Germany

• Holland• Hungary• India• Israel• Italy• Japan• Korea (South)• Lithuania• Mexico• Netherlands (Holland)• Norway• Papua New Guinea• Poland

• Russia• Saudi Arabia• Singapore• Slovenia• Slovakia• South Africa• Spain• Sweden• Switzerland• Turkey• United Arab Emirates• United Kingdom• United States


Example Implementations

• TeliaSonera• British Telecom• Lucent• IBM• Microsoft • CISCO• Intuit• Qualcomm• Ford• USAF• Daimler Chrysler• GM• Toyota• Honda• Arvin Meritor • GoodYear• Disney• Best Buy• Ameriquest

• British & American Tobacco• Henkel Iberia• Boeing• Northrop Grumman• Goodrich Aerospace• ADP• MasterCard• Aero Star• Colinx• Enporion• Quadrem• General Electric• Bank of America• USAF• Rockwell• Chicago Tribune• General Electric• Sara Lee• Sasol



End User Examples




Agilent Enterprise Integration Model

Service & SupportService

& Support

eBusinesseBusinessOrder

GenerationOrder

Generation

Order Fulfillment

Order Fulfillment

Information Management

Legacy Systems

Broadvision

enCommerce

BladeRunner Oracle Apps

HRFinanceReference Systems

Product

Customer

Supplier

Price

Company Information

PeopleSoftSAP/Oracle

Data Warehousing

Reporting

Intranet ContentXpedio/

BladeRunner/

Filenet

FunctionalApplications

Legal, GTT, WPS ...



Packaged, Legacy

OAGi Canonical ModelTIBCO Bus (RVRD)


Lucent and OAGIS®

OAGIS®


Ford and OAGIS®


From: [email protected]: Wednesday, June 04, 2003 11:41 PMTo: Dave ChamblessCc: David Connelly; [email protected];[email protected]: RE: Campbell Soup and the Open Applications Group

Hello Dave,

Thanks for the invitation to join OAG. At Campbells Asia Pacific (I ambased in Sydney, Australia) we have already adopted OAGIS as our messagecontent schema (canonical form) in our EAI projects. We are a Tibco shop,and leverage the toolset for both B2B and A2A integrations. We reviewedebXML for the initial B2B integration with a 3PL that was our first EAIproject, but since the particular trading partner in question did not havea messaging framework in place enabling the infrastructure levelinteroperability, we leveraged the default Tibco framework (tibXML) as themost appropriate alternative because it is simpler to implement and todeploy and was sufficient for the 3PL integration.

The principle we've adopted is that all messages hitting the Tibco message"bus" will be mapped into a standard "canonical" XML content schema - OAGIS- to ensure future reuse of any data published on the bus.

We found OAGIS supported most of the B2B transactions we needed for 3PL . . .

Campbells and OAGIS®


SKF and OAGIS®

From: [email protected]: Thursday, July 29, 2004 7:20 AMTo: [email protected]: An XML question

Dear Sir, Good afternoon!

I am trying to learn as much as I can about XML. The company I work for have chosen OAGIS 8 as the XML standard.

I am not an IT programmer - I am a 'user'

Please could you just help me to understand the basic differences difference between XML and EDIFACT ?

Thank you very much in advance Kind regards, Chris ------------------------------------------------Chris McCullochSKF Logistics ServicesAB SKF Gothenburg//Sweden(Tel: +46 99 9999999)(Email: [email protected])------------------------------------------------


Dubai eGovt.


UK Ministry of Defense


New Zealand


OAGIS® around the world


Thanks and Questions?


Portions of the previous material Copyright © 1995 - 2006

Open Applications Group, Inc. All rights reserved