Business Collaboration Framework: Interoperability on Top of Web Services

Klaus-Dieter Naujok, Global e-Business Advisory Council
Christian Huemer and Birgit Hofreiter, University of Vienna

Abstract-- Web Service standards ensure interoperability on the technology layer of e-business applications. They do not guarantee interoperability on the business layer. We present UN/CEFACT's Business Collaboration Framework (BCF) which provides businesses with a solution to define their external information interchanges and related business activities (business collaborations) independent of the underlying implementation and infrastructure technology. Moreover, we define which Web Service standards might be used to implement the BCF when moving towards the technology layer.

Index Terms-- Business Processes, B2B, ebXML, UML, Web Services

XML and e-Business is synonymous with Web Services. Therefore, one must look at Web Services to determine if it has what it takes to provide the full solution for e-Business. Many feel that Web Services have the potential to transform e-Business into a plug-and-play affair. Not only will Web Services simplify how businesses will interconnect, they will also enable businesses to find each other. One reason for the increased interest in Web Services is the promise of interoperability, in the same way that Web pages can be accessed from anywhere on the Internet. However, complex standards are needed to achieve true interoperability, not only at the messaging and transport layer, but also at the business (application) layer. The success of Web Services will depend on how easily businesses will be able to engage interoperability at all levels.

There are many efforts in standardizing Web Services, but none of them provide the required features for e-Business transactions. Web Service standards only address the infrastructure side1. There is a need to provide standards for interoperability at the business layer. The United Nation's Centre for Trade Facilitation and Electronic Business (UN/CEFACT) is addressing this aspect of standardization with its "Business Collaboration Framework".

Lessons from History

The idea of exchanging business data by linking computer systems together so that data could be sent from one partner's system to the other was not invented by Web Services. It has existed for more than 25 years and has become known as Electronic Data Interchange (EDI). Whereas EDI was successfully implemented by 98% of the Fortune 1000, it failed to gain acceptance by the Small and Medium Enterprises (SMEs). The high start up costs of an EDI partnership prevent SMEs from participating in EDI. Many people accuse the complexity and the 'cryptic' syntax of traditional EDI standards, like UN/EDIFACT or X12 to be responsible.

Accordingly, XML seemed to be the solution to traditional EDI problems. However, it became clear that the most significant short-coming of EDI message types, or B2B document types in general, is independent of syntax. EDI message types were not implemented as published because of the overwhelming choice of data elements in any applicable EDI message. Implementers are forced to utilize industry implementation guides that limit the number of data elements to be used. Even that is not enough. Business partners further limit the choices by spending much time in negotiating the data elements they agree to use in their exchange. Usually about 3% of the data elements appearing in the standard are considered in the agreement between two partners. To make things worse, the set of data is different between any two trading partners. Further, if one of the trading partners exchanges with many others for the same business process, such as invoicing, that partner may be able to enforce its preferred way on others because of relative size and importance, but only to a certain extent.

In other words, implementing EDI is a time consuming affair that does not lend itself to automation and mass production of off-the-shelf software for small and medium sized customers. One might argue that the arguments presented above are based on traditional EDI standards. Usually, XML document standards trying to deliver a commonly accepted solution follow the same approach of building the superset of the data element requirements of all supporters. A corresponding comparison of UN/EDIFACT and xCBL is detailed in an article by Huemer2.

Looking for Alternatives

In order to reduce the cost so that the implementation becomes transparent, one would have to agree to a single data requirement for a particular document type. This would allow software vendors to create a B2B application that would have a large enough market to reduce the cost for small and medium sized companies to be able to afford. This will never happen. So what would it take for software companies to build software that is not tailored for each of the different EDI message implementations but will be able to adapt to the different data requirements for a particular customer and their trading partners?

Already in the late 1980's a special working group in ISO started to research the idea of exchanging electronic data amongst organizations without prior agreement. The resulting "Open-edi" reference model became an ISO standard3 in 1997. A key concept of Open-edi is to separate the "what" in the Business Operational View (BOV) from the "how" in the Functional Service View (FSV). The BOV addresses the aspects of the semantics of business data in business transactions and associated data interchanges, as well as the rules for business transactions which apply to the business needs. The FSV addresses the supporting services meeting the mechanistic needs of Open-edi. It focuses on the information technology aspects of functional capabilities, service interfaces, and protocols.

UN/CEFACT (or better its predecessor) picked up the idea of technology-neutral business models towards the analysis of next generation EDI standards. The group reported that the most promising technology addressing the shortcomings of EDI was that of Business Process and Information Modeling (BPIM). By utilizing BPIM, standards would not have the problem of ambiguity; instead they would describe the complete processes and their information requirements, including constraints, options in execution, exceptions, etc.

Of course, it was recognized that even with BPIM, the issue of businesses doing things differently would not go away, even if it was only in regard to external processes. It was envisioned that the next generation standards would be BPIMs for a particular business goal, such as "Catalog Ordering," that contained "all" the possible activities that could be part of that goal. In other words, the approved BPIM would be a super-model for a given business process. Since such models would have many ways of executing (paths through the model) each path would be identified as a scenario. Depending on their internal processes, one trading partner may be able to execute all the scenarios of a model, where another may only execute a certain number of them. For two trading partners to engage in the same business process, they must both be able to execute at least one scenario in common. In regard to the SMEs, it is envisioned that the software providers would create applications that implement BPIMs with their most popular scenarios.

The Techniques & Methodologies Working Group (TMWG) of UN/CEFACT evaluated different alternatives for BPIM. It recommended UML4 as the most appropriate modeling technique. It is the vision to use UML for BPIM in such a way that any industry group or standards body, including UN/CEFACT, can create models that identify every possible activity to achieve a specific business goal. In absence of a single modeling authority it is a prerequisite that all groups use a strict methodology to ensure interoperability. For this purpose TMWG develops UN/CEFACT's Modeling Methodology (UMM)5. The UMM is an incremental BPIM methodology that provides levels of specification granularity that are suitable for communicating the model to business practitioners, business application integrators and network application solution providers. Since the start of UMM, TMWG members such as SWIFT, TM Forum, EAN*UCC, and RosettaNet have not only participated in the work but also adopted it in part or expanded it.

The Business Collaboration Framework

The primary goal of the BCF is to capture the business knowledge that enables the development of low cost software components to help the small and medium size companies and emerging economies engage in e-Business practices. A commercial trading agreement is modeled as a business collaboration model, according to the UMM. By focusing on developing business process and information models in a technology-neutral manner, the BCF provides insurance against obsolescence by allowing recasting of the business scenarios into new information exchange technologies.

Fig. 1: Business Collaboration Framework

The Business Collaboration Framework architectural structure is comprised of a set of architectures, patterns and business semantics defined in accordance with certain business reference models and ontologies. This framework provides for the reification of process and information definition from one view or perspective to the next without the loss of semantic or computational integrity. The framework consists of 4 views, corresponding patterns, as well as a well-formed meta-model which defines the syntax and semantics for each view. Uniformity of notation and precision of semantics provide concise and unambiguous business process definitions.

Business Domain View

The Business Domain View (BDV) provides a framework for understanding business area and process interrelationships. A BDV is typically a domain specific business reference model that is used to categorize a business process to aid in business process identification, business process integration, and auto discovery. In the BDV business processes are discovered, not constructed. Hence any ontology is appropriate and no patterns apply for this step.

Business Requirements View

The Business Requirements View (BRV) provides a view of a collaborative business process ("business collaboration") as an elaboration of business scenarios, resources, business events, and constraints. It defines the semantics that people and businesses use to describe their collaborative units of work or activities. These activities represent the processes and resources used to achieve certain definable goals or objectives, the economics of a system. Resources, Events (indication of a process result) and Agents (participants) are the key elements of an economic ontology known as the REA enterprise ontology6. Currently, a subgroup of TMG is developing business collaboration patterns for e.g. negotiation, order-fulfillment-settlement, long term contract with periodic releases, to name just a few.

Business Transaction View

The Business Transaction View (BTV) is the view of a business process that captures the semantics of business information and business transactions amongst business partners as they perform business activities. The reference ontology for the BTV comes from "The Commercial use of Electronic Data Interchange, Section of Business Law American Bar Association, A report and model trading partner agreement" and "Part 2 Uniform Rules of Conduct for Interchange of Trade Data by Teletransmission (UNCID), Chapter 2 - Text of the Uniform Rules of Conduct". Accordingly, the patterns defined from this ontology work as equally well within a private or corporate environment as they do in a public or commercial trade environment.

According to the ontology, six patterns are defined for the business transactions: Commercial Transaction, Query/Response, Request/Response, Request/Confirm, Information Distribution and Notification. These business transaction activity patterns comprehensively cover all known legally binding collaborations at the level of request/response and one-way interaction between two business applications. These patterns are successfully implemented in the RosettaNet Implementation Framework7. The specific business transaction activity patterns used in a business collaboration are based on extracting information from business domain experts via answers to questions asked according to a standard script in the BDV and BRV.

Business Service View

The Business Service View (BSV) is the view of a business process that specifies the network component services and agents and the information exchanged as interactions which are necessary to execute and validate a business process. The reference ontology for the BSV comes from the "UN/ECE Recommendation No. 26, The Commercial Use of Interchange Agreements for Electronic Data Interchange". This is the same recommendation that forms the basis of traditional EDI, like UN/EDIFACT and X12.

A total of 24 service interaction patterns have been identified. They specify interaction sequences between two application systems, i.e., protocols of message exchanges, according to the type of business transaction, type of role, security and timing parameters. The specific service interaction pattern follows the type of business transaction and is derived from information gathered in the requirements workflow.

A Business Collaboration Example

A business environment may be large and complex. Understanding such a business environment begins with gathering information provided by business experts. Business experts provide a categorization and decomposition of the business environment into business areas, process areas, and business processes. Since the business environment includes identification of requirements placed by one-partner activities on multi-partner activities, the interaction of one-partner activities with multi-partner activities needs to be taken into account as well. All of this takes place in the language of the business environment experts and stakeholders. In our simple example, which is ordering from a punch out catalog, potential sellers and buyers will describe their needs.

By harmonizing the views of the stakeholders we identify possible business collaborations in the considered domain. A business collaboration covers a set of activities among partners to accomplish a shared business goal and terminates upon recognition of an agreed state. Business collaboration activities are specified by a process analyst as use cases, use case descriptions and business object flow graphs. The use case descriptions capture goals, requirements and constraints of the collaboration. These are then expressed in formal representations that can be understood and confirmed by business domain experts. A business collaboration is recursively broken down in composite business collaborations, which are analyzed again. On the lowest level the collaboration is realized by a request/response pair or a one-way exchange. This is the level of a business transaction. The use cases involved in our example are presented in Fig. 2. Due to space limitations we are not able to show the use case descriptions.

Fig. 2: Use Cases of the Business Collaboration

Business requirements are expressed with reference to business information structures that are affected by a business collaboration activity, e.g., order information, customer information. Preconditions and post conditions of the atomic business processes and of the business collaboration itself are best expressed by states of affected business entities, e.g., customer information - pending and customer information - accepted. In support of this, business entities must be understood as to the states in which they may exist and the permitted state transitions in one or more life cycles. Business requirements are also expressed in terms of events that trigger the state transitions of business entities and of the business collaboration, e.g., receipt of a Positive Registration Response triggers the transition of Customer Information from tendered to assigned. The business entity life cycle for the customer information (as part of the register customer use case) is depicted in Fig. 3.

Fig. 3: Enitity Lifecycle for Customer Information

Having gathered all necessary information, the business process analyst is ready to direct the modeling of the business collaboration. The first artifact is the business collaboration protocol, i.e., an activity graph specifying the choreography of the business collaboration. It defines possible sequences of business transaction activities based on identified business states. Fig. 4 shows the business collaboration protocol for the punch out catalog example.

Fig. 4: Business Collaboration Protocol

The next step of the BTV details each business transaction activity by its own activity graph. The business transaction follows one out of the six business transaction patterns. Furthermore, all the messaging and security parameters for the activities and the business information exchanged are defined. Fig. 5 defines the register customer transaction of our example.

Fig. 5: Business Transaction Register Customer

The performance of a business transaction results in the exchange of business information. Business information that is exchanged must contain information needed to identify the business entities affected by a business transaction. In addition, business information structures contain information content that satisfies the requirements for exchange of information required to be shared in the business collaboration. Shared information is generally the attributes of affected business objects (BOs) that must be shared in order to align the partners' views of those BOs. A resource for defining new BOs would be core components (CC). In Fig. 6 we present the structure of the business information for the registration request. It includes the business entity customer information which is built by the BOs party, address, and account.

Fig. 6: Business Information Registration Request

The fundamental principle for the design workflow is to describe the business collaborations between network components. The business service workflow does not add any new information. Accordingly, the business service view artifacts can be automatically created from the information gained in the previous workflows. For each role appearing in any business transaction a network component is created. Each business transaction is mapped to a service transaction defining the exchanges between the components. The exchanges are either the business document exchanges or the business signals sent as acknowledgment (or failure notices). Fig. 7 depicts the register customer service transaction that follows a service-service pattern. Since the corresponding business transaction does not require any acknowledgments, the resulting sequence diagram is quite simple and only includes document exchanges. A network component for a given role has to support all the operations defined in any business transaction. To denote this fact we list all assigned methods in the service components of Fig. 7.

Fig. 7: Service Transaction for Registration Request

Towards Web Services

The BCF is independent of the interchange data syntax, transport infrastructure, and server software. By focusing on developing business process and information models in a technology-neutral manner, the BCF provides insurance against obsolescence by allowing recasting of the business scenarios into new information exchange technologies. This way, the same models can be used to move the information using UN/EDIFACT or X12 messages, distributed object technology or whatever new technology may surface, such as today's Web Services (see Fig. 8).

The basic idea is that the business community, which does not speak in angle brackets, defines the business semantics using the BCF. The IT community is responsible for transforming the business semantics into machine-processable solutions. Today's choice would clearly be Web Services. So how will the BCF and Web Services work together?

BCF-compliant models will be registered and stored in a global repository. Users will register their particular path(s) through the model scenario(s) so that others who want to engage with them can determine if they share at least one scenario. However, the application programming interface (API) and the meta-model for the repository are not defined by the BCF but by the underlying implementation technology. Therefore, UDDI as well as ebXML registries are candidates to be used. References from the UDDI green pages to a BCF model will support the business partner discovery process.

Fig. 8: Technology Buffer

A BCF model defines all the external interfaces that are needed for a given business collaboration. In our example these external interfaces are manifested by the operations assigned to the service components in Fig. 7. External Web Services interfaces are described by WSDL documents. Accordingly, operations of BCF service components will be expressed in the Service Interface Description section of WSDL. This will be done automatically.

WSDL is sufficient to describe atomic business information exchanges. However, a business collaboration is a complex choreography of multiple business information exchanges. At the moment we see a lot of competing efforts in Web Services to describe the choreography of Web Services: BPEL, WSCL, WSCI, ebXML BPSS, WSFL, and XLANG. Owing to the variety of languages it is obvious that one that is technology-neutral is of great advantage. In the BCF the choreography of business collaborations is defined by the business collaboration protocol as well as by the business/service transactions. Thus these artifacts have to be transformed into the choreography language of choice. Since not all of these languages are capable of all business aspects defined in the BCF this might result in a loss of information.

BCF models precisely define which role participates in which activities during the business collaboration and, thus which interfaces that role has to offer. This means a party performing one or more roles in a business collaboration must implement all of the the roles' Web Services. This fact might be published in the party's green pages of UDDI, in the party's ebXML Collaboration Protocol Profile (CPP), or in another profiling mechanism that will arise in Web Services.

Prior to message exchanges parties set up an agreement to do business electronically. Languages like ebXML Collaboration Protocol Agreement (CPA) or its predecessor IBM's Trading Partner Agreement Markup Language (tpaML) consider the infrastructure level agreements. Additionally, legally enforceable business agreements are needed. Commonly agreed BCF models might serve as a basis for these agreements. UN/CEFACT's Unified Business Agreements and Contracts Project is conducting research in this area.

During the execution of business collaborations SOAP messages are exchanged. Business collaborations usually have complex requirements for QoS features like security, reliability and exception handling. Hence, business collaborations require specific SOAP header entries to carry the business context1. In an optimal case the business context of BCF models is represented in the headers of the SOAP dialect used. Candidate dialects are ebXML Messaging, BizTalk Messaging, or possibly a fully BCF-compliant SOAP.

Conclusion

Technology for e-Business changes more frequently than the basic B2B processes. Instead of developing new business solutions every time the technology is changing, we need a technology buffer that separates the "what" (business processes and information models") from the "how" (IT infrastructure). The Business Collaboration Framework (BCF) offers a solution to specify all business aspects of e-Business partnerships. It sets all business semantics that must be expressed in Web Services standards to become machine-processable. The combination of BCF and Web Services standards will lead to the full potential of today's e-business. The BCF provides the missing link to guarantee interoperability on the business layer for Web Services. Furthermore, it will be ready to serve the next technology that comes up after Web Services.

Fig. 9: BCF and Web Services

References

  1. S. Patil and E. Newcomer, "ebXML and Web Services," IEEE Internet Computing, Vol. 7, No. 3, May/June 2003, pp. 74 - 82
  2. C. Huemer, "<<DIR>>-XML2 - unambiguous access to XML-based business documents in B2B e-commerce," Proceedings of the 3rd ACM conference on Electronic Commerce, Tampa (FL), October 2001
  3. International Organization for Standardization, "Open-edi Reference Model," ISO Std. 14662, Geneva, 1997.
  4. Object Management Group, "Unified Modeling Language (UML)," http://www.omg.org/technology/documents/formal/uml.htm
  5. UN/CEFACT TMG, "UN/CEFACT's Modeling Methodology (UMM)," http://webster.disa.org/cefact-groups/tmg/doc_bpwg.html
  6. W.E. McCarthy, REA Enterprise Ontology Source Page, http://www.msu.edu/user/mccarth4/rea-ontology/
  7. RosettaNet, "RosettaNet Implementation Framework"

Klaus-Dieter Naujok is Founder & Principal Advisor of Global e-Business Advisory Council, has been a successful CSO, CTO, EVP and Director of Standards and Technology in the computer software industry. He was the Chairman of ebXML initiative. Currently, Mr. Naujok is the Chairman of UN/CEFACT's Techniques & Methodologies Group (TMG), responsible for the Business Collaboration Framework.

Christian Huemer is Associate Professor at the Institute for Computer Science and Business Informatics at the University of Vienna, Austria. There, he serves as director of studies for the curriculum in business informatics. Currently, Christian Huemer is Vice Chair of UN/CEFACT's Techniques and Methodologies Group (TMG). He received a doctors degree from the University of Vienna in 1997. Christian Huemer is a member of IEEE Computer Society and ACM.

Birgit Hofreiter received a Master degree in Business Informatics from the Vienna University of Technology, Austria in 2000. Since then she is employed as a research assistant at the Institute for Computer Science and Business Informatics at the University of Vienna. Currently, she conducts her Ph.D. thesis on the topics of e-Business and the Semantic Web.