XML-based Supply Chain Management - CiteSeerX

Inter-organizational Document Exchange – Facing the Conversion Problem with XML – Luis Martín Díaz

Erik Wüstner

Peter Buxmann

Freiberg University of Technology Chair of Information Systems / Wirtschaftsinformatik Lessingstr. 45 09596 Freiberg / Germany +49 3731 393262 http://www.bwl.tu-freiberg.de/wi



[email protected] [email protected] [email protected] ABSTRACT Information exchange processes are often characterized by the need of translating from one data format into another in order to achieve compatibility between information systems. A conversion problem often arises when exchanging files between applications of different software vendors or when incorporating legacy business data into new standard software. In this paper we want to survey the conversion problem in the field of multi-organizational networks, since participants often use different data formats. We examine, to what extent XML is able to support the interorganizational exchange of business documents. Thereby, we concentrate on the problem of converting different data and examine different approaches for solving the transformation problem. We show how XML can actually be implemented for a Web-based integration in multi-organizational networks. Moreover, we present a java-based prototype that enables document exchange over the Internet using XML business vocabularies for document representation, XSLT for document conversion and presentation, and both DOM and SAX for processing and integrating documents into in-house-systems.

Keywords XML, Java, Standardization, Supply Chain Management, Information Systems, Conversion Problem, Inter-organizational Document Exchange.

1. INTRODUCTION Information exchange processes are often characterized by the need of translating from one data format into another, in order to achieve compatibility between information systems. This is what we call the conversion problem. It often arises when exchanging files between applications of different software vendors or when incorporating legacy business data into a new standard software. In this paper we want to survey the conversion problem in the field of multi-organizational networks, since participants often use

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC 2002, Madrid, Spain © 2002 ACM 1-58113-445-2/02/03…$5.00.

different data formats.Thereby, we examine, to what extent XML is able to support the inter-organizational exchange of business documents in cooperation networks, since other approaches, such as traditional EDI, have not gained the wide acceptance that was expected among the industry [3]. For this purpose, we concentrate on the problem of converting different data formats and examine alternative approaches for solving the conversion problem, which could enable cooperating organizations to use XML as a common fundamental language, building upon it different business vocabularies, which best meet their specific requirements, without loosing compatibility. In the following section, we describe the role that XML can play for reducing this problem. We explain how the representation of business documents can be achieved, how these can be translated into other XML vocabularies and how the integration of document data into in-house-systems can be done. In the third section, we present a Java-based prototype, which gives an example of how to implement XML for displaying, describing, exchanging, converting, and integrating documents. The paper ends with an outlook on further research activities.

2. XML TECHNOLOGY FOR REDUCING THE CONVERSION PROBLEM XML was developed by the World Wide Web Consortium (W3C) back in 1998. Since then, it was published as a recommendation [10]. The W3C defines XML as a “data format for structured document interchange on the Web” [9]. XML strictly follows the principle of separation of content and structure of the described data from its layout [1]. This makes it possible to describe meaningful data and document structures without any application or vendor constraints. With the help of Document Type Definitions (DTDs) and schemas, this data can be validated. Furthermore, XML enables flexible processing and simple information exchange between heterogeneous applications, media, and platforms. The presentation of XML documents can be realized by using technologies such as CSS and XSL [11]. This splitting of data holding and presentation allows the separated optimization of both aspects without any compromises or dependencies. A major reason for XML´s current success is the fact that the W3C has created more than just a data format. The XML family

rather consists of a variety of related open standards, which enhance the functionality of data marked up with XML.

2.1 XML-based business vocabularies The conversion problem is however not solved by XML. The general difficulty of the integration and standardization of documents remains. As long as the cooperating organizations do not agree on the tags, patterns and schemas to use, neither a correct interpretation nor a subsequent processing of the documents is possible. Thus, similar to traditional EDI a semantic standardization of message types and data structures is necessary. For this purpose, it makes sense to use available knowledge from conventional EDI. Standardization initiatives such as xCBL (XML Common Business Library, http://www.xcbl.org), the CEN/ISSS XML-EDI pilot project (http://www.cenorm.be/isss/workshop/ec/xmledi/default.html), or the XML/EDI Group (http://www.xmledi group.org) are based on EDIFACT or X12-structures. Other initiatives offer XML business vocabularies, which try to start from scratch, without any legacy design constraints. Examples of these are cXML (Commerce XML, http://www.cxml.org), eBIS XML (http://www.ebis-xml.net), and OAGIS (Open Applications Group Integration Specification, http://www.openapplications.org). A recent study identified 250 different XML-based e-business vocabularies [4]. This fact shows how the diversity can be maintained through an agreement on a single standard like XML.

2.2 Conversion strategies with XML As we already mentioned, XML is more than just one standard. The XML family offers a set of related standards that complement each other. One member of the XML family is XSL (Extensible Stylesheet Language). This specification consists of three technologies – XSL-FO, an XML-based formatting language, XSLT, a language for defining transformations of XML data, and XPath, a pattern language for addressing elements of XML documents. The basic idea in the context of the conversion problem is that, with XSLT, there is a technology available, which allows the definition of style sheets for transforming from one XML vocabulary and structure into another. The XSLT syntax allows composing style sheets, in which every element of the initial document is associated with an element of the target document. The concrete addressing of the elements is implemented using XPath. Template-rules allow a contentspecific conversion. The actual transformation is performed by an XSLT processor such as Xalan of the Apache XML project (http://xml.apache.org/), which applies the style sheet to the source document and thus creates the desired target document. The result of the transformation can be any kind of structured format. So it is possible to translate from an XML vocabulary to another, from XML data to EDIFACT, to WML, or to plain text. Figure 1 shows the result of applying an XSLT-style sheet to an XML purchase order in order to generate its representation in HTML.

Figure 1. Visualizing an XML document using an XSLT style sheet. If a set of n organizations agrees on using XML and every member chooses the XML standard that best fits his needs, there will be, in the worst case, a maximum of n different standards. This implicates the need of conversions between these standards, in order to be compliant when transferring information. There are different strategies to organize these conversions, which stem primarily from network topologies. Their use is not restricted to inter-organizational information exchange, it is also applicable for information exchange between different departments and production sites within larger companies. It is hereby assumed, that bi-directional communication between the partners has to be supported: Ring Structures Members could agree to position their respective standards in a circular structure as shown in figure 2:

B A

A

C n Standards

H

D

n Stylesheets

G

E F

B In-houseStandard

n Standards 2n Stylesheets

C D E

Figure 2. The ring structure and the peer-to-peer situation of a company. In this scenario, conversion takes place by passing the document in a single, pre-defined direction along the ring, until the document finally is converted into the desired destination standard. The advantages of this structure are on the one hand easy extensibility and on the other hand low development costs. If a new standard is introduced, only two new conversions have to be developed while one conversion is dismissed. Therefore, if n is the number of participants, there are always n conversion

processes, which keep the development costs for the conversions relatively low. A disadvantage of this structure is the low conversion speed, which comes from moving the document-to-be-converted along the ring. Therefore, with m intermediate standards, m+1 conversions have to be done. Furthermore, the ring structure is only applicable in situations, where all standard can be converted loss free into one another, which is due to the complexity and variety of standards rather doubtful in practice. When loss-free conversion cannot be fully ensured, eventual losses multiply when moving the document along the ring. Furthermore, if one style sheet is defective, many conversions cannot be done. Peer-to-Peer Structures In this environment, it is up to the respective organization to convert incoming or outgoing documents into the standard of the direct business partners. This leads to a situation where every organization in the network faces the need to develop converting mechanisms for the whole range of different standards he is dealing with. This is illustrated in figure 2. Although every organization is free to choose a standard fitting its unique needs, converting costs are quite high, because with n network members, a maximum of n(n-1) style sheets has to be developed as figure 3 shows. This scenario has the disadvantage of being hard to extend, when new standards are incorporated within the network. Nevertheless, contrary to ring structures, this structure has the advantage that occurring conversion losses are reduced to a minimum and do not alter the results of other combinations. Superior Standard In this architecture, the cooperating organization could create a superior standard S, which would mediate in document exchange processes within the network. With n standards, 2n style sheets would be necessary. The advantage of this structure is that additional standards can easily be supported by creating only two new style sheets. As shown in figure 3, in this scenario any of the standards can be converted into the superior standard and vice versa.

B A

E D

C

H

D G

E F

C

F S

B

G H

A

n Standards

n Standards

n(n-1) Stylesheets

2n Stylesheets

Figure 3. Peer-to-peer and superior standard enviroment for converting XML documents. This superior standard has to master as many details as any of the single standards used by the network participants. Furthermore, it has to cover the full range of possibilities of all the involved

standards to ensure a conversion with minimum loss of information. It is strongly questionable whether the requirements of such a superior standard can be met by any XML vocabulary currently available. Table 1 summarizes the pros and contras of the three different conversion strategies: Topology \ Efficiency Criteria Maximum number of conversions to be developed for n Standards Development costs Extensibility Conversion accuracy (loss free) Conversion speed Protection against defective conversions

Ring

Peer-to-Peer

Superior Standard

n

n(n-1)

2n

+ +

-

-/o o/+

-

+

o

-

+

o

-

+

+

Table 1. Pros and contras of the different conversion strategies.

2.3 The integration of XML documents The effort of integrating XML data in in-house-systems is, compared to traditional EDI, relative small. The processing capabilities of XML documents facilitate their integration into ERP-Systems, such as SAP R/3. Available open APIs like DOM and SAX allow a standard processing of the XML documents to, for instance, apply the BAPI interface or the Business Connector to access the SAP R/3 system. The integration of XML data with non-XML databases is also relatively easy [2]. There are APIs for most of the existing databases available, which allow the integration of XML into relational databases. So it is possible to use DOM or SAX together with a JDBC driver (http://java.sun.com/products/jdbc/). Another way to integrate XML data into relational databases is offered by the XML database Tamino (see section 3). Schema mappings allow a quick integration of a relational database through an ODBC interface [8]. Some database, e.g. Oracle, offer applications that already enable this integration (http://technet.oracle.com/tech/xml/). In addition, the new concepts like the object relational model and “nested tables” ease the fusion of the relational and the XML world [7][6]. In contrast to most of the EDI standards, XML data is humanreadable. The human factor is nowadays an important bottleneck in IT processes. Thereby, an important aspect is the need of visualizing the business documents. One easy way offers the XSLT technology, which allows the transformation of XML documents into HTML-documents, in order to view them in a browser, for example. This transformation can be done without changing the original data in any way. So is it possible to create as many different visualizations of one document as the user needs [3].

3. AN IMPLEMENTATION EXAMPLE XML is an open standard. The acceptance of the XML technology, not only throughout industry and commercial institutions but also by the Open Source and Internet community,

makes it relatively easy to access corresponding knowledge. Moreover, there is a wide variety of free XML-related tools available, which can easily be implemented in new applications. Following this open philosophy, we are developing an open application for enabling a straightforward exchange of business documents between partners in multi-organizational networks. This application, called SIMPLEX (Supply Chain Management Platform Enabled by XML), is therefore mainly based upon open standards, open source software, and freeware. This prototype, uses XML to describe and structure business documents like invoices, purchase orders, order entries, forecasts, reports, monitoring transactions, etc [3]. With these XMLformatted documents, the application supports the execution of pull and push information processes, the conversion between different XML vocabularies, and the integration into in-housesystems.

statements, we apply XQL („XML Query Language“, see http://www.w3.org/TandS/QL/QL98/pp/xql.html). The result of the XQL queries and the data sent to the database is then parsed in SIMPLEX with Apache´s Xerces. This parser offers processing of XML documents via the DOM and SAX programming interfaces. The presentation possibilities offered by SIMPLEX include showing business documents as XML code, as a directory tree, as a table, and as a styled document. The tabular representation can be exported to Microsoft Excel for further analysis of the XML data. The following figure shows the user interface of SIMPLEX. It presents the defined business documents of the subject network, in this case a supply chain, on the left hand side. An XML purchase order in the XML code representation can be seen in the main part of the window.

However, one component breaks with the philosophy of the technologies implemented. Tamino, the commercial XML database of the Software AG, is the only exception to this principle in SIMPLEX’ architecture. Tamino is currently part of this prototype for two particular reasons. First, Tamino offers interfaces for integrating XML data in external non-XML data sources such as relational databases. Second, XML data stored in Tamino is accessible via a web server. This makes the data available at any time with no other help than an XML-capable browser. There are meanwhile some open source and freeware projects, which will probably offer high-performance native XML data storing in the future. Examples for such projects are the XML databases XDBM (http://bowerbird.com.au/XDBM/), Lore (http://www.db.stanford.edu/lore/), and GMD IPSI’s XQL Engine (http://www.darmstadt.gmd.de/IPSI). We are currently testing the suitability of these applications for further implementation. SIMPLEX is written in Java, which is also an open technology and grants platform independency. Especially for Java, there is a wide range of efficient XML components available. Free XML parsers and XSLT processors can easily be incorporated in a Java application. In order to be parser and processor-independent we implemented the JAXP (Java API for XML Processing) technology, which makes the application independent from the actually used XML parser and XSLT processor [5]. The SIMPLEX prototype uses the parser Xerces and the XSLT processor Xalan of Apache (http://xml.apache.org). For the graphical user interface, we use the Swing and AWT classes available in Sun’s JDK and integrate the HTML ActiveX component of Microsoft’s Internet Explorer 5.x. This windowsspecific component is wrapped into a Java class and is directly usable in a Microsoft Windows platform. Nevertheless, we do not lose the platform independent character of this solution. Some vendors offer solutions that allow the porting of windows-specific components to other operating systems and so let SIMPLEX remain platform independent (see http://www.linar.com/). The communication with the XML database takes place via a web server. Every query and its result is transferred between SIMPLEX and the web server using HTTP. In our implementation, we use the Apache web server. For query

Figure 4. The graphical user interface of SIMPLEX. Apart from the pure representation of XML documents in different ways, SIMPLEX offers two defined modules that take over important functions. The first module is the so-called RetrievalAgent. It supports the automated exchange of XML documents without human intervention. The second module is STYX. This part of the application is responsible for the transformation of documents from one XML vocabulary into another (see section 2.2). These transformation capabilities are also used in SIMPLEX for the integration of XML documents into in-house-systems. At this stage of the development, this integration is also possible via the XML database itself. Tamino is capable to integrate external data sources over the so-called XNode using an ODBC interface (see section 2.3). Information exchange processes in supply chains can generally be divided into push and pull-processes. While in push processes the sender is actively delivering the information to the recipient, pull means that the recipient has to fetch the desired information. SIMPLEX supports both push and pull processes. In a push process of a supplier-customer-relationship, for example, the customer will release an order in his in-housevocabulary. She or he has the opportunity to convert the document into the vocabulary of the recipient and store it over the Internet in the remote database.

SIMPLEX also allows automated information exchange. For instance, in a pull process, the customer will automatically fetch invoices addressed to him from the supplier’s database and transform them to his vocabulary without human intervention [3].

5. ACKNOWLEDGEMENTS

However, the fact that the partners exchanging business documents rely on XML technology does not eliminate the conversion problem. Each business partner may use different XML formats, which best match their different needs for data storing. The STYX (STYX Translates Your XML) module was developed for making different XML vocabularies compatible using the already mentioned XSLT technology.

6. REFERENCES

The STYX module contains a set of style sheets for the conversion between the vocabularies OAGIS, xCBL, and eBISXML. Since information about used vocabularies and supported business document types is stored in an XML file, this set of translation style sheets can be enhanced dynamically at run-time. In the context of push and pull process the document conversion is realized by selecting, both the standard of the source document and the standard the document it is supposed to be converted into. STYX automatically finds the corresponding XSLT style sheet for the conversion and applies it to the source document.

Figure 5. Conversion of business documents using the STYX module.

4. OUTLOOK ON FURTHER RESEARCH At this stage of development, SIMPLEX just supports the exchange, the conversion and the integration of business documents based on XML. Currently we develop a technique for graphically mapping XML structures to database structures for automatic integration processes between XML and non-XMLsystems. Further, we follow the very promising super-standard strategy shown in section 2.2, to allow the automatic creation of an appropriate super-standard, which will enable on-the-fly conversion between XML vocabularies. These projects could drastically reduce the efforts, when facing the conversion problem, making all the processing and structuring advantages of the XML family available to support inter-organizational information procedures. XML could so replace existing EDI solutions, allowing the integration of those companies, who could not yet afford joining traditional EDI networks.

We want to thank the German Research Society (DFG) for sponsoring our research project SKILNet, in which context we developed the SIMPLEX prototype. [1]

Bosak, J.: XML, Java, and the future of the web. http://sunsite.unc.edu/ pub/suninfo/standards/xml/why/xmlapps.html, October 1997, Visited on 2001-08-19.

[2]

Bourret, R.: XML and Databases. http://www.rpbourret.com/ xml/XMLAndDatabases.htm, November 2000, Visited on 2001-08-19.

[3]

Buxmann, P.; Martín Díaz, L.; Wüstner, E.: XMLbased Supply Chain Management – As SIMPLEX as it is. Appears in: Proceedings of the Hawaii International Conference on System Sciences (HICCS-35), Hawaii 2002. See also http://www.simplex-platform.com

[4]

Kotok, A.: Extensible and more: An Updated Survey of XML Business Vocabularies. http://www.xml.com/pub/2000/08/02/ebiz/extensi ble.html, August 2000. Visited on 2001-08-23.

[5]

McLaughlin, B.: All About JAXP. ftp://www6.software.ibm.com/ software/developer/library/x-jaxp.pdf, November 2000. Visited on 2001-08-23.

[6]

Oracle Corporation: Oracle8i Concepts: Introduction to the Oracle Server. http://technet.oracle.com/doc/server.815/a67781/c 01intro.htm#15033. Visited on 2001-09-01.

[7]

Pinnacle Software Solutions Inc.: Oracle 8i New Features. Pinnacle Software Solutions Inc., Vienna NC 2001.

[8]

Software AG: Tamino Schema Definition. In: Tamino Documentation for Version 2.2.1, Software AG.

[9]

World Wide Web Consortium: Extensible Markup Language (XML). http://www.w3.org/XML/, May 2000. Visited on 2001-09-01.

[10]

World Wide Web Consortium: Extensible Markup Language (XML) 1.0 (Second Edition) W3C Recommendation. http://www.w3.org/TR/RECxml, October 2000. Visited on 2001-09-01.

[11]

World Wide Web Consortium: Web Style Sheets. http://www.w3.org/Style/, May 2000. Visited on 2001-09-01.