More and more companies are building B2B systems to conduct business on the Internet. These systems are different from catalog-based B2C Web sites. Among other things, B2B systems usually need to provide stronger negotiating capabilities.

XML documents are flexible and self-explanatory and are now the preferred solution for B2B information exchanges. A good application of the technology is to use XML files as workflow documents to convey the attributes in trading negotiations. We found that while XML documents are flexible and easy to understand, searching information from such plain text files is difficult.

A B2B trading system needs both flexible negotiations and convenient query capabilities. We designed an Attribute Search Engine (ASE) for XML trading negotiations using Java EJBs and a relational database (RDBMS). It's based on the generic concepts we distilled from the use of attributes and enables powerful data searches for XML attribute documents. The resultant system has the strength of both sides and delivers the functions needed in a practical B2B system.

The attribute concepts we established are generic. The engine can be applied many other places.

ASE and XML Complement Each Other for E-Negotiations
Trading negotiations is a workflow process. Workflows typically have act- ors that process some documents in a certain sequence. A buyer and a seller may take turns processing a negotiating document before an agreement is made.

In e-commerce negotiations the parties need the flexibility to use various attributes in a workflow document to describe their commodities and terms. We conclude that implementing those documents with XML text files is better than the conventional RDBMS tables. First, relational tables have a finite number of predefined data entities. In negotiations many new things may come up dynamically. It's impractical to predefine them. Second, relational tables usually require high data integrity for transactions as they tend to have tight data constraints among one another. Negotiating documents should be loosely composed with fewer data restrictions. Third, with normalized data, the content of one document is often scattered in a number of tables in RDBMS. The danger of unintentionally changing historic data is greater. XML is effective in modeling document-oriented trading processes because the negotiating parties can add conditions/attributes at will to the same self-explanatory document with greater flexibility. Buyers and suppliers may pass around an XML document in a negotiation until a deal is reached. After the deal they can simply archive the XML as a single file, hence the information is retained independent of other variables.

XML shines in its flexibility; however, we soon found one of its shortcomings. Compared to querying data in RDBMS, searching information from a pile of XML files is difficult because data is stored in display strings rather than its native data types. Also, opening a number of XML files and parsing them is expensive. It's even harder to search through XML documents with compound attribute value constraints. As a simple example, the date string "5/17/1997" in an XML file is meaningful to human eyes, but our computers can't tell whether it's before or after another date value.

RDBMS is good at searching data with SQL. EJBs can connect to RDBMS using JDBC and provide flexible and consistent APIs for search engine clients. In the above example when the date is stored in Date type in RDBMS, ASE EJBs can easily compare it to other values using SQL.

Searching and analyzing trading details is important in B2B e-commerce. The trading service provider (TSP) can use the information to provide more personalized services. Buyers and suppliers can leverage the information to improve their business. For instance, a hammer manufacturer may ask this question for marketing its products: Which buyers purchased hammers in the size range x1 to x2 last year? This is a tough question for people who deal with tons of XML files. But a simple query call to the ASE can provide the answer.

Our attribute search engine is built to complement the functions XML offers. It stores those negotiating attributes into RDBMS in their native data types and makes information searches easy. In the following sections we focus on presenting the design of the ASE. First, we introduce the basic concepts we established regarding the use of attributes - the foundation of the ASE.

Basic Attribute Concepts
Entity Type
Anything that can be a target of descriptions is called an entity. An entity has its position in a taxonomy tree, and all entities of the same classification are of the same entity type. It may have a parent and a number of children. For example, hammer entity type may be a child of the hardware tool entity type.

Attribute Type
We call those name/value pairs that describe an entity type attributes. A type of attribute is uniquely identified by its name, and it may have metadata to help describe its use.

Attribute Instance
When the same type of attribute is used in several places, each of its occurrences is an instance of that attribute. Those instances share the same static information of that attribute type.

Entity Specification
We usually use a set of attributes to describe the entities of an entity type. The entity type and the set of attributes together are called an entity specification.

Attribute Carrier
An entity specification may be used in different places. The object that uses an entity specification is called an attribute carrier. For example, a purchase order that has an entity spec for hammers is an attribute carrier.

Attribute Carrier Type
Carriers have different types, such as purchase order, request for bid (RFB), and bid item.

Designing a Searchable Attribute Repository with RDBMS
An important approach to using the powerful SQL queries for XML text attributes is to store attribute values in their native data types in an RDBMS. As stated in a previous example, we can't query date values effectively if they're stored in a text format. In our RDBMS table design we separate attribute value tables from other attribute information and further split them into a number of data-type tables.

Metadata is used to describe those attributes. Frequently used metadata, such as the data type of the attribute value, is stored with the attribute. Most other information, such as the options of attribute values, the default value, and so on are stored in metadata tables.

We take XML documents as the primary source of the negotiation information. The attribute engine doesn't intend to record all the information in an XML document; it only records attributes that are useful for data searches.

We've provided brief descriptions of several key tables for ASE (see Tables 1-5).

Designing the Attribute Search Engine Server with EJBs
ASE Server runs on top of the attribute RDBMS. We implemented it with EJBs and JDBC. ASE provides Java remote interfaces for its client systems, such as the trading system, to store and search attributes. Each client system supplies its defined entity type, attribute carrier type, and attribute carrier ID while storing attributes to the ASE. ASE doesn't need to know their meanings. Only the client application knows how to search them and how to interpret the search results. In this way the engine can serve multiple applications.

ASE uses three attribute Java interfaces as its foundation. The attribute interface captures the essential behaviors of an attribute type identified by its name. The AttriInstance interface declares the core methods an attribute instance should have. The DataTypes interface defines the five native data types our ASE supports. The ASE EJBs communicate with their clients with the three foundation interfaces. Both ASE EJBs and the client programs can implement the interfaces in their own ways thus making the contract independent of the implementations (see Listing l).

ASE search methods are based on business requirements. In our case most methods are for searching carrier IDs by carrier type and attribute value constraints. Listing 2 shows a couple of search methods we use.

As the construction of the EJBs is not the theme of this article, we omit further details of the software program.

XML and ASE Work Together for Trading Negotiations
Here's an example illustrating how XML and the ASE work together in a trading system.

We assume a B2B trading system has implemented ASE and XML and offers XML product (entity) spec templates to buyers through Web GUI interfaces. A buyer picks the template for "pipe" and then specifies attribute values to its request for bid (RFB). The trading system knows that the entity type is "pipe" and the entity spec carrier type is "RFB." The GUIs let the buyer specify the desired pipe attributes - such as diameters and lengths - on the fly and record them in the plain RFB XML document. When the buyer completes the forms and creates an instance of RFB, the trading system sends the request out to a number of relevant suppliers.

At this point the system knows the entity spec carrier is the RFB instance ID. Several suppliers may be interested in the request, but in most cases no one has a product that meets all conditions. Some suppliers may make modifications to the buyer's initial spec through the trading system's GUIs and send the response with the XML file back to the buyer. The buyer and a supplier can go through several rounds of negotiations by adding and modifying the attributes in the XML document. When they reach a deal and the buyer is ready to issue a purchase order, the trading system parses the XML document, extracts the attributes inside, converts text values to their native data types, and then feeds those attributes together with relevant information (such as entity type, entity spec carrier type, entity spec carrier, etc.) into the ASE. The XML file itself is also archived as historic data.

After a period of time the ASE may have recorded thousands of such transactions. One day, the TSP wants to know what and how many RFBs have been issued for pipes with x diameters and y lengths. The TSP can get the information, which is a list of entity spec carrier IDs, by supplying the entity type ID (pipe), entity spec carrier type (RFB), and those attribute names and values to the ASE.

Discussion

• The attribute concepts and principles we established are the foundation of the ASE. They make the construction of a generic ASE possible.
• We emphasize that XML documents are the primary data source of negotiations. The attribute search engine complements their shortcomings. Therefore, attempting to reconstruct an XML document with data in the ASE is not recommended.
• A trading system should strive to make attribute names unique. Otherwise XML documents need to provide extra fields to distinguish different attributes with the same names.
• If there's no standard in attribute names, the trading system should have an alias field that maps to the actual internal name. In design there should be an attribute search service layer on top of ASE. The service layer converts nonstandard data to the internal ASE standard and may also translate ASE search results back to the client's standard. In this way users may choose their own preferred terms in negotiations. From the architecture perspective, ASE and those personalized services must be completely separate. This is the only way to keep ASE stable and robust, hence, the word "engine."
• The ASE should use a common set of units of measure so that values are easily compared. All data should be converted to their preferred unit values in the service layer before being stored in the ASE.
• ASE is not only useful for trading attributes; its design supports many other applications. For example, in Web personalization we need to record users' preferences as a number of name/value attributes. The personalization server can simply hook into the ASE to save and retrieve users' preferences.

Conclusion
Searching and analyzing B2B trading details are important to a successful e-commerce provider and its users. While XML offers users flexible attribute negotiations, an ASE makes information search and analysis easy. They work together nicely to provide the capabilities desired in a practical B2B trading system.