Practice
Artificial Intelligence and Machine Learning The semantic e-business vision

Toward an Ontology-Driven Architectural Framework For B2B

Moving online business processes and practices from a static collection of data to a distributed multiprocessing framework of interoperability.
Posted
  1. Introduction
  2. A Brief Overview of Existing Frameworks
  3. B2BOOM: An Example of a B2B Ontology-driven Framework
  4. Conclusion
  5. References
  6. Authors
  7. Figures

E-commerce (EC) affects almost every aspect of how business is conducted. Information gathering, shopping, trading, brokering, banking, accounting, negotiating, manufacturing, scheduling, marketing, supply, servicing, and retailing all experience benefits from this emerging field. Business-to-business (B2B) may be defined as EC between two or more business partners via the third wave of EC where the interactions among a very wide range of organizations should be handled seamlessly and dynamically without problems in ad hoc integrations [6].

Let us suppose that two business entities bek and ben are going to join an EC environment and establish some B2B relationship (see Figure 1). They will find a heterogeneous environment where much dissimilarity among business partners exists by default. Various applications may use different descriptions of the same products that may also be represented by different data structures. In addition, the upper-layer protocols for data exchange are likely heterogeneous rather than homogenous. Moreover, the business logic of each business entity may differ. At a glance, business entities may be viewed as black boxes with respect to each other, each having their own strengths and weaknesses: that is, their ability to be autonomous, adaptable, and externally manageable simultaneously [7].

The business strategy of each be and the collaboration agreements between the business entities also influence how B2B processes are executed and when they are required. If they are involved in a long-term relationship, their business interactions are a priori defined, they are tightly coupled and probably less heterogeneous than in the case where they are loosely coupled, that is, where business interactions occur on demand. In a fully B2B environment [6], the second scenario is more likely to occur.

In such a complex environment, two very important attributes of B2B systems must be carefully considered: openness and security. The security issues of B2B are discussed elsewhere [9]; in short, business entities should share the same confidence with respect to each other and have the confidence in the overall EC safety as well. The three widely recognized characteristics for computer applications openness are portability, scalability, and interoperability. (The issues of portability and scalability are not covered here).

In general, interoperability refers to the ability of two or more systems or components to exchange information and to use the information exchanged [5]. At least three levels of interoperability based on the required knowledge must be considered:

Communication interoperability relies on the infrastructure and standardized protocols where all the necessary data is precisely defined (for example, encapsulation, frames, checksum algorithms, among others). There is no machine knowledge required, but it may be deployed; for instance, using intelligent agents for network maintenance, to avoid bottlenecks or in order to provide a better quality of service, and so on.

Syntactic interoperability allows content exchange among multiple software components independent of their implementation languages, runtime environments and other technological differences.

Semantic interoperability is the knowledge-driven interoperability that provides business entities involved in a B2B process with the ability to overcome semantic conflicts arising from differences in implicit meanings, perspectives, and assumptions in the data, business processes, and so on, used in heterogeneous B2B environments [10].

Back to Top

A Brief Overview of Existing Frameworks

To bridge the problems with heterogeneity, it is common to define the appropriate middleware and put it into a generic template that provides the desired functionality, commonly known as a framework. Such middleware acts as a dynamic self-organized layer of a framework that provides uniformity between the lower layers of the framework (hardware, operating systems, and so on), that are different by default, and the middleware hides serious, natural discrepancies that exist among B2B applications.

It consists of several B2B-oriented standardized protocols that describe how B2B messages are exchanged, make necessary bindings to the transport protocols involved, define the security that should be provided, and provide many other functions [1]. If such middleware tends to reach full B2B interoperability it must cover both the content and semantics issues. At the content layer business entities should agree on data formats, data models and languages, and they should be able to bind their business messages to specific transport protocols either in advance (during the development) or dynamically (during the execution). One step forward is to support conversation between business processes, such as adding semantic interoperability where human interventions are no longer required or at least minimized.


Semantic interoperability in B2BOOM is the ability to share information at the application level, without knowing or understanding the terminology of other systems.


B2B frameworks may be classified by several criteria such as the basic technologies they deploy, how much intelligence they bring, whether they support the syntactic interoperability only, or whether they support semantic interoperability as well, whether they are fully open or proprietary, how secure they are, or the constraints in their usage. We may distinguish between Internet-based EDI frameworks, frameworks based on second-generation middleware components, XML-based architectures, workflow architectures, integrated solutions provided by major vendors, and Web Services; the accompanying table offers a brief overview. XML-based frameworks and Web services have been recent EC research topics for several reasons: they are both open. XML is a fundamental technology for data portability, Web Services are specially designed for EC, XML and Web Services may be concatenated to each other.

In the area of XML-based solutions, two frameworks are currently dominant—ebXML (www. ebxml.org) and RosettaNet (www. rosetanet.org)—because they can communicate at the business process layer [1] via collaboration protocol agreements and so-called Partner Interface Processes (PIPs), respectively. The concept of Web Services (www.w3.org/2002/ws) is based on the loosely coupled reusable open software components that can be brought together at the time of service invocation. Interactions at the business process layer have not been supported by Web Services. Despite several efforts to extend Web Services with new features such as composition, content mark-up, among others, full semantic interoperability is not provided [6].

Progress has been made by implementing mediators [12] and ontologies [3, 4] into an open B2B framework known as the Web Service Modeling Framework (WSMF; www.swsi.org/resources/wsmf-paper.pdf). This aims to provide an industry-scale framework for semantic Web Service discovery, execution, and composition. WSMF is centered on complementary principles: strong decoupling of the various components that realize a B2B application, and a strong mediation service that should allow full P2P communications between business entities.

WSMF defines four different main elements: ontologies, goal repositories, Web Services descriptions, and mediators. Ontologies provide a shared and common understanding of a domain and are used here to define the terminology employed by other elements of WSMF. Goal repositories describe the objectives that a client may have been asking for in a Web service. Mediators solve various P2P incompatibilities such as data formats, business logics, service invocation, and message exchange. Web Services descriptions allow for distinctions between internal and external processes, and also external complexity in a Web service. Web Service Modeling Ontology (WSMO) is the recent extension of this framework, providing ontological specifications for the core elements of Semantic Web services (www.wsmo.org).

Figure.

Back to Top

B2BOOM: An Example of a B2B Ontology-driven Framework

B2B Ontology-Oriented Middleware (B2BOOM) is our approach to building an interoperable open framework for EC. HTTP and SOAP are the main protocols on top of TCP/IP, which provide communication interoperability while XML brings syntactic interoperability to the framework. Full interoperability among B2B systems requires dealing with the meaning of data being used in business processes. A business process is defined as a set of one or more linked procedures or activities that collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships. Thus, this is the point where we should apply semantic interoperability.

Semantics refers to users’ interpretation of the computer representation of the world; that is, the way users relate a computer representation to the real world [8]. In order to achieve semantic interoperability systems must be able to exchange data in such a way the precise meaning of the data (the semantics) is readily accessible and the data itself can be translated by any system into a form it understands. If we consider metadata not only as a description of the schema definition in a data set, but also a description of the conceptualization of the reality, then representation of the semantics is a part of the metadata.

Semantic interoperability in B2BOOM is the ability to share information at the application level, without knowing or understanding the terminology of other systems. The basic architecture of B2BOOM is shown in Figure 2. Each B2B business entity contains a B2B application, a local ontology, and a corresponding database. For each data source there is a translator (or wrapper) that logically converts basic data objects to the common information model. The translator/wrapper at the destination be‘s application converts requests to the local application data model (SQL or API). The data source application may execute these requests. The next layer performs mediator functions, which include transformation of data and mapping between data models. In order to make this logical translation, the mediator converts queries to requests using the common model and top-level ontology.

Much research work recognizes mediators and the so-called global-as-view and local-as-view paradigms as useful approaches to identifying and solving semantic conflicts in heterogeneous environments. Examples include, but are not limited to, Information Manifold [2], Ginis Mediator [11], WSMF, WSMO, and CREAM [10]. Information mediators were originally developed for integrating information in databases [12]. Mediators are not just simple interfaces between applications and databases, rather they must include some knowledge that cannot exist in the data they work on. They have to aggregate underlying data depending on criteria dictated by the application layer. The process of understanding which domain contains the best information for answering a query is delegated to the automatic knowledge-based engines built into the mediators themselves. Mediator-based systems are constructed from a large number of relatively autonomous sources of data and services, communicating with each other over a standard protocol and enabling on-demand information integration.


Semantic interoperability appears to be an essential attribute for bridging the complexity of heterogeneous environments and may allow flexible mediation between business partners on a conceptual basis.


The B2BOOM solution to the problem of semantic heterogeneity is to formally specify the meaning of the terminology of each be using a local ontology and to define a translation between each be terminology (local ontology) and an intermediate terminology (in the top-level ontology). The B2BOOM formal ontology consists of definitions of terms, and it includes concepts with associated attributes, relationships, and constraints defined with respect to the concepts and entities that are instances of concepts. In our system architecture it is assumed the ontology is shared, and there exist commitments by the clients about the data to be shared.

It is necessary to choose a formal language to describe an ontology. Recent efforts include OIL (www.ontoknowledge.org/oil) and DAML-S, and most recently OWL-S (www.daml.org), the successor of DAML-S. We used Ontology Web Language for Web Services (OWL-S), which goes beyond all previously mentioned technologies in terms of expressing meaning and semantics on the Web, especially Web Services. Three interrelated OWL subontologies—the profile, the process model, and the grounding form OWL-S—are used to express what a service does, how it works, and how to map the process model onto detailed specifications of message formats, protocols, and so on.

In addition to domain-oriented B2B applications, there is one common B2B server that maintains all shared/common data. This data is publicly available and can be used by clients in any business entity. Data in local databases is accessible depending on user privileges. Requests for specific data are forwarded through local mediators or the server. The B2B server also contains information about registered business entities and their access rights. Every new business entity wanting to join the B2B environment and participate in exchanging data must register with the B2B server in order to allow access to its data and top-level ontology. From that point, registered business entities have access to all available data from other public databases (possibly with certain access rights) and access to shared data on the B2B server. B2BOOM uses a shared ontology for each source of data, such as for each business entity, and a single top-level ontology located on the B2B server.

The generic architecture of B2BOOM recognizes several different components that have important roles in information discovery and retrieval processes: business entities, wrappers/translators, semantic mediators, and shared servers. A unified method for data access allows us to simply chain the translators. We can also easily add new information sources without influencing other environments. In order to do this, we must provide semantic mapping only for the business entity environment with the new information source. The generic B2BOOM architecture also allows chaining of the semantic mediators. Metadata and top-level ontologies must be provided in order to integrate business data, and business models, among others, from several different mediators. These metadata and top-level ontologies can be maintained using shared servers as suggested by the architecture presented.

Back to Top

Conclusion

Interoperability of B2B systems is an extremely important requirement for future EC. The deployment of Web Services represents an important move in service discovery and remote invocation so that EC applications among business partners may interoperate automatically. Web Services is a step forward, but the complexity of B2B heterogeneity is too great for technical integrations only. Semantic interoperability appears to be an essential attribute for bridging the complexity of heterogeneous environments and may allow flexible mediation between business partners on a conceptual basis.

The results of this emerging approach will transform the Internet and Web from a static collection of data into a distributed multiprocessor machine making the content within it machine readable and machine processable. Full semantic interoperability will bring B2B to its full potential, allowing participating business entities to concentrate on their mission tasks, offerings, or market requirements, instead of spending time and money on expensive software integration that is usually difficult to implement and is often delivered too late and with limited results. Access to the B2B environment for small- and medium-sized enterprises will also be enabled in a much easier manner, benefiting everyone and eliminating some of the major reasons for the dot-com failures in the late 1990s.

Back to Top

Back to Top

Back to Top

Figures

F1 Figure 1. The requirements for B2B interoperability (P = portability; S = scalability; I = interoperability).

F2 Figure 2. The integration platform in B2BOOM for ontology-based B2B interoperability.

UF1 Figure. Some major attributes of the existing frameworks.

Back to top

    1. Bussler, C. B2B protocol standards and their role in semantic B2B integration engines. IEEE Data Engineering Bulletin 24, 1 (2001), 3–11.

    2. Ceri, S. and Fraterbali, P. Designing Database Application with Objects and Rules: The IDEA Methodology. Addison-Wesley, Reading, PA, 1997.

    3. Fensel, D. Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce. Springer, 2004.

    4. Gruber, T.R. A translation approach to portable ontology specifications. Knowledge Acquisition (1993), 199–220.

    5. Institute of Electrical and Electronics Engineers. IEEE Standard Dictionary: A Compilation of IEEE Standard Computer Glossaries. IEEE, NY, 1990.

    6. Kajan, E. The maturity of open systems for B2B. ACM SIGecom Exchanges 5, 2 (2004), 34–44.

    7. Medjahed, B. et al. Business-to-business interactions: Issues and enabling technologies. VLDB Journal 12 (2003) 59–85.

    8. Meersman, R. An essay on the role and evolution of data (base) semantics. In Proceedings of the IFIP WG 2.6 Working Conference on Database Application Semantics. R. Meersman and L. Mark, Eds., 1995.

    9. Nugent, J.H. and Raisinghani, M.S. The information technology and telecommunications security imperative: Important issues and drivers. J. of Electronic Commerce Research 3, 1 (2002) 1–14.

    10. Park, J. and Ram, S. Information systems interoperability: What lies beneath? ACM Trans. on Information Systems 22, 4 (2004), 595–632.

    11. Stoimenov, L., Mitrovic, A., Djordjevic-Kajan, S. and Mitrovic, D. Bridging objects and relations: A mediator for an OO front-end to RDBMSs. Information and Software Technology 41, 2 (1999) 59–68.

    12. Wiederhold, G. Mediators in the architecture of future information systems. IEEE Computer 25, 3 (1992), 38–49.

Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More