|
Article Excerpt
WHEN ASKED TO JOIN THE OAGIS MODERNIZATION PROJECT (OAGIS 8), I LEAPT AT THE CHANCE. HERE WERE TWO RENOWNED SPECIFICATIONS JUST WAITING TO GET ACQUAINTED:
* OPEN APPLICATIONS GROUP'S OAGIS, THE SOLID, PROVEN INTEGRATION SPECIFICATION, AN EARLY XML APPLICATION (1998) WITH A LOT OF MILES ON IT
* W3C's XML SCHEMA RECOMMENDATION (HEREINAFTER "SCHEMA"), A SOPHISTICATED NEW METAMODELING CHASSIS, READY TO BE ROAD TESTED
The outcome exceeded expectations: OAGIS's established and widely used family of horizontally focused, DTD-encoded interchange messages was updated, eliminating major usability issues inherent in a DTD-based implementation of this scale. At the same time, Schema enabled the horizontal OAGIS specification to employ an extensible architecture, OAGIS 8 Overlay Extensibility, to address the specific needs of vertical industries. Vertical market fit versus broad horizontal reusability has long been a sticking point between competing integration standards--Overlay Extensibility enabled an approach that leverages the strengths of both models.
Developing a specification that promotes both horizontal coverage and vertical specialization wouldn't have been possible without Schema's advanced capabilities. However, the experience also opened our eyes to some challenging aspects of developing a usable, practical XML Schema solution to a complex real-world problem.
This article describes the Open Applications Group Integration Specification, discusses the enhancements made possible by rearchitecting to Schema, and explores the challenging aspects of applying current Schema technology. Despite those challenges, OAGI architects were able to work with Schema to craft a new OAGIS that sustains proven strengths and adds desirable and innovative features, most notably, Overlay Extensibility.
What is OAGIS?
* OAGIS is an Integration Specification: A technology-neutral means of integrating enterprise applications and of engaging in e-business transactions. We live in a world where integration is a necessity, not a luxury: enterprises face EAI scenarios daily--within their enterprise, with partnered enterprises, and, increasingly, with merger partners; and they steadily offer and consume more e-business services. Having a technology-neutral reference specification provides the clear benefit of minimizing pairwise integrations.
For OAGIS, Integration Scenarios (see Figure 1) are the basis for integration message design, establishing the context of messages that accomplish the integration, whether B2B or EAI. These scenarios are reusable designs that can be modified to meet specific business process needs.
[FIGURE 1 OMITTED]
* OAGIS is the BOD: The Business Object Document, OAGIS's atomic transactional interchange message, is the structured XML message interchanged between applications, either intra- or interenterprise. BODs (e.g., ProcessInvoice, ChangePurchaseOrder) represent applications' integration APIs and/or the enterprise's e-business service interactions. The BOD defines, among other things, a Noun, the business object (Invoice, PurchaseOrder, ...) that is the subject of the interchange; and a Verb, the operation (Add, Change, Process, Cancel, ...) to be applied to the Noun. Benefits of using the BOD message architecture include consistency of architecture, message, and dictionary; high levels of reuse across messages; rapid development; and a smaller learning curve for users and developers.
* OAGIS is a canonical language: OAGIS provides a horizontal set of messages to address a broad spectrum of typical e-business and EAI interchange needs composed from a large set of core components. A canonical, general core establishes a strong common base. Yet no business or industry consortium would feel that this alone could cover all of their interchange needs, nor could it adequately express their segment's specific vocabulary. Because of this ...
* OAGIS is extensible: Vertically adaptable to specific industries and enterprises, core OAGIS can be nominally extended using UserArea Extensibility, a rudimentary means of plugging additional content into standard BODs. OAGIS can be more substantively extended using Overlay Extensibility, where specific, new vocabularies are built on core OAGIS by extending existing BODs and components and/or by creating new ones. Extension is better than building from scratch: building on an established base enables reuse.
* OAGIS is transport independent: It's not a communication protocol, nor is it tied to a specific messaging technology. Any message transport can deliver a BOD: HTTP, HTTPS, SMTP, SOAP, publish/subscribe models; both synchronous and asynchronous communication models are supported.
* OAGIS is member-developed: BOD existence and coverage are dictated primarily by member need (not solely by theory of relevance), informed by member-developed interchange scenarios.
* OAGIS is usable, practical, maintainable: OAGIS elides details and complexities of the underlying representation, important where XML Schema is considered. Messages are constructed from core components; better modularization leads to reusable BOD processing code.
* OAGIS is established, widely used: OAGIS debuted in 1996; the first XML release was in...
|
