Scaleable eCommerce Architecture

Dave Hollander; CTO; Contivo, Inc.

December 12, 2000



For organizations to remain competitive they must choose a B2B architecture that meets their needs. Increasingly, the flexibility and agility required by eCommerce business models will define these needs. One measure of the suitability of an B2B architecture to an organization’s needs is how little the architecture must be considered in making B2B related business decisions.

Yet, many of today’s architectures cannot support the rate of change required. With increasing competition among B2B enabled companies, difficulty in interfacing to your systems may provide sufficient cost or time disincentives to lose partner and customer opportunities. For example, using architectures common today, it can take 4 weeks to add a partner. And it is common for eMarkets to want to add 50 to 100 or more partners a year. This requires more than 5 or 6 integration teams (remember Brooks Law [1] that states that due to inter-team coordination doubling the number of people does not double the work completed).

To achieve trading partner scalability, the B2B architecture must allow organizations to concentrate integration efforts on business level integration instead of the lower-level technical implementation details.  This is achieved by overall architecture design, design of the technical infrastructure and the use of eCommerce standards such as XML. XML based architectures make integration simpler, more reliable and robust to changes and system failures.

Even a well-designed B2B architecture presents major challenges because it is expensive and time-consuming to prepare the necessary business level mappings.  For B2B contexts involving rapidly growing exchanges and marketplaces, or organizations directly trading with dozens or hundreds of partners, the mapping requirements can become a critical impediment. This makes it imperative to design the architecture to assure that this business level investment is independent of the technical infrastructure.  Contivo has designed its eService to help meet this challenge.  Contivo eService takes B2B architectures to a higher level of productivity and flexibility by automating much of the business model mapping process. 

Architecture Design

B2B architectures have several common components such as the technical infrastructure used to implement and connect systems, the interfaces between systems and the information architecture that describes the interchanged information. Over the last several decades various architectures and design methodologies have emphasized the importance of designing these components to be as independent as possible--that is to create a loosely coupled architecture.

The separation of data level services from business level processes is central to the three-tier architectural model and is a common theme in newer design models.  In the following model, the intent is to develop separate, parallel technical systems and processes for managing each layer of the overall architecture. The parallelism allows each layer to evolve independently and streamline processes to integrating with other systems.

·         Policy - business automation

·         Process - events

·         Schema - semantics, vocabulary

·         Transport - security, transport

One reason that XML has been so closely associated to emerging B2B architectures is the ease with which XML can separate data and its semantics and vocabulary from business rules and automation that act on the data. XML was designed to describe data in terms important to the author, not how it is to be processed or viewed. This allows data to be easily processed using differing rules and procedures depending on the needs of each party. In other words, XML allows decoupling of heterogeneous systems and applications.


The ease with which an interface can be implemented will have significant impact on the number of partner systems that will be integrated. Borrowing a term and concept from the medical profession, noninvasive interface definitions are key to making scaleable B2B infrastructure. To make an interface noninvasive you must determine the minimum level of interaction necessary for the business function and then define those requirements, preferably using industry standards.

While you can never be totally noninvasive, the use of industry standards such as email, HTTPS and XML provides you, your partners and customers the most flexibility in developing the matching interface. Designing interfaces around open standards makes it possible to use existing and emerging technologies to quickly and efficiently implement cross-system infrastructures. Commercial B2B integration servers can be deployed to interface between the internet-based cross-enterprise systems and Contivo's eService can be deployed to quickly and efficiently adopt the information exchange requirements.

Loose Coupling

Loose Coupling is a method for linking computers. Loose coupling is sometimes referred to as asynchronous integration and is an alternative to tight coupling or synchronous integration. A recent GartnerGroup study advocates loose coupling to achieve digital dial tone – the combination of the Web and XML to automate B2B collaboration.

Loose Coupling means lots of things to lots of people. It’s a method for linking computers, and also a method for linking applications and/or business processes. Loose coupling can also refer to the ability to separate applications from static data formats such that they need not be written and maintained by the same people. Finally, for all the reasons described in this paper, loose coupling should also be applied within an overall architecture between layers of the architecture.

More efficient use of resources is the primary business advantage of loose coupling of all levels of your architecture. It enables rapid deployment due to less need to coordinate between independent enterprises.  Loose coupling between layers in you architecture allows you to add partners, change rules or deploy new technologies without coordinating with all partners, significantly reducing the time and cost of running a dynamic business. The parallelism means you don’t have to treat integration with each new trading partner as a new adventure.

Technical advantages of loose coupling are the efficient use of resources. A loosely coupled technical infrastructure facilitates parallel operations, load balancing and a host of other efficiencies. Loosely coupled transport protocols are more efficient because business processes on both ends are not tied up waiting for replies. Because machines are not locked together during a dialog, loose coupling requires additional technologies to ensure that transactions are matched together including security (Public Key Infrastructure), logging, tracking, and acknowledgement at the transport and protocol levels. These additional features are useful for additional functions such as auditing and managing information flows.

At the information and process levels of the architecture loose coupling reduces the likelihood that integration will require significant programming and implementation efforts. XML based integration architectures make it possible to implement tightly integrated business processes while retaining the advantages of loosely coupled system design and maintenance.

Technical Infrastructure

The technical infrastructure is the software, systems and networks that are used to implement the B2B architecture.  The selection of this infrastructure requires balancing competing needs and interests as well as guarding against overvaluing familiarity and technical measures not relevant to the business needs.

One important decision is the information transport method(s) and protocol(s) to be supported. It can be a difficult choice because each option has a different level of invasiveness and performance characteristics. The synchronous/asynchronous nature of the transport selected impacts how to implement the protocols, the following discussion will therefore combine both transport and state management services.

The most pervasive transport methods are the web (HTTP/HTTPS) and email (SMTP). These transports are supported by most every type of computer system and company and are readily passed through firewalls. Both of these transport methods are stateless, therefore additional development is needed to maintain state. State information is needed to associate messages with the appropriate step in the protocol, to track business processes and assure transactional integrity.

Message-oriented middleware (MOM) such as Microsoft MSMQ and IBM MQSeries combine transport and protocol to create a robust transport environment. MOM based architectures are asynchronous and support loosely coupled systems. MOMs require that all interacting applications be programmed to the API provided with the software. These APIs are often a better alternative than proprietary APIs since they either implement their own “standard” or an industry standard such as JMS (SunSoft) or AMI (OAG).  However, the use of APIs is more invasive than a non-API approach and MOMs use use proprietary transport protocols and may not run across standard HTTP transport layers.

Components systems such as DCOM and CORBA are also tightly coupled modern architectures. The transport and protocol are tightly coupled into the application environment and assure high performance and reliability (at least on good, high-performance networks).  The reusable component methodology and the associated standardized APIs make distributed components a good solution for business applications that require high performance and are tightly coupled. However, component architectures are invasive and may not run across standard HTTP transport layers.

The most loosely coupled solutions for moderately complex business processes are integration servers such as WebMethods and Netfish. These servers specialize in providing state-full transactions from messages delivered across the Internet (HTTP/HTTPS and SMTP). They provide sufficient routing, transport and protocol services to match messages to business processes. In addition, these systems can be used to isolate the trading partner interfaces from the integration technologies implemented to access ERP systems, legacy file systems and existing databases. They also provide a wide range of adaptors which provide access to the legacy systems and tools to help manage the data from the adopters.

Making the selection more confusing is the rapid state of evolution of these infrastructure technologies. Each is adding features and capabilities that have traditionally been separate. For example, MOM based EAI systems are adding web interfaces while web bases systems add direct support for COM/CORBA and other adaptors for both legacy data access and integration with other technical infrastructures.


Scalability in terms of the amount of time and cost required to adding partners is a key metric for B2B eCommerce. Regardless of the technical infrastructure used, it will be less invasive and more trading partner scaleable if the interfaces are developed to separate data and processes specifications from system implementation and transport details. Leveraging loose coupling techniques for the information architecture introduces a number of strong parallels – independent development, ease of versioning over large complex systems, reusability of information as well as software components.

The separation will allow organizations to concentrate their efforts and expertise on one of the most time consuming portions of the integration process, matching information requirements. The separation also allows the use of industry standards such as XML and technologies such as Contivo’s eService giving you the ability to concentrate on high level business integration  making the architecture even more productive and profitable.


[1] The Mythical Man-Month : Essays on Software Engineering; Frederick P. Brooks Jr;

W3C XML Protocol Matrix; A complete listing of XML related protocols,

W3C XML Protocol Charter; Information about the W3C Protocols activity; href="

Integration Challenges in B2B Commerce by Adam Sohn ; EAI Journal;