chapter 2 types of e-business models and markets

Chapter 2: Types of E-Commerce Technology
“Peace, commerce, and honest friendship with all nations-entangling alliances with none.”
—Thomas Jefferson (1743–1826)
The global economy may have faltered in 2002, but advances in e-commerce technology continue to transform
personal communication and global business at an astounding pace. Although these advances promise to bring a
substantial percentage of the world’s population online in the next five years, they also present significant
challenges to industry and policymakers alike.
According to NUA Internet Surveys ( over 620 million people worldwide are linked to
the Internet. Experts predict that global Internet usage will nearly triple between 2003 and 2006, making e-
commerce an ever more significant factor in the global economy. Estimates suggest that by 2009, some 47
percent of all business-to-business (B2B) commerce will be conducted online.
E-Commerce Technology
With the preceding in mind, the dynamic nature of the new economy, and particularly the Internet, calls for
decision makers to develop policies that stimulate growth and advance consumer interests. But, in order to create
the foundation for the rapid growth of e-commerce, enterprises must adopt the effective e-commerce technology
policies that embrace the following four crucial principles:
Strong intellectual property protection: Innovation drives e-commerce technology, and rewarding creativity
fosters innovation. Thus, strong copyright, patent, and other forms of intellectual property protection are key to
invigorating the information economy.
Online trust: security and privacy: Without consumer confidence in the safety, security, and privacy of
information in cyberspace, there will be no e-commerce and no growth. Protecting information and
communications on the Internet is an absolute prerequisite to the continued success of the Internet and the
information economy
[4]
.
Free and open international trade: Closed markets and discriminatory treatment will stifle e-business. The
Internet is a global medium, and the rules of the information economy must reflect that fact. Only in an open, free
market will the Internet’s potential be realized.
Investing in an e-commerce technology infrastructure: Supporting the physical infrastructure necessary to
deliver digital content (primarily through telecommunications deregulation and government efforts to reduce the
digital divide) is vital to spurring technological growth

[3]
.
Strong Intellectual Property Protection
For hundreds of years, protection of creative material has given authors and other innovators powerful incentives
to develop and distribute exciting new products. Throughout, respect for private property (whether in its tangible
or intellectual form) has been a core value of market-driven economies.
In the information economy, such protection is even more vital, because the core currency of the Internet is
nearly exclusively intellectual property. Today, software developers and other authors of creative works depend
on the rights granted by copyright laws to develop new, more functional, and more powerful products. Overall,
U.S. copyright-based industries (particularly the software, film, music, and publishing industries) are among the
fastest growing segments of the American economy. Of those industries dependent on copyright for their
business models, the high-tech industries comprise an ever-growing share, particularly those creating software
and hardware products.
Industry leaders estimate that, within five years, an astonishing two thirds of software sales will be conducted
over the Internet. Furthermore, one third of all software exports from the United States will be distributed
electronically. Failure to properly protect this vital intellectual currency means its value will evaporate and the
global economy will suffer greatly.
Copyright in the Internet Age
Digital piracy (the online theft of creative property) poses one of the single greatest threats to the success of the
information economy. It undermines the confidence that creators and consumers place in their commercial
interactions over networks.
The very nature of the online world that makes it so attractive in the marketplace also renders the work of
copyright violators easier. Now that unlimited, flawless copies of creative works in digital form can be made and
distributed globally in a matter of seconds, intellectual property on the Internet can be at great risk. Internet piracy
is real, acute, and growing, demanding strong protections in the digital arena.
Software Piracy Is the Industry’s Most Serious Problem
Piracy is the most significant problem facing the software industry globally. Every day, pirates steal millions of
copies of copyrighted computer programs. Some of these are stolen by users making illegal copies personally,
others by professional counterfeiting, and still others via illicit sales or auctions on the Internet.
For example, International Planning and Research (IPR; recently found that 48 percent of

all software loaded onto computers globally in 2002 was pirated. In many countries, the piracy rate exceeds 80
percent. The resulting economic losses, according to IPR, were staggering: over $23 billion lost internationally,
with $4.3 billion attributable to piracy in the United States alone.
Caution
URLs are liable to change without
notice!
Widespread software theft harms not only America’s leading e-commerce technology developers, but also its
consumers. They risk purchasing defective, counterfeit products and losing the benefits enjoyed by purchasers of
legitimate software, such as customer support and product upgrades.
But, the economic impact of software piracy extends far beyond the confines of the software industry and its
consumers. Piracy distorts e-commerce technology economies worldwide by robbing governments of legitimate
tax revenues and citizens of badly needed jobs.
A recent study by PricewaterhouseCoopers ( found that software piracy cost the U.S.
economy over 200,000 jobs, more than $5 billion in lost wages, and nearly $2 billion in foregone tax revenues.
The study concluded that, by 2009, these losses would grow to 286,000 jobs, $8.4 billion in lost wages, and $2.7
billion in lost tax revenues. Conversely, PricewaterhouseCoopers concluded that reducing piracy could produce
at least two million additional jobs and nearly $36 billion in additional government revenues worldwide by 2006.
Governments Must Combat Copyright Theft
Stemming these massive losses requires a concerted, multifaceted effort to combat the theft of copyrighted
material. Although technological measures to fight piracy and increased public education about copyright are
essential, the key to copyright protection lies in governments worldwide adopting and vigorously enforcing strong
laws prohibiting this theft.
Copyright Laws Must Be Enforced
Strong words in a statute are not enough. These laws must be backed by vigorous enforcement by governments
and must allow private parties to pursue fast and inexpensive remedies when their rights have been infringed.
Strong copyright protection includes:
 Deterrent civil and criminal penalties.
 Sustained criminal enforcement.
 Copyright-related law enforcement efforts must be funded sufficiently.
 Court-ordered and court-appointed piracy inspections must be available.

Deterrent Civil and Criminal Penalties
Effective copyright laws must provide strong civil remedies, including permanent injunctions against further
infringement, the seizure of illegal software (and articles used to defeat copyright protection), compensation, and
fines. They must also provide for minimum criminal penalties when piracy is committed knowingly and for
commercial purposes or to satisfy the internal demands of a business or other entity. In the United States, both
criminal penalties and civil remedies are available and, increasingly, other countries are adopting similar legal
models.
Sustained Criminal Enforcement
Sustained criminal enforcement is absolutely necessary in order to deter piracy and send the message that
piracy is a serious crime with serious consequences. In the United States, the No Electronic Theft (NET) Act
enables law enforcement officials to prosecute individuals who steal software by distributing it over the Internet,
even if they do not profit economically from their activities. The NET Act has proven to be an effective antipiracy
tool and has resulted in numerous convictions. In countries where such laws do not exist, however, customs and
other governmental agencies must vigorously investigate and enforce traditional copyright laws as a first step
toward addressing Internet-based piracy.
Copyright-Related Law Enforcement Efforts Must Be Funded Sufficiently
Despite the very real economic damage caused by software piracy, copyright enforcement actions too often are
forced to take a back seat to other criminal prosecutions. For authorities to make a real dent in copyright crimes,
governments must provide adequate funding and explicit direction to those agencies responsible for copyright
enforcement.
Court-Ordered and Court-Appointed Piracy Inspections Must Be Available
Given even minimal warning, a pirate can swiftly and easily eliminate evidence of software theft with the touch of
a button. As a result, the prosecution of software piracy, whether in civil or criminal contexts, requires court-
ordered inspections without advance notice to the suspected software pirate (as required under the Trade-
Related Intellectual Property Rights [TRIPs] Agreement). To ensure fairness, such searches should be court-
supervised, with court-appointed experts being permitted to search and inspect for the suspected piracy.
The WIPO Copyright Treaties Must Be Implemented
With the Internet, copyright theft has become a global phenomenon. The World Intellectual Property Organization
(WIPO) recognized that fact when it adopted “digital” copyright treaties to create an international legal standard,
covering online intellectual property. Now, the nations of the world must ratify them.

The treaties were designed to promote online commerce by ensuring that authors are able to determine how their
works are sold and distributed online. The WIPO treaties reinforce the fact that copyright protects all copies of a
work, whether they are considered “permanent” or “temporary,” “tangible” or “digital.” The treaties also ensure
that authors retain the right to determine the point at which their copyrighted works are placed on the Internet, in
the same way that authors determine the locations at which tangible copies of their works may be distributed.
The WIPO treaties also recognize that, to protect intellectual property from theft, owners need to employ e-
commerce technology that guards against unauthorized access and copying. Because such e-commerce
technology-based protections are an extremely effective means to prevent theft, the treaties recognize that
attempts by pirates to break these technical defenses must be outlawed.
Because many international copyright laws do not specifically protect creative materials distributed over the
Internet, global adoption of these treaties is essential to promoting the safe and legal growth of Internet
commerce. Under provisions of the treaties, a total of 30 signatory countries must ratify the treaties in order for
their provisions to become enforceable worldwide. To date, over 36 countries have taken this step.
Governments Must Lead By Example
Governments are among the largest purchasers of computer-related services and equipment the world over. Not
surprisingly then, many governments internationally have taken the important step of directing their public
administrations to effectively manage software resources. High-profile government software management
policies have been issued in the People’s Republic of China, Spain, Taiwan, Ireland, Colombia, Jordan, Thailand,
the Czech Republic, and Paraguay, among other nations. A number of other governments are drafting similar
policies, which have served as a catalyst for enhancing software protection in both the public and private sectors
in those nations.
For example, in 1998, the United States issued an Executive Order requiring U.S. government agencies and
contractors to effectively manage their software resources and, in so doing, to use only legal, licensed software.
Several U.S. states, including California and Nevada, issued similar orders applicable to state government
agencies and related entities. These policies have had a powerful impact on the health of the software industry in
the United States and, importantly, have set the tone for proper software management practices in America’s
private sector.
Online Trust: Security and Privacy
In the aftermath of the tragic events of September 11, 2001, individuals, companies, and governments have all
focused attention on the issues of safety and security. Much of that attention has fallen on the Internet, as it has

emerged as a vital information and economic link throughout the world
[4]
.
The continued success of the Internet is, in many ways, dependent upon the trust that individuals, businesses,
and governments place in it. For that trust to exist, user information transmitted over computer networks must be
safe from thieves, hackers, and others who would gain access to and make use of sensitive information without
permission.
Consumers have repeatedly shown they will not conclude commercial transactions over the Internet, unless they
are confident of the security and privacy [4] of their personal information. Recent surveys by GartnerG2
( and BusinessWeek/Harris
( suggest that 75% of U.S. Internet
users fear going online for this reason, and that 70% of those who are already online harbor concerns about
privacy that keep them from transacting commerce on the Internet. Yet, even as concerns about these vital
issues proliferate, no single solution can suffice.
Consider privacy
[4]
, where consumer expectations vary considerably, based on a number of factors. Privacy
expectations for a voluntary, online commercial transaction are very different from those that accompany a
demand by a government entity.
The key difference is choice. When an individual is required by law to submit his Social Security number or tax
return to a government entity, that information should receive greater protection than that disclosed in a private
business transaction. In the latter case, an individual is free to choose the online entity whose privacy polices
match his needs. When consumers “vote with their feet,” businesses quickly take notice.
For e-commerce to flourish, businesses also need to provide personalized products and services so that
consumers get what they want without suffering “information overload.” Knowing this, successful e-business
marketers must gather information about the wants and needs of their customers in the same way as traditional
marketers. Policymakers also must remember that online “trust” encompasses two distinct concepts: security, so
that an individual’s private information will not be obtained through illegal hacking, and confidence that the private
information collected for one transaction will not be used in ways the information provider did not anticipate or
expect.

Protecting the Security of Information
The first and best line of defense against unwarranted intrusions into personal privacy is for individuals to employ
e-commerce technology to protect themselves. Industry-developed and supplied encryption technologies and
firewalls, for example, provide individuals with substantial tools to guard against unwarranted intrusions.
Encryption is technology, in either hardware or software form, which scrambles e-mail, database information, and
other computer data to keep them private. Using a sophisticated mathematical formula, modern encryption
technology makes it possible to protect sensitive information with an electronic lock that bars thieves, hackers,
and industrial spies.
In light of the recent tragic events of 9-11, security in all its forms (including security against cyber intrusion and
attack) is more important than ever. Strong encryption technology plays a key role in such security, helping
individuals, businesses, and governments protect sensitive or personal information against willful or malicious
theft. Not surprisingly, then, nations have increasingly adopted policies that encourage the widespread availability
of encryption tools for consumers. At the same time, they have successfully worked to permit law enforcement to
access encrypted communications in certain critical instances, while rejecting calls for encryption products to be
undermined through the building of “back-door” government keys.
A firewall is essentially a filter that controls access from the Internet into a computer network, blocking the entry of
communications or files that are unauthorized or potentially harmful. By controlling Internet “traffic” in a network,
firewalls protect individuals and organizations against unwanted intrusions, without slowing down the efficiency of
the computer or network’s operations. They also limit intrusions to one part of a network from causing damage to
other parts, thereby helping to prevent large-scale system shutdowns brought on by cyber attacks. Not
surprisingly, then, firewalls have become a key component of computer systems today, and their architecture
comprises some of the most state-of-the-art e-commerce technology available in today’s marketplace.
But, computer security, or cyber security, is more than encryption, and it requires more than a onetime fix. It is an
ongoing process requiring the adoption of strong security policies, the deployment of proven cyber security
software and appliances-such as antivirus, firewalls, intrusion detection, public key infrastructure (PKI), and
vulnerability management, as well as encryption-and, in the case of larger organizations, the existence of trained
security professionals. These professionals, in turn, must be continually retrained in order to ensure that they are
able to address and combat the evolving nature of cyber threats.
Strong security tools alone, however, cannot protect users against threats in each and every instance. Dedicated
hackers and criminals will always seek new ways of circumventing even the most effective security technologies.

That is why it is critical that strong laws be put in place to deter such activities. In particular, where needed, laws
should make it illegal to defeat, hack, or interfere with computer security measures, and penalties for these
crimes should be substantial.
As is the case with copyright laws, however, strong words in a statute are not enough. Effective antihacking and
computer security laws must:
 Provide deterrent civil and criminal penalties.
 Be backed by vigorous enforcement by governments (including through adequate funding of such
enforcement).
 Allow private parties to pursue fast and inexpensive remedies when their cyber security has been
illegally breached
[3]
.
Although the government should create a strong legal framework against cyber crime, it should not intervene in
the marketplace and pick e-commerce technology “winners” by prescribing arbitrary standards in the security
field. Such intervention would do little more than freeze technological development and limit consumer choice.
Instead, the development and deployment of security tools should be determined by technological advances,
marketplace forces, and individual needs, and should be free of regulation.
Empowering Individuals to Manage Their Personal Information
In the private sector, all parties to any transaction should have the discretion to voluntarily choose the terms of an
information exchange. The choice should be informed; both parties should clearly understand the information to
be exchanged and what will be done with it. The choice will then be based on the reasonable expectations of the
parties regarding a specific transaction. There likely will be fewer expectations about privacy accompanying the
online purchase of a newspaper subscription, than the purchase of prescription medicines, for example.
The choices of both consumers and businesses should be respected, and the private sector should be given the
latitude to develop and implement effective privacy policies to meet customer demands. Marketplace-developed
measures are far more likely than government regulations to meet the expectations of individuals and promote
the development of online commerce. The role of policy in this area should be aimed at ensuring that:
 Industry self-regulation of privacy practices continues, including giving notice to customers of these
practices.
 Consumers have the option to prevent information from being gathered from them or used for a different

purpose (opt-out), rather than requiring their specific permission for the information to be gathered (opt-
in).
 There is predictability and certainty in interstate Internet-based commerce that allows the marketplace to
function efficiently, rather than multiple state laws that will complicate, and thus chill, commerce.
 Hackers face stiff criminal penalties for stealing information or impeding its online movement.
 Law enforcers are fully funded, staffed, equipped, and trained to fight cyber crime.
 The government should lead by example by implementing strong security tools in its own systems,
including Internet security solutions in its electronic operations.
 Enhanced basic research and development on security technologies is appropriately funded.
 Skilled professionals in the computer security field are trained and developed.
 Information and best practices are more freely shared between the public and private sectors
[3]
.
Free and Open International Trade
The global vitality of an electronic marketplace depends upon free and open trade. Tariffs, regulations, and
similar barriers to commerce raise costs and can price many smaller, competitive firms out of the market. When
trade is restricted, economic development is slowed, consumer choice is reduced, and global prosperity is
harmed.
International trade is vital to the software industry. Over half of the U.S. industry’s global revenues are derived
from foreign sales. Exports as a percentage of American software companies’ total sales have increased
dramatically over the past decade. They now account for over $50 billion each year.
Enforcing the Trade-Related Intellectual Property Rights (TRIPs) Agreement
Widespread piracy is the software industry’s single most significant trade barrier. The most effective means of
reducing piracy internationally is to enforce TRIPs, the agreement by which all members of the World Trade
Organization (WTO) commit to abide by laws that protect intellectual property. TRIPs-compliant nations must
have in place adequate civil and criminal laws protecting intellectual property and must, in practice, effectively
enforce those laws.
Unfortunately, many countries fail to criminalize or adequately protect copyright holders against “end-user” piracy,
as required by the TRIPs Agreement. Other nations lack critical enforcement tools, such as the right to conduct
surprise (“ex parte”) civil searches, also required by the TRIPs Agreement.

The deadline for developing nations to comply with the TRIPs Agreement was January 1, 2000. However, today,
many countries still remain in noncompliance and in violation of their international commitments.
Facilitating Importation and Production of Information E-Commerce
Technology Equipment
A decade ago, in addition to rampant software piracy, the U.S. software industry faced another major problem in
foreign markets: unreasonably high tariffs on computers and related devices. Significant progress has been made
in this area. The WTO “Uruguay Round” agreements and the subsequent Information Technology Agreement
(ITA), substantially reduced many tariffs for e-commerce technology devices.
Still, many economies, mostly in the developing world, impose high duties or excise taxes on foreign e-commerce
technology equipment. These barriers can range from 20 percent to as much as 100 percent of a product or
system’s price. In some cases, a government might justify such a barrier by claiming that these products are
“luxury goods.” Or, a government might argue that such actions are necessary to protect an “emerging” domestic
industry or “sensitive” sector of its economy.
But, in all cases, such policies simply stifle the development of a vibrant base of e-commerce technology
consumers and service providers. It is essential for governments to adopt policies that encourage the use of e-
commerce technology—not policies that effectively prohibit or punish it.
The preceding is true whether considering a computer and software in the home, or routers and wires in the
workplace. The refusal to compete against high-quality, imported products will do nothing to enable domestic
manufacturers to produce quality products at affordable prices.
For a nation’s e-commerce technology development to flourish, countries should also open up their domestic
markets to foreign investment. Foreign companies willing to invest in e-commerce technology overseas are
affirming that particular country’s development and manufacturing capabilities and consumption potential. An
infusion of capital and expertise also serves as a catalyst for the further development of the domestic industry.
Pursuing New Trade Agreements that Respect E-Commerce
As trade moves increasingly from the import and export of tangible goods to Internet-based commerce, it is vital
to ensure that traditional free-trade principles apply equally in the realm of electronic commerce. Nations that
have sought to rid themselves of burdensome trade barriers must ensure they do not stifle e-commerce with
those same barriers. Because trade liberalization is crucial to the worldwide growth of the software industry, the
following agreements and negotiations are very important:
 The pursuit of a new round of multilateral trade negotiations under the auspices of the WTO

 The conclusion of regional free trade agreements, such as the Free Trade Area of the Americas (FTAA)
 New, bilateral trade agreements, including the U.S Singapore Free Trade Area (FTA)
[3]

Thus, the preceding bilateral and multilateral talks provide opportunities to further strengthen international trade
law, provide a predictable business environment for e-commerce, and develop a progrowth e-commerce agenda.
Keeping E-Commerce Barrier-Free
Any new trade negotiations should focus on barring new measures whose effect would be to restrict or inhibit the
growth of global e-commerce. Countries should also ensure that they apply current WTO standards to online
transactions. Specifically, countries should:
 Sign the Information Technology Agreement (ITA) and eliminate e-commerce technology tariffs.
 Make the 1998 Moratorium on Customs Duties on Electronic Commerce permanent and binding.
 Refrain from trade classifications that penalize software and other products acquired through
downloading from a computer network, compared to those purchased in tangible form.
 Affirm that current WTO obligations and commitments, namely the General Agreement on Tariffs and
Trade (GATT; trade in goods), General Agreement on Trade in Services (GATS; trade in services), and
TRIPs (intellectual property) rules are technology-neutral and apply to e-commerce. Countries should
refrain from enacting trade-related measures that could impede, actually or potentially, international e-
commerce. Such rules should be enacted only where a legitimate policy objective necessitates doing so
and where the least trade-restrictive measure is chosen.
 Support a NAFTA-type approach to e-commerce services issues in future trade negotiations. NAFTA’s
services obligations apply to all services, including new services that have developed since the
conclusion of NAFTA (this approach is sometimes referred to as “top-down”). Because it is impossible to
anticipate what specific e-commerce services will develop over time, any “bottom-up” approach, as
embodied in the current GATS, almost certainly will be out-of-date from its inception. There is a need to
set the stage for an agreement that is more flexible with respect to future e-commerce and computer
industry developments.
 Adopt a horizontal work program in the WTO for all e-commerce issues. This is necessary in order to
ensure that WTO rules and disciplines reflect the horizontal (cross-disciplinary) nature of e-commerce.
Investing in a Technology Infrastructure

All the consumer confidence and legal support in the world won’t boost e-commerce if there’s no way to deliver
electronic content to customers efficiently and quickly. The future of electronic delivery demands a dramatic
evolution of the telecommunications infrastructure in the United States and across the globe. Today’s
infrastructure was built to carry voice telephone traffic and has served well for the last 50 years. But, the
information age is placing new demands on this system-demands that it cannot readily meet. Today’s slow
transmission speeds and congestion are a legacy of an outdated system that must be modernized, lest
consumers and businesses turn away because of the “world wide wait.”
High-speed constant connections to the Internet (broadband access) let users send and receive far larger
volumes of information than traditional dial-up telephone lines allow. Broadband access can be provided through
modified cable television lines, an enhanced telephone service called Digital Subscriber Line (DSL), satellite,
fixed-wireless
[5]
, and other means.
Broadband access is absolutely necessary in order to make the vision of new, exciting Internet-based services a
reality. For example, highly anticipated interactive applications (whether online classrooms, business showrooms,
or health clinics) cannot exist if users lack broadband access.
In the United States today, roughly 70 percent of American households have access to the Internet, according to
NielsenNetRatings ( But, fewer than 10 percent of U.S. households have
broadband access.
Many other nations rival the United States in their level of Internet penetration. In Sweden, nearly 75 percent of
citizens have access to the Internet, whereas the number in Canada is 58 percent. But globally, broadband
access rates are even lower than in the United States.
Several factors conspire to stymie more extensive broadband deployment. There are financial challenges,
changing market conditions, uncertain consumer preferences, and even cultural and societal trends. In this
environment, policymakers must take the lead and encourage the provision of broadband to consumers and their
homes over the so-called “last mile.”
There is also a need to ensure that individuals in all sectors and geographical locations enjoy the benefits of
broadband access. Not surprisingly, early evidence suggests that, in the United States, the rate of broadband
deployment in urban and high-income areas is outpacing deployment in rural and low-income areas.
The preceding disparity has raised concerns that the “digital divide” (the gap between information “haves” and

“have-nots”) will increase. The digital divide is a major concern for companies who have worked individually to
expand access to computer technologies in underserved areas. They recognize that a global e-commerce
technology future depends on widespread access to new technologies, particularly by individuals who have thus
far failed to share in many of the communications and productivity benefits that technology brings. For all these
reasons, many e-commerce companies support policies to promote broadband deployment in a way that will
enhance widespread access to technology and, in so doing, close the digital divide.
Deregulating and Making Telecommunication Markets Competitive
Genuine competition in all telecommunications markets will accelerate the deployment of advanced e-commerce
technologies at reasonable prices. Competition in the long-distance market in the United States over the past
decade has substantially reduced the cost of telecommunications services and steadily increased service quality
and product innovation. This same model should be applied to local telephone markets in the United States and
other countries. Competition will stimulate existing and new companies alike to deploy new equipment and
software that is data friendly (packet-switched) and enable companies to tap into significant consumer demand
for information-intense services.
Now, let’s look at another type of e-commerce technology: the tools that reside within the Internet environment
itself. In other words, with the growth of the Internet, B2B procurement and other processes are being moved to
the World Wide Web, for increased efficiency and reach. Procurement systems from different vendors use
various protocols, and additional protocols are being defined by several industry consortia. As a consequence,
suppliers are faced with the difficult task of supporting a large number of protocols in order to interoperate with
various procurement systems and private marketplaces. In this part of the chapter, the connectivity requirements
for suppliers and private marketplaces are outlined, and a description of how suppliers and marketplaces can
interoperate with diverse procurement systems and electronic marketplaces is presented. A description of a
simple connectivity that is based on punchout processes for fixed and contract-based pricing is presented first.
Next, a description of how asynchronous processes, such as requests for quotes, auctions, and exchanges can
be distributed for interoperability across suppliers and marketplaces, is also presented. Finally, this part of the
chapter presents a description of the B2B/market-to-market (M2M) Protocol Exchange. This is a prototype that
IBM has implemented, which maps between different, but analogous, protocols used in procurement systems
and, thus, alleviates some of the interoperability difficulties.
[4]
Vacca, John R., Net Privacy: A Guide to Developing & Implementing an Ironclad ebusiness Privacy Plan,

McGraw-Hill Trade, 2001.
[3]
“Necessary Elements For Technology Growth,” © Copyright 2003 Business Software Alliance, Business
Software Alliance, 1150 18th Street, N.W., Suite 700, Washington, DC 20036, 2003.
[5]
Vacca, John R., Wireless Broadband Networks Handbook, McGraw-Hill Osborne Media, 2001.
The Internet Environment
As previously explained, with the rapid growth of the Internet, organizations are increasingly using the Web to
conduct business with greater speed, reach, and efficiency. This transformation is especially prevalent in
business-to-business (B2B) commerce and trade. Many of the Fortune 500 companies have adopted e-
procurement systems such as Ariba (see sidebar, “Ariba”), Commerce One, and mySAP. Many others participate
as buyers in e-marketplaces, such as Commerce One MarketSet, Ariba Hosted Market Place, and IBM’s
WebSphere Commerce Suite, Marketplace Edition (WCS MPE, or MPE for short), among others.
Figure 2.1 illustrates the environment for B2B procurement on the Web
[1]
. B2B buyers have diverse procurement
systems, such as those offered by Ariba, Commerce One, and SAP, among others. Each of these procurement
systems uses different B2B protocols for interaction with seller systems. Many of these protocols are proprietary
and specific to the procurement system. For example, as illustrated in Figure 2.1, Ariba uses the punchout
process between the Ariba Order Request Management System (ORMS) and seller systems using their
Commerce XML (cXML, or Commerce Extensible Markup Language) specification for the messages. Commerce
One uses XML Common Business Library (xCBL) as the format of messages, and mySAP uses the Open
Catalog Interface (OCI; for a process similar to punchout) between buyer and seller systems.
Figure 2.1: Business-to-business procurement environment.
Ariba
With purchasing managers facing the prospect of tighter corporate budgets, developers Verticalnet Inc.,
PeopleSoft Inc., and Ariba Inc. are each readying software that they indicate will enable their customers to better
manage spending. The goal is to enable companies to more closely tie the process of finding sources of raw
goods, negotiating the price for those products, and closing the loop with electronic settlement.
Verticalnet has recently released an enhanced Spend Management module as well as the next version of its

Metaprise collaborative planning and order management suite. Spend Management introduces a supplier score
card and enhanced reporting and analytics, which will let suppliers see through a Web browser how they are
serving buyer and performance metrics, such as actual costs versus standard spending. New functionality in
Metaprise, which comes from the company’s acquisition of Atlas Commerce Inc., facilitates the process of
improving requisitions and managing purchase orders. Enhanced logistics functionality integrates shipping
updates with third-party logistics providers.
Meanwhile, PeopleSoft, of Pleasanton, California, recently announced the general availability of its strategic
sourcing suite. The company unveiled PeopleSoft Strategic Sourcing as a collaborative solution that helps
companies manage the complex bidding and negotiation process in the procurement of direct goods, services,
and large capital expenditures, according to officials.
Separately, Ariba, of Sunnyvale, California, recently unveiled its Spend Management Suite, which has been in
beta testing. The suite consists of new and enhanced software modules for analysis, sourcing, and procurement
to help companies manage their spending before, during, and after the procurement process-stages that Ariba
refers to as “find it,” “get it,” and “keep it.”
In the find-it category, the new Ariba Analysis module gathers procurement information, which typically resides in
the Ariba Buyer platform, accounts payable, and ERP planning systems. It then generates reports to help
companies find potential savings.
The second new module, called Ariba Contracts, falls into the get-it and keep-it categories, by focusing on the
administration of contracts—those being used successfully and those requiring renegotiation. Integrated with
Ariba Buyer and Enterprise Sourcing, the module helps companies track and manage contract life cycles. Ariba
Invoice, the third new module, automates every stage in the invoicing process to help companies reduce
reconciliation cycle times and lets suppliers upload invoices into Ariba Supplier Network and transmit them back
to buyers.
As for enhancements, Ariba Buyer has new integration with the Contracts module. Ariba Workforce features an
expanded capability to capture and manage a broader spectrum of workforce procurement, indicate officials
[2]
.
Many other protocols for B2B processes, many proprietary to procurement and other systems, and others
customized for specific partners are being defined and implemented. In addition to the procurement systems,
which typically reside within the firewall of the buying organizations, marketplaces are being set up on the

Internet through which buyers can access a large number of suppliers, typically for specific industry segments.
Many of these marketplaces use the same or similar technology to connect to procurement and supplier systems
and offer buyers at small and medium-sized businesses access to suppliers.
Meanwhile, standards bodies are defining protocols and message formats for B2B processes. One of the early
processes was that defined by the Open Buying on the Internet (OBI) consortium, a precursor of the punchout
process. The RosettaNet consortium used OBI as a starting point and defined Partner Interchange Processes
(PIPs), including both flows and XML-based message formats for interactions between partners. The electronic
business XML (ebXML) framework (sponsored by the United Nations Center for the Facilitation of Procedures
and Practices for Administration Commerce and Transport [UN/CEFACT] and the Organization for the
Advancement of Structured Information Standards [OASIS]) includes a messaging service, a Collaborative-
Protocol Agreement (CPA) specification, and a Business Processes Specification Schema. These are all used for
enabling the interaction between business processes.
The Web services approach defines both a messaging and a remote procedure call mechanism using Simple
Object Access Protocol (SOAP). On top of SOAP, the Web Services Description Language (WSDL) defines a
Common Object Request Broker Architecture (CORBA) interface definition language (IDL)-like interface for Web-
based B2B remote procedure calls. And, the Universal Description, Discovery, and Integration (UDDI) consortium
has defined a directory mechanism for registering and locating businesses on the Web, with an optional WSDL
interface specification. The Open Application Group (OAG) has defined Business Object Documents (BODs) for
the content of B2B messages.
Some of these originally disparate efforts are now coming together. For example, the RosettaNet consortium has
announced that they will move to the ebXML messaging protocol, and OAG has announced that they will support
ebXML. In spite of these efforts, however, the number of B2B protocols continues to grow.
This proliferation of B2B protocols gives rise to several connectivity requirements and problems, as illustrated in
Figure 2.2
[1]
. First, from a supplier’s point of view (box A in Figure 2.2), suppliers need to connect to the many
customer procurement systems and private marketplaces, using various B2B protocols. Second, private
marketplaces (and, over time, procurement systems as well) need to connect to procurement systems (box B in
Figure 2.2), using different B2B protocols. Third (box C in Figure 2.2), private marketplaces need to connect to
suppliers that may support different B2B protocols. Fourth (box D in Figure 2.2), private marketplaces need to

connect to each other, in order to access suppliers connected to other marketplaces, or to access services
offered at other marketplaces.
Figure 2.2: Business-to-business connectivity requirements.
Now, let’s look at the connectivity requirements for suppliers and private marketplaces, and how suppliers and
marketplaces relying on IBM’s WebSphere Commerce Business Edition (WCBE), WebSphere Commerce Suite,
and Marketplace Edition (WCS MPE) can interoperate within the environment for B2B procurement. Simple B2B
connectivity using punchout processes as supported by WCBE are also discussed. Next, marketplace
connectivity for emerging asynchronous processes and distributed trading mechanisms, as supported by WCS
MPE, are discussed. Finally, the last part of this chapter discusses connectivity, how to use a B2B protocol
exchange, and how many of these protocols can be mapped to each other—thus allowing procurement systems
and suppliers to use different protocols.
Simple B2B Connectivity Using Punchout
Now, let’s focus on two of the B2B connectivity problems previously mentioned, and illustrated in Figure 2.2. First,
let’s discuss the supplier connectivity problem and present a solution based on IBM’s WCBE for connectivity of
suppliers to diverse procurement systems. Second, a discussion of marketplace connectivity takes place, as well
as a presentation of a solution based on IBM’s WebSphere Commerce Suite and Marketplace Edition (WCS
MPE) for connectivity of marketplaces to diverse procurement systems and diverse supplier systems.
Most procurement systems and private marketplaces support the notion of punchout (albeit sometimes using a
different term, such as RoundTrip, used by Commerce One). A buyer at a procurement system or marketplace
selects a remote supplier, and the buyer is automatically logged on to the supplier catalog server and presented
with a catalog customized for his organization, with prenegotiated prices. The buyer shops at the site, as the
items selected for purchase are being stored in a shopping cart. On checkout, the shopping cart contents are
sent back to the buyer’s procurement system for approval. The procurement system provides workflow for
approvals and, on approval, a purchase order is sent from the procurement system to the supplier. Additional
messages may be exchanged between the supplier and the procurement system, such as shipping notices and
invoices. By having punchout capability, suppliers and marketplaces can interoperate with procurement systems
or marketplaces, with significant benefits to both suppliers and buyers.
Note
Details of the punchout flow are provided later in the chapter.
For example, IBM’s WCBE is a solution for the business-to-consumer trade, whereas WCS MPE supports the

private trading exchange customers. Customers can connect to the WCBE Web site, browse through the catalog,
and place orders. In the case of WCS MPE, customers have the benefit of working with various trading
mechanisms, such as request for quotations (RFQs), auctions, reverse auctions, and exchanges. It is especially
useful, given the emerging trends in the industry, that the WebSphere Commerce products have punchout
capability and can interoperate with buyers’ procurement systems and marketplaces.
Although WCS MPE supports aggregation of suppliers’ catalogs, certain suppliers may have enormous catalogs
and their systems may include complex configuration tools. Often, it is not feasible to offload supplier catalogs
into external marketplaces. Thus, suppliers often have their supply-side Web sites enabled for punchout, and
expect WCS MPE to initiate punchout to the supplier Web site.
Catalog aggregation in the current WCS MPE product is done using the WebSphere Catalog Manager (WCM)
product. WCM supports the loading of catalog data into an electronic marketplace (eMP) database, transforming
catalog data from ASCII, spreadsheet, and XML formats into a canonical XML format, and extracting catalog data
from any relational database. More enhancements to support industrial catalogs are planned for future versions
of WCM.
Many large corporations have relatively independent subsidiaries and are classic examples of customers that
require support for both receiving punchout requests and initiating punchout requests. Such corporations often
have aggregated supplier catalogs across their subsidiaries, so their customers see a unified company-wide
catalog and require support for receiving punchout requests from the buyers’ procurement systems to the
aggregated catalog. They also require punchout initiation functionality to connect from their aggregated-catalog
server to individual catalogs supported by their subsidiaries.
Punchout from Procurement Systems to WCBE and WCS MPE
For example, IBM’s Commerce Integrator is a generic framework that enables WCBE and WCS MPE to handle
business-to-business transactions using industry standard protocols. It offers customers the opportunity to
integrate their systems with the procurement system’s own network of high-volume buyers. Commerce Integrator
provides an integrated, scalable system that enables suppliers with WCBE to participate as a supplier in the
procurement system’s marketplace, to increase sales and to enhance their business-to-business presence on the
Web. Specifically:
 Suppliers maintain a single catalog within WCBE and use that catalog to enable their own Web
presence as well as to participate in the procurement system’s network.
 Suppliers can take advantage of WCBE connectivity to supply chain management systems, retail

business systems, and order management backend systems to automatically flow orders from the
buyer’s procurement system.
 Suppliers can take advantage of the updated business-to-business features of the WCBE product for
using and maintaining information about buyer organizations, buyer-specific catalogs and price lists, and
contract pricing.
Figure 2.3 illustrates a high-level view of a typical punchout flow in which WCBE interoperates with an e-
procurement system, which includes the following steps
[1]
:
Figure 2.3: Typical punchout flow using WCBE and Commerce Integrator.
1. An agent in the buyer organization logs on to the procurement system using the user ID (identifier) and
password, and then selects an external catalog. The procurement system authenticates the buyer
agent.
2. The procurement system constructs a request to access the external supplier catalog using a user ID
and other buyer organization credentials.
3. The Member Subsystem of Commerce Integrator authenticates the buyer agent against the buyer
organization data stored in the WCBE database. If successful, the buyer agent is presented with a
catalog customized for the buyer organization.
4. The buyer agent browses the catalog in the WCBE database while a shopping cart is created. On
checkout, the shopping cart is submitted to WCBE, and a quote is recorded in the database.
5. Commerce Integrator picks up the quote from WCBE.
6. Commerce Integrator sends the quote to the buyer in the format required by the buyer’s procurement
system. An authorized agent for the buyer is prompted for acceptance of the quote.
7. The authorized agent approves the quote. An order from the procurement system is sent to Commerce
Integrator.
8. Commerce Integrator forwards the order to WCBE
[1]
.
Further messages, such as advance shipment notices and invoices (not shown in Figure 2.3) are sent from
WCBE to the procurement system.

Although the punchout flow is similar for most procurement systems, the message format is different for different
procurement systems. For example, Ariba uses cXML messages, mySAP uses Hyper Text Markup Language
(HTML) name-value pairs, Metiom uses the OBI electronic data interface (EDI) message formats, and Commerce
One uses xCBL message formats. There are some differences between the flows, as outlined previously in the
B2B protocol exchange. To handle these differences, Commerce Integrator includes some protocol-specific
functions, in addition to functions common to all protocols. As shown in Figure 2.4, incoming messages are
handled by a common servlet, which identifies the protocol and calls protocol-specific functions that map the
message to a common internal format
[1]
. Then, WCBE commands, shared by all punchout protocols, are invoked.
Responses are converted from the common format into protocol-specific formats by Commerce Integrator.
Figure 2.4 also shows a B2B gateway. The function of the B2B gateway is to provide a means of connecting
remote trading partners over the Internet, each using its protocol of choice. Clearly, this functionality facilitates the
integration of interenterprise business processes. Although the B2B gateway may support additional functions,
such as business process management, audit trails, and intraenterprise connectivity, it is beyond the scope of
this chapter to elaborate further on these functions.
Figure 2.4: WCBE Commerce Integrator architecture.
The protocol associated with an incoming message is identified by the URL to which the request is sent. The use
of a single servlet for all requests should have no negative performance impact, because the servlet engine
launches a new thread for each request. Performance bottlenecks would only be caused by undue contention for
shared resources. Were such contention present, it would impact multiple servlets in the same manner as a
single servlet. Because the servlet is merely the entry point for requests that quickly fan out to different parts of
the server, it is unlikely that the degradation of reliability from the use of a single servlet would be significant.
There are two scenarios of interest: one in which there is no separate B2B gateway and one in which there is a
gateway present. When there is no B2B gateway, protocol-specific requests are sent to Commerce Integrator,
and appropriate commands are invoked. If a B2B gateway is present, the incoming requests are mapped into a
common canonical format, and then Commerce Integrator invokes appropriate WCBE commands. Thus, there is
a synergistic relation between WCBE/Commerce Integrator and the gateway.
Punchout from WCBE and WCS MPE to External Suppliers
A traditional electronic marketplace (eMP) or a private trading exchange (PTX), such as IBM WCS MPE, provides

various trading mechanisms: RFQs, contract-based buying, fixed-price buying, auctions, exchange, and so forth.
It also provides support for aggregated catalogs. Both buyers and sellers begin by using the catalog to select a
product to buy or to sell. When sellers offer products for sale, they specify the method of purchase to be used:
RFQ, contracted price, fixed price, auction, or exchange. Buyers must purchase products using the method
specified by the seller (with the exception of RFQ, which they can initiate).
Aggregating the catalog at the eMP site offers advantages including: it makes a parametric search across
suppliers possible, and it enables small businesses, which do not have the infrastructure to host catalogs, to
engage in e-commerce. However, aggregating catalogs has its own limitations, including:
 It does not preserve each supplier’s unique brand and Web site design (it requires direct links to the
supplier’s Web pages).
 It supports only static content rather than promoting dynamic, up-to-date information.
 It provides limited support for suppliers with very large catalogs.
 It provides no support for product configurators (needed for complex products).
 It provides limited support for suppliers with fast changing catalogs or pricing
[1]
.
Thus, in situations in which there is a need for product configurators, or if the catalog contains fast changing
products and prices, the suppliers have to maintain catalogs at their own sites and not aggregate the catalog
onto an eMP. In the common eMP approach, a buyer has access to only the sellers who participate in the
marketplace with which the buyer is registered. Similarly, a seller cannot sell goods and services in a marketplace
different from the one with which the seller is registered. Now, let’s look at a mechanism called punchout, in
which a buyer in a private marketplace can “punch out” to a remote supplier to buy fixed-price and contract price
offerings.
Figure 2.5 shows the flow for setting up a punchout process (steps 1 to 7) from a procurement system (or
marketplace) to a supplier site; for example, a WCBE site
[1]
. Remote suppliers are listed at the procurement
system. They may provide their entire catalog remotely using punchout. Alternatively, a supplier may provide a
local catalog at the procurement site, with links for specific functions or details. For example, a supplier may use
punchout for system configuration, or for parts of the supplier catalog that may change frequently. As shown in

Figure 2.5, after selecting a remote supplier for initial or further shopping (step 1), a login request (step 2) is sent
to the remote supplier as an XML document, encapsulating the user and organization credentials as well as a
URL for postback to the procurement system (used at step 7, as shown in Figure 2.5). The remote supplier
authenticates this request and returns a URL (step 3) with embedded user information. The client’s browser is
redirected (step 4) to this URL, allowing the buyer to directly shop (step 5) at that remote site using the
appropriate catalog for the buyer’s organization. At the end of the shopping session, a quote representing the
shopping cart is sent back to the client (step 6) and posted back to the procurement system (step 7) at the
postback URL referred to previously.
Figure 2.5: Typical punchout request flow.
After the purchase request (in XML format) is received back at the procurement system (step 7), it is parsed and
added to the buyer’s requisition. The buyer then submits the requisition for approval. After submission, the buyer
can then view the submitted requisition and its status, and modify the requisition, if so desired.
Note
The buyer may punch out to multiple suppliers and add the contents of those shopping carts to his or her
requisition.
Subsequently, the approver views the submitted requisitions and, optionally, may punch out to the supplier to
view details of the requisition. The approver can modify the requisition, if so desired. If the approver rejects the
requisition, the status is so indicated, and can be viewed by the buyer. If the requisition is approved, it is
converted into one or more purchase orders (POs), and is sent to the supplier(s). The PO is sent as an XML
document, in the format required by the supplier. If the remote supplier’s system is based on WCBE, the PO is
formatted in a common canonical format. Also, if it is an Ariba-compliant supplier, it is formatted in cXML. And, if
the format is different, a B2B protocol exchange can be used to convert the PO to the desired format and
protocol. When the remote supplier acknowledges the receipt of the PO, the state of the order at the procurement
system is updated. Subsequently, additional messages may be sent by the supplier to the procurement system to
indicate further events, such as issuing an advance shipping notice.
Marketplace Connectivity for Asynchronous Processes
As illustrated in Figure 2.6, IBM’s WCS MPE provides different trading mechanisms, such as fixed-price buying,
contract-based buying, RFQs, auctions, and exchanges
[1]
. Also, the punchout mechanism can be used for remote

supplier integration when dealing with fixed and contract pricing. However, the more advanced trading
mechanisms, including RFQs, auctions, and exchanges, cannot be supported by the basic punchout mechanism.
This is because the flows between WCS MPE and the remote suppliers for fixed and contract pricing are
synchronous, and occur during a real-time session with the buyer, thus making them amenable to the online
punchout process. RFQs, auctions, and exchanges involve asynchronous interactions between WCS MPE and
the supplier. Next, let’s look at how such asynchronous processes are handled. RFQs are used as a typical
example. Similar flows and XML document interchanges can be used for other asynchronous trading
mechanisms.
Figure 2.6: Trading mechanisms in WCS MPE.
In WCS MPE, an RFQ is a trading mechanism used when a buying organization attempts to obtain a special
price for a purchase, or when a buying organization cannot find an acceptable offering in the eMP aggregated
catalog that meets its needs. The RFQ may be issued in order to obtain a special price based on quantity for
well-defined items or for a group of items. The RFQ may also be issued for unique items based on the buyer’s
description. The request is sent to one or more selling organizations, and these may submit a bid on the RFQ.
The selling organizations respond to the RFQ and the buying organization may select one or more winning
responses. The result of the RFQ process could be an order placed by the buyer or a contract could be created
for the negotiated price. Figure 2.7 shows this process flow in WCS MPE
[1]
.
Figure 2.7: RFQ process flows in WCS MPE.
Now, let’s look at two different mechanisms for extending the RFQ process to a distributed environment. The first
mechanism, referred to as “local RFQ,” exploits the advantages of aggregating the catalogs at the eMP site,
while distributing only the RFQ process. The second mechanism, which is referred to as “remote RFQ,” allows
buyers to connect to a remote WCBE at a supplier or a remote WCS MPE and issue an RFQ.
For local RFQs, the catalog is hosted at the WCS MPE site where the buyer is registered. Figure 2.8 shows the
process flow for this configuration
[1]
. The configuration includes the following parties:
Figure 2.8: RFQ process flow for local RFQ.
 One or more buyers

 An eMP where the buyers are registered
 One or more remote eMPs
 One or more sellers registered on the remote eMP
[1]

The flow starts with the buyer browsing the catalog on the eMP and creating an RFQ. The RFQ is sent as an
XML message to the remote eMP. Upon receiving the RFQ, the remote eMP notifies the target sellers. Each
seller views the RFQ and creates a response for it. The asynchronous responses are then sent to the eMP as
XML messages. The buyer can check the status of the RFQ at any time. The buyer views the RFQ responses by
logging on to the eMP, evaluates them, and selects a winner. Selecting a winner leads either to a purchase order
or a negotiated contract. The order or the contract is then sent to the remote eMP or remote seller as an XML
message. This solution has the advantages of an aggregated catalog and allows buyers on one eMP access to
sellers on a remote eMP, and vice versa. It has, however, the previously mentioned limitations of aggregated
catalogs.
For remote RFQs, the catalog is hosted either on the remote eMP where the seller is registered, or on the remote
seller’s Web site. Figure 2.9 shows the process flow for this configuration
[1]
. This configuration also involves four
parties. The flow starts with the buyer selecting on the local eMP a registered remote eMP or a remote seller. The
eMP connects the buyer to the remote eMP site. The buyer browses the catalog on the remote eMP and creates
an RFQ template. The RFQ template is then sent as an XML message to the eMP. The RFQ template received
from the remote eMP is converted into RFQ by providing additional information. It can then be optionally
submitted for approval. Finally, it is sent to the remote eMP or remote seller as an XML message. The remote
eMP notifies the target sellers. The sellers view the RFQ and create responses for it. The responses are then
sent to the local eMP as XML messages. The buyer views the RFQ responses by logging on to the eMP,
evaluates them, and selects a winner. Selecting a winner leads either to an order or to a negotiated contract. The
order or the contract is then sent to the remote eMP or remote seller as an XML message.
Figure 2.9: RFQ process flow for remote RFQ.
This solution overcomes the limitations of aggregated catalogs for such asynchronous trading mechanisms, and
allows buyers on one eMP access to sellers on a remote eMP, and vice versa. This comes at the price of losing

the advantages of aggregated catalogs.
Connectivity Using a B2B Protocol Exchange
As previously mentioned, some suppliers participating in a private marketplace prefer to keep the catalog
contents to themselves and not participate in an aggregated catalog hosted by the marketplace. As B2B
connectivity becomes increasingly popular, the number of protocols for engaging in B2B transactions continues to
grow. Given this growing “babelization,” it is likely that businesses and marketplaces that need to communicate
will be using different protocols. For example, IBM built the B2B/M2M Protocol Exchange, a prototype capable of
converting between different protocols.
Now, let’s look at how the exchange could be used to enable punchout between a buyer and a supplier using
different protocols. Although this example is limited to punchout, the protocol exchange can cover many other
common B2B interactions, such as shopping cart processing and order processing.
Suppliers participating in a marketplace may have catalog systems already in place supporting existing standard
or proprietary formats. These formats may vary from supplier to supplier. Thus, Supplier A may support cXML
punchout messages, Supplier B may support OCI punchout messages, and Supplier C may support some other
format. The marketplace punchout function must send punchout messages in the format and protocol that a
specific supplier is capable of processing. The B2B protocol exchange is a tool that allows suppliers to interact
with buyers whose protocols would otherwise be incompatible.
Unlike some kinds of protocol conversions, most B2B protocol conversions cannot be achieved in a stateless
manner, that is, in a manner in which the protocol converter has no knowledge of prior events or message
exchanges. This is because many of the protocols refer to the session state or to prior messages. In other words,
a B2B protocol involves not only message formats, but also message flow and the state of the interchange
process between business partners. Thus, session state management is required along with message format
translation.
A block diagram of a typical environment is shown in Figure 2.10
[1]
. In this illustration, Buyer 1 and Supplier 1 use
protocol A, whereas Buyer 2 and Supplier 2 use protocol B. Information exchange between Buyer 1 and Supplier
2, or between Buyer 2 and Supplier 1, requires the use of the protocol exchange. The presence of the exchange
is transparent to buyers as well as suppliers. When Buyer 1 and Supplier 2 are interoperating, Supplier 2 appears
to Buyer 1 to be a protocol A supplier, and Buyer 1 appears to Supplier 2 to be a protocol B buyer.

Figure 2.10: Typical B2B environment using protocol conversion.
Now, let’s look in some detail at a punchout operation such as an Ariba cXML punchout between a buyer and a
supplier that use the same protocol. The data flow is illustrated in Figure 2.5, shown earlier. The numerals refer to
the process steps described here. To purchase from a network catalog, the buyer typically uses a browser to
interact (step 1) with the procurement system, and through the procurement system, establishes a connection to
a network catalog hosted on the supplier’s behalf. The procurement system thus sends a login request (step 2; a
cXML PunchOutSetupRequest) to the supplier system. The login request contains the credentials
(userid/password) of the procurement system, a session identifier (<BuyerCookie> in cXML), and the postback
URL, which is the HTTP URL at which the procurement system accepts the completed purchase requests (in
step 7). The supplier system authenticates the request and responds (step 3) with the URL for accessing the
network catalog (in a cXML PunchOutSetupResponse). The procurement system then redirects the browser to
the network catalog URL (step 4), and the buyer connects directly to the network catalog system (step 5)
bypassing the procurement system.
As previously described in some detail, the punchout operation illustrated in Figure 2.5 (between a buyer and a
supplier) uses the same protocol. In the event the buyer and supplier use different protocols, they will be unable
to support a punchout interoperation unless some mechanism such as the protocol exchange is used. The data
flow is shown in Figure 2.11
[1]
.
Figure 2.11: Punchout request flow with protocol conversion.
When using a protocol exchange for this mapping, the procurement system is configured to treat the exchange
as the supplier system. The initial login request (step 2a in Figure 2.11) is sent to the exchange rather than the
target supplier system. The processing required at the exchange at this point may be fairly involved. Typically, the
protocol conversion involves two different authentication domains (the source protocol and the target protocol).
The exchange must validate the incoming credentials and generate the outgoing credentials for the target
protocol domain. In addition, the incoming request typically has an associated session ID (BuyerCookie), which
must be recorded and mapped to an equivalent session ID in the target protocol. Also, the postback URL must be
saved, and the URL of the exchange must be substituted in the outgoing message. Finally, the target supplier
system must be identified, and the converted request must be passed as a new login request (step 2b) to the
target supplier system.

When the login response (step 3a) is received by the exchange, the response is converted into a protocol A
response by the exchange and is returned to the procurement system (step 3b). The procurement system
redirects (step 4) the browser to the network catalog site, and the shopping session (step 5) takes place directly
between the buyer’s browser and the network catalog site. At checkout time, the browser accepts the contents of
the shopping cart in protocol B format (step 6), and sends it to the exchange (step 7a) rather than to the
procurement system, due to the substitution of the exchange URL for the procurement system URL in the
protocol A login response. In order to process the checkout, the exchange creates a new checkout page, with the
shopping cart converted into the protocol A format, and returns this page to the buyer’s browser (step 7b). The
target URL of the “checkout” button on this page is the postback URL of the procurement system, which was
saved during the translation of the login request in step 2a. The buyer is instructed to perform a second checkout
operation (step 7c), which causes the purchase request to be submitted to the procurement system for approval.
The second checkout may be hidden from the user by using scripting (JavaScript) in the HTML page generated
by the exchange.
This particular punchout description is one example of how the exchange flows might operate. Specific protocol
flows will vary in the exact details. The protocol exchange runtime is constructed from a set of common protocol
objects (Login, ShoppingCart, Order), with plugins for specific functions of the various protocols. For example, the
mySAP inbound logon plugin accepts a mySAP logon request and converts it to an internal logon object. The
cXML outbound logon plugin converts the logon object into a cXML PunchOutSetup Request. The various
shopping cart plugins convert shopping carts in different protocols into a common ShoppingCart object. The
exchange also contains code to map between credential domains (from Ariba Network IDs to mySAP OCI
userid/password). Finally, there is a state management framework to maintain the state of a session and keep
track of message content (such as the postback URL), which must be extracted from one message, temporarily
saved, and replaced in a subsequent message.
The B2B interaction between two parties is defined within the protocol exchange as a series of plugin
transformations to be performed. One plugin accepts a message and turns it into a common object. A subsequent
plugin takes the object and issues it as a message in a different protocol. There is no implicit assumption, for
example, that a cXML punchout to a supplier will result in the supplier returning the shopping cart in cXML format,
or that a shopping cart returned in cXML format is to be followed by an order to the supplier in cXML.
This flexibility is necessary to accommodate some of the interactions that are common today. As an example, the
SAP Open Catalog Interface allows the shopping cart to be returned in either XML or HTML, depending on the

configuration of the buyer’s procurement system. Some of the private buyer and supplier marketplaces are
implemented using combinations of different protocols. A supplier might expect an OBI logon from which it might
return a cXML shopping cart to the purchasing system. And, the subsequent order may have to be transmitted in
EDI, because the supplier’s EDI order processing system was in place, running over a value added network long
before the supplier had implemented any B2B interactions over the Internet.
Finally, it is hoped the various electronic commerce dialects will someday coalesce into a smaller and more
concise set. But until then, it seems that something like a B2B protocol exchange will be required to bridge the
communication gap between prospective trading partners.
[1]
Dias, D. M., Palmer, S. L., Rayfield, J. T., Shaikh, H. H., and Sreeram, T. K., “E-Commerce Interoperability with
IBM’s Websphere Commerce Products,” IBM Systems Journal, © Copyright 2002 IBM Corporation, IBM
Corporation, 1133 Westchester Avenue, White Plains, New York 10604, United States (2002): pp. 272-286.
[2]
Ferguson, Renee Boucher, “E-Sourcing Apps Lead to Time Well-Spent,” eWeek, © Copyright 2003 Ziff Davis
Media Inc., Ziff Davis Media Inc. 28 East 28th Street, New York, New York 10016-7930, ( March 2002): p. 18.
Summary
The best way to encourage future growth of the global information economy is to learn from the past. Centers of
e-commerce technology activity continue to emerge around the world: the original Silicon Valley in California,
joined by Silicon Alley in New York City, Silicon Forest in Seattle, or even Silicon Dominion in the State of Virginia,
is mirrored by the emergence of Silicon Glen in Scotland and Silicon Plain in Finland. Other concentrations of
expertise, equipment, and infrastructure include the Research Triangle in North Carolina, the Route 128 Corridor
in Massachusetts, the Intelligent Island in Singapore, and the Multimedia Super Corridor in Malaysia.
Some of these centers developed naturally; others were created and fostered by governments that provided
financing, tax relief (for imported equipment or income earned), open immigration for “knowledge workers,” and
telecommunications infrastructure. Each of these centers embraced the fact that collecting industry experience
and expertise in a specific area promotes “critical mass” and synergies, thus fostering faster e-commerce
technological development in that region’s economy.
The same can hold true with regard to users. The world is comprised of over six billion people, yet there are only
900 million telephone lines in existence. Many of the world’s citizens have never made a telephone call, let alone
used the Internet. How can this be changed?

The United Nations Educational Scientific and Cultural Organization (UNESCO) offers one approach to this
problem. UNESCO suggests the establishment of public access communication and information services, known
as Telecentres. These centers are being developed across Africa, either as standalone facilities or by adding PCs
to schools, libraries, police stations, and clinics.
Private Telecentres and telekiosks have been established in Ghana, Kenya, and Senegal, among other countries.
Built on the principle that sharing the expense of equipment, skills development, and access among a large
group helps to cut costs and make information services viable in remote areas, UNESCO has helped foster these
technology hubs across the continent of Africa. It has even developed a “Community Telecentre Cookbook for
Africa,” a how-to guide on establishing and operating Telecentres.
In addition to a general discussion of e-commerce technology, this chapter also covered various business-to-
business connectivity protocols between procurement systems, private marketplaces, and suppliers. The chapter
described how WCBE-based suppliers and private marketplaces can connect to diverse procurement systems,
other suppliers, and external private marketplaces. Specifically, the chapter showed how WCBE-based suppliers
and WCS MPE-based marketplaces can connect to buyers at procurement systems that use punchout, such as
Ariba, Commerce One, and mySAP. The chapter then described how a WCS MPE-based supplier or private
marketplace could originate a punchout process in order to connect to either an external supplier or another
private marketplace.
Next, the chapter outlined the types of trading mechanisms that can be supported by existing punchout protocols
and the asynchronous trading mechanisms, such as RFQs, which require extensions to the punchout
mechanisms. Although these mechanisms can be used across WCS MPE-based suppliers and private
marketplaces, such mechanisms need to be standardized in order to enable them to connect to suppliers and
marketplaces provided by other vendors.