Home | Business News | Browse by Publication | X | XML Journal

Using OAGIS for integration: enabling everywhere-to-everywhere integration.

Publication: XML Journal
Publication Date: 01-NOV-02
Format: Online
Delivery: Immediate Online Access
Full Article Title: Using OAGIS for integration: enabling everywhere-to-everywhere integration.(Open Applications Group Integration Specification )

Article Excerpt
The Open Applications Group Integration Specification (OAGIS) is implemented because it simply works--and it's available today. While it's not as "cool" as the Web services protocols, it does provide the missing piece for Web services.

Without OAGIS, a canonical business language that enables integration, these cool protocols would simply pass proprietary data. Yes, the data could be in XML, but there wouldn't be a common understanding of what the messages mean. OAGIS includes the most XML messages defined in any XML dialect, and more are being defined every day.

OAGIS Simply Works

OAGIS is the common content model needed to represent messages that enable communication between business applications, whether the messages are application-to-application (A2A), business-to-business (B2B), or vertical industry-to-vertical industry (V2V) in nature. In short, OAGIS enables everywhere-to-everywhere integration.

OAGIS Is the Content

To see how OAGIS works, let's use the mail analogy. If I send you a message using postal mail, I write the message in one of a few accepted formats. I then address an envelope with the sending and receiving addresses, put the message inside the envelope, seal the envelope, apply postage, and place it in the mailbox. My mail delivery person retrieves the package. It's routed through the mail system, and after some time it arrives at your address. You retrieve the package from your mailbox, open the envelope, and read the message. Assuming you and I understand the same format and speak the same language, you can understand the message.

If my application needs to send a message to you and your application(s), something similar takes place. My application creates a message in one of several formats. Next, the application or an agent for my applications wraps the message into a transport envelope (Web services, ebXML, RosettaNet Information Framework, or Message-Oriented Middleware [MOM]) and applies the sender's and receiver's addresses to the envelope. The package is placed on the transport mechanism, which routes the package to your application. Your application retrieves the package from the transport mechanism, opens the envelope, and reads the message. Again, assuming our applications understand the same format and speak the same language, our applications understand the message.

If both applications speak OAGIS, they can understand the message. The problem is that many applications use their own proprietary formats and languages for integration.

OAGIS provides a common data model that provides a common basis of understanding, allowing all the applications involved in the information exchange to understand the intent of the message. The messaging specifications are analogous to the envelope. The integration engine used to transport and route the message is analogous to the postal service. The message and message format are analogous to OAGIS, which enables the understanding of the information on each end.

Just as it doesn't matter what brand of envelope you use to send a message via postal mail, it doesn't matter what framework you use to carry your OAGIS messages. So, use the framework that makes the most sense for your business, your supply chain, or your integration. It doesn't matter if the exchange of information is A2A, B2B, or V2V in nature. It's always critical that both sides understand the message--if the receiver doesn't understand the purpose or the content of the message, it's worthless. In many integrations, messages have to be translated for each application, business, and vertical industry for which they're intended. Doing this in a point-to-point manner is messy, not to mention inefficient.

Let's assume that it takes one-tenth of a person's time to maintain each integration mapping. (By all estimates this is extremely low, but it makes the point.) The formula for point-to-point integrations is n(n-1).

Using a canonical business language to translate to and from, it's possible to use a common format in the center. The formula for a canonical integration is n * 2. If we use the same...

View this article FREE - Now for a Limited Time, try Goliath Business News
Free for 3 Days!



More articles from XML Journal
Distributed AI, schedules, and the Semantic Web: RCal provides a glimp..., November 01, 2002
Rapidly growing SYS-CON Media Garners Awards. (XML News).(Brief Articl..., November 01, 2002
DataDirect Technologies introduces DataDirect jXTransformer for transf..., November 01, 2002
Rogue Wave Software expands Web integration technologies with XML Obje..., November 01, 2002
Corel Ventura 10.0 now available: extending the power of XML content t..., November 01, 2002

Looking for additional articles?
Search our database of over 3 million articles.

Looking for more in-depth information on this industry?
Search our complete database of Industry & Market reports by text, subject, publication name or publication date.

About Goliath
Whether you're looking for sales prospects, competitive information, company analysis or best practices in managing your organization, Goliath can help you meet your business needs.

Our extensive business information databases empower business professionals with both the breadth and depth of credible, authoritative information they need to support their business goals. Whether it be strategic planning, sales prospecting, company research or defining management best practices - Goliath is your leading source for accurate information.