There are plenty of jokes regarding the world of standards development, from "Standards are like sausages - you're better off not knowing how they were created" to the old-time paradox: "The good thing about standards is that there are so many to choose from."

As a person who spends a considerable amount of time trying to keep track of the e-business technology landscape, I can appreciate the pain and frustration of anyone trying to make sense of the dozens of "standards" that are being developed by different organizations.

Useful Reference Model
While I can't promise to completely untangle the mess out there, over the last three months I've started to use a reference model that I've found to be a useful tool to navigate the maze of e-business standards. Published by the Business Internet Consortium (BIC: www.businessinternetconsortium.org), the model was developed under the leadership of Dr. Jackson. He of Intel. While not - yet - perfect and only in first revision, it is, in my view, a very prom-ising approach, and I've already used it successfully in my own presentations. The very positive feedback I've received prompts me to use this forum to introduce it to a broader group of people.

Since I'm not representing BIC (so if you don't like my explanations, blame me, not them), I'll also weave in my own thoughts and will try to associate some of the current e-business-related OASIS activities with the respective layers (this isn't an official OASIS view, by the way; it's just my own ramblings). I choose OASIS, in particular, because as a long-time fan and board member, I'm probably as familiar as anyone with its current initiatives.

Underlying Philosophy
The basic principles underlying the design of the BIC Reference Model - that's the name I use for it - are open standards and a layered approach.

I use open standards simply because the model includes only standards where a group of experts worked together to collaboratively come up with a solution for a problem, and where a potentially unlimited number of companies, countries, and/or individuals could exercise influence and vote on matters and the final release of the intellectual newborn. This approach hopefully avoids proprietary vendor-specific specifications. We'll leave aside the fact that in reality standards development is a fantastic mix of full-contact combat sports and UN Security Council-style political games and charades.

I have a layered approach because ultimately we want to end up with a model where we have clearly defined layers that are functionally well specified, with a lower layer forming a solid foundation for an upper layer. The ISO/OSI networking model would, for example, be an excellent example of such an approach.

While I can see why this approach is necessary, one shouldn't forget that it can only work in practice if all the participants agree on what the layers and their defined interfaces look like. Having said that, it's still my hope that over time we may see some convergence fostered by discussions around this model. Certainly one thing the model achieves is that one is able to put into broad conceptual "buckets" many of the initiatives currently under way. Given that the model is a conceptual one, this is just fine.

On a high level there are three layers (and the BIC makes reference to Gartner here): the lowest layer provides the base-level communications and integration infrastructure; the middle layer provides the syntaxes and schemata to define business objects and business processes; and finally the top layer houses the actual business messages and processes.

Base-Level Layers
Backend Integration
Most (if not all) e-business architectures will require us to provide connectivity to the back-end systems that host our mission-and business-critical data. I personally would see the J2EE Java Connector Architecture (JCA) as an important emerging standard. Also good old JDBC and ODBC might fit into this layer.

Service-Oriented Architecture
Here we have all the tools and systems that allow us to build e-business systems, including both Java 2 Enterprise Edition (J2EE) and Microsoft's .NET architecture. In this layer we find all the components that help us write the code that allows us to connect to our back-end systems but also the business logic of the e-business software itself.

Network Transport
Network transport is, not surprisingly, one of the best-understood layers. In this section we can find the likes of HTTP, FTP and SMTP. This layer really provides the foundation upon which we move around our business data and objects.

Syntax and Schemata
Core XML Standards
The core XML standards are what the W3C has been focusing on for the last few years. Here we can include XML, XSL, and many other of the X<insert-name-here/> specifications. From an OASIS perspective, this layer includes the interesting RELAX NG initiative that just finalized its approach to developing lightweight XML schemata. Other relevant efforts at OASIS include an XML version for the entity resolution mechanism developed originally for SGML, as well as the topic map-related initiative, "Topic Maps - Published Subjects."

Messaging
In the messaging layer are the standards that help us to define the structures of both the envelopes, as well as the actual contents of our business objects. One example in the spotlight right now is the Simple Object Access Protocol (SOAP). We can also mention here the OASIS TRP (Transport Routing Protocol) specification, which uses SOAP at the core but adds more "business strength" messaging qualities on top of it. SOAP and OASIS TRP are a great example of how within one and the same layer we might find initiatives that actually address a similar problem-space but are very different in their approach.

Service Description Languages
A lot of attention is currently being given to this layer (it's even one of the core subjects of an entire magazine - Web Services Journal!). Here BIC puts initiatives such as WSDL (Web Services Description Language), but a more recent initiative worth mentioning, one that was started after the model was published, is the Web Services Component Model (WSCM), a new OASIS Technical Committee.

Repository
Repositories can provide a very diverse set of functionalities, such as the storage of business object definitions and business processes, as well as data-dictionaries. Many repository initiatives have emerged over the last years. Examples are the RosettaNet business and technical dictionaries as well as the OASIS Registry and Repository specifications.

Directory/Registry Services
Registries and repositories are often combined, as in the case of the OASIS Registry and Repository work. While the repository stores actual objects, the registry provides the management interfaces and protocols to register and discover the entries of a repository. Another well-known example is UDDI (Universal Description Discovery and Integration). Also underway is the OASIS DSML (Directory Services Markup Language), which provides an XML-based interface to LDAP.

Business Content Format Definition
The specifications in this layer enable the actual definition of all aspects of our business objects. This layer provides the basic building block for business messages. Examples listed by the BIC include RosettaNet Technical Dictionary Structure, RosettaNet Business Dictionary Structure, RosettaNet PIP Service Content, OAGI Business Object Document, as well as ebXML Core Components.

Business Conceptual Model
Universal Business Content
This specifies business terminology and accepted values that may be universally used in business messages that support a broad range of industries, business models and locales; it's the vocabulary used to construct the business content of a message. Examples are RosettaNet Business Dictionary, OAGIS, ebXML Core Components, and many others.

Jon Bosak, former chair of the W3C XML Working Group, is spearheading UBL (Universal Business Language) with the objective of developing an XML business library under the OASIS umbrella. There are two "religions" on how one should define business objects and business processes. One is bottom-up - i.e., construct the individual components based on their specific requirements - and the other is top-down, following a modeling approach such as the Unified Modeling Language. Ultimately there are ways to combine them, but if you want to see a good catfight between experts, then just bring up this subject. (But don't quote meS)

OASIS examples here include OASIS CIQ (Customer Information Quality) working on a global scheme for specifying address information and the OASIS Provisioning Services Technical Commit-tee. Finally, there's OASIS DocBook, a schema for documenting software and hardware (and incidentally the first OASIS specification ever to be the subject of a full-length book - published by O'Reilly).

Specialized Business Content
In many ways you can't separate this layer clearly from the "universal" business content layer. Certainly, the model is correct in assuming that there will be vocabularies used only in a specific industry or context, but specific approaches often contain more universal components that are embedded into and strongly tied to these specialized components, and thus can't be separated out.

Business Content Instance
Finally, we have the actual business objects and messages themselves. Many still hope that someday we'll be able to build our business content instances from the building blocks found in universal and specialized vocabularies.

Process Descriptions
As with business objects, we have a set of three layers containing specifications regarding the descriptions of business processes. Specifications for Process Description Languages are plentiful and include approaches such as UML, XLANG, ebXML BP, BPML, and the Web Services Flow Language (WSFL). The Universal Business Process layer and the specialized Business Process layer contain - just like their counterparts on the business object side - the more generic and the more specialized business process building blocks respectively. In the actual Business Process Instance layer we can finally find the final business process descriptions that define the sequence of interactions between one or more business partners.

An example of an OASIS effort in the process description layer is the OASIS BTP (Business Transactions Protocol) - which develops specifications to describe distributed and long-lasting business transactions.

Vertical Layers
TPAs, or Trading Partner Agreements, are created when two or more parties agree on all aspects of their e-business communications - including protocols, message schemas, and business processes. In the future, a business will publish its trading partner profile by making explicit its preferences and capabilities, and autonomous agents will then be able to use negotiation mechanisms to create trading partner agreements between these parties. To give but two examples, we've already seen such ideas in the shape of UDDI and its t-Models as well as, in a more complete and complex form, in ebXML.

Security
Security is a layer that crosses all the vertical buckets discussed so far. Digital certificates and XML Signature are mentioned by BIC, but I would include here the OASIS XAML (Access Control Markup Language), which is concerned with expressing policies for information access over the Internet. I'd also include the very important OASIS SAML (Security Assertions Markup Language) - addressing, among other things, the Internet-wide Single-Sign-On problem.

Management
This layer is largely undiscovered. From a B2B and Web services perspective, while we do have tools based on standards such as SNMP (Simple Network Management Protocol), a lot of research has to be done here and many opportunities exist in this space for new startup companies.

Try the Model Out
While the model I present here definitely won't cure the common cold, you may want to try it out by trying, when you next hear about a new specification, to find the "bucket" you think it belongs to. A more distant hope on my part is that this model may serve as a guide to help all standards organizations to make a better job of determining how and where they and their respective initiatives fit in - and to figure out how we can achieve what we're all looking for...convergence.

Author Bio
Norbert Mikula has more than 10 years of experience in building and delivering Internet and e-business technologies. He serves as vice-chairman of the board of directors of OASIS and is industry editor of Web Services Journal. Norbert is recognized internationally as an expert in Internet and e-business technologies and speaks regularly at industry events. norbert@sys-con.com