Scope of XML/EDI

The Achilles Heel for this approach has always been two fold. Firstly, companies require flexibility in, and wish to deviate from, doctrinaire standards that do not fully meet their business needs. Secondly, because the standards are pre ordained there is no mechanism provided to transfer processing rules and associated information. It is assumed that the data meets the defined constraints and if not, has been duly modified to conform. This means that companies must conduct exacting analysis to determine precisely how they are going to move their business data to and from the predefined EDI formats.

The cost of these constraints has been borne as excessively long and complex implementation cycles for traditional EDI systems. The world has changed from what it was ten years ago, and now requires more dynamic and vibrant services that match the organized yet ad hoc nature presented by both modern business practice, and particularly its manifestations on the Internet. The Internet is re writing the rules on how people interact, buy and sell, and exchange goods and services. In particular, the Internet is showing us that EDI is not relevant for business to business communications alone. The same concepts are also relevant for all consumer to suppl ier relationships, whether the consumer is an end user, a manufacturer, a service organization such as a hospital or a hotel, a governmental organization or a virtual organization.

With the arrival of the Internet in the last decade of the 20th century the pattern of electronic commerce has dramatically changed. In particular, the Internet has introduced many new ways of trading, allowing interaction between groups that previously could not economically afford to trade with one another.

Whereas previously commercial data interchange involved mainly the movement of data fields from one computer to another, without human intervention, the new model for web based commerce introduced by the Internet is typically dependent on human interaction for the transaction to take place. The new model is based principally on the use of interactive selection of a set of options, and on the completion of "electronic forms", to specify user requirements.

As this new model develops there has been a fundamental shift in how data used for commerce should be processed. The original create -->transmit -->receive -->process cycle of information processing, using individual programs, is beginning to be replaced by the concept of active objects which have inherent processes associated with them, based on the class of information they contain. Today an invoice may no longer contain a copy of the information stored in the database it was generated from: instead it contains a pointer that says where it expects to get the data from, and this data will be fetched from its managed source each time the invoice is processed.
Such interactive programs require us to review the underlying philosophy of electronic commerce. What are the characteristics of a system designed for "electronic business transactions" in an international market place?
To be truly interactive you need to be able to:
Understand the business concepts represented in the interchanged data.
Apply business specific rules to the interchanged data to identify what class(es) of data it contains and formulate appropriate responses. To do this you need to be able to:
identify the role and syntax of each piece of interchanged data.
identify the source of each shared piece of information.
identify which pieces of information should occur in each interchanged set of data and, if relevant, the order in which they occur in a particular message stream.
identify who is responsible for creating, transmitting, receiving and processing each message, and which programs should be used to control each of these processes.
identify when a message should be moved from one stage of the interchange process to another.
identify which rules should be used to check that the relevant forms of interchange have taken place and to move data from one presentation template to another. Because these interactions can be complex, and potentially require specialized knowledge, the rule templates can be supplemented by XML/EDI data manipulation agents (DataBots) to ensure that users can express their requirements in high level, natural language, terms. DataBots automatically create appropriate rule templates and XML syntax to match user requirements and broker the entire interchange.

When DataBots are being used XML/EDI is identified as being robot generated by adding an R to its name to become XML/EDI R. At this point in time the ECMAScript subset of the Java programming language provides the vehicle that permits the DataBots to be deployed and received along with XML/EDI messages.
Base Technologies of XML/EDl

XML/EDI is a synthesis of many concepts. XML/EDI:
uses the XML protocol as its "data interchange modelling" layer
uses the XSL protocol as its "presentation" layer
can be integrated with traditional methods of Electronic Data Interchange (EDI)
can be used with all standard Internet transport mechanisms such as IP routing, HTT P, FTP and SMTP
allows for document centric views and processing methodologies uses modern programming tools such as Java and ActiveX to allow data to be shared between programs
• uses agent technologies for data manipulation, parsing, mapping, searching...
• XML/EDI can be seen as the fusion of five existing technologies:
• Web data interchange based on the new XML specification
Existing EDI business methods and message structures
• Knowledge templates that provide process control logic
• Data manipulation agents (DataBots) that perform specialist functions
• Data repositories that allow relationships to be maintained.

Domain Name Search