- Email: [email protected]
A distributed EDI model
The Journal of Systems and Software 56 (2001) 1±7
www.elsevier.com/locate/jss
A distributed EDI model q Eric Jui-Lin Lu *, Rong-Ji Hwang Information Management Department, Chaoyang University of Technology, 168 Gifeng E. Rd., Wufeng, Taichung County, Taiwan 413, ROC Received 27 August 1999; received in revised form 10 January 2000; accepted 21 February 2000
Abstract Electronic commerce (EC) has marked a new era for contemporary business. Although electronic data interchange (EDI) is a major component of EC, it is not widely adopted mainly due to high entrance cost and the lack of interoperability among information systems. To alleviate these problems, this paper proposes a distributed model so that EDI transactions can be directly generated from or transformed to either local or remote databases without going through expensive mapping and translation procedures. The most superior outcome of this model is that it combines the advantages of both application-to-application and database-to-database approaches and thus results in an integrated EDI model independent of databases structures, network locations, development languages, etc. Ó 2001 Elsevier Science Inc. All rights reserved. Keywords: EDI; Electronic commerce; Distributed computing; CORBA
1. Introduction It is doubtless that one of the hottest topics in the end of the 20th century is electronic commerce (EC). Forrester Research Inc. projected that the total amount of electronic transactions in the United States would grow from $43 billion dollars in 1998 to $1300 billion dollars by 2003. EC is commonly categorized into (1) Businessto-consumer (B2C) that consumers learn about and purchase products electronically, and (2) Business-tobusiness (B2B) that businesses conduct transactions through computer-to-computer communications (Kalakota and Whinston, 1996). Because the dollar value involved in B2B transactions is much higher than B2C's, B2B is seen as the key to success in the future. Electronic data interchange (EDI) facilitates exchanging of business documents among trading partners electronically. Since business documents are exchanged electronically and entered as well as reused whenever applicable, transaction lead time is shortened, document processing cost is reduced, data errors are minimized due to less human interventions, etc. (Kimberley, 1991) q
This project was supported in part by the National Science Council, Taiwan, ROC, under contract number: NSC-88-2213-E-324-020. * Corresponding author. E-mail address: [email protected] URL: http://www.cyut.edu.tw/jlu/ (E. Jui-Lin Lu).
Despite these advantages, EDI is not widely adopted. It is estimated that less than 5% of businesses in the United States exchange commercial data electronically (Kalakota and Whinston, 1996). The major factors that constraint the acceptance of EDI are high entrance cost and the lack of interoperability among information systems (Iacovou et al., 1995; Kalakota and Whinston, 1996). Traditional EDI utilizes value-added networks (VAN) as communication medium. It is estimated that the average cost of exchanging 1000 messages through VAN is about US$650 per month (Fu et al., 1999). If the Internet is used, it will save up to 50% of the cost. The typical Internet EDI systems provide Web interfaces such that users, especially for those small- and mediumsize enterprises (SMEs), conduct transactions using browsers instead of traditional EDI software (Waltner, 1997; Tucker, 1998; Fu et al., 1999). In essence, the Web-based Internet EDI systems are utilized to replace VAN EDI. Though Internet EDI helps cost reduction, it lack ¯exibility in integration. The implementation of EDI is complex (Adam et al., 1998; Kotok, 1999). An EDI transaction generally constitutes the following tasks: a ¯at ®le is extracted from a database by a mapper; the ¯at ®le is translated into EDI format by a translator; and then the EDI ®le is transmitted to receivers. Since the mapper and the translator depend on the operating systems and
0164-1212/01/$ - see front matter Ó 2001 Elsevier Science Inc. All rights reserved. PII: S 0 1 6 4 - 1 2 1 2 ( 0 0 ) 0 0 0 8 1 - 9
2
E. Jui-Lin Lu, R.-J. Hwang / The Journal of Systems and Software 56 (2001) 1±7
database management systems (DBMSs), a new version of mapper and translator are required once the operating environment is changed. Also, because mapping and translation are generally executed at separate computers, human interventions are required. These problems will be exaggerated if an organization has multiple locations with heterogeneous systems. Therefore, there is a strong need to simplify the separated processes into one automated step and relax the strong dependency of mapping and translation to the operating environment. Furthermore, to provide frictionless information ¯ow in the supply chain, EDI should not only be easily cooperated with existing systems within an organization, but also be collaborated with other systems outside the organization. Adam et al. (1998) proposed a model based on the distributed database concepts. In the model, senders construct EDI messages directly from DBMSs and the messages are transmitted to receivers. Once the messages are received, the receiver then converts the messages directly into databases. Adam's approach allows trading partners exchanging EDI messages via a databaseto-database communication rather than applicationto-application and without requiring tedious process of standardization. However, since the messages are extracted and saved directly from and to DBMSs, the Adam's approach highly depends on operating environment and thus lacks ¯exibility. Fu et al. (1999) developed a Web-based Internet EDI model that oers end-to-end integration. When receiving EDI messages, users transfer the messages into their backend systems using Java applets downloaded from sender's site. The users, after preparing reply documents, transfer the reply documents into a browser using a adapter. Fu's approach provides an inexpensive solution for SMEs. Nevertheless, Fu's approach has several drawbacks. For example, the development of backend systems at the user side is dicult if the user conducts transactions with many businesses using dierent Internet EDI systems; Java applets may impose security problems when the users allow them to access the backend systems (Zhang, 1997; Soh and Young, 1998) etc. In this paper, we propose an ecient and ¯exible distributed EDI model so that an EDI system developed based on this model can be easily installed into any organization and cooperate with systems within and outside the organization. By utilizing modern distributed object techniques, the complexity of integrating EDI with legacy systems is reduced tremendously. From the experience of laboratory experiments, it is seen that the proposed model provides both a ¯exible approach for software developers to implement an ecient EDI system that will run on almost all platforms and encourages businesses to adopt EDI without worrying redesign of their business process or redundant investment in information technology.
In brief, the distributed object technology enables the communication and coordination of information systems distributed among geographically separated computers. These information systems perform tasks collaboratively independent of development platforms. The most well-known distributed object techniques are Java's Remote Method Invocation (RMI) (Sun, 1999; Farley, 1998), the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) (Vogel and Duddy, 1998) and Microsoft's Distributed Component Object Model (DCOM) (Grimes, 1997). In this paper, RMI, DCOM, and CORBA are ®rst brie¯y described. The scenario of using CORBA to integrate EDI with an existing system is also illustrated. This scenario will serve as an important building block of the proposed distributed model. Before the distributed model is presented, traditional EDI and its limitations are reviewed. Then the distributed model is presented. The architecture of the model and the structure of data mapping are described in detail. To study the feasibility of the model, we developed a prototype in two phases. The goal of the ®rst phase is to build up an EDI system from scratch. Then, in the second phase, we integrated the newly developed EDI system with a simple legacy system which provides basic functions such as query, insert, etc. Finally, this paper concludes with the ®ndings of this study and presents future works.
2. Distributed object techniques RMI, a Java class library, was introduced into JDK 1.1. It provides a simple distributed model for Java objects. In general, servers register their services on a RMI server (called RMI Registry). Clients request remote services, without knowing who actually ful®ll their requests, by invoking function calls. After completing services, servers returned messages to the calling clients. A major limitation of RMI is that it only allows interoperability among objects written in Java. DCOM is Microsoft's solution to distributed object computing. Providing similar capability as CORBA, DCOM is well-suited for Microsoft environment. Although DCOM is now promoted by a standard body ± The Open Group (TOG), it is not well supported in the industry (Saleh et al., 1999). CORBA was developed by OMG which is a consortium of over 800 members from the software industry. CORBA allows communications among objects no matter how they are implemented. For example, to allow a client to access a purchase order (PO) from an existing system, interfaces are de®ned using Interface De®nition Language (IDL). The following IDL ®le
E. Jui-Lin Lu, R.-J. Hwang / The Journal of Systems and Software 56 (2001) 1±7
3
Fig. 1. The integration of EDI with legacy system.
de®nes an interface get PO() which returns PO in string and is programming language independent. module EDIIDL { interface EDI { string get PO(); }; }; By using IDL compilers, the IDL ®les are converted into programs required for communications. Two types of programs are created from the conversion: stub (for clients) and skeleton (for servers). Suppose the client is written in Java and the existing system is developed in COBOL, we need a IDL-to-Java compiler to generate stubs and a IDL-to-COBOL compiler to create skeletons. Then, the previously de®ned interfaces for the existing system have to be implemented. The components of the system are shown in Fig. 1. Once the above steps are completed, to generate an EDI message from the legacy system, the EDI system will call the stub, the stub will pass the request to the skeleton which, in turn, will invoke the interface implementation. The interface implementation will call the appropriate functions in the legacy system to retrieve data. The retrieved data will then be passed back, in reverse order, to the EDI system. The path of the above procedure is indicated in dotted lines as shown in Fig. 1. In an ideal situation, the interface implementation simply calls existing functions of the legacy system to perform the required tasks and, thus, no modi®cation to the legacy system is needed. In cases when no existing functions provide the required services, only the required functions have to be implemented into the legacy system. This approach enables software developers or EDI initiators to construct a portable EDI system which includes EDI, IDL, and stub as shown in the picture. Only the interface implementation, plus the required
functions in the legacy system, have to be developed when the EDI system is installed.
3. The distributed EDI model EDI de®nes the standard formats for exchanged commercial data among computers. The most wellknown ones include ANSI ASC X.12 which is mainly used in North America and UN/EDIFACT which is used in the rest of the world. To send an EDI message such as purchase order, the following tasks are generally performed: a ¯at ®le is extracted from a database; the ¯at ®le is transferred to a computer where an EDI translator resides and translated into EDI format; and then the EDI ®le is transmitted to receivers through either email, FTP, or HTTP. The process is depicted in Fig. 2. The conventional EDI model has the following restrictions. Because the commercial data are produced from business applications and usually stored in databases, a speci®c version of mapper is required to extract data from databases. The selection of the mapper is highly dependent on the OSs and DBMSs used. Once the operating environment is changed, a new version of mapper is required. Also, since mapping and translation are generally executed at separate computers, manual interventions are required. These problems will be exaggerated if an organization has multiple locations with heterogeneous systems. Therefore, there is a strong
Fig. 2. The conventional EDI model.
4
E. Jui-Lin Lu, R.-J. Hwang / The Journal of Systems and Software 56 (2001) 1±7
need to simplify the separated processes into one automated step and relax the strong dependency of mapping and translation to the operating environment. Additionally, to provide frictionless information ¯ow in the supply chain, EDI should not only be easily integrated with existing systems within an organization, but also be collaborated with other systems outside the organization.
3.1. Architecture To solve the above problems, this research proposes a distributed EDI model which is depicted in Fig. 3. In the shown model, commercial data are directly extracted from databases or legacy systems through the middleware. The extracted data can be either formatted into EDI messages and transmitted to remote sites or, by utilizing a layer of middleware, connected to and save the data into databases at the receiving side. The main function provided by the middleware is to retrieve data from or save data to legacy systems or databases. A straight approach to implement the middleware is utilizing ODBC, JDBC, or similar protocols to access databases. Since the database de®nitions used in various organizations are generally dierent, a structure of data mapping is required for this approach. The structure of data mapping will be described later. As long as the structure of data mapping is realized, this approach provides an ecient, yet easy-to-be-integrated EDI model. However, since both JDBC and ODBC can only be used with relational databases, this approach cannot be applied to organizations whose databases are not relational.
A more robust approach is to utilize distributed object techniques such as CORBA described in the previous section. In the case that CORBA is implemented, the middleware communicates with the functions of the legacy system, not the databases, and therefore: < sender tablename:fieldname:unit receiver tablename:fieldname:unit > 1. The middleware can access data without knowing the types of databases used in the legacy systems and, thus, provides greater ¯exibility; that is, this approach can also be applied to other types of database systems such as hierarchical databases. 2. The knowledge of data structures is now embedded in IDL ®les which de®ne the required data exchanged between processes and, thus, no data mapping is required. This provides greater ¯exibility and ease of introducing EDI into a business which has its own business applications and thus reduces the entrance cost. 3.2. The structure of data mapping The heterogeneity of business application systems and DBMSs makes data mapping extremely dicult. For example, unit price may be named as unit_price in one database and as unitp at other database. This issue has been addressed by several researchers (Sheth and Larson, 1990; Adam et al., 1998). In this study, we modify the pro®le base approach proposed by Adam et al. (1998). The resulting structure of data mapping is de®ned as tuples and presented in Fig. 4. There are two possible situations. In the situation when the mapping/translation module (MTM), shown
Fig. 3. The distributed EDI model.
Fig. 4. The general structure of data mapping.
E. Jui-Lin Lu, R.-J. Hwang / The Journal of Systems and Software 56 (2001) 1±7
in Fig. 3, saves data directly into databases at the receiving side, sender_tablename.fieldname indicates that MTM selects values from fieldname in sender's database table sender_tablename and receiver_tablename.fieldname indicates that MTM saves values into fieldname of receiver's table receiver_tablename. As the unit price example described above, the data mapping tuple will be: < pur order:unit pricepo:unitp > Each element of EDI transactions may be associated with a unit. For example, the unit for unit price can be US dollar or Japanese Yen. To transfer commercial data at one end whose unit is in US dollar to other end whose unit is in Japanese Yen, it is required to calculate the unit price correctly. In addition to formula required for the calculation, it is necessary to provide unit information. The unit shown in Fig. 4 is optional and used to indicate the unit associated with the ®eld. The MTM uses the information and appropriate formula for calculation. Again, as the unit price example described above, the data mapping tuple will be: < pur order:unit price:usdpo:unitp:yen > In the situation the output of the MTM is merely a plain EDI text ®le, the meaning of sender_tablename.fieldname is the same as the previous situation, but receiver_tablename.fieldname simply represents its corresponding EDI tag name. There will be no need of using unit at all since the information will be inserted into EDI messages directly. 3.3. Analysis The proposed distributed EDI model is a combination of both application-to-application and databaseto-database approaches (Adam et al., 1998) and thus provides the following advantages: · Increasing ¯exibility: This model provides both application-to-application and database-to-database approaches for EDI transactions. Businesses can use whichever approach ®ts their operations. · Less complex: Due to modern techniques such as Java and CORBA, it is now possible to develop an EDI system which can run on almost any platform and be easily integrated with existing systems. · Better performance: If commercial data is retrieved from sender's database and then saved directly into receiver's database, the performance is better because of the elimination of expensive translation task. · Reduction in transaction cost: Since the new model does not require any human intervention once installed, labor cost and error rate will be reduced. Although security is not considered so far and not implemented in our prototype, the secrecy of the model can be achieved in the following manner:
5
· For EDI messages transmitted through WWW and Mail, secure socket layer (SSL) and privacy enhanced mail (PEM) can be employed, respectively (Lu and Tsai, 1999). · The OMG Security Special Interest Group has been seriously working on CORBA security services. Once the modules of the CORBA security services are developed, we can simply incorporate them into our model. 4. Implementation To investigate the feasibility and eectiveness of the proposed model, we developed a prototype based on the model. The development was accomplished in two phases. The goal of the ®rst phase is to build up an EDI system, based on the model, from scratch. Then, in the second phase, we integrated the newly developed EDI system into a simple legacy system which provides basic functions such as query, insert, etc. In the ®rst phase, we developed an EDI system which is capable of handling EDI messages in compliance with 96A version of UN/EDIFACT standard. The user interface module provides functions including con®guration, data entry, etc. Based on the data mapping tuples, the MTM retrieves data from databases and then translates them into EDI format. The MTM can also receive EDI data sent from trading partners and then save the data into databases for further processing. The whole system is developed in Java due to its portability among platforms. JDBC is utilized to access databases. In the prototype, two kinds of user interfaces are implemented and they are either Java programs which request services from servers or HTML forms which request services through Java servlet. In the second phase of the development, the existence of a legacy system is considered. The goal of this phase is to study the ease of the proposed distributed model in incorporating an EDI system into an existing system. The system architecture is shown in Fig. 5. An information system was developed in Java and used as the existing system. This system is capable of performing simple query, add, delete, and update on databases. Also, we created an IDL ®le containing four interface de®nitions required for EDI transactions and compiled the IDL ®le to obtain stubs. To install the EDI system into the existing system, all we did was to generate skeletons from the IDL ®le and implement the interfaces described in the IDL ®le. VisiBroker for Java 3.2, conforming to CORBA 2.0, is used in this project. Sample screen shots are provided in Fig. 6. The window on the left is a Java application which allows users to enter EDI data. The windows on the right demonstrate the batch mode of extracting data from the existing system and converting the data into EDI format.
6
E. Jui-Lin Lu, R.-J. Hwang / The Journal of Systems and Software 56 (2001) 1±7
Fig. 5. The CORBA-based system architecture.
Fig. 6. Sample screen shots from the CORBA-based EDI.
There are less than 200 lines of codes added which include the de®nition of interfaces using IDL and the implementation codes of the interfaces. From the experience of laboratory experiments, it is clear that little modi®cation is required to the existing system. Furthermore, because commercial data are accessed through the legacy system, the proposed model is not restricted to relational DBMSs and thus provides greater ¯exibility. Note that, although not shown in the picture, to store EDI data directly into a remote legacy system, it is a simple task of applying another layer of middleware which constitutes stub, skeleton, and interface implementation. Therefore, the proposed model can provide frictionless information ¯ow in supply chain. From various development experiments, we found that this system can be easily ported to many platforms. The tested platforms include Win32 systems (including Windows 95/98 and Windows NT), Red Hat Linux, and Sun Solaris. The DBMSs used include Microsoft's SQL Server and Access as well as Hughes Technologies's mSQL.
5. Conclusions EDI is a major component of EC. It should be portable so that no duplicate investment is necessary. It should prevent human interventions so that transaction
cost is minimized. It should be easy to be incorporated in legacy systems so that maintenance cost is decreased and previous investment is reserved. In this paper, we designed an ecient and ¯exible distributed EDI model. Also, we implemented a prototype based on this model and found that this model is applicable to either a new installation of the EDI system or incorporation EDI in legacy systems. Although the proposed model has been successfully implemented in a near-real environment, cautions should be taken when generalizing the proposed model to the real world case. Recently, XML/EDI has been seen, by many researchers, as the next generation of EDI (Ogbuji, 1999). Since commercial data is now described in XML format, it would be interesting to ®nd out the possibility of merging XML data into the proposed model. Appendix A module SqlIdl{ typedef sequence DataList; interface SqlSyntax{ long TodatabaseIn(in DataList comp, in DataList compaddr, in string ordate, in string reqdate, in DataList goodsname, in string ordnum, in DataList quantity, in DataList unit, in string payconditionclass, in string paycondition, in string
E. Jui-Lin Lu, R.-J. Hwang / The Journal of Systems and Software 56 (2001) 1±7
transmode, in DataList sentlocalid); long ToEnt(in string entnum, in string ordate, in string reqdate, in DataList entgoodsname, in DataList entcomp, in DataList entsellcomp, in string extworknum, in string oriordnum, in string payconditionclass, in string paycondition, in DataList wafer, in DataList gooddie, in DataList die, in DataList entimdinfo, in DataList dienum, in DataList waferbat, in DataList entprice, in string transmode, in string locaddr); long ToDes(in DataList descomp, in DataList dessellcomp, in string desnum, in string desdate, in DataList trangoodsname, in string meaunit, in string meanum, in string ordate, in DataList descompaddr, in DataList typenum, in DataList desgoodq, in DataList desbadq, in DataList batchnum, in DataList moaprice, in DataList on, in string transmode, in string addr2); long ToRsp(in string rspnum, in string ordate, in string rspdate, in string reqdate, in DataList rspon, in DataList rspcomp, in DataList rspsellcomp, in string payconditionclass, in string paycondition, in string patdetail, in string deltermsclass, in string toddetail, in DataList rspgoodsname, in DataList rspordq, in DataList rspordunit, in string purnum, in string pritype, in string oneprice, in DataList sentlocalid, in DataList sentlocal, in DataList rspprice, in string transmode, in string change); }; References Adam, N., Adiwijaya, I., Atluri, V., 1998. EDI through a distributed information systems approach. In: Proceedings of 31st Annual Hawaii International Conference on System Sciences, pp. 354±363.
7
Farley, J., 1998. Java Distributed Programming. O'Reilly. Shiwa Fu, Jen-Yao Chung, Walter Dietrich, Vibby Gottemukala, Mitchell Cohen, Shyhkwei Chen, 1999. A practical approach to web-based internet EDI. In: Proceedings of the 19th IEEE International Conference on Distributed Computing Systems Workshops on Electronic Commerce and Web-based Applications/Middleware, pp. 53±58. Grimes, R., 1997. Professional DCOM Programming. Wrox Press, 1997. Iacovou, C.L., Benbasat, I., Dexter, A., 1995. Electronic data interchange and small organizations: Adoption and impact of technology. MIS Quarterly, 465±485. Kalakota, R., Whinston, A.B., 1996. Frontiers of Electronic Commerce. Addison-Wesley, Reading, MA. Kimberley, P., 1991. Electronic Data Interchange. McGraw-Hill, New York. Kotok, A., 1999. Introduction to XML and EDI. http://www.xml.com/ pub/1999/08/edi/index.html, August 1999. Eric Jui-Lin Lu, Ru-Hui Tsai, 1999. A secure internet EDI (SIEDI). In: 1999 Conference on the Theories and Practices of Commercial Automation, pp. 323±344 (in Chinese). Uche Ogbuji, 1999. XML: The future of EDI? SunWorld, http:// www.sunworld.com/sunworldonline/swol-02-1999/swol-02-xmledi.html. Sun White Paper, 1999. Java remote method invocation ± distributed computing for Java. http://java.sun.com/marketing/collateral/ javarmi.html. Saleh, K., Probert, R., Khanafer, H., 1999. The distributed object computing paradigm: concepts and applications. Journal of Systems and Software 47, 125±131. Sheth, A., Larson, J., 1990. Federated database systems for managing distributed, hetergeneous, and autonomous databases. ACM Transactions on Database Systems 22 (3), 183±236. Soh, B.C., Young, S., 1998. Distributed computing: an experimental investigation of a malicious denial-of-service applet. Computer Communications 21, 670±674. Tucker, M.J., 1998. EDI and the Net: A pro®table partnering. http:// www.developer.com /journal/ITfocus/101298_tucker.html. Vogel, A., Duddy, K., 1998. Java Programming with CORBA, 2nd ed. Wiley, New York. Waltner, C., 1997. EDI travels the Web. Communications Week (June) 55±58. X. Nick Zhang, 1997. Secure code distribution. IEEE Computer (June) 76±79. Eric Jui-Lin Lu received his B.S. degree in Transportation Engineering and Management from National Chiao Tung University, Taiwan, ROC, in 1982; M.S. degree in Computer Information Systems from San Francisco State University, California, USA, in 1990; and Ph.D. degree in Computer Science from University of Missouri-Rolla, Missouri, USA, in 1996. He is currently an associate professor and vice chairman of the Department of Information Management, Chaoyang University of Technology, Taiwan, ROC. His current research interests include electronic commerce, distributed processing, and security. Rong-Ji Hwang received his B.S. degree in Information Management from Chaoyang University of Technology, Taiwan, ROC, in 2000. His current research interests include electronic commerce and distributed processing.
www.elsevier.com/locate/jss
A distributed EDI model q Eric Jui-Lin Lu *, Rong-Ji Hwang Information Management Department, Chaoyang University of Technology, 168 Gifeng E. Rd., Wufeng, Taichung County, Taiwan 413, ROC Received 27 August 1999; received in revised form 10 January 2000; accepted 21 February 2000
Abstract Electronic commerce (EC) has marked a new era for contemporary business. Although electronic data interchange (EDI) is a major component of EC, it is not widely adopted mainly due to high entrance cost and the lack of interoperability among information systems. To alleviate these problems, this paper proposes a distributed model so that EDI transactions can be directly generated from or transformed to either local or remote databases without going through expensive mapping and translation procedures. The most superior outcome of this model is that it combines the advantages of both application-to-application and database-to-database approaches and thus results in an integrated EDI model independent of databases structures, network locations, development languages, etc. Ó 2001 Elsevier Science Inc. All rights reserved. Keywords: EDI; Electronic commerce; Distributed computing; CORBA
1. Introduction It is doubtless that one of the hottest topics in the end of the 20th century is electronic commerce (EC). Forrester Research Inc. projected that the total amount of electronic transactions in the United States would grow from $43 billion dollars in 1998 to $1300 billion dollars by 2003. EC is commonly categorized into (1) Businessto-consumer (B2C) that consumers learn about and purchase products electronically, and (2) Business-tobusiness (B2B) that businesses conduct transactions through computer-to-computer communications (Kalakota and Whinston, 1996). Because the dollar value involved in B2B transactions is much higher than B2C's, B2B is seen as the key to success in the future. Electronic data interchange (EDI) facilitates exchanging of business documents among trading partners electronically. Since business documents are exchanged electronically and entered as well as reused whenever applicable, transaction lead time is shortened, document processing cost is reduced, data errors are minimized due to less human interventions, etc. (Kimberley, 1991) q
This project was supported in part by the National Science Council, Taiwan, ROC, under contract number: NSC-88-2213-E-324-020. * Corresponding author. E-mail address: [email protected] URL: http://www.cyut.edu.tw/jlu/ (E. Jui-Lin Lu).
Despite these advantages, EDI is not widely adopted. It is estimated that less than 5% of businesses in the United States exchange commercial data electronically (Kalakota and Whinston, 1996). The major factors that constraint the acceptance of EDI are high entrance cost and the lack of interoperability among information systems (Iacovou et al., 1995; Kalakota and Whinston, 1996). Traditional EDI utilizes value-added networks (VAN) as communication medium. It is estimated that the average cost of exchanging 1000 messages through VAN is about US$650 per month (Fu et al., 1999). If the Internet is used, it will save up to 50% of the cost. The typical Internet EDI systems provide Web interfaces such that users, especially for those small- and mediumsize enterprises (SMEs), conduct transactions using browsers instead of traditional EDI software (Waltner, 1997; Tucker, 1998; Fu et al., 1999). In essence, the Web-based Internet EDI systems are utilized to replace VAN EDI. Though Internet EDI helps cost reduction, it lack ¯exibility in integration. The implementation of EDI is complex (Adam et al., 1998; Kotok, 1999). An EDI transaction generally constitutes the following tasks: a ¯at ®le is extracted from a database by a mapper; the ¯at ®le is translated into EDI format by a translator; and then the EDI ®le is transmitted to receivers. Since the mapper and the translator depend on the operating systems and
0164-1212/01/$ - see front matter Ó 2001 Elsevier Science Inc. All rights reserved. PII: S 0 1 6 4 - 1 2 1 2 ( 0 0 ) 0 0 0 8 1 - 9
2
E. Jui-Lin Lu, R.-J. Hwang / The Journal of Systems and Software 56 (2001) 1±7
database management systems (DBMSs), a new version of mapper and translator are required once the operating environment is changed. Also, because mapping and translation are generally executed at separate computers, human interventions are required. These problems will be exaggerated if an organization has multiple locations with heterogeneous systems. Therefore, there is a strong need to simplify the separated processes into one automated step and relax the strong dependency of mapping and translation to the operating environment. Furthermore, to provide frictionless information ¯ow in the supply chain, EDI should not only be easily cooperated with existing systems within an organization, but also be collaborated with other systems outside the organization. Adam et al. (1998) proposed a model based on the distributed database concepts. In the model, senders construct EDI messages directly from DBMSs and the messages are transmitted to receivers. Once the messages are received, the receiver then converts the messages directly into databases. Adam's approach allows trading partners exchanging EDI messages via a databaseto-database communication rather than applicationto-application and without requiring tedious process of standardization. However, since the messages are extracted and saved directly from and to DBMSs, the Adam's approach highly depends on operating environment and thus lacks ¯exibility. Fu et al. (1999) developed a Web-based Internet EDI model that oers end-to-end integration. When receiving EDI messages, users transfer the messages into their backend systems using Java applets downloaded from sender's site. The users, after preparing reply documents, transfer the reply documents into a browser using a adapter. Fu's approach provides an inexpensive solution for SMEs. Nevertheless, Fu's approach has several drawbacks. For example, the development of backend systems at the user side is dicult if the user conducts transactions with many businesses using dierent Internet EDI systems; Java applets may impose security problems when the users allow them to access the backend systems (Zhang, 1997; Soh and Young, 1998) etc. In this paper, we propose an ecient and ¯exible distributed EDI model so that an EDI system developed based on this model can be easily installed into any organization and cooperate with systems within and outside the organization. By utilizing modern distributed object techniques, the complexity of integrating EDI with legacy systems is reduced tremendously. From the experience of laboratory experiments, it is seen that the proposed model provides both a ¯exible approach for software developers to implement an ecient EDI system that will run on almost all platforms and encourages businesses to adopt EDI without worrying redesign of their business process or redundant investment in information technology.
In brief, the distributed object technology enables the communication and coordination of information systems distributed among geographically separated computers. These information systems perform tasks collaboratively independent of development platforms. The most well-known distributed object techniques are Java's Remote Method Invocation (RMI) (Sun, 1999; Farley, 1998), the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) (Vogel and Duddy, 1998) and Microsoft's Distributed Component Object Model (DCOM) (Grimes, 1997). In this paper, RMI, DCOM, and CORBA are ®rst brie¯y described. The scenario of using CORBA to integrate EDI with an existing system is also illustrated. This scenario will serve as an important building block of the proposed distributed model. Before the distributed model is presented, traditional EDI and its limitations are reviewed. Then the distributed model is presented. The architecture of the model and the structure of data mapping are described in detail. To study the feasibility of the model, we developed a prototype in two phases. The goal of the ®rst phase is to build up an EDI system from scratch. Then, in the second phase, we integrated the newly developed EDI system with a simple legacy system which provides basic functions such as query, insert, etc. Finally, this paper concludes with the ®ndings of this study and presents future works.
2. Distributed object techniques RMI, a Java class library, was introduced into JDK 1.1. It provides a simple distributed model for Java objects. In general, servers register their services on a RMI server (called RMI Registry). Clients request remote services, without knowing who actually ful®ll their requests, by invoking function calls. After completing services, servers returned messages to the calling clients. A major limitation of RMI is that it only allows interoperability among objects written in Java. DCOM is Microsoft's solution to distributed object computing. Providing similar capability as CORBA, DCOM is well-suited for Microsoft environment. Although DCOM is now promoted by a standard body ± The Open Group (TOG), it is not well supported in the industry (Saleh et al., 1999). CORBA was developed by OMG which is a consortium of over 800 members from the software industry. CORBA allows communications among objects no matter how they are implemented. For example, to allow a client to access a purchase order (PO) from an existing system, interfaces are de®ned using Interface De®nition Language (IDL). The following IDL ®le
E. Jui-Lin Lu, R.-J. Hwang / The Journal of Systems and Software 56 (2001) 1±7
3
Fig. 1. The integration of EDI with legacy system.
de®nes an interface get PO() which returns PO in string and is programming language independent. module EDIIDL { interface EDI { string get PO(); }; }; By using IDL compilers, the IDL ®les are converted into programs required for communications. Two types of programs are created from the conversion: stub (for clients) and skeleton (for servers). Suppose the client is written in Java and the existing system is developed in COBOL, we need a IDL-to-Java compiler to generate stubs and a IDL-to-COBOL compiler to create skeletons. Then, the previously de®ned interfaces for the existing system have to be implemented. The components of the system are shown in Fig. 1. Once the above steps are completed, to generate an EDI message from the legacy system, the EDI system will call the stub, the stub will pass the request to the skeleton which, in turn, will invoke the interface implementation. The interface implementation will call the appropriate functions in the legacy system to retrieve data. The retrieved data will then be passed back, in reverse order, to the EDI system. The path of the above procedure is indicated in dotted lines as shown in Fig. 1. In an ideal situation, the interface implementation simply calls existing functions of the legacy system to perform the required tasks and, thus, no modi®cation to the legacy system is needed. In cases when no existing functions provide the required services, only the required functions have to be implemented into the legacy system. This approach enables software developers or EDI initiators to construct a portable EDI system which includes EDI, IDL, and stub as shown in the picture. Only the interface implementation, plus the required
functions in the legacy system, have to be developed when the EDI system is installed.
3. The distributed EDI model EDI de®nes the standard formats for exchanged commercial data among computers. The most wellknown ones include ANSI ASC X.12 which is mainly used in North America and UN/EDIFACT which is used in the rest of the world. To send an EDI message such as purchase order, the following tasks are generally performed: a ¯at ®le is extracted from a database; the ¯at ®le is transferred to a computer where an EDI translator resides and translated into EDI format; and then the EDI ®le is transmitted to receivers through either email, FTP, or HTTP. The process is depicted in Fig. 2. The conventional EDI model has the following restrictions. Because the commercial data are produced from business applications and usually stored in databases, a speci®c version of mapper is required to extract data from databases. The selection of the mapper is highly dependent on the OSs and DBMSs used. Once the operating environment is changed, a new version of mapper is required. Also, since mapping and translation are generally executed at separate computers, manual interventions are required. These problems will be exaggerated if an organization has multiple locations with heterogeneous systems. Therefore, there is a strong
Fig. 2. The conventional EDI model.
4
E. Jui-Lin Lu, R.-J. Hwang / The Journal of Systems and Software 56 (2001) 1±7
need to simplify the separated processes into one automated step and relax the strong dependency of mapping and translation to the operating environment. Additionally, to provide frictionless information ¯ow in the supply chain, EDI should not only be easily integrated with existing systems within an organization, but also be collaborated with other systems outside the organization.
3.1. Architecture To solve the above problems, this research proposes a distributed EDI model which is depicted in Fig. 3. In the shown model, commercial data are directly extracted from databases or legacy systems through the middleware. The extracted data can be either formatted into EDI messages and transmitted to remote sites or, by utilizing a layer of middleware, connected to and save the data into databases at the receiving side. The main function provided by the middleware is to retrieve data from or save data to legacy systems or databases. A straight approach to implement the middleware is utilizing ODBC, JDBC, or similar protocols to access databases. Since the database de®nitions used in various organizations are generally dierent, a structure of data mapping is required for this approach. The structure of data mapping will be described later. As long as the structure of data mapping is realized, this approach provides an ecient, yet easy-to-be-integrated EDI model. However, since both JDBC and ODBC can only be used with relational databases, this approach cannot be applied to organizations whose databases are not relational.
A more robust approach is to utilize distributed object techniques such as CORBA described in the previous section. In the case that CORBA is implemented, the middleware communicates with the functions of the legacy system, not the databases, and therefore: < sender tablename:fieldname:unit receiver tablename:fieldname:unit > 1. The middleware can access data without knowing the types of databases used in the legacy systems and, thus, provides greater ¯exibility; that is, this approach can also be applied to other types of database systems such as hierarchical databases. 2. The knowledge of data structures is now embedded in IDL ®les which de®ne the required data exchanged between processes and, thus, no data mapping is required. This provides greater ¯exibility and ease of introducing EDI into a business which has its own business applications and thus reduces the entrance cost. 3.2. The structure of data mapping The heterogeneity of business application systems and DBMSs makes data mapping extremely dicult. For example, unit price may be named as unit_price in one database and as unitp at other database. This issue has been addressed by several researchers (Sheth and Larson, 1990; Adam et al., 1998). In this study, we modify the pro®le base approach proposed by Adam et al. (1998). The resulting structure of data mapping is de®ned as tuples and presented in Fig. 4. There are two possible situations. In the situation when the mapping/translation module (MTM), shown
Fig. 3. The distributed EDI model.
Fig. 4. The general structure of data mapping.
E. Jui-Lin Lu, R.-J. Hwang / The Journal of Systems and Software 56 (2001) 1±7
in Fig. 3, saves data directly into databases at the receiving side, sender_tablename.fieldname indicates that MTM selects values from fieldname in sender's database table sender_tablename and receiver_tablename.fieldname indicates that MTM saves values into fieldname of receiver's table receiver_tablename. As the unit price example described above, the data mapping tuple will be: < pur order:unit pricepo:unitp > Each element of EDI transactions may be associated with a unit. For example, the unit for unit price can be US dollar or Japanese Yen. To transfer commercial data at one end whose unit is in US dollar to other end whose unit is in Japanese Yen, it is required to calculate the unit price correctly. In addition to formula required for the calculation, it is necessary to provide unit information. The unit shown in Fig. 4 is optional and used to indicate the unit associated with the ®eld. The MTM uses the information and appropriate formula for calculation. Again, as the unit price example described above, the data mapping tuple will be: < pur order:unit price:usdpo:unitp:yen > In the situation the output of the MTM is merely a plain EDI text ®le, the meaning of sender_tablename.fieldname is the same as the previous situation, but receiver_tablename.fieldname simply represents its corresponding EDI tag name. There will be no need of using unit at all since the information will be inserted into EDI messages directly. 3.3. Analysis The proposed distributed EDI model is a combination of both application-to-application and databaseto-database approaches (Adam et al., 1998) and thus provides the following advantages: · Increasing ¯exibility: This model provides both application-to-application and database-to-database approaches for EDI transactions. Businesses can use whichever approach ®ts their operations. · Less complex: Due to modern techniques such as Java and CORBA, it is now possible to develop an EDI system which can run on almost any platform and be easily integrated with existing systems. · Better performance: If commercial data is retrieved from sender's database and then saved directly into receiver's database, the performance is better because of the elimination of expensive translation task. · Reduction in transaction cost: Since the new model does not require any human intervention once installed, labor cost and error rate will be reduced. Although security is not considered so far and not implemented in our prototype, the secrecy of the model can be achieved in the following manner:
5
· For EDI messages transmitted through WWW and Mail, secure socket layer (SSL) and privacy enhanced mail (PEM) can be employed, respectively (Lu and Tsai, 1999). · The OMG Security Special Interest Group has been seriously working on CORBA security services. Once the modules of the CORBA security services are developed, we can simply incorporate them into our model. 4. Implementation To investigate the feasibility and eectiveness of the proposed model, we developed a prototype based on the model. The development was accomplished in two phases. The goal of the ®rst phase is to build up an EDI system, based on the model, from scratch. Then, in the second phase, we integrated the newly developed EDI system into a simple legacy system which provides basic functions such as query, insert, etc. In the ®rst phase, we developed an EDI system which is capable of handling EDI messages in compliance with 96A version of UN/EDIFACT standard. The user interface module provides functions including con®guration, data entry, etc. Based on the data mapping tuples, the MTM retrieves data from databases and then translates them into EDI format. The MTM can also receive EDI data sent from trading partners and then save the data into databases for further processing. The whole system is developed in Java due to its portability among platforms. JDBC is utilized to access databases. In the prototype, two kinds of user interfaces are implemented and they are either Java programs which request services from servers or HTML forms which request services through Java servlet. In the second phase of the development, the existence of a legacy system is considered. The goal of this phase is to study the ease of the proposed distributed model in incorporating an EDI system into an existing system. The system architecture is shown in Fig. 5. An information system was developed in Java and used as the existing system. This system is capable of performing simple query, add, delete, and update on databases. Also, we created an IDL ®le containing four interface de®nitions required for EDI transactions and compiled the IDL ®le to obtain stubs. To install the EDI system into the existing system, all we did was to generate skeletons from the IDL ®le and implement the interfaces described in the IDL ®le. VisiBroker for Java 3.2, conforming to CORBA 2.0, is used in this project. Sample screen shots are provided in Fig. 6. The window on the left is a Java application which allows users to enter EDI data. The windows on the right demonstrate the batch mode of extracting data from the existing system and converting the data into EDI format.
6
E. Jui-Lin Lu, R.-J. Hwang / The Journal of Systems and Software 56 (2001) 1±7
Fig. 5. The CORBA-based system architecture.
Fig. 6. Sample screen shots from the CORBA-based EDI.
There are less than 200 lines of codes added which include the de®nition of interfaces using IDL and the implementation codes of the interfaces. From the experience of laboratory experiments, it is clear that little modi®cation is required to the existing system. Furthermore, because commercial data are accessed through the legacy system, the proposed model is not restricted to relational DBMSs and thus provides greater ¯exibility. Note that, although not shown in the picture, to store EDI data directly into a remote legacy system, it is a simple task of applying another layer of middleware which constitutes stub, skeleton, and interface implementation. Therefore, the proposed model can provide frictionless information ¯ow in supply chain. From various development experiments, we found that this system can be easily ported to many platforms. The tested platforms include Win32 systems (including Windows 95/98 and Windows NT), Red Hat Linux, and Sun Solaris. The DBMSs used include Microsoft's SQL Server and Access as well as Hughes Technologies's mSQL.
5. Conclusions EDI is a major component of EC. It should be portable so that no duplicate investment is necessary. It should prevent human interventions so that transaction
cost is minimized. It should be easy to be incorporated in legacy systems so that maintenance cost is decreased and previous investment is reserved. In this paper, we designed an ecient and ¯exible distributed EDI model. Also, we implemented a prototype based on this model and found that this model is applicable to either a new installation of the EDI system or incorporation EDI in legacy systems. Although the proposed model has been successfully implemented in a near-real environment, cautions should be taken when generalizing the proposed model to the real world case. Recently, XML/EDI has been seen, by many researchers, as the next generation of EDI (Ogbuji, 1999). Since commercial data is now described in XML format, it would be interesting to ®nd out the possibility of merging XML data into the proposed model. Appendix A module SqlIdl{ typedef sequence
E. Jui-Lin Lu, R.-J. Hwang / The Journal of Systems and Software 56 (2001) 1±7
transmode, in DataList sentlocalid); long ToEnt(in string entnum, in string ordate, in string reqdate, in DataList entgoodsname, in DataList entcomp, in DataList entsellcomp, in string extworknum, in string oriordnum, in string payconditionclass, in string paycondition, in DataList wafer, in DataList gooddie, in DataList die, in DataList entimdinfo, in DataList dienum, in DataList waferbat, in DataList entprice, in string transmode, in string locaddr); long ToDes(in DataList descomp, in DataList dessellcomp, in string desnum, in string desdate, in DataList trangoodsname, in string meaunit, in string meanum, in string ordate, in DataList descompaddr, in DataList typenum, in DataList desgoodq, in DataList desbadq, in DataList batchnum, in DataList moaprice, in DataList on, in string transmode, in string addr2); long ToRsp(in string rspnum, in string ordate, in string rspdate, in string reqdate, in DataList rspon, in DataList rspcomp, in DataList rspsellcomp, in string payconditionclass, in string paycondition, in string patdetail, in string deltermsclass, in string toddetail, in DataList rspgoodsname, in DataList rspordq, in DataList rspordunit, in string purnum, in string pritype, in string oneprice, in DataList sentlocalid, in DataList sentlocal, in DataList rspprice, in string transmode, in string change); }; References Adam, N., Adiwijaya, I., Atluri, V., 1998. EDI through a distributed information systems approach. In: Proceedings of 31st Annual Hawaii International Conference on System Sciences, pp. 354±363.
7
Farley, J., 1998. Java Distributed Programming. O'Reilly. Shiwa Fu, Jen-Yao Chung, Walter Dietrich, Vibby Gottemukala, Mitchell Cohen, Shyhkwei Chen, 1999. A practical approach to web-based internet EDI. In: Proceedings of the 19th IEEE International Conference on Distributed Computing Systems Workshops on Electronic Commerce and Web-based Applications/Middleware, pp. 53±58. Grimes, R., 1997. Professional DCOM Programming. Wrox Press, 1997. Iacovou, C.L., Benbasat, I., Dexter, A., 1995. Electronic data interchange and small organizations: Adoption and impact of technology. MIS Quarterly, 465±485. Kalakota, R., Whinston, A.B., 1996. Frontiers of Electronic Commerce. Addison-Wesley, Reading, MA. Kimberley, P., 1991. Electronic Data Interchange. McGraw-Hill, New York. Kotok, A., 1999. Introduction to XML and EDI. http://www.xml.com/ pub/1999/08/edi/index.html, August 1999. Eric Jui-Lin Lu, Ru-Hui Tsai, 1999. A secure internet EDI (SIEDI). In: 1999 Conference on the Theories and Practices of Commercial Automation, pp. 323±344 (in Chinese). Uche Ogbuji, 1999. XML: The future of EDI? SunWorld, http:// www.sunworld.com/sunworldonline/swol-02-1999/swol-02-xmledi.html. Sun White Paper, 1999. Java remote method invocation ± distributed computing for Java. http://java.sun.com/marketing/collateral/ javarmi.html. Saleh, K., Probert, R., Khanafer, H., 1999. The distributed object computing paradigm: concepts and applications. Journal of Systems and Software 47, 125±131. Sheth, A., Larson, J., 1990. Federated database systems for managing distributed, hetergeneous, and autonomous databases. ACM Transactions on Database Systems 22 (3), 183±236. Soh, B.C., Young, S., 1998. Distributed computing: an experimental investigation of a malicious denial-of-service applet. Computer Communications 21, 670±674. Tucker, M.J., 1998. EDI and the Net: A pro®table partnering. http:// www.developer.com /journal/ITfocus/101298_tucker.html. Vogel, A., Duddy, K., 1998. Java Programming with CORBA, 2nd ed. Wiley, New York. Waltner, C., 1997. EDI travels the Web. Communications Week (June) 55±58. X. Nick Zhang, 1997. Secure code distribution. IEEE Computer (June) 76±79. Eric Jui-Lin Lu received his B.S. degree in Transportation Engineering and Management from National Chiao Tung University, Taiwan, ROC, in 1982; M.S. degree in Computer Information Systems from San Francisco State University, California, USA, in 1990; and Ph.D. degree in Computer Science from University of Missouri-Rolla, Missouri, USA, in 1996. He is currently an associate professor and vice chairman of the Department of Information Management, Chaoyang University of Technology, Taiwan, ROC. His current research interests include electronic commerce, distributed processing, and security. Rong-Ji Hwang received his B.S. degree in Information Management from Chaoyang University of Technology, Taiwan, ROC, in 2000. His current research interests include electronic commerce and distributed processing.