E-commerce is not simply about business transactions that run over the Internet, but is fundamentally about the flow of information. Nowadays the boundaries of organizations are more fluid than they used to be. Supply-chain management forces companies to streamline the ways they manufacture, distribute, and sell products and ultimately will improve the way organizations conduct business. The supply-chain cycle begins with a customer’s order. The manufacturer passes the order through the usual intra-enterprise activities, for example, sales, marketing, manufacturing, distribution, purchasing, and fiscal accounting. Usually the manufacturer turns to outside support from suppliers, utilities, transportation, and other providers of goods and services that are needed to make the product. The information exchange pertains to such matters as requests for quote, bids, purchase orders, order confirmations, shipping documents, invoices and payment information. In this way multiple enterprises within a shared market segment collaboratively plan, implement, and manage the flow of goods, services, and information along the value system in a way that increases customer-perceived value and optimizes the efficiency of the chain [3]. Company value chains are transformed into integrated value systems if they are designed to act as an “extended enterprise,” creating and enhancing customer-perceived value by means of cross-enterprise collaboration.
Value-chain integration means that an enterprise’s business systems can no longer be confined to internal processes, programs, and data repositories, rather they must interoperate with other such systems that support links in the supply chain. Unfortunately, present business-to-business (B2B) e-commerce implementations automate only a small portion of the electronic transaction process. For example, although ordering and distribution of goods can be fast, the supporting accounting and inventory information, payment, and actual funds transfer—which require communication of business processes with business application systems—tends to lag substantially. A classical example of a business application system, which typically relies on database support, is an accounts receivable system that keeps track of invoices sent and payments received. This time-lag and the decoupling of accounting and payment information systems from the ordering and delivery of goods and service (business) processes, increases the transactions credit risks. Moreover, it may often introduce discrepancies between various information sources requiring expensive and time-consuming reconciliations. Ideally, an e-commerce application should eliminate the gaps between ordering, distribution, and payment, enabling the development of interoperable links to record-keeping and accounting information systems.
The most effective form of electronic messaging to support inter-trading between consenting organizations to date has been Electronic Data Exchange (EDI). Inter-trading is effected through the exchange of messages containing standard business objects, such as invoices, purchase orders, or electronic funds. EDI is prevalent in industries such as goods transportation, food manufacturing and automobile production, in which companies trade in high volumes. However, EDI is both limited and inherently inflexible in its ability to enable a value chain. Its primary objective is as a vehicle to communicate basic information about business transactions, but it is unable to adapt to rapidly changing market conditions.
To improve this situation, business processes that operate within, across, or between organizations—in order to implement value chains that deliver e-commerce transactions—can be realized using a set of workflow definitions created to support discrete segments of the overall business goal. To be successful with e-commerce applications, workflow systems should be able to support an integrated view of all business elements that cut across departmental boundaries and manage the entire business operational flow. This requires integrating business functions, application program interfaces, databases, and legacy systems across departments and groups. This type of distributed workflow technology [9] allows business processes to be shared and passed across the value chain. This avoids creating islands of automation in the operation of an end-to-end business process by encouraging networks of highly efficient virtual organizations that will challenge the conventional business paradigm.
Interoperability in the context of e-commerce and integrated value chains is driven by a number of factors including the following major elements:
- Business process compatibility;
- Adaptability of business processes;
- Leveraging legacy assets;
- Support for business transactions; and
- Network security services.
In this article we briefly describe an architectural framework that permits the flexibility, interoperability, and openness needed for e-commerce applications rather than a collection of independent solutions that may not work in concert. Following this, we describe the critical elements of interoperability in the context of e-commerce and integrated value chains and discuss current developments trends and expectations.
Strawman Reference Architecture for Interoperable E-Commerce Applications
To meet the requirements of integrated value chains and get better reuse from software, distributed business object computing is the preferred solution [2]. Distributed object computing blends together the power of client/server computing and object-oriented development by distributing clients and servers, in the form of cooperating objects, across an integrated value-chain network. The whole concept of distributed computing can be viewed as simply a global network of cooperating business objects. Furthermore, mission critical legacy systems can be wrapped and participate in the distributed object environment.
Figure 1 illustrates an integrated value-chain enterprise framework for modeling business applications and for developing and delivering enterprise solutions. This enterprise framework consists of business components, processes, and workflow applications defined within a specific “vertical” industry, such as real estate, securities trading, manufacturing, or any vertical supply chain. The enterprise framework comprises the layers described in the following paragraphs.
Workflow-enabled e-commerce applications layer. Traditional workflow environments concentrate on the internal business process—routing work from one user to the next [6]. However, when we consider the needs of the modern enterprise, with its outsourced processes and complex partnerships, traditional models of internal control delivered via workflow are no longer relevant. The business processes evolve too quickly and when it comes to linking those evolving applications across organizational boundaries, all of the established approaches are inadequate. What the workflow layer (depicted in Figure 1) delivers is the ability to easily thread together distributed applications, supporting the integration of diverse users and other applications and systems.
The workflow layer provides the means for developing inter-business applications that interconnect and manage communication among disparate business applications and put the business processes in motion. The purpose of distributed workflow technology for integrated value chains is to manage long-running, process-oriented applications that automate business processes over enterprise-wide networks. For example, an order activity in a production planning process may start an appropriate order entry process at a closely aligned parts supplier. This type of cooperation can only be achieved if the workflow systems of the cooperating companies are loosely coupled. This results in the elimination of supply-chain discontinuities that produce delays and waste. Workflow-enabled business processes can track transactions across department, company and enterprise boundaries, tracking of the status of business activities, coordination of the flow of information of (inter- and intra-) organizational activities, and the possibility to decide among alternative execution paths [6].
One of the key aspects of multilateral e-commerce is to effectively and seamlessly provide real-time integration of databases across multiple organizations. Thus workflow activities may invoke components from existing applications, for instance legacy (wrapped) objects, and combine them with newly developed applications comprising business objects and processes.
Business process layer. This layer comprises two sublayers: the specialized business services and the generic business services sublayer. The specialized business services sublayer provides business processes, business objects and default business logic for particular vertical domains, for example, financial, manufacturing, or health-care applications. These are used to develop customized workflow-enabled applications in a specific vertical domain by extending or overriding the default business behavior. The generic business services sublayer represents generic business services common to multiple vertical industries, such as retail (shopping order fulfillment and shipping) and B2B functions (procurement, order entry, inventory, supply chain management, and so forth).
Business processes interact in a predictable, repeatable manner to produce a recognized business activity of a generic nature in a specific business domain. An example might be procurement management or general ledger, possibly according to a set of prespecified policies. The main difference between a business process and a business object is that a business object is data with behavior, while a business process operates on business objects—it changes their states and coordinates their interactions. In other words, a business process is a kind of active object.
The approach taken here is to develop fragments of business processes with the relevant application functionality attached. These fragments are then combined as required to suit the needs of each workflow-enabled application. Rather than having to compose increasingly complex end-to-end offerings, the enterprise can leave it to the knowledge worker to choose those elements that are most appropriate, combining the process fragments into a cohesive whole.
Common business object layer. Business objects provide preassembled business functionality that can be used to bring together and customize applications. They provide a natural way for describing application-independent (common) concepts such as customers, products, orders, bills, financial instruments, and temporal information, such as a quarterly earnings period or annual tax cycle. Business objects add value to a business by providing a way of managing complexity and giving a higher level perspective that is understandable by the business.
Business transaction services layer. The business services and workflow layers are implemented as value-added business and workflow capabilities layered on top of a flexible e-commerce transaction service layer. This layer provides flexible transaction support for such services as funds transfer, payment, billing and accounting services, invoicing, remittance, debit/credit and models contingency, exception, and remedial facilities. It also provides facilities that allow for the specifying of contractual obligations, contract violation conditions, and sanctions.
Middleware services layer. This layer provides the runtime environment and the distribution, reliability, and security services to accommodate mission-critical business requirements. It caters for initiating, executing, sequencing and controlling instances of a process definition in conjunction with multicast protocols, delivery receipts, authenticated packages, and smart firewalls [8]. Distributed object computing sets the foundation for supporting business objects and processes. Moreover, object request brokers (ORBs) can integrate with distributed transaction processing (DTP) monitors, such as Encina and Tuxedo, to provide the transactional properties required for supporting business transactions.
It is worth remarking at this point that this generic architecture was inspired by projects like the Object Management Group’s CommerceNet architecture [8]—a suite of services providing components interconnected using a distributed object management protocol (like CORBA)—and business frameworks such as San Francisco [1]. CommerceNet has the goal of supporting all aspects of commerce, including agents and intermediary brokers.
Compatibility of Business Processes
One of the most important requirements for interoperation is compatibility at the business level. This requires in many cases a formalization of the process of expressing business process interchanges in a consistent and extensible manner in order to facilitate communication between business processes and enable electronic interchange.
Interoperation in integrated value chains is achieved mainly at the workflow and business process level, where cross-enterprise applications may invoke business services or script together business objects from different organizations. However, as e-commerce focuses increasingly on transenterprise communications, and as the number of trading partners and sophistication of commerce applications increase, the need to harmonize business models, processes, and representation formats rises rapidly. Many companies have already begun to organize and standardize their digital services in order to create and maintain sustainable network relationships with their trading partners. Common ontologies (www.ontology.org) are being developed in several industry sectors so that trading companies can interact without misunderstanding.
In many situations it is desirable to facilitate spontaneous commerce between trading partners without custom integration or prior agreement on specific industry-wide standards. In such cases business documents represent a more intuitive and flexible way to access business services than programming business process APIs. In such situations it is much easier to interconnect companies in terms of the documents they exchange, on which they largely agree, rather than in terms of their business system interfaces [4]. The coupling in such situations is looser and interoperation is achieved by means of the Common Business Language (CBL). CBL (www.marketsite.net/xml) consists of a set of XML document type definitions that are common for B2B (ANSI X12 EDI) transactions across most industries. Its purpose is to preserve and extend the EDI infrastructure, by leveraging semantics and structure of EDI standards such as X12 and EDIFACT. Some concepts and constructs needed in these “vertical” specifications apply to all business domains and are expressed in a common way across vendors to enable CBL-based e-commerce. These constructs include descriptions of businesses, products and individuals, measurements, date, time, location, currencies, business classification codes, and so on. Translation services can be developed to handle the mapping from one company’s XML documents into document formats used by its trading partner and into data formats required by its own legacy systems. A complete business integration solution along the lines of CBL requires standardized tags (metadata), for each industry sector, a means for mapping between different metadata descriptions, and means for processing XML documents and invoking business applications and services provided by business processes and workflows. The World Wide Web Consortium is currently developing the Document Object Model (DOM), which is an object-oriented application interface for HTML and XML documents. In this way the workflows and business processes in Figure 1 can communicate effectively with CBL documents. DOM (www.w3c.org) represents a document in a hierarchy of objects that closely model the structure and processing of a document and the objects of which it is composed.
Adaptability of Business Processes
To remain competitive organizations must be able to move fast and quickly adapt to change. Moreover, they must be able to reconfigure their key business processes as changing market conditions dictate. Enterprises must respond to new requirements quickly without interrupting the course of business. Such changes must be mapped to the business object level and related to already existing enterprise models.
In the enterprise framework described in Figure 1, we take the classical organizational view that business changes are initiated by changes to business goals. This is in accordance with approaches toward linking the organizational goals to business activities that have been identified in the research literature [7, 12]. It is only natural to expect that these changes would become visible at the workflow level. However, it is virtually impossible for workflows to predict in advance all potential exceptions and paths through a business process. Most workflow products require all exceptions to be predicted and built into the process definition. Rather than insisting that all exceptions are predicted in advance, workflow systems must allow users to change the underlying process model dynamically to support a particular case of work. To achieve this degree of business process adaptability, each case of work must be related to a distinct and corresponding process fragment. A critical challenge to building robust business applications is to be able to identify the reusable and modifiable portions (functionality and data) of an existing business process or object and combine these with newer-generation business processes/objects in a piecemeal and consistent manner. These ideas point toward a methodology that facilitates proactive change management of business objects that can easily be retrofitted to accommodate selective functionality from legacy information systems.
Componentization of Legacy Assets
The interoperability requirements of e-commerce and virtual organization scenarios cut across the traditional product or organizational boundaries of systems and mandate that the legacy assets of an organization are leveraged and integrated into next-generation business systems. The e-commerce interoperability challenge places particular emphasis on integration at the transaction level and not on data integration, replication, and batch transfers of data. In addition, the virtual nature of the e-commerce end-to-end business processes requires business rules and transactions be available to partners for incorporating within their own systems. Legacy systems can be componentized physically by developers or they can be perceived as components by means of their interfaces. Needs for legacy componentization could be met by either case, depending upon the business objectives. These may include:
The interoperability requirements of e-commerce and virtual organization scenarios cut across the traditional product or organizational boundaries of systems.
- Replacement. This allows the implementation of the whole or parts of the legacy application to be upgraded or replaced at the component level, without having impact on other components.
- Enhancement. The function of the legacy applications must be changed to meet new requirements.
- Separation of concerns. This requires that components provide separate services and determine how these services are invoked via the component interface.
- Selective reuse. Reusing the services locked inside the legacy may not require reworking the existing application, just the ability to access it and integrate it into new systems. This option can be used if one wants to use (part of) the legacy system in current and future implementations.
The tactics used to leverage existing investments in legacy systems by including them in a new computing environment can be summarized as:
- Identify the logical content of the existing system in term of its data content and functionality.
- Restructure the source of the legacy into separate component interfaces and express them as abstract interfaces that exclude implementation details.
- Publicize the interfaces and direct new applications to access this interface rather than accessing the legacy system.
Object wrappers are a successful technology for combining business objects with legacy systems. Object wrapping is the practice of implementing an object-oriented facet to preexisting heterogeneous components. It allows mixing legacy systems with newly developed applications by providing access to the legacy systems. The wrapper specifies services that can be invoked on legacy systems by completely hiding implementation details. It provides external applications a clean legacy API that supports a host of abstract services irrespective of the complexity of internal representations of the legacy systems. This legacy API is the software access path to the legacy implementations’ supported functions. For example, a simple layer of software mapping the legacy APIs to CORBA IDL provides for broader system interoperation and distribution of legacy system services through CORBA.
Encapsulation is used to partition and componentize legacy systems. Each component can be objectified separately, and then the system can be reintegrated using object-based messaging. The benefits of this approach are that each component can be reused and system upgrades can happen incrementally. Wrapping provides an opportunity to include a system’s semantic contents and patterns of usage in the public definition of the system. Such concerns are shared by enterprise resource planning (ERP) systems, such as SAP, which has developed the SAP Application Link Enabling (ALE) technology that enables clients to interface their R/3 systems with other R/3 and/or legacy systems [5]. For this purpose ALE provides data containers with built-in intelligence in the form of intermediate document objects that are associated with the different types of messages exchanged between R/3 and external systems.
Interoperability in Terms of Business Transactions
A key activity in integrated value chains is the collection, management, analysis, and interpretation of the various commercial data to make more intelligent and effective transaction-related decisions. Examples include collecting business references, coordinating and managing marketing strategies, determining new product offerings, granting/extending credit, and managing market risk. Performing tasks requires involving collaborative computing technologies to support the distributed workflow processes. Workflow implementations of business processes can be not only transactional processes or classical transactions, but also non-transactional processes. Transactions as activity implementations frequently appear when the business model represents one of the core business processes of an enterprise. Non-transactional activity implementations are frequently found within support processes such as travel expense accounts.
Transactions in the B2B e-commerce are usually long-lived propositions involving negotiations, commitments, contracts, floating exchange rates, shipping and logistics, tracking, varied payment instruments, exception handling, and customer satisfaction. Business transactions are used to interchange everything from product information and pricing proposals to financial and legal settlements. They can be dynamically constructed from data in relational databases and can include descriptive text and graphics from document management systems.
Business transactions have several distinguishing characteristics when compared with traditional database transactions. First, they extend the scope of traditional transaction processing as they may encompass classical transactions combined with non-transactional processes. Second, they group both classical transactions as well as non-transactional processes together into a unit of work that reflects the semantics and behavior of their underlying business task. Thirdly, they are governed by unconventional types of atomicity. We may distinguish between four broad types of atomicity [11]:
- Payment atomicity. Payment-atomic protocols effect the transfer of funds from one party to another. Payment atomicity is the basic level of atomicity that each electronic commerce protocol should satisfy.
- Goods atomicity. Goods atomicity protocols are payment-atomic, and also allow an exact transfer of goods for money.
- Delivery atomicity. Delivery-atomic protocols are payment- and goods-atomic protocols that allow both transacting parties to prove exactly which goods were delivered.
- Contract atomicity. In addition to these basic atomicity protocols, business transactions are generally governed by contracts and update accounts. These are normally based on e-commerce protocols that include the exchange of financial information services and the exchange of bills and invoices. Thus payment-atomic protocols must also be contract-atomic.
In the world of e-commerce, traditional database transactions are replaced with long-lived, multilevel collaborations. It is therefore not surprising that they require support for a variety of unconventional behavioral features that can be summarized in the following:
1. Generic characteristics:
- Who is involved in the transaction;
- What is being transacted;
- The destination of payment and delivery;
- The transaction time frame; and
- Permissible operations.
2. Special purpose characteristics:
- Links to other transactions;
- Receipts and acknowledgments; and
- Identification of money transferred outside national boundaries.
3. Advanced characteristics:
- The ability to support reversible (compensatible) and repaired (contingency) transactions;
- The ability to reconcile and link transactions with other transactions;
- The ability to specify contractual agreements, liabilities and dispute resolution policies;
- The ability to support secure EDI, for example, SET (www.setcom.org), transactions that guarantee integrity of information, confidentiality and non-repudiation; and
- The ability for transactions to be monitored, logged, and recovered.
Integrated value chains demand advanced transaction paradigms that relate to their business processes. An important requirement of business transactions that deserves mentioning is transactional support for business commitments. Business commitments comprise the “glue” that binds businesses and other organizations at their boundaries. A business commitment is the result of an agreement between business parties that may bring about contractual agreements. Business commitments, namely contracts, mandate certain outcomes that are to be produced by the business. They have a strong recursive element that says agreements are composed of more granular agreements such as terms, conditions, and obligations, namely conditions of fulfillment and conditions of satisfaction. It is therefore important for a distributed workflow application to be able to express varying types and extents of business commitments.
Network Security Services
Protecting financial data in transit, communications, and securing the entire e-commerce transaction process are critical concerns. A number of improvements have been made in network protection technology. Firewalls, one of the primary mechanisms for protecting an organization’s internal networks and computers from outsiders, have been combined with a strong domain and type enforcement (DTE) security mechanism so restrictions can be imposed on clients and the types of applications and services can be accessed over the network.
Before integrated value chains reach their potential, security must be in place to give the trading partners and customers the confidence that their transactions are safely handled by the network. Thus e-commerce B2B communication needs to be guarded by specially designed systems that provide the security services required for the conduct of e-commerce. Support for secure e-commerce can be segmented into two distinct categories: secure transactions and enterprise network security.
Secure Transactions
For the Internet to become a more viable vehicle for e-commerce, there are a number of security issues that must be resolved. Among the technical efforts to address these concerns is the development of a secure electronic transaction specification for credit/payment card transactions over the Web.
The Secure Electronic Transaction (SET) protocol (www.setco.org) was developed jointly by payment card companies, specifically Visa and MasterCard, and software manufacturers. SET offers advancements in Internet specifications and is the first end-to-end solution. SET makes use of Netscape’s Secure Sockets Layer (SSL), Microsoft’s Secure Transaction Technology (STT), and Terisa System’s Secure Hypertext Transfer Protocol and uses aspects of a public key infrastructure. The SET specification is designed to enable payment security for all involved, authenticate card-holders and merchants, provide confidentiality of payment data, and define protocols for potential electronic security service providers. Currently, IBM and VeriFone are extending SET to achieve product interoperability. The three basic types of interoperability pursued are consumer/merchant interoperability in which any consumer may purchase from any merchant; merchant/gateway interoperability, which indicates the ability for any gateway to acquire transactions from any merchant; and SET component/certificate authority interoperability, which indicates the ability for any SET component (such as card-holder wallet or merchant) to obtain SET certificates from any SET certificate authority.
Other activities in the area of secure transactions have concentrated on providing reliable and secure delivery of electronic goods with low transaction costs. The NetBill e-commerce system (www.ini.cmu.edu/ netbill) is an electronic payment negotiation framework that was developed to support economical, secure sales of low-cost goods. The NetBill software components provide the core transaction capabilities of a micropayment system. Server components exist for the managing of consumer private keys and certificates [10]. The transaction processing components accept purchase requests from merchant product servers, perform the necessary validation, and transfer funds within a back-end accounting system. Moreover, additional functions are provided such as consumer and merchant statement queries, transaction status queries, balance queries, and account creation and management.
Such activities address several of the security requirements of integrated value chains and can provide the basic infrastructure necessary for the development of a secure transaction framework that guarantees interoperability at the level of secure business transactions.
Enterprise Network Security
The fundamental network security issues of e-commerce are directly related to contract formation and enforcement. Authentication, authorization, communication integrity, confidentiality, and non-repudiation are the major aspects of network security.
Authentication is the process of ascertaining the identity of a party that has sent or received a message, and/or determining that the message received is accurate.
Authorization implies that certain transactions may need to be partly accessible to certain parties, while the remainder of the transaction is not. These tasks can be coordinated by the transaction workflow and authorization modules. Authorization is meant to limit the actions or operations that authenticated parties are able to perform in a networked environment.
Secure transactions should guarantee that a message has not been modified while in transit. This is commonly known as communication integrity and is often accomplished through hashing algorithms and digitally signed digest codes. Secure transactions should also guarantee confidentiality. Confidentiality refers to the use of encryption for scrambling the information sent over the Internet and stored on servers so that eavesdroppers cannot access the data. This is also known as “quality privacy,” but most specialists reserve this word for the “protection of personal information” (confidential or not) from aggregation and improper use.
Non-repudiation is of critical importance for carrying out transactions over the Internet. It consists of cryptographic receipts that are created so an author of a message cannot falsely deny sending a message. These tasks fall well within the premises of contract formation and enforcement.
Secure Payment Mechanisms
Currently, numerous merchants are successfully conducting business on the Internet using HTML/XML-based forms. The data formats used in these forms vary considerably from one merchant to another. Electronic wallets help this situation by assisting consumers in conducting online transactions by allowing them to store billing, shipping, payment, and preference information and to use this information to automatically complete merchant interactions. Electronic wallets that fill in forms have been successfully built into browsers to simplify the check-out process and minimize the need for a consumer to complete a merchant’s form every time. However, the proliferation of electronic wallets has been hampered by the lack of standards.
The Electronic Commerce Modeling Language (ECML) (www.ecml.org) is an initiative, very much in the same spirit as CBL, which provides a set of simple guidelines for Web merchants that enable electronic wallets from multiple vendors to fill in their Web forms. ECML can be used in conjunction with any secure payment mechanism, for example, SET transactions, to allow a merchant to publish consistent and simple Web forms. ECML has a simple syntax in HTML and provides the basis for interoperability as it is expected to be supported by multiple wallets and multiple merchants.
Conclusion
Although we have looked at SI from the information systems/business perspective, we observe a lot of affinity and overlap with other areas involving SI such as software engineering and database systems. We have argued in favor of the development of business applications out of libraries of certifiably robust, specified, modeled, and tested software components, namely, business processes and objects. Here the benefits and influence of software engineering are undeniable. These can be summarized in the following:
- The enhancement of reuse of core functionality across applications;
- The facilitation of flexible upgrade and replacement of parts of software independent of their production (manufacture); and
- Providing the means for establishment of collective organizations’ best practices so that extant processes may be replaced because of changing business or market-driven scenarios.
On the other side the influence of database systems integration is also unquestionable. In particular, we distinguish two major aspects of database systems integration that are of paramount importance to B2B e-commerce:
- The integration of legacy database systems with new components to accommodate a broader range of business process variability and evolution; and
- The homogenization and the coupling of disparate database systems to facilitate automation of a large portion of the electronic transaction process.
In this article we have reviewed the situation with current integrated value-chain applications and suggested that interoperability support be provided along five lines: business process compatibility, adaptability of business processes, leveraging legacy assets, support for business transactions, and network security services. Value-chain integration means that an enterprise’s business systems can no longer be confined to internal processes, programs, and data repositories, rather they must interoperate with other such systems that support links in the supply chain. We discussed each of these critical factors for e-commerce interoperation in some detail. We also observed other important aspects of interoperability are the use of common ontologies for vertical industry sectors and the use of languages for representing metadata for standard documents being exchanged during e-commerce and for describing metadata structures of electronic wallets and payment schemes.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment