The hype over the Internet would have led to the belief that Electronic Commerce has arrived only after the advent of Internet. This is however, not true, in fact, Electronic Commerce has been bubbling away for atleast 25 years. The efforts over the years have led to the creation of Electronic Data Interchange standards. The best known of these standards are EDIFACT and ANSI standards. EDIFACT is the acronym for Electronic Data Interchange For Administration, Commerce And Transport.

The EDIFACT standard is a message format for business-oriented transactions such as purchase orders, invoices and so on. EDIFACT messages can be converted into XML and vice versa. In addition, once represented in XML, the Internet can be used in place of a Value Added Network communicating EDIFACT messages.

XML has many advantages as an EDI data format. The primary goal of EDI is well served by piggy backing on this phenomenon, thereby reducing the cost of commerce. Apart from its market success, the XML open systems format, human readability and the concept of a DTD all have much to offer EDI.

XML/EDItors are envisioned as interactive tools for the creation of business forms. The idea is to download XML/XSL descriptions of the business document to a web browser.

The creation of Electronic Catalog formats based on XML/EDI standards will open up a whole new world for buyers and sellers alike. Purchasing web agents will roam XML/EDI sites, gathering pricing information. They may report their findings to a human user. They may even be embued with discretionary e-cash buying power by their creators.

So far, we have learnt that XML offers a standard syntax for marking up data and allows us to add additional messages to the information.

This allows us to validate completely the syntax as well as the message structure.

The BizTalk framework is the set of guidelines that specify as how the schemas in XML are to be published. It specifies also how to use XML messages for application integration and electronic commerce, the goal being to accelerate the rapid adoption of XML in eBusiness.

In such cases, it is important to include header information in addition to the message that is added.

The two sections are often referred to as a header and a body.

Header information also called as the envelope includes the additional information required to carry out the exchange.

There is no set of information or definition as to what should be included in the header. However, includes information regarding routing, security, batching, error process flagging, transaction identification and transaction that is legally required.

The ability to exchange and route transactions between XML servers in a set of standard methods is very critical for global eBusiness.

An important aspect of the messages is how to reference local information or resources concerning a message during a conversation with a trading partner. This local information could be any logical set of elements.

Local information is not the information that is stored in the message but it is the information that is required by the processing application, as we need to provide hooks with which the application can work.

Since eBusiness deals with business conversations, the thread of the conversation and all session information requires a mechanism to keep all the related information together. For example, when receiving an invoice from a trading partner it might be essential to relate this information to the purchase order, the transaction files of the trading partner and so on.

Sometimes it is also necessary to add information to the when the trading partner sends down some message for further processing.

At present, there is no way out for dealing with the local information, even though there would be a great benefit from one, but there is a common methodology for tagging such resources.

The methodology must aim to achieve the goals such as support chained and nested workflows allow for the keeping of individual system keys for tracking and accessing information stored in a hierarchical or relational order and lastly have a standard language for defining record access.

The figure shown describes the persistence of information as the eBusiness moves through the pipeline.

The body holds the main content of the message that needs to reach the destination specified in the header. This could be an order, a confirmation or sales data that needs to be shared.

The best way would be to use existing schemas or use the schemas already defined by the trading partner. In case on using an existing standard for the base of the vocabulary, it is worth considering for the organization whether the functionality of the schemas need to be replicated.