Open Applications Group

Open Applications Group
OAGi 101 OAGIS Introductory Seminar

Introductions Go around the room and have everyone give their name, their job, and if they are looking for anything specific out of the training.

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 course will give the attendee a broad background and some of the topics may be know to some of the attendees. Ask the audience the the class is moving too slowly or too quickly throughout the day. Take breaks at logical stopping points. Either at the right time of day or if you see the audience drifting away.

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 Here we want to make the point that this is not a heavy duty engineer oriented class. This class may stretch some of the attendees knowledge limits, but they will at least be familiar with the topic if they encounter it again.

Target Audience Managers EDI Analysts Business Analysts
Systems Analysts Integration Architects Software Architects Data Analysts No notes necessary

OAGi 101 Open Applications Group Introduction

Who we are 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. Next I would like to say a couple of words about the OAGI in order to better explain the plans of the Group to adopt the various specifications within ebXML. The Open Applications group focuses on an enterprise’s entire need for interoperability. They call this End to End integration. This includes B2B, A2A (Internal integration), and A2E (Applications to Execution systems such as Manufacturing Execution or Plant Data Collection systems). The efforts of the OAGI are focused on a horizontal based solution with a strategy to work with the vertical industry groups.

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 Out Reach 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
Most efforts today are focused solely on B2B integration. We think this is not enough. Organizations instead need to be looking at End to End integration which connects the B2B efforts with the Application to Application and Application to Execution software efforts. Without connecting across this continuum, firms will be be missing key capabilities to execute their B2B as well well as getting stuck implementing multiple standards or doing their internal integration the old fashioned point to point way, costing them too much money, too much time, and limiting their ability to be responsive to business needs. E2E = B2B + A2A + A2ETM Everywhere 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 and for 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 Enterprise Membership Open to All $25,000 US IT Solution Providers Revenues of $100 million or more $25,000 US Revenues of $10 to 100 million $12,500 US Revenues of $1 to 10 million $ 5,000 US Revenues of $0 to 1 million $ 2,500 US End-Users Revenues of $100 million or more $ 5,000 US Revenues of $10 to 100 million $ 3,500 US Revenues of $1 to 10 million $ 2,000 US Government Federal & State $ 5,000 US Local $ 2,500 US University Flat Rate $ 1,000 US Individual Flat Rate $ US

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

Some OAGIS Contributors
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:

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 Inventory Control Business Object Document General Ledger
App1 App2 App3 Inventory Control Business Object Document App4 App5 App6 App7 General Ledger

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 TBG17 BIE/ABIE 10 Years in the Field

What The Group is NOT doing
Not building software Not building a protocol Not building middleware Not choosing technology Not defining objects

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 Emerging 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

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

Why XML? “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.” At best, XML makes it possible for businesses or developer groups to share data, provided they agree on the semantics of that data in advance. This is not to say XML is not an enormous advance. It plainly is. However, its advance lies in aiding data interoperability where shared semantics can be assumed. It does nothing at all to create semantic interoperability.

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 Some background to XML. It came from SGML (Standards Generalized Markup Language), which is a documentation language. XML was developed for the web to simplify the SGML language to improve web capabilities by separating the content of the web pages from the formatting of the web pages as HTML requires it. Then the web folks obviously picked up on this but also the data folks, like us, found it early on as it addressed a need that has been around for a very long time.

XML Segmentation Standards Groups
Defining XML W3C ebXML, OASIS WS-I RN OAGi HR-XML IFX ebXML HL7 etc. Frameworks and infrastructure Defining Content (vocabulary and process) Defining Internet Service layer

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 Validated against .XSD definition File names are .XML

XML Definition and Instance
XML Instance Schema Definition

XML Payload Example

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 So Why are we looking at XML? What does it do for us.

How does this relate to EDI?

EDI and OAGIS and Co-Exist!
EDI Views 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 and OAGIS and Co-Exist!

OAGIS and EDI Example Customer End User Pricing XML Message Processing
Broker Pricing XML Message Processing Web Front End ProcessPO ProcessPO Java calls AcknowledgePO AcknowledgePO Order EDI 850 PO EDI 850 ACK EDI 850 PO Custom XML Purchasing System Order Entry Processing Order Management System Real EDI 850 ACK Legacy Recent

EDI Views Long Start Up Fast 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 to XML Reference More examples at

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

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 Document or 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 XML Prototyping Started
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

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

OAGIS® Scenario

Production Synchronization
OAGIS® Scenario Production 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 Open Development Methodology calls for 6 pieces of data when describing the Scenario. These are laid out below. You can show an example in the OAGIS documentation if you start at a scenario # 49 or above.

OAGIS Scenarios Page one of three
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) Just walk the audience through this page one of three. You might want to note the broad range of scenarios, financials, manufacturing, Plant Data Collection, etc.

OAGIS Scenarios Page two of three
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 Just walk the audience through this page two of three.

OAGIS Scenarios Page three of three
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) Just walk the audience through this page three of three.

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 Credit Management Sarbanes/Oxley & Control Value Chain Collaboration Applications Enterprise Management Applications Enterprise Execution Applications

Questions?

Integration Approaches
Batch Asynch Synchronous EDI Import/Export Process/Workflow Desktop launching Cross product reporting Low Latency and High Latency point also

Payloads and Envelopes
Our metaphor for ebXML and OAGIS working together. Envelopes

Previous Best Practices
Tightly coupled Synchronous RPC based CORBA COM, DCOM Unique content

Integration Topologies
Request Reply Point to Point Spaghetti Hub and Spoke Publish and Subscribe Bus Topology Exchanges

Point to Point or . . . Connector Order Mgmt MRP Connector
Integration Server or . . . Point-to-point integration is where data is interchanged directly between the two systems. The sending system needs to convert its internal data format to a format acceptable for the receiving system. Examples would be direct TCP/IP sockets interfaces between systems, flat file export/import, direct read/write to target database schema. Advantages: • Typically better performance and tighter integration because of the tighter coupling between the two systems. • Two-way communications between applications are easier without a middleman. • In smaller cases, or where applications are static, can be simpler than an EAI solution. Disadvantages: • Complexity. The number of integration points increases as number of systems increases and can quickly become unmanageable. • Tighter coupling (transport, document formats) makes it harder to change either of the two systems involved in an interchange without impacting other systems. • Static integration design does not allow for rapid changes (swapping in of new applications) often required to be competitive in this day and age.

Known as Spaghetti Diagram
Point to Point Order Management ERP CRM Finance eCommerce Data Warehouse Content Mgmt. Logistics Point-to-point integration is where data is interchanged directly between the two systems. The sending system needs to convert its internal data format to a format acceptable for the receiving system. Examples would be direct TCP/IP sockets interfaces between systems, flat file export/import, direct read/write to target database schema. Advantages: • Typically better performance and tighter integration because of the tighter coupling between the two systems. • Two-way communications between applications are easier without a middleman. • In smaller cases, or where applications are static, can be simpler than an EAI solution. Disadvantages: • Complexity. The number of integration points increases as number of systems increases and can quickly become unmanageable. • Tighter coupling (transport, document formats) makes it harder to change either of the two systems involved in an interchange without impacting other systems. • Static integration design does not allow for rapid changes (swapping in of new applications) often required to be competitive in this day and age. Known as Spaghetti Diagram

Hub and Spoke Connector CRM Integration Server Connector Connector
Order Mgmt Connector MRP Products that follow the hub-and-spoke approach include those from CrossWorlds, Vitria, webMethods, and WRQ. In this approach, all integrated applications connect through a central server. Thus, a new system or application only needs to be connected with the hub to be automatically integrated with other applications that also are connected with the hub. The integration server acts as a message broker to control communication, data translation, and process interaction among the connected systems. Besides minimizing point-to-point integration, hub-and-spoke integration servers can be centrally managed, which simplifies administration. On the downside, the centralized approach can create performance bottlenecks and a single point of failure. Under this model, scalability must be achieved by adding multiple message brokers and servers, which introduces additional architectural and administrative complexity. Hub-and-spoke integration is where integration between systems (spokes) occurs with an intermediary, the hub, involved in routing messages to other spoke systems. A spoke system will send a message with a defined destination to the hub. The hub will perform any required transformations of the message contents and send it to the destination spoke system. Advantages: • Decoupling of sender and receiver. Documents can be transformed by the hub. • Less complexity of integration. Applications on either side of the hub can be modified independently of each other and the hub performs any mapping of documents between different application formats. Disadvantages: • Two-way communications is harder. The hub has to correlate messages flowing between both parties. • Applications on both sides of the hub have to work well in a decoupled fashion. • Some knowledge of the target is required by the source of a message making it somewhat harder to add or remove senders and receivers. Connector Data Warehouse

Publish and Subscribe CRM Integration Server Order Mgmt MRP Connector
Data Warehouse Order Mgmt CRM MRP Integration Server Publish-Subscribe EAI Publish-subscribe is a system whereby messages generated by publishers are sent to a central messaging hub or broker that in turn sends these messages to subscribers that have previously subscribed to receive some or all of these messages. This method is similar to hub-and-spoke, and the main conceptual difference is that spokes in a hub-and-spoke system typically know the destination of the message, whereas in publish-subscribe, the publishers do not have any knowledge of the subscribers.

Bus Topology (SOA) Message Bus Connector Order Management
Data Warehouse CRM MRP Configurator Integration Server In a message-bus topology, all nodes are linked in a series along a common communication backbone. Messages that are sent between interconnected applications travel along the bus to the integration server, which handles the data transformation, translation, and subsequent routing to the receiving node. Products that use the bus architecture include those from SeeBeyond and Tibco. The bus provides the medium for messages to reach their destinations. The physical implementation of this approach involves placing adapters within each integrated system or application, which then uses the bus backbone for interacting with the integration server and the other interconnected systems. Compared with the hub-and-spoke model, the bus model scales better and potentially offers better performance. However, implementation of the bus model is more complex and more difficult to administer as the environment grows. The decision as to which architecture to use should be based on your application mix, usage, and available resources. For example, hub-and-spoke architectures are better for companies with limited IT resources and environments that involve a handful of systems and moderate transaction volumes. Bus architectures are more difficult to manage for resource-strapped IT groups, but they're better-suited for large-scale environments involving dozens or hundreds of systems with heavy transaction volumes.

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.

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.

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 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. OSF issues a request for distributed computing technologies amongst its member companies. After lots of tests, analyses and reviews a core set of technologies for a distributed computing environment (DCE) is finally selected. 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
This is the WRONG Picture for SOA Web Services Provider Web Services Provider Request Internet Response J2EE™ AppServer SOAP Messages .NET

What is a Service? This is A Service OAGIS 8.0 Scenario 41

Typical SOA Depictment
Web Services Provider Web Services Provider Request Internet Response J2EE™ AppServer SOAP Messages .NET

OAGIS® and SOA WSDL SOAP OAGIS XML
SOAP standardizes the shape of the plugs WSDL standardizes the shape of the outlet (WSDL) OAGIS® provides the current that powers the service SOAP OAGIS XML This slide will be shown again with more details. This is a metaphor for web services standards and their roles.

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
This is just the intro slide to this section

Source: Information Week,
Need for Integration 82% of IT Professionals say that integrating existing systems is their way to improve business processes Source: Information Week, We want to start with the real data showing that integration is a need at all levels of the organization. Other slides will show that integration is making it to Board rooms as a need to have, not a nice to have. This is due to cost pressures and competitive issues.

Demand for Integration
This survey shows that application integration as an overall issue, not just for B2B is a high priority. What we have found is that many organizations determined that they filed in their B2B efforts because their internal applications were not connected to their external applications. Thus both B2B and A2A are necessary for an effective program. Customers’ top strategic software platform project over the next year

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 This is a good news / bad news message The good news is that as organizations, most everyone is in the same boat. The bad news is that most everyone has a big problem with applications. Legacy is a big issue to everyone. So we are all in the same boat.

The Business Environment
Integration Back Bone Business Unit n Supplier Customer Business Unit 1 Business Unit 2 Enterprise This is a VERY important slide. It depicts the business environment where an organization may decide to address the integration problem by selecting a single vendor for all business applications. This is no longer enough. This is because no single organization can control their customers and suppliers technical environments . And what about when the organization does acquisitions or divestitures. Therefore the organization needs to plan for “plugging in” suppliers, customers, and internal divisions quickly, as cheaply as possible, and with as little disruption as possible. This environment makes a compelling case for everything the rest of this class covers. This is “WHY OAGIS”.

The B2B (and A2A) World Current State of Integration XML World
eBusiness Architectures ebXML Overview Web Services Overview This slide is an AGENDA slide for the upcoming topics.

Current State of Integration
Mostly at the data level Mostly point to point Custom program interfaces or flat file exchange Grows at exponential rate Our (OAGI) experience in seeing hundreds or more organizations tell us that most integration is done at the data level today. (not process). Also people are doing point to point connections, uniquely to each business partner, even in the EDI world. Because this work is all custom, the model grows according to the N-squared Model. This leaves us all in the same place of trying to break out from this dilemma. We are spending so much on maintaining what we have, we have no money to fix the problem. Just maintain status quo. We will address this issue of how to move forward shortly.

Application Integration
How can we break out of this?

Canonical Model CANON CANONICAL
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 Just read these definitions to set the stage.

A Case for a Canonical Model
From <many to many> to <many to one> Many companies have a “spaghetti” diagram. We have several different drawings all depicting the same issue. . The left side of this is one version. The right side of this slide depicts a single language approach, not a middleware solution.

The mathematics of scaling up
For traditional point to point or <many to many> integration: The number of possible connections among any number of items is n(n-1) for two way connections. Number of components to integrate Cost of traditional 0.1 FTE Apply traditional formula n = 5 5(4) = 20 n = (9) = 90 n = (14) = 210 n = (19) = 380 2 FTEs (200,000 USD) 9 FTEs (900,000 USD) 21 FTEs (2.1 million USD) 38 FTEs (3.8 million USD) This shows the math of the cost of doing things how we tend to do them today. Show how this point to point model scales very high very fast. The currency valuations refer to a fully loaded person with salary, overhead, benefits, etc. Average is 100K. Could be more, could be less, but the number is a good basis to show cost.

The mathematics of scaling up
For best practices integration: The number of possible connections among any number is n * 2.0 Number of components to integrate Best practices formula Cost of best practices 0.1 FTE n = * 2.0 = 10 n = * 2.0 = 20 n = * 2.0 = 30 n = * 2.0 = 40 1 FTE 2 FTEs 3 FTEs 4 FTEs This shows the math of the cost of doing things how we could be doing them. Show how this model scales flat and scales slowly. The currency valuations refer to a fully loaded person with salary, overhead, benefits, etc. Average is 100K. Could be more, could be less, but the number is a good basis to show cost. Make the point that this is the goal and it usually needs to be done by drawing a line in the and and starting all new work towards this model as we are NOT recommending people rip out their stuff that is working today. This model works for B2B and A2A.

Side by side comparison
<many to many> growth <many to one> growth This is just the graphical comparison. 38 FTEs 4 FTEs

Case Study- Agilent Canonical Model
This whole case study shows how one end user came to the conclusion that implementing a CANONICAL MODEL was necessary for them to meet their goals.

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

Agilent Mission 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

Current Landscape(s): Point-to-Point Integration
Product Master Existing Systems DOC-IT BroadVision Oracle Database HP3000 Mercury Customers ERP Applications APS Applications CRM Systems Agilent-Tech Corporate Systems CORBA Server OFP Systems

Initially Identified Solutions
Batch Process Oldest way known Point-to-Point Interfaces in Middleware Do more faster Internal EDI Middleware: was new technology Batch Process: already in place

Issues and Concerns With 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 We started down this path Goals: supports all but OneIT

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

Canonical!! Revelation: 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 Technical architecture of OAGi intended to be technology sensitive, but not technology specific RosettaNet RNIF considered Freely operate across internal infrastructure: HTTP, FTP, etc.

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 & Support eBusiness Order Generation Fulfillment Information Management Legacy Systems Broadvision enCommerce Blade Runner Oracle Apps HR Finance Reference Systems Product Customer Supplier Price Company Information PeopleSoft SAP/Oracle Data Warehousing Reporting Intranet Content Xpedio/ BladeRunner/ Filenet Functional Applications Legal, GTT, WPS ... Merging Companies’ Applications Packaged, Legacy OAGi Canonical Model TIBCO Bus (RVRD) Which leaves us with… Messages which can be well defined and common throughout the enterprise, but… We were missing a common vocabulary

Sample of Customers using the OAGIS Canonical Model
ADP Agilent Goodyear AT&T Wireless Boeing Cisco Ford General Electric Power Lucent Weyerhauser U.S. Air Force IBM A short list but not a complete list of organizations working towards this model.

A Single Horizontal Language
std1 Sn... stdn S2 std2 S1 std1 Sn... stdn S2 std2 Neutral Markup Language (OAGIS) Service Broker Internal Systems External Systems

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 We want to introduce the class to each of these components of what best practices are telling us are the components of “Modern” eBusiness frameworks.

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 Self Explanitory

ebXML Specifications Requirements Architecture Registry and Repository
Transport and Routing Business Process Collaboration Collaborative Partner Protocol Collaborative Partner Agreement Core Components Self explanitory

Business Process and Information Models
ebXML Architecture Business Process and Information Models UML to XML conversion Registration Retrieval of Profiles & new or updated ebXML Models Retrieval of New or Updated ebXML Models Repository Retrieval of ebXML Specifications & Models Internal Bus App Implementers Shrink Wrap App Build Build I think you understand this. It is standard ebXML stuff. TPA Biz Service Interface Biz Service Interface ebXML Transport Transport Package

ebXML Usage Example Company X Company Y ebXML Repository
1 Request ebXML specification Company X 3 Send ebXML specification Build System 2 4 DO BUSINESS! 11 Register company profile ebXML Repository 8 TPA Accepted 6 7 Submit TPA Specifications Query about Company X 10 Send Company X’s Profile You can just run through this point by point. It gives the attendees an excellent walk through of a use case. Profiles 5 Request Company X’s Scenario Send Company X’s Scenario Scenarios ebXML Software 9 Company Y ebXML BO Library ebXML BP Model

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 This slide describes how the OAGIS Standard fits with ebXML Standards in a complementary fashion.

OAGIS and ebXML OAGIS is the Payload ebXML is the Envelope
Our metaphor for ebXML and OAGIS working together. 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. A couple of textbook definitions. Hard to tell what web services really is by these. Therefore we use a few more slides to define it. 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 Web Services Level One - TCP/IP – Telecommunications Protocol/Internet Protocol HTTP – Hyper Text Transport Protocol SOAP - Simple Object Access Protocol WSDL- Web Services Description Language UDDI – Universal Description, Discovery, and Integration XML – Extensible Markup Language

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. You can just read this. 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 The profile provides constraints and clarifications to those base specifications with the intent to promote interoperability. Where the profile is silent, the base specifications are normative. If the profile prescribes a requirement or constraint, it supersedes the underlying base specification. Some of the constraints imposed by the profile are intended to restrict, or require, optional behavior and functionality, so as to reduce the potential for interoperability problems. Some of the constraints or requirements are provided to clarify language in the base specification that may be the source of frequent misinterpretation, that have been a frequent source of interoperability problems

What is SOAP? Point here is SOAP is really the merging of two existing technologies to improve the calling and wrapping function. ebXML uses this technology also, with a few extensions. (note to trainer – go to picture on next page).

SOAP Envelope Architecture
POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope <SOAP-ENV:Header> Authentication etc. Transaction SOAP Envelope Architecture </SOAP-ENV:Header> <SOAP-ENV:Body> OAGIS BOD XML Payload Here you can show through a two step build how the SOAP envelope defines a header and a body and what is in each. Then you can show where the OAGIS BOD fits in, then you can show where HTTP fits in. </SOAP-ENV:Body> </SOAP-ENV: Envelope>

SOAP Example POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:SOAP-ENV=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Header> <t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1"> 5 </t:Transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:GetLastTradePriceDetailed xmlns:m="Some-URI"> <Symbol>DEF</Symbol> <Company>DEF Corp</Company> <Price>34.1</Price> </m:GetLastTradePriceDetailed> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Just show them the code and what the code for the envelope and the body look like.

WSDL Introduce Web Services Definition Language as a way to describe an interface or API, using XML. Basically one can describe what the API looks like using the WSDL standard. WSDL is really just XML used in a specific manner to do this and there are specifications all over the web that go into more detail. This slide is to familiarize the audience. You can see how WSDL defines the end points and what XML payload is used at that end point. One can do a google search to get programming guides from the internet.

BOD WSDL Example ProcessPurchaseOrder AcknowledgePurchaseOrder
ConfirmBOD

OAGIS PO WSDL

Web Services WSDL Web Services standardizes Technology neutral
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 OAGIS XML SOAP Security

Barriers to Web Services
Security Conflicting Standards Immature Technology (and standards) RPC only Mechanism Async is on the way Web Services still have an issue, primarily around security, and the industry is working very hard to address this. In addition there is sort of a conflict in the industry (note to trainer, go to next slide). RPC is a Remote Procedure Call. RPC has been the basic way for programs to communicate for many years. A drawback is that it requires that the connection always be present between the two applications. We can not rely on that for web based work and therefore need to have a way to guarantee delivery and tracking of messages. The best way known is messaging and Queueing. This is where a message is sent and tored in a file before it is sent and after it is sent, to ensure nothing gets lost.

eBusiness Architectures
Without editorializing on which is best, the point is that these two factions are somewhat at odds. Our hope is that there will be some convergence over time. Note that we already have SOAP used in both groups, and OAGIS XML is used in both groups. We can hope for more and influence this as organizations by making the convergence issue known to industry. 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
ebXML is the envelope OAGIS is the payload Web Services is the envelope Your Envelope is the envelope

OAGIS Architecture Industry Collaboration OAGIS Specification
Message Architecture UML, ebXML Collaborations Collaboration Architecture Collaboration Content Core Components Elements Component Fields & Compounds Data Architecture Values Process Architecture Collaborate with Industry Technical Architecture Frameworks SOAP, ebXML, BizTalk, RNIF, Other Message Content Business Object Document BOD Messages SOAP, ebXML, BizTalk, RNIF, Other UML, ebXML UML, BPSS, BPEL Collaborate with Industry Industry Collaboration OAGIS Specification UML, ebXML Collaboration Definitions Business Object Documents Component Fields and Compound Fields BOD Architecture

Questions?

Back to OAGIS

OAGIS BOD Architecture

Object Communication Before we get too far into architecture, lets look at the basic model for object communication. One sends a request to an object through a publicly defined interface to an object. This object contains both data and methods (data and process, or NOUN and VERB). The request receives a response back through the public interface and the request contains an 1) object name <NOUN>, Method <VERB>, and a list of arguments <values in the BOD>. NOTE: trainer should now go to next slide to show more detail.

Architecture Characteristics
Loosely coupled Asynchronous Heterogeneous Message based Common content Meta data based You may remember this slide from earlier in the day. It is important to take a look at it again to understand the BOD as an independent entity that goes across the wire.

Interface Architecture
Bod Driver Builder Mapper Parser Parser Bod Driver Mapper Builder BOD API In/Out Proprietary API Functions Proprietary API Functions API In/Out Application Programs Application Programs This is a more technical version of the interface architecture on the prior page. This is a logical architecture that OAGi provides to end users and vendors to figure out how this works. It shows relational tables at the bottom, application programs accessing the data, an API on the Application that can talk to a BOD adapter that can take a proprietary API, build a BOD, map it correctly and send it across the wire. On the right side, the BOD Adaptor parses the BOD, maps it to the proprietary API, and brings it into the application.

The BOD Architecture The Business Object Document Basic Architecture. All BODs are comprised of an Application Area and a Data Area.

BOD Application Area This picture depicts a Process Purchase Order BOD with the Application Area expanded in a graphical view. The Application Area is used to communicate between Applications and is NOT meant to be an envelope. Although some of the fields may be redundant to ebXML or SOAP (Web Services), because OAGIS does not reply on a specific framework, the Application Area relies on itself.

OAGIS DSIG Support of DSIG in Payload itself

BOD Data Area Verb This picture depicts a Process Purchase Order BOD with the Data Area expanded in a graphical view. This shows the basic Noun structure with the Verb. Noun

BOD Architecture Here we show both areas in graphical mode at the summary level.

Business View of a BOD

Business View of BOD Core Components (each box is a component)
OAGIS BOD – (Payload is entire structure) POORDERHDR POTERM ADDRESS CONTACT PARTNER CHARGE DISTRIBUTN Diagram Note: - Required = Solid boxes - Optional = Dashed boxes POORDERLIN POSUBLINE POLINESCHD Business View of BOD This usually gives the audience a very good idea of an overall BOD from a structure perspective. Each box is a component that is used to assemble the BOD. You can note that the dotted lines on the multiple boxes denote more than one occurrence and also when occurrences are optional or required. The solid lines denote required component instances.

Technical View of a BOD

The BOD XML Instance Application Area BOD Name Data OAGIS Namespace
Definition Location BOD Attributes Data Area Noun Verb Just walk the audience through this multi-step build and point out each section of the BOD.

The BOD XML Instance Just walk the audience through this multi-step build and point out each section of the BOD.

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 neutral No 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:
Design Considerations and Assumptions 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

OAGi XML Solution Solution Components The OAGi XML solution is comprised of a broad set of XML Definitions and sample files Reference XML shared across all transactions Data Domains Fields and Common Information Structures Each Transaction in the Specification Sample XML files are provided for testing and general structure

Navigating BODs

How BODs Work

BOD Interchange – What you send
B2B BOD Schema A2A BOD BOD Schema

BOD Interchange – What you do with what’s sent to you
Parser Schema-Validating XML Parser BOD XML Schema Application BOD Instance This slide depicts the parsing function that validates the BOD prior to passing it into an application program. The parser reads the BOD instance and validates against the OAGIS XML Schema Files.

Questions?

Begin OAGIS Nouns

BOD Data Area Verb This picture depicts a Process Purchase Order BOD with the Data Area expanded in a graphical view. This shows the basic Noun structure with the Verb. Noun

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 Self explanatory

Noun Example – Party Self explanatory

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 OAGIS Core Components are the basic building block for OAGIS BODs. OAGi has been building their own since Over 50 per cent of all new BODs are constructed from existing OAGIS Components.

PO BOD Assembled using Components
POORDERHDR POTERM ADDRESS CONTACT PARTNER CHARGE DISTRIBUTN Diagram Note: - Required = Solid boxes - Optional = Dashed boxes POORDERLIN POSUBLINE POLINESCHD PO BOD Assembled using Components This usually gives the audience a very good idea of an overall BOD from a structure perspective. Each box is a component that is used to assemble the BOD. You can note that the dotted lines on the multiple boxes denote more than one occurrence and also when occurrences are optional or required. The solid lines denote required component instances.

Component Example This is an XML Code example of the Amount Compound.

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 OAGIS Architects used XML Schema Typing where there were standards types. But there were many cases where the standard types were not enough, so OAGIS build some of their own types and they also build some Compound Fields. These compound fields don’t lend themselves to typing. The best way to understand them is to look at the examples. An amount could never have meaning by itself. It requires the context of several fields that always occur in concert with it, as in Amount, Currency Code, and Debit Credit Indicator.

Compound Example Compound Details Attribute
This is an XML Code example of the Amount Compound. Attribute

Compound Example Compound Attribute Details
This is an XML Code example of the Amount Compound.

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) Self Explanatory

Field Examples <xs:simpleType name="JobCode">
<xs:restriction base="Code"/> </xs:simpleType> <xs:simpleType name="Priority"> <xs:restriction base="xs:string"/> <xs:complexType name="EmployeeId"> <xs:annotation> <xs:documentation source=" An Employee specific Identifier</xs:documentation> </xs:annotation> <xs:simpleContent> <xs:extension base="xs:string"/> </xs:simpleContent> </xs:complexType> This slide contains two examples of fields. The JobCode and the EmployeeId.

OAGIS Architecture Resources Which Content Includes

BOD Assembly Example

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) Self Explanatory

Sync Verb In many scenarios, the first phase is to synchronize the data before processing transactions. This shows Synchronizing the Item Master and the Inventory Amounts before processing an Available-to-Promise transaction scenario.

Time and Attendance Data Gathering Process
Get and Show Verbs Plant Data Collection Time and Attendance Data Gathering Process Shop Floor Control, etc. ERP Human Resources Get Personnel Show Personnel Update PersonTime This picture shows the Get List and List verbs in a natural pairing. Go onto the next five slides that describe these verbs behavior. You can also make the point that often the Get Show are used after the Get List and List.

Get Verb The purpose of the GET verb is to communicate to a business software component a request for an existing piece of information to be returned. The GET may be paired with most of the nouns defined in the OAGIS specification. The response to this request is the SHOW verb. The behavior of a BOD with a GET verb is quite predictable across most of the nouns it may be paired with. The GET is designed to retrieve a single piece of information by using that information's primary retrieval field, or key field. The GET verb is not used to request several documents at once. The GETLIST verb is designed to achieve that purpose.

Show Verb The SHOW verb is used when sending the information about a specific instance of a business document or entity. The SHOW verb may be used: 1) To respond to a GET request or 2) It can be used in a publish scenario, where it pushes information other applications based on a business event. Although BODs based on this verb do not commonly cause updates to occur, there may be times when the component receiving the SHOW decides to use the information it receives to update. This is entirely the decision of the receiving software component and is not forbidden. The behavior of the SHOW verb is quite straight forward with one exception. The SHOW response to any GET request needs to read the request carefully to ensure the response is returning the requested Data Types.

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) Self Explanatory

A Constraint Rule Rule Context Test Message

Using Constraints to Add Context
BOD Instance Application Validating Parser BOD XML Schema XSL Processor BOD Constraints

Simplified OAGIS® Transactions - Verb Use
VERB Request Verb Response Process Acknowledge Post Sync ConfirmBOD Load Cancel Change Respond Get Show Update

Questions?

Error Handling Confirmation of transactions or data synchronization
Applications may log BODs Commitment handling, i.e. “all or nothing” is indicated in the Control Area of the BOD

Application Confirmation

Confirm BOD Application Integrity Not a middleware message
Received and understood Received and did not process Did not receive?

Confirm BOD Example Question: Consider the fact that an application can publish many types of BOD's. For example, a Sales Order, an Invoice, etc. When it receives the confirmation BOD back, how does it know what is being confirmed ??. I.e. is it a Sales Order or an Invoice ??. The ORIGREF field just identifies the actual Order or Invoice number. It might happen that I have the same sequence for Invoices and Orders. I.e. I might have an Order number and an Invoice number I thus first need to know what type of BOD is being confirmed. Answer: The entire control area is now being sent back in the CONFIRM BOD. This will tell the originator what the originating BOD was.If one sends five occurrences of data in a single BOD, then you still only get one instance of a CONFIRM BOD. One must send single instances of BOD’s to receive single confirmations for each. A work-around to this is to send a separate CONFIRMMSG for each instance of the Data Area. This enables a one to one response, but the responsibility for tying the CONFIRMMSG Data Types to each instance of the original Data Area sent would be on the software. The original intent of the ORIGREF is to include whatever is necessary to accomplish the drill back or audit capabilities from the Ledger to the sub-ledger. The design point here the assumption that the summarization will occur in the sub-ledger.

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. Introduce the class to the two methods for extensibility. Make the point that these methods enable one to extend the standard without breaking it or making changes to the base standard. OAGi does not encourage changing the standard, but since most everyone needs another field, the architecture team spend an incredible amount of time working to make extensibility logical and practical but keeps the standard intact.

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 Self Explanatory

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 Self Explanatory

Recommended extensibility approach when using OAGIS; Overlay Extensibility

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 Self Explanatory

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 This is the recommended approach to extensibility for OAGIS.

Overlay Example Overlay OAGIS® Your BOD
This is a fictional picture of how an overlay plugs into OAGIS. The overlay uses all the base functions from the OAGIS library and just adds or changes the parts that are specific to the vertical. This preserves the horizontal backbone (CANONICAL MODEL) and enables excellent fit for vertical industries.

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 Self Explanatory.

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 Meta Model
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 Verb
Nouns are content Verbs add “context” Verb Noun

OAGIS Meta Model BOD 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

OAGIS 9 Naming and Design Rules

The BOD Architecture The Business Object Document Basic Architecture. All BODs are comprised of an Application Area and a Data Area.

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 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

OAGIS® Component Libraries
UN/CEFACT IST/ISO

Standards within the OAGIS® Standard
W3C - URI/URL W3C - XML Schema 1.0 Part 1 W3C - XSL Schema 1.0 Part 2.0 W3C - XML Style Language W3C - XML Path Language (XPath) Version 1.0 ISO - ISO11179 ISO - ISO Core Components Type Specification ISO - ISO20022 (UNIFI Financial Standard) ISO - ISO Currency Codes ISO - ISO639 - Language Codes UN/CEFACT ATG2 Naming and Design Rules - NDR UN/CEFACT Harmonized Core Components – TBG17 MIME Media Type Code UNECE Unit Code OMG UML 2.0

OAGIS® BOD Stack Lite BOD OAGIS® Business Object Documents
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/ISO Core Components Meta Model Naming and Design Rules BOD Architecture

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

Value of Interoperability
high Common Content ? Value of Differentiation low low Value of Interoperability high [Shaffner 1994]

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:

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 site. Click “Free Downloads” Click on OAGIS link Fill in the Registration Form; click the Submit button at the bottom of the form. For OAGIS 8.x, simply click on the OAGIS 8.x link. (This will retrieve a single zip file that contains all of OAGIS.) 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

OAGIS Release 9.0 Unzipped File in /OAGIS/9.0 Documentation
Scenarios BODs Instances Tools When you download the OAGIS zip file, and you un-zip it, this is what it looks like. To open the documentation,

Getting OAGIS 9 – What you get
A large (12MB) zip file containing The OAGIS 9 XML Schema Definition (.xsd) Files Developer version of all of the BODs Standalone version of all of the BODs Resource library containing all of the Components, Fields, etc. 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

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

Recipe for Integration
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…. This is a detail step by step checklist that developers can use to ensure they think through all of the issues when designing a business process flow. Walk the audience through this step by step.

Use of the 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 This is a detail step by step checklist that developers can use to ensure they think through all of the issues when designing a business process flow. Walk the audience through this step by step.

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 eXcelon Stylus xmlArchitect Validating Parsers For validating, using incoming BODs Xerces 2.0.1 MSXML 4.0 SP1 Oracle Before we go look at OAGIS, here are some tools you might want to consider. Most have trial versions.

OAGi Free Resources http://www.openapplications.org
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 This slide is the closing slide to remind people of resources available to them on the OAGi Web Site. Please make note the OAGIS Extensions guide for Schema is almost ready.

Questions?

Canonical Model Stewardship

Stewardship Topics 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 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

Development Methodology
This is an introductory class to the OAGIS Open Development Methodology. The methodology is based on best practices in software development using Rapid Application Development techniques combined with the open collaborative methods used in the best open development processes. Also phase make the point that the Open Development Methodology is free to download from the OAGi web site. Introduce the class to the four phases of the development methodology and the names of the phases. Each phase will be covered in more detail.

Development Methodology
Demand driven Projects led by members Virtual teams Work done by and teleconference between meetings Repeatable process All work is done when it is requested by members. Any work that may be controversial is always discussed at the board for resolution. All content projects are led by members of OAGI. The teams are formed for each project and exist for the length of the project. This is a best practices approach to development. Much of the work is done using teleconferences and by , just as in other open development groups that have a broad constituency. This process is repeatable and successful and has proven itself out over 9 years.

Working in the OAGI Time is self-governing
Much work can be done remotely Meeting attendance is not mandatory Technical Meetings Managers Business analysts Architects/Developers 3 days 4 times year One can contribute to the work and to projects as much as their priorities dictate.

Member-Driven Process
Members Attend OAGi Meetings Held 4 times per year in various locations Member Organizations Drive the Standard Members originate BOD proposals From the proposal project teams are formed. These project teams develop the BOD definitions based on an Integration Scenario Members vote on New BOD inclusion BOD revision This is the first in a series of introductory slides that describe the principles of the Open Development Process. Members drive the process and members drive the content. Walk the audience through each bullet.

Core Development Values
Projects will not be re-started when new members join the meetings. Members must be present at meetings to participate in the process. International Requirements built in No feature regression is permitted. Backward compatibility must be maintained. Content will be reused whenever possible. These are all very important poitns, and each one needs to be presented and discussed. These very important core values have been developed by the membership over the years to ensure high quality standards built in a timely manner. POINTS: - Everyone who participates has a voice. -International requirements are something that needs to be built into the standards, not added on after the fact and this is reviewed during each phase of the projects. -No feature regression refers to the removal of a function that has already been delivered. It it not allow to take away features that have already been delivered. -Backward compatibility means that each new version of the specification must be able to interoperate with prior releases. -The membership greatly discourages building new stuff just because they can. The membership has adopted the principle that all existing content will be reviewed and re-used when building or revising OAGIS content.

OAGi Open Development Methodology
Roles: PL - Member Project Leader TM - Team members OA - OAGi Architect CTO - OAGi CTO OAGi Open Development Methodology Construction Review & Approval Publication Project Definition Activities - OAGi Architectural review for consistency, etc. - Editing by OAGi architect - Final testing of XML deliverables - Combine all project content together - Complete any defect removal necessary - Complete any requested enhancements not in a specific project - Publish to OAGi web site. Activities - Propose Project - Build Project Definition - Choose Team - Get CTO Approval - Set up Yahoo Group Activities - Business process modeling - BOD message development - Dictionary development - XML Schema development - XML message examples development - Teleconferences with project team - Construction Phase review to OAGi technical meeting - OAGi architectural review Activities - Review deliverables with OAGi Architect - Review final deliverables with working team and ask for vote. - Present to OAGi Technical team and ask for vote - Finalize changes based on voting results - Turn deliverables over to OAGI architect - CTO presents to OAGi Board for final approval This is a single slide that summarizes each phase, the activities in each phase, the deliverables in each phase, and which role is responsible for each deliverable. This page can be printed and used as a tri-fold reminder guide. Deliverables (PL) - Project Definition - Project Team - Yahoo Group Deliverables (PL, TM) - Integration Scenario(s) - BOD documentation - Dictionary updates - XML Schemas (DTDs) - XML message examples Deliverables (PL, TM) - Approved versions of the following: - Integration Scenario(s) - BOD documentation - Dictionary updates - XML Schemas (DTDs) - XML message examples Deliverables (OA, CTO) - Final versions of the following: Integration Scenario(s) UML Sequence Diagram UML Collaboration Diagram - BOD documentation - Dictionary updates - XML Schemas (XSD) - XML message examples

Building a Scenario Think boxes and arrows Define components in domain
Draw dialogs with arrows between boxes Define sequences Define exception handling UML Notation Collaboration Sequence Diagrams Here is a step by step explanation how what to do when developing a Scenario. Walk the audience through the bullets.

Constructing a BOD Start with BOD closest to your needs
Operational BOD Financial BOD Table BOD Start with the Noun Focus on the content and structure Use OAGIS naming conventions Use std. XSD and OAGIS Types OAGIS Reuse or add as required Add Fields and Segments Reuse existing Add new as required Here is a step by step explanation how what to do when developing a Business Object Document. Walk the audience through the bullets.

Naming Conventions Element and type names are UpperCamelCase
SalesOrder, PartyId, TelephoneNumber Attribute names are lowerCamelCase qualifyingAgency, name Most names are unabbreviated Exceptions UOMType An abbreviation of UnitOfMeasure Type, a simpleType uom An abbreviation of what would be the unitOfMeasure attribute, unabbreviated This slide is mostly self-explanatory. You can note the points and just walk the audience through the points.

The Relaxed Model Different BODs require different parts to be present
Process, Update, …, require much content Get, Cancel, …, can require little Keeping N copies of a Noun or Component consistent Is a nightmare to maintain Is error prone Degrades over time Faced with the prospect, we chose not to

Constructing a BOD Now define the Verb
Start with SYNC Or other primary update verb (ADD, etc.) Define Required and Optional Rules Based on context Define Processing Notes Here is a step by step explanation how what to do when developing a Business Object Document. Walk the audience through the bullets.

Process Summary All new work is process-based
Top down from the process except when doing modifications Business content drives technical content This is to reinforce that all new projects start with the Business Process Modeling. Modifications to the specification may not require business modeling.

Value of Interoperability
high Common Content ? Value of Differentiation low low Value of Interoperability high [Shaffner 1994]

Questions?

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 The point of this is not to spend a lot of time but to make a statement about working with the worlds important de jure and open standards groups.

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 Liaison with ISO TC184
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. The MoU establishes a cooperative coordination mechanism to produce mutually supportive data interchange and interoperability standards for business transactions as well as product design and manufacturing to meet industry and user needs. It aims to minimize the risk of divergent and competitive approaches to standardization and avoid duplication of efforts and confusion among end users. For More Information on the MoU, go to their web site:

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
Automotive Aftermarket Industry Association American Body Parts Association Heavy Duty Distribution Association Motor and Equipment Manufacturers Association Aftermarket Industry Association of Canada Automotive Engine Rebuilders Association You can just point out several of these organizations to show the diversity. Automotive Warehouse Distributors Association Specialty Equipment Market Association Production Engine Remanufacturers 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 This section just tries to give the audience a feel for the broad adoption of OAGIS. Because OAGIS is free to download and is Royal-Free to use, tens of thousands have downloaded it over the years. It is actually impossible to fully determine how many and who is using it completely. You want to point out that is is being used for B2B, A2A, and in some cases even C2B. The user base of OAGIS is a grass roots user base because most people download it and use it because “It just works”.

Knowledge of Adoption We believe we only know about 10 per cent of the actual users You can make the point that we really only know about the tip of the iceberg and then move on to the data slides.

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 NOTE: This list is not complete. We need to update it before publishing as Final. (02/10/2003)

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 QAD iWay webMethods Websphere Camstar
Kaba Benzing Wonderware Baan SSA WiPro EDS SAP (partial) IBM ExpiditeBiz Microsoft iBASEt iConnect Covisint (Compuware) HK Systems Catalyst Brooks Software Compiere

OAGIS® Logistics Web Services Example

Compiere Open Source ERP

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 Sara Lee Sasol

End User Examples

Agilent Enterprise Integration Model
Service & Support eBusiness Order Generation Fulfillment Information Management Legacy Systems Broadvision enCommerce Blade Runner Oracle Apps HR Finance Reference Systems Product Customer Supplier Price Company Information PeopleSoft SAP/Oracle Data Warehousing Reporting Intranet Content Xpedio/ BladeRunner/ Filenet Functional Applications Legal, GTT, WPS ... Merging Companies’ Applications Packaged, Legacy OAGi Canonical Model TIBCO Bus (RVRD) Which leaves us with… Messages which can be well defined and common throughout the enterprise, but… We were missing a common vocabulary

Lucent and OAGIS® OAGIS®

Ford and OAGIS®

Campbells and OAGIS® From: paul_xxxxxxxxx@arnotts.com
Sent: Wednesday, June 04, :41 PM To: Dave Chambless Cc: David Connelly; Subject: RE: Campbell Soup and the Open Applications Group Hello Dave, Thanks for the invitation to join OAG. At Campbells Asia Pacific (I am based in Sydney, Australia) we have already adopted OAGIS as our message content schema (canonical form) in our EAI projects. We are a Tibco shop, and leverage the toolset for both B2B and A2A integrations. We reviewed ebXML for the initial B2B integration with a 3PL that was our first EAI project, but since the particular trading partner in question did not have a messaging framework in place enabling the infrastructure level interoperability, we leveraged the default Tibco framework (tibXML) as the most appropriate alternative because it is simpler to implement and to deploy 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 . . .

SKF and OAGIS® From: xxxxx.xxxxxxx@skf.com
Sent: Thursday, July 29, :20 AM To: Subject: 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 McCulloch SKF Logistics Services AB SKF Gothenburg//Sweden (Tel: ) (

Dubai eGovt.

UK Ministry of Defense

New Zealand

OAGIS® around the world
Here we graphically portray that OAGIS is truly a GLOBAL Standard used in at least 6 continents and 39 countries.

Thanks and Questions?

Open Applications Group

Similar presentations

Presentation on theme: "Open Applications Group"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Open Applications Group

Similar presentations

Presentation on theme: "Open Applications Group"— Presentation transcript:

Similar presentations

About project

Feedback