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

OAGIS: a `canonical' business language for Web services: the missing piece.

Article Excerpt
With all of the capability of Web services and the hype surrounding them, there's still a missing piece. Most people don't talk about this missing piece, despite the fact that it's what end users care the most about.

Integration isn't possible without an understanding of the payload of the message. While protocols are "cool," the customers' "end-in-mind" is business integration. For this to happen, Web services must be able to communicate the information of the business transactions being performed. At the end of the day, my message must reach you and your business application such that your business application understands the intent of the message and its impact on the business process in which the two of us are currently involved.

Web services promises integration of business applications over the Internet by exchanging data, sharing tasks, and automating business processes--all while lowering the cost of integration, regardless of operating system, language, and location. However, most Web services today are informational in nature, not transactional. For example, many financial companies offer Web services that give stock quotes, and Amazon has Web services that allow you to check the availability of a book and its price. But no one currently offers a Web service that enables a stock trade or book purchase. It's possible to perform these transactions in a business-to-consumer scenario in which a customer buys a book via a Web page, but not in a business-to-business scenario in which the business applications on each side make the transaction happen. The promise of Web services is just this--the ability to automate these types of tasks so that business applications can be performed with minimal human intervention.

To do this, Web services need to be able to communicate the information needed for business transactions to occur. This simply isn't provided by the agreed-to set of Web services standards, nor is it provided through the extended set of Web services standards.

The Open Applications Group Integration Specification (OAGIS) provides for both vertical and horizontal requirements for integration. This is the case whether an integration is implemented via Web services or any other technology. The Open Applications Group (OAGI) made a conscious decision to craft OAGIS to be technology sensitive but not technology specific. Because of this decision, OAGIS has been implemented over a variety of different technologies: Web services, ebXML, RosettaNet Informational Framework (RNIF), BizTalk, and Message-Oriented-Middleware to name a few. (OAGI provides white papers on their Web site, www.openapplications.org, that describe using OAGIS with several of these frameworks.)

In this article, we'll look at the Web services standards and how to use OAGIS with Web services.

Web Services

"Web services" is a glamorous term for some very old and established ideas. Web services is actually a stack of standards that complement each other. These standards fall into one of four layers; Table 1 shows the standards typically associated with Web services and identifies the layer in which each belongs.

It's generally agreed that the standards shown in Table 1 are the base Web services standards. There are also other protocol standards that help make Web services secure and provide quality of service and routing, among other things. These additional standards aren't listed here because they differ depending upon the Web services camp. There are other resources that identify the standards of each side--it's always interesting...

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