A Standards-Based, P2P Approach to Marketplaces and Exchanges

BadBlue

A Standards-based, P2P Approach to Marketplaces and Exchanges

BadBlue Position Paper

February 5, 2001

Doug Ross, Chief Technology Officer, BadBlue.com

Executive Summary

Peer-to-peer (P2P) architectures are emerging as key components in the formation of effective business-to-business (B2B) marketplaces. Within the last few months, e-commerceguide.com, eweek.com, netmarketmakers.com, Plant-wide Research and others have painted a compelling picture for the use of P2P in trading partnerships. Reasons include:

·  Transparency of information flow

·  Multiple channels of information flow

·  Autonomy and control of information flow

·  Component-based approach to security and confidentiality

·  Reduction in work processes around information management

In brief, BadBlue believes that P2P architectures will drive the acceptance of B2B marketplaces in many quarters. Further, the company believes that a strong commitment to the use of Internet standards (e.g., HTTP, SSL, LDAP, etc.) will permit the highest possible level of cooperation and collaboration among marketplace participants, vendors and integrators.

Rationale for P2P in B2B

Transparency of information flow

In any marketplace, transparency of information facilitates a dramatic reduction in the “friction” surrounding transactions. Specifically, accurate and timely data around transactions can drive inefficiencies out of exchanges, supply chains, marketplaces and other arenas in which trading partners interact.

P2P architectures can facilitate clarity in transactions by leveraging the most timely and accurate partner data. In essence, a peer can abstract a trading partner’s back-office infrastructure and represent it as simply one of a series of unified peers in a partnership. By definition, the trading partner’s back-office data will represent the most up-to-date and correct information that can exist for the partner.

Multiple channels of information flow

Prior to the advent of the Internet, organizations electronically automated supply-chain segments in relatively rudimentary ways. Typically, Electronic Data Interchange (EDI) - facilitated by Value-Added Networks (VANs) - permitted only the largest organizations to participate in transactions such as quoting, procurement or invoicing. Excluded from this automation were the vast majority of potential trading partners including small- and medium-sized enterprises (SMEs).

Peer architectures (especially those predicated upon standards-based, component-oriented architectures) permit a much more open marketplace. For instance, smaller and more nimble contract manufacturers can offer capacity to larger manufacturers on a near real-time basis. Specifically, redundancy and non-hierarchically organized channels of information permit a wide variety of trading partners to participate in marketplace processes, increasing efficiency and reducing costs.

Autonomy and control of information flow

In a typical marketplace environment, information is shared through duplication. In essence, each transaction (e.g., an offer to buy) is copied to another system and then often recopied to still other systems. By definition, the more copies which exist of a given transaction, the greater the possibility that such a copy becomes incorrect, out-of-date or desynchronized from its correct context.

Peer architectures help address this issue by providing a participant authority for a partner’s transactions, thereby allowing the partner to assert overall control over the information. This control manifests itself in the following ways:

·  Roles (who can access the data)

·  Timing (when the data can be accessed)

·  Rationale (why the data is being accessed; i.e., its marketplace context)

·  Specificity (which data is being accessed)

In short, the P2P approach provides a new level of autonomy to marketplace participants.

Component-based approach to security and confidentiality

While the software industry has, for some time, espoused the use of components and object-oriented methods of design and implementation, most systems that exist today do not support run-time components. A component-based approach is extraordinarily crucial for security because new exploits, stronger ciphers and rapid innovation mark both sides of the security coin.

A P2P security approach predicated upon the use of Internet standards will be inherently more adaptable to dynamic and ever-evolving marketplaces. Such support should include the following:

·  HTTP for non-secure traffic

·  HTTPS (SSL using 168-bit triple DES, 128-bit RC4, 128-bit RC2, 56-bit DES + SHA-1 and/or additional strong cipher suites) for secure traffic

·  LDAP as a DN authority and/or certificate store

·  ISAPI (Internet Server Application Programming Interface) filters to enable plug-and-play authentication modules

P2P systems, which use Internet standards throughout the infrastructure, will be more flexible and therefore more secure than alternative approaches.

Reduction in work processes around information management

Conventional marketplaces - in which information is centrally managed - require a daunting array of work processes surrounding the actors, access, entry, maintenance and deletion of transactions. These work processes, by definition, can be significantly reduced in peer architectures because the majority of operational processes are distributed among networks of peers.

Concomitant with this distribution is an inherent simplicity relating to the nature of P2P structures: the marketplace participant is responsible for the significant portion of work processes surrounding their peer (e.g., an agent or proxy on the network). This individual responsibility mitigates and distributes the work-process load to marketplace participants in efficient and natural ways.

BadBlue Marketplace Security Architecture

The security around marketplace processes can revolve around a component-based approach that leverages Internet standards. BadBlue Enterprise Edition (EE) supports marketplace transactions using a variety of security methods. All authentication and authorization approaches leverage “plug-and-play” compatibility using ISAPI filter technology.

In a marketplace environment, EE identifies three types of actors for the purposes of security:

·  Marketplace administrator (ADMIN)

·  Marketplace participant (PEER)

·  Certificate authority (CA)

The following sections briefly describe an overview of the EE approach to marketplace security.

Creation and Maintenance of the Marketplace

The marketplace platform generally consists of one or more secure web servers of unspecified type (e.g., Apache, IIS, etc.). The marketplace can be administered by the ADMIN, who can perform various activities relating to upkeep of the trading arena:

·  Create an arena (“trading floor”)

·  Modify an arena’s properties

·  Delete an arena

·  Grant a request for participation (requested add of a PEER)

·  Deny a request for participation

·  Unilaterally add a participant

·  Modify a participant’s properties

·  Delete a participant

The addition of a participant (PEER) consists of an HTTP or HTTPS request to the PEER that it should add the marketplace to its list of trusted arenas. In addition, the request contains properties relating to the arena, the PEER’s role in the arena and other information relevant to the acts of accessing, updating and removing information from the marketplace.

PEER Interaction with the Arena

Once a PEER has received and processed a request from an Arena, it has been accepted as a participant for one or more operation types. Some of the potential operations a PEER can perform related to the Arena are:

·  Read marketplace entries that match the access rights of the PEER

·  Create a marketplace entry (e.g., a buy or sell order)

·  Modify the properties of a marketplace entry

·  Delete a marketplace entry

·  Request additional information regarding an entry

All operations are checked by the Arena - before they are executed – to ensure that the PEER has sufficient, verifiable and correct access control rights.

Figure 1 – A Typical Peer Request to the Exchange

Figure 1 illustrates a typical SSL request from a PEER to the exchange (arena).

Arena Interaction with the PEER

The arena can perform several operation types relating to access of information and workflow. These operation types include:

·  Read marketplace entries that match the access rights of the arena

·  Notify the PEER of a marketplace event

·  Notify the PEER of a workflow event

Certificate Authorities

EE can support multiple architectures relating to the use of certificate authorities (CAs). The marketplace itself can become a CA or a third party CA can be used. Server-side and peer software must agree on CAs to ensure transactional integrity among the actors.

Conclusion

Today's business environment requires the ability to communicate and securely share information and applications fast, seamlessly and through multiple channels. Peer-to-peer infrastructure using Internet standards represents a major improvement in communication, collaboration and implementation related to B2B marketplace arenas.

BadBlue Enterprise Edition

BadBlue Enterprise Edition is a tiny, full-featured web server that runs on Windows 95, 98, NT and 2000. Designed for mobile, wireless, P2P and conventional architectures, it allows corporations to collaborate using standards-based approaches. For marketplace participants and trading partners, BadBlue EE supports live sharing of standard Office documents (e.g., Excel spreadsheets, Word documents), thereby lowering the barrier-to-entry for marketplace candidates.

For more information, email or visit http://badblue.com.