Level: Introductory Michael Rowell (mrowell@openapplications.org), Chief Architect, Open Applications Group
30 Jun 2003 The Open Applications Group Integration Specification (OAGIS) is an effort to provide a canonical business language for information integration. It uses XML as the common alphabet for defining business messages, and for identifying business processes (scenarios) that allow businesses and business applications to communicate. Not only is OAGIS the most complete set of XML business messages currently available, but it also accommodates the additional requirements of specific industries by partnering with various vertical industry groups.
The Open Applications Group (OAGi) -- the organization that oversees the OAGIS -- was formed in November 1994 in an effort to dramatically ease everywhere-to-everywhere integration (inside and outside of the enterprise, as well as across the supply chain). OAGi has done this by crafting standards where necessary and by recommending standards where they already exist.
The first release of OAGIS was developed in 1995 to address the need for a common business language that would enable business applications to communicate. OAGIS provides the definition of business messages in the form of Business Object Documents (BODs) and example business scenarios that provide example usages of the BODs. The business scenarios identify the business applications and components being integrated and the BODs that are used. The current release, OAGIS 8.0, includes 200 business messages and 61 business scenarios that can be used to integrate business applications. This summer, OAGIS will publish its 19th release (both major and minor releases) in OAGIS 8.1, which will include 400 business messages.
OAGi also partners with other standards bodies to provide a true canonical business language. OAGi recognizes that no one organization can be all things to all people, however by partnering with industry vertical groups OAGIS provides the means to plug in the additional requirements and constraints that meet the specific needs of each vertical industry.
Because of this long history of delivering quality usable integration standards, OAGIS has support from application vendors and implementation providers, and has been implemented by various customers in over 40 countries worldwide.
OAGIS 8.x is expressed in XML Schema and provides the transactional and operational information needed to support the needs of business and application integration. You can access OAGIS along with all of the resources that OAGi makes freely available from the OAGi Web site (see Resources). You'll also find links to more information about training and services that are provided for a nominal fee in order to enable integration with OAGIS.
OAGi's track record
Since its inception, OAGi's mission has been to promote and ease cost-effective integration by focusing on business needs. OAGi continuously works toward this mission through the development of a best practices model for interoperability, while providing an impartial forum for industry stakeholders to learn, cooperate,
and further improve the model.
OAGi's solid track record is demonstrated by the following:
- Within months of organizing, OAGi hosted a proof-of-concept which proved that the standard could be used to integrate heterogeneous business applications.
- A wide range of customers have implemented OAGIS.
- Many application vendors have built-in support for OAGIS in their products.
- Many implementers support OAGIS as a means of increasing the speed at which integrations occur.
- OAGi was the first standards body to adopt XML for defining its content. OAGi did this a week after XML became a formal recommendation from the W3C. Since then, the organization has been involved with defining best practices around XML and recommending ways that it should be used.
- OAGi was one of the first standards bodies to adopt XML Schema and continues to define best practices on the practical use of XML Schema.
Most of the people from the member companies who work in OAGi are the same people who are responsible for product implementations or application interfaces within their respective companies. As a result, OAGIS and OAGi seek to make the standards practical and usable.
Because of this, OAGi views itself more as a development organization with a focus on providing what is needed to enable and simplify integration. While OAGi is a standards organization, it has not lost sight of the fact that at the end of the day what matters is providing value to its member companies and to the rest of the industry by enabling the sharing of information between businesses and business applications. As a result, OAGi works more like a development organization than a standards body. OAGi follows the Open Applications Group Open Development Methodology, which is freely available on the OAGi Web site (see Resources). This methodology derives from rules that most experienced software developers follow today.
OAGi recognizes that it is important for OAGIS to be technology-sensitive but not technology-specific. Because of this, OAGIS works well with Web services, ebXML, or any other framework that your organization chooses to use to transport information, including FTP, SMTP -- or even none at all.
OAGi also authors articles (like this one) in various publications, as well as white papers, design documents, and users' guides that describe how to use OAGIS with these various frameworks.
So who's involved? OAGi members include individuals and small, medium, and large companies -- companies like Irista Software, MRO, IBM, Oracle, Sun Microsystems, Lockheed Martin, Lucent, Ford, and Agilent to name just a few. (For more information about OAGi members see the OAGi members list in Resources.)
Plays well with others
While it is important to provide a horizontal backbone to integrate across vertical industries, OAGi realizes that each vertical industry group has the domain knowledge for its specific industry and often uses an existing vocabulary that is widely known within that industry. For this reason, to provide a true canonical business language OAGi must work with vertical industry groups to leverage the understanding that already exists and provide an overlay of the vertical information on top of the horizontal understanding of that information. This is similar to the layers of information provided in a blueprint of any physical structure.
Because of this, OAGi actively partners with many different vertical groups. Examples of this include various automotive standards bodies from around the world (such as AIAG, Odette, NADA STAR, and Aftermarket), as well as standards bodies focused on human resources, chemical, aerospace, and a range of other industries.
OAGi is also involved with other standards bodies, including UN/CEFACT and WS-I. OAGi has also been recognized as a work group by the Memorandum of Understanding Management Group (MoU MG) of the four recognized standards bodies in the world, which include International Electrotechnical Commission (IEC), International Organization for Standardization (ISO), International Telecommunication Union (ITU), and United Nations Economic Commission for Europe (UN/ECE).
Since OAGi is not interested in duplicating the work being done by the different framework standards, OAGi provides a neutral place to learn how to use OAGIS within these frameworks.
Available and being used today
OAGi members and non-members have actively worked to add support for OAGIS within their products; new implementations by vendors, consulting companies, and users emerge constantly.
This continues from the challenge issued from the OAGi customer council in which they asked OAGi member vendors to support OAGIS to enable integration.
This culminated in the OAGi-hosted Vendor Challenge event in November 2001,
in which 21 OAGi member vendors demonstrated their support for OAGIS in their off-the-shelf products. By integrating three real-world scenarios -- one provided by each of the following: Ford Motor Company, Boeing, and Lucent Technologies -- each member vendor integrated its own application with the other member vendor applications in at least one aspect (many in several aspects) of the three scenarios.
The Vendor Challenge was valuable because it recognized the level of adoption that the participating companies had made in their applications and within their enterprises. Because of this commitment, it is now possible for everyone to realize a large return-on-investment by using a canonical business language for integration. Since the Vendor Challenge, OAGIS has been adopted by companies in a wide range of domains and countries worldwide.
Show me the code
Now that you've taken a look at a brief history of OAGi, you're ready to explore what OAGIS is all about.
OAGIS: A business process
First and foremost, everything in OAGIS begins with the business process. OAGIS currently includes 61 business processes, which provide examples that show what is possible using the standard. Likewise, when you need to integrate businesses or applications using OAGIS the first place to start is with the business scenarios which can help you find the solution that most closely matches your needs.
These business scenarios provided by OAGIS were used to define OAGIS and are provided as examples to help the user understand how to work with OAGIS. They identify the business applications and components that are being integrated along with the BODs used to pass information. The business scenarios also capture the sequence in which the messages are intended to occur, the dependencies, the scope, and the error handling that has been addressed. OAGi provides these example scenarios as a starting point for any new implementation.
Figure 1 illustrates an example of one such scenario. Notice that this scenario has call-outs to other scenarios to display more detail -- specifically, the integration of Manufacturing to Purchasing scenarios and the Manufacturing to Order Management scenario.
Figure 1. The supply chain integration (Manufacturing to Purchasing, Order Management, Billing, Shipping, and Financials)
In Figure 1, you can see that the ProcessPurchaseOrder BOD starts this scenario by communicating a customer's demand for an order. The ProcessPurchaseOrder communicates the line items that the customer is interested in buying from the supplier to the Order Management system within the supplier's enterprise. The Order Management system then communicates with the Production and Inventory systems to determine availability and to initiate the fulfillment of the order based on inventory on hand and the capacity to produce more widgets that are being sold through the originating ProcessPurchaseOrder. Once the line items can be fulfilled, the Inventory system communicates the picking information to the Shipping system and the line items are delivered to Shipping to be packaged and shipped.
In addition to all of this, the supplier may purchase parts of the order from a second supplier; this is indicated by the AddPurchaseOrder at the top of the diagram to the Purchasing system, where an additional ProcessPurchaseOrder and AcknowledgePurchaseOrder make this purchase happen. It is also important to note that throughout this process, the accounting systems are receiving updates as to where the order is and the cost incurred at each step of the process.
Of course, error processing and error handling are built into each of these steps as the information proceeds through the business process.
To learn more about the specifics of this scenario -- and all the OAGIS business scenarios -- see the OAGIS documentation in Resources. These business scenarios are also expressed in UML collaboration and sequence diagrams. OAGi has found that business analysts tend to favor the block scenario diagrams above, while developers prefer the UML diagrams. OAGi attempts to provide both.
Once you find the business scenario that matches your integration needs, you can use the business scenario to find the BODs that are needed to enable your integration -- the BODs are identified by name in the business scenario.
A BOD
Now that you've had a brief look at an OAGIS scenario, I want go to the next step and look at a BOD.
OAGIS BOD messages make use of today's best practices of object-oriented design by defining a common consistent Noun or object that has Verbs or methods that indicate the action to be performed upon the Noun. By using this construct, it is possible for OAGIS messages -- and the code that reads and produces OAGIS messages -- to leverage this reuse. Once the initial OAGIS BOD can be read or produced, much of the code can then be used to read or produce the next message.
Figure 2. General structure of all BODs
All of the OAGIS BODs use the same general structure:
- The name of the BOD is the VerbNoun combination being applied (notice that the Verb and Noun are used as separate elements in the DataArea)
- An Application Area
- A DataArea that contains the Verb and one or more of the Nouns indicated
The ProcessPurchaseOrder structure looks like the following:
Figure 3. Structure of the ProcessPurchaseOrder BOD
The details of the PurchaseOrder are defined under the PurchaseOrder element; again to learn more about the OAGIS BODs, refer to the OAGIS documentation. The OAGIS ProcessPurchaseOrder is defined by the XML Schema code in Listing 1 (ProcessPurchaseOrder.xsd), which includes the Process (verb) and the PurchaseOrder (noun) definitions.
An example XML instance of this ProcessPurchaseOrder is shown in Listing 2 (ProcessPurchaseOrder.xml). (You can download both ProcessPurchaseOrder.xsd and ProcessPurchaseOrder.xml in a zipped file. See Resources.)
Extensions anyone?
Notice from the code listings that all of OAGIS is defined to be within the OAGIS namespace.
Unlike most standards organizations, OAGi recognizes the fact that no matter how many smart people work on a standard, all possible uses of the messages cannot be addressed. For this reason, OAGIS allows users to extend OAGIS messages by using either:
UserArea extensions which allow simple extensions of a few fields to an existing OAGIS component orOverlay extensions which allow users to extend an OAGIS BOD, noun, and component to meet their own needs, even adding new BODs, verbs, nouns, and components where necessary
Both of these extension mechanisms use XML namespaces to separate the extended content from the standard content and definitions. By using XML namespaces, extensions can be made without editing any of the OAGIS XML Schema files.
To learn more about extending OAGIS, please see the OAGi User's Guide for Extending OAGIS 8.x (in Resources).
What's next?
OAGIS 8.1 will be released this summer, and will include:
- 70 business scenarios for integration
- More than 400 BODs
- 70 nouns
- Support for ebXML's CoreComponent Type 1.90
- OAGIS's submission to the UN/CEFACT CoreComponent Harmonization committee
In addition, OAGi will provide direction on how to enable OAGIS through Web services by providing guidelines and WSDL that can be used to develop your own Web services.
OAGi has already publicly announced that it will support harmonized components that result from the UN/CEFACT CoreComponent Harmonization work group.
Summary
OAGi has been enabling integration for a long time. OAGIS currently includes 61 integration scenarios and more are coming.
OAGIS provides a standard canonical business language that enables streamlined communication between businesses and/or business applications. OAGIS works with whatever transportation layer you and your company choose to use.
OAGi also has a long track record of working with other standards bodies to enable integration. Over the years, OAGi has been and continues to be more interested in real solutions than in academic exercises. OAGi works and acts more like a development organization than a traditional standards organization. By doing this, it is able to deliver a solution that works and can be implemented quickly.
But don't take my word for it -- see for yourself and share your feedback with OAGi. If you are interested in participating, join. OAGi is open to everyone.
Download | Name | Size | Download method |
|---|
| x-oagis.zip | | HTTP |
Resources
About the author  | | | Michael Rowell is the Chief Architect for the Open Applications Group, a not-for-profit consortium of application vendors, implementers, and customers working to achieve dramatically easier business integration through standards and the implementation of standards. Mr. Rowell is responsible for the technical architecture of all Open Applications Group standards, including OAGIS, and for providing direction for Open Application Group training and services. You can contact him at mrowell@openapplications.org. |
Rate this page
| 
