Matthew Gertner

Subscribe to Matthew Gertner: eMailAlertsEmail Alerts
Get Matthew Gertner: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

UBL and Web Services

UBL and Web Services

Web services, the latest new new thing in computing, have attracted the massive hype and attention traditionally bestowed on the holder of this title. The high level of interest, although perhaps excessive, is understandable considering what Web services are meant to deliver: nothing less than immediate and automatic integration of disparate IT systems, eliminating the need for drawn-out custom integration efforts involving huge dollops of expensive consulting.

The flood of coverage that Web services has attracted might not be indicative of much, other than the fact that IT journalists haven't had much else to write about lately. Certainly some have started (yet again) to catch on to the fact that if something seems too good to be true, it probably is. Like the graphical user interface, the Internet, Java, and many other technologies, Web services may have a profound, even revolutionary effect on computing. But like these other technologies, Web services will require much work over years, not months, for this potential to be realized.

Among the most significant questions still facing Web services are:

  • Who is responsible for turning preliminary Web service specifications into real standards?
  • How are Web services chained together to form complete applications?
  • How are the semantics of Web service interfaces codified in a way that lets an application access an unknown Web service?
The answers to these questions are slowly becoming clearer. The recently formed Web Services Interoperability Organization (WS-I), which brings together Microsoft, IBM, Oracle, SAP, Intel, HP, and other high-tech leaders, is the most plausible answer yet to the question of who will standardize the hodgepodge of existing Web service-related specs. Recently the World Wide Web Consortium also reaffirmed its commitment to aggressive pursuit of work on Web services standards. And early business process languages like IBM's Web Services Flow Language and BPMI.org's Business Process Modeling Language are increasingly addressing the problem of assembling Web services into applications.

The Semantic Gap
In this article we examine the final question, that of standardizing Web service semantics.

The challenge of representing all but the most trivial Web service semantics in a machine-readable way was well exposed last fall in an article by Clay Shirky. Existing Web service standards, specifically SOAP, WSDL, and UDDI, provide little more than a way for applications to invoke a Web service once they already know what its interface looks like. This is all very well for Web services whose purpose is sufficiently transparent (Shirky uses the example of a Web service that translates centimeters into inches), but it's exactly these services that are the least interesting. After all, we're talking about revolutionizing computing.

Far more significant are Web services that perform an important business function and can be linked automatically to a broader process. Imagine, for example, Web services that deliver catalog information as part of a procurement process, synchronize delivery schedules as part of a materials management solution, or offer financial services for credit, factoring, or payment. This is where the rubber of Web services hits the e-business road: when I can develop my whole business application without worrying about the issue of payment, and then plug in any one of a number of competing payment services at the last minute, or even let the end user decide at runtime which one he or she wants to use.

So far so good, but this is actually a massive effort. It's not impossible to imagine someone coming up with standard definitions of catalogs, orders, advance shipment notices, bills of lading, invoices, and payment requests. But any survivor from the various Electronic Data Interchange (EDI) standards efforts will tell you that it's a daunting technical task to define data formats that come even close to meeting the requirements of a broad range of diverse enterprises, and perhaps an even more daunting political task to get companies to adopt them.

Building a Better Business Vocabulary
Nevertheless, a standard vocabulary for e-business is an essential piece of the Web services puzzle. To the benefit of anyone brave enough to undertake this task, there is a large body of existing work to draw upon. This ranges from business vocabularies predating XML, such as ANSI X.12 and UN/EDIFACT, through horizontal business libraries like Commerce One's xCBL and Ariba's cXML, to vertical business libraries for specific industries, such as RosettaNet for high tech and CIDX for chemicals. Finally, some pioneering work on creating business libraries that can be adapted automatically to different business requirements (or "contexts") has been performed as part of ebXML, a joint effort between OASIS and UN/CEFACT.

How then to turn this alphabet soup into a single, coherent, and widely accepted business vocabulary? By far the most comprehensive effort was launched last year under the name Universal Business Language. Structured first as an independent group, UBL was formally accepted as an OASIS Technical Committee last October. UBL brings to the table a number of strengths, including experienced and proven leadership, broad industry and vendor support, and a solid technical foundation.

UBL takes as its starting point xCBL, widely accepted as one of the most comprehensive XML-based business libraries. UBL's Library Content subcommittee has been entrusted with the task of harmonizing xCBL with the fruits of EDI's Joint Core Components initative and with other business libraries, including vocabularies for industry verticals. Official liaisons have been appointed to UBL from several vertical standards organizations to ensure that the basic UBL business documents will work across multiple industries.

At the same time, UBL's technical subcommittees are specifying the nuts and bolts that will underpin the document library. These include tricky but important decisions about which schema features to use and how to name tags in a clear, concise, and consistent manner. The ebXML context extension methodology is also being adopted and improved in order to produce an automated procedure for creating extended schemas (e.g., for a specific industry, region, or company) that interoperate with the base schemas in the document library.

A first version of the UBL document library is scheduled to be completed 12 months into the effort (a draft of the first schema, for Purchase Order, has recently been released). The context extension methodology will be released approximately one year later - sooner if it turns out that this work can be performed in parallel with the creation of the document library.

Mission Impossible
Some might claim that the task facing UBL is not so much difficult as it is impossible. The real-world requirements for a business vocabulary are such that it isn't feasible to create a single document library that meets the need of every trading party. This is because different companies use different document formats depending on their industry, region, internal conventions, and a range of other factors. Since doing business with companies outside your industry and region is more the rule than the exception, this calls into question the whole premise of a business library that is truly universal.

Various approaches have been taken in previous efforts to address this issue. EDI formats tend to be highly customized for specific pairs of trading partners. Unfortunately, this manual customization is prohibitively expensive for all but the largest enterprises, explaining why EDI adoption has been restricted mainly to big companies with big IT budgets. As for xCBL, it took a slightly different tack, defining schemas that are maximalistic, with a host of optional fields augmenting the core set of required fields. By using object-oriented features, new schemas can be derived that redefine the appropriate optional elements as required and add any new elements that weren't originally anticipated.

The xCBL approach has a lot of advantages. On the one hand, it maximizes interoperability by using so many optional fields. If you and I require a warehouse party in our purchase orders, chances are we'll both use the one defined in xCBL, so my IT systems will understand the data I receive from you without having to be modified. At the same time, the use of an object-oriented extension means that I can create an extended schema with information no one could have anticipated without breaking the ability of processing engines to understand the standard information in the document. (That's the principle of polymorphism, for you gearheads out there.)

But at the end of the day, xCBL and similar business libraries still bear the genes of their EDI ancestors. Whizzy XML features make it a lot easier (and cheaper) to customize newer libraries like xCBL than EDI, but they still have to be customized through a painstaking manual process. This prevents the creation of cheap, standardized implementations for small businesses and, as with EDI, rules out the possibility of dynamic e-commerce. The latter point is particularly important since much of the Web service hype is premised on the idea that new services can be discovered and invoked without constantly calling in the IT department.

UBL is building on the pioneering work undertaken as part of ebXML to create a "context extension methodology" that accepts the need for customization but turns it into an automated process. This is done by defining rules that can be applied to a base schema to create a new schema automatically. For example, a rule might specify that a required "State" field be added to addresses in the United States.

It's likely that in the short term the context extension methodology will be used mainly at design time to lower the cost and technical expertise needed to create customized schemas. By applying both my context rules and those of my trading partner, I can instantly generate document formats that fill both of our requirements. In the longer term context rules will become a standard part of the trading agreements exchanged at the beginning of trading interactions, and mutually acceptable document formats will be generated in real time. Runtime binding of freshly discovered Web services will then become a real possibility.

Web Services + UBL = Interoperability
By defining what in essence are the basic interfaces for a complete set of business processes, the UBL effort will have huge implications for Web services. Consider, for example, a Web service for online payment. The core functionality of this service is to receive invoices, create payment request documents based on these invoices, and settle the payment through a bank payment gateway.

The defining principle of Web services is that a service of this type should be able to interact in a plug-and-play manner with other Web services, and that it should be replaceable by any other Web service targeting the same functionality. Without UBL this goal isn't achievable because the exact formats of the invoice and payment documents would have to be determined by the implementer of the system, so they wouldn't be interoperable with Web services from other vendors.

UBL solves this problem by providing standard formats for the invoice and payment documents. Any Web service that produces an invoice (a billing service, for example) can thus interface with the payment service. By using the context methodology, subtle differences in invoice and payment formats can be handled without invalidating the overall approach. In addition, the payment service can be swapped for another one, perhaps with some advantages, such as better terms, higher availability, or interfaces to more banks.

*  *  *

The technical framework being designed for Web services is extremely promising. The combination of a simple but coherent vision for discovering and invoking third-party services, strong industry support from virtually every major technology vendor, and avid attention from the market makes the eventual realization of the Web services vision a strong probability, if not a virtual certainty. But a level-headed assessment of the gaps that still exist, and the steps necessary to resolve them, is essential if disillusionment is to be avoided. The same hype that has made Web services the industry darling could easily turn against them, calling the whole enterprise into question.

One of the major challenges still facing Web services is the creation of a standard vocabulary to convey business semantics. This issue is not even on the table in any of the Web service-specific standardization efforts under way in the W3C or the newly formed WS-I. Fortunately, the UBL work initiated independently as an outgrowth of ebXML is perfectly placed to address Web services' dependence on universally accepted semantics, helping to allay one of the main concerns of Web service skeptics.

SIDEBAR
UBL Subcommittees

Faced with a challenging job, the UBL Technical Committee has divided its organizational, semantic, and design work among a set of subcommittees working in parallel. Here are brief descriptions of the most interesting ones. For further details, see the UBL Web site at www.oasis-open.org/committees/ubl/.

Context Drivers SC
Part of the context methodology work is determining what are the "drivers" of context, that is, the axes along which context can be plotted. To the most obvious drivers, especially industry and region, have been added a set of additional drivers that can influence document formats: business process, product classification, official constraints, business process role, supporting role, and system capabilities. The job of this SC is to take this list, developed as part of ebXML, and determine whether any further drivers are needed.

UBL Context Methodology SC
This SC is tasked with the finalization of the context extension methodology published as a technical report after the first phase of ebXML. As a first step, the SC has gathered a list of use cases, real-world examples in which a given context requires modification of the standard document formats. These outline the specifics of everything from Brazilian invoice headers to documentation for shipping goods by sea. These use cases will be used to test and, where necessary, refine the ebXML methodology.

UBL Liaison SC
Success rarely comes in a vacuum, and this is doubly so of international standards efforts. UBL can only hope to reach its lofty goals by standing on the shoulders of the giants that came before it, including decades of work on EDI and the many more recent industry-specific groups. This SC is made up of UBL representatives who are charged officially with coordinating with other organizations involved in related work.

UBL Library Content SC
The central goal of UBL is to create a standard set of document schemas that can be used as the basis for e-commerce. The Library Content SC carries the responsibility for the actual design of the document formats. Its task has begun with a thorough review of xCBL, which has been retained as the starting point for the business library. Also essential to the work of this SC is the harmonization of UBL with the work of EDI's Joint Core Components and a whole range of industry-specific standardization efforts. The LC SC has made an early review copy of the UBL schema for Purchase Order available on the UBL Web site.

UBL Marketing SC
It's a well-worn cliché that technical excellence takes a backseat to marketing in achieving adoption in the IT industry. UBL has thus set up this SC to ensure that the goals and benefits of UBL are clearly communicated to outside parties. Responsibilities include drafting press releases and organizing participation in conferences and trade shows, as well as such niceties as chartering the design of a UBL logo.

UBL Naming and Design Rules SC
One of the hardest parts of creating a standard business library is ensuring consistent naming and structure of tags, types, and other constructs across all the document formats. This SC is finalizing a set of recommendations, to be used by the Library Content SC, specifying such things as when to use attributes rather than elements and how the name of a tag should relate to its type. These recommendations will also be made publicly available so that third parties can create their own extensions to UBL while conforming to its overall style. Snapshots of position papers on basic XML design questions are available on the UBL Web site.

UBL Tools and Techniques SC
Document design is difficult, and collaborative document design even more so. There is a wealth of schema editors, context management systems, forms generators, and other tools that can ease this task. This SC is charged with evaluating these tools and specifying a standard toolset to be used by the Library Content SC and recommended to third-party document designers.

More Stories By Matthew Gertner

Matthew Gertner is cofounder and chief executive officer of Schemantix, a vendor of business services for enterprises and e-marketplaces. Prior to joining Schemantix, he headed the development of Internet and XML-related products for POET Software, a leading provider of data management and supplier-enablement solutions. The author of numerous articles and a frequent speaker at industry events, Matt chairs the Context Methodology Subcommittee of OASIS’s UBL Technical Committee.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.