Applying a mediator architecture employing XML to retailing inventory control

Applying a mediator architecture employing XML to retailinginventory control

Stephen Chan *, Tharam Dillon, Andrew Siu

Room PQ818, Department of Computing, Hong Kong Polytechnic University, Hung Hom, Kowloon, Hong Kong

Received 1 June 2000; received in revised form 1 December 2000; accepted 1 March 2001

Abstract

The concept of mediation has been successfully applied to the development of distributed information systems, where medi-

ators form the middle tier between client applications and data resources, providing valuable abstraction and integration func-

tions. Extensible MarkUp Language (XML) has been used to develop self-describing data models and common interfaces for

mediators to be deployed in Web-based information systems. This makes such systems easier to develop, to maintain, and to

evolve. This paper discusses the design of such an architecture and its application in retail inventory control in electronic com-

merce (e-commerce). The prototype system is implemented with Java Servlets and CORBA. � 2002 Elsevier Science Inc. All rights

reserved.

Keywords: Mediators; XML; E-commerce

1. Introduction

The emergence of electronic commerce (e-commerce)poses new challenges to many businesses. The tradi-tional c-centric applications require permanent networkconnections between the frontends and the hosts, e.g., inthe form of expensive leased lines. The currently populartwo-tier client–server applications reduce the depen-dency on the permanent network connection, but theycannot be easily ported to the Internet environmentwhich has become the preferred environment for e-commerce. The main reason is that in two-tier client–server design, client components typically incorporate alot of processing logic, resulting in thick clients. Thickclient design is not an easy design to put into the In-ternet environment, because of problems such as longdownloading time and platform dependency. In addi-tion, the cost and ease of maintenance is a major con-sideration. It is difficult and risky to update a largenumber of thick client programs in a short period oftime (e.g., over-night for the many outlets of a chainstore). In case the update cannot be completed suc-cessfully, the time window may be too short to back-outsafely. Thin client design provides one possible solution.

However, if the client is too thin, it does not providemuch value. The burden of customer interface logic willbe pushed back to the server.

The use of domain-specific value-added middleware,in the form of mediators, provides a way for right-sizingthe three layers: client, middle-tier server and the back-end. Besides ease of maintenance, using the mediatorapproach provides an easier way for creating new ser-vices for clients. Through well-defined mediator–clientinterface standards it is easier for clients to use newservices from the original mediators or to obtain servicesfrom new mediators. One of the problems of usingmediators, however, is that the databases and their as-sociated data models, which these mediators access, tendto evolve. It is generally impractical to expect the me-diator administrator to continually access these datamodels manually in order to update them. Some meansof producing machine-readable data model descriptionshas to be provided. Extensible MarkUp Language(XML) provides a framework for describing structureddata in a uniform way independent of applications andvendors, and is designed for deployment on the Web.For these reasons, XML has been chosen to develop andto standardize the data models at the mediator tier, andthe interface between client applications and the medi-ators. This provides a facility for semi-automaticmaintenance of the mediators.

www.elsevier.com/locate/jssThe Journal of Systems and Software 60 (2002) 239–248

*Corresponding author. Tel.: +852-2766-7259; fax: +852-2170-0108.

E-mail address: [email protected] (S. Chan).

0164-1212/02/$ - see front matter � 2002 Elsevier Science Inc. All rights reserved.

PII: S0164 -1212 (01)00095 -4

We have chosen inventory control in retail as a testcase for the XML/mediator-based architecture. All overthe world, a major trend in retailing is to have chainstores consisting of relatively small outlets spread overwide geographic areas. The chain store operation modelcreates challenges for traditional inventory control ap-plications. Since data is constantly flowing between theoutlets and the back office, inventory control applica-tions must be able to consolidate those distributed dataon time to produce accurate information. They facemany of the same problems faced by other e-commerceapplications.

The Web and the distributed object system is a goodcombination for delivering distributed applications.Much research have been done to develop suitable de-signs for the integration. For example, Rees et al. (1996)studied the use of the HTTP-IIOP gateway; Merle et al.(1996) developed CorbaWeb, a CORBA-extended CGIscript; and Tigue and Lavinder (1998) developed anXML-based distributed object definition. This paper isaimed at developing an architecture using well-knownstandards to integrate the Web and distributed systems,with the emphasis on retail applications for e-commerce.

2. Mediator-based architecture

In order to facilitate the discussion in this paper, weprovide a brief summary of mediators. Mediation is anarchitectural concept proposed by Wiederhold in theearly 1990s (Wiederhold, 1992, 1995a,b, 1998). A me-diated architecture differs from several prior architec-tures, which are mainly two-layered, by inserting a thirdlayer containing mediators. A mediator is a software

module that exploits encoded knowledge about somesets or subsets of data to create information or a higherlayer of applications. It should be small and simple, sothat it can be maintained by one expert, or at most, asmall and coherent group of experts. Mediator is a classof software modules that mediates between client ap-plications and the base resources like databases andWeb pages. Conceptually, mediators form an intelligentand active layer between clients and data resources thatcreates a three-layered architecture. The three layers aretypically:• client applications that require relevant information,• mediators that provide value-added services, and• data resources that are the repositories of basic

data.The concept of mediation has been applied to the

development of information systems in many domains,e.g., health care (Wiederhold et al., 1996). It has alsobeen recognized that the interfaces between the layersneed to be standardized in order for such systems tooperate efficiently. In the mean time, XML has emergedas the potential lingua franca of the Internet. Because ofthis and other characteristics of XML, we have chosenXML to develop the data models for the databases thatthe mediators interact with as well as their interfaces.This provides the mediators with data models of thedatabases that they access in a machine-readable form.Hence, it is easier for the mediators to keep abreast ofany changes or evolution in these data models. So hereXML would be used to represent metadata. Increas-ingly, we will see repositories of XML data or XML-enabled databases. In these the data itself would berepresented in XML when exchanged. Fig. 1 illustratesthe concept of mediation applied to a system architec-

Fig. 1. General system layout for XML-based mediator architecture.

240 S. Chan et al. / The Journal of Systems and Software 60 (2002) 239–248

ture designed for general business applications on theWeb.

Two major types of data are involved: content relateddata stored mainly in the form of XML files, andtransactional data stored mainly in database systems.Currently, transactional data are stored mainly in tra-ditional relational database formats. With the metadatadescribed in XML, appropriate mediators can thentranslate the transactional data in relational data for-mats into XML. Gradually it is expected that XML-enabled database systems will become popular, whichcan automatically output the transactional data in XMLformat, offloading some of the tasks currently per-formed by the mediators. Inventory control for retailbusiness applications has been chosen as the test case inthis project. Since mediators are the middle layer be-tween client application and data resources, there will betwo major interfaces: application to mediators, andmediators to data resources. Fig. 2 illustrates the systemdesign using the process flow of Buyer update as anexample.

Note that there are generally three types of mediatorsin the mediation layer. The Service Interface Processor is

mainly responsible for interacting with the client appli-cations. The Resource Access Interface Processor ismainly responsible for interacting with the data sources.The rest are function-specific mediators which handlethe business logic contained in the system. Their func-tions are discussed in more detail in Section 4.

2.1. Client applications to mediators interface (ServiceInterface)

Mediation adds value to the data by applying theknowledge of the domain experts. It is expected thatmediators will evolve to maintain their value, as theproblem domain, the applications, and the knowledgeabout them change over time. Hence, an effective in-terface standard for the Service Interface should provideflexibility and extensibility. Static interface specificationsdo not seem able to cater for the evolution of mediatorsbut a language interface that has its own vocabulary andsyntax does. The basic language structure should permitincremental growth so that new functions can be sup-ported as mediators join the network to provide newfunctionality (Wiederhold, 1992).

Fig. 2. Process flow of Buyer update.

S. Chan et al. / The Journal of Systems and Software 60 (2002) 239–248 241

The emergence of XML provides a framework fordescribing structured data that is self-describing andeasy for machine processing. The self-describing, vendorand platform-independent features of XML make itsuitable for defining the interface between client appli-cations and mediators. In this project, a InventoryControl Markup Language (Inventory Control XML)has been developed based on XML standards. The In-ventory Control XML is used as the interface standardfor the Service Interface. As the Inventory ControlMediators evolve, new mediation functions will be ad-ded and existing functions will be enhanced. By the useof Inventory Control XML, new vocabularies can beadded to support new functions provided by mediators.By careful design, the enriched language can be madecompatible with the previous version. All existing Ser-vice Interfaces and mediators need not be changed.Client applications are not required to know the physi-cal location of mediators. The only requirement for theuse of mediation services is the service name and theinterface of the service.

2.2. Mediators to data resources interface (ResourceInterface)

Many tools used in two-tier client–server applica-tions, such as SQL, ODBC, JDBC and CORBA, can beused for this interface. In terms of structure, mediatorsare distinct modules. Distributing them over the net-work has the advantage of economy for access. In termsof function, mediators abstract and summarize data inorder to transform them into knowledge. Generally, thevolume of input data for a mediator is much higher thanthe result generated. The proximity of mediators to dataresources has the economy of access and reduces muchnetwork traffic. For these reasons, it is expected thatmediators and data sources are typically located in thesame local area network, and are likely to be protectedby firewalls. In addition to the economy of access, an-other advantage of distributing mediators over the net-work is load balancing. Mediators that have heavycomputational requirements or are mission-critical canrun on multiple copies on separate machines to providebetter performance and fault tolerance.

Although the distribution of mediators providesmany advantages as discussed above, the co-ordinationand communication among them can be quite compli-cated if there is no standard interface and service.CORBACORBA is a standard for the communication betweendistributed objects that are compatible with the dis-tributed mediation concept. Mediators that can com-municate through CORBA can share a standard ServiceRequest method and mediators do not need to havedetailed knowledge about the physical location of themediation services that they are requesting.

3. XML processing

XML was developed by an XML Working Groupformed under the auspices of the World Wide WebConsortium (W3C). It is a subset of the StandardGeneral Markup Language (SGML) that is optimizedfor delivery over the Web. It provides a framework fordescribing structured data in a uniform way and inde-pendent of applications or vendors (XML, 1998). ADocument Type Definition (DTD) defines the rules/syntax of the XML document. DTDs provide criticalinformation that allow XML processors to parse thecode and make certain that the XML documents con-tain all information that the applications need.

XML describes the data structure but is not respon-sible for displaying data. There are two major ways todisplay XML in a Web browser. The first method is totranslate XML into HTML for display – usually ascripting program is written for the translation. Thesecond way is to use Extensible Stylesheet Language(XSL) (XSL, 1998) to define the output format of theXML. Each style sheet describes rules for presenting aclass of XML documents. XML documents are pre-sented by pattern matching. The formatting informationis mapped into matched elements in the XML documentthat are described in XSL documents. Microsoft Inter-net Explorer (Version 5.0) can present XML documentsdirectly using appropriate XSL documents. This way,one does not need to write an XML processor in orderto present XML documents.

4. Functions of the mediator-based retail Inventory

Control System

Inventory Control for chain stores has been chosenfor testing the XML/mediator-based system architec-ture. Through mediation, the resulted system will bemade more flexible and easier to extend. XML is used toconstruct data models used by the mediators, and tospecify the data exchange format between client appli-cations and mediators, and also between mediators.CORBACORBA is used to implement the communication infra-structure between mediators, making the mediatorsflexible, adaptive for change, and easy to maintain. Italso enables multi-mediator design, i.e., new mediatorscan be created and made to co-operate with existingmediators to provide new services to client applications.

The Inventory Control Mediators will provide twocategories of services: transaction data capture servicesand assortment planning and replenishment services.

4.1. Transaction data capture services

Transaction data are basic to Inventory Control. Itprovides basic information for the higher-level functions


such as assortment planning and automatic replenish-ment. The Inventory Control Mediators will provide thefollowing data capture services.1. Item maintenance: Define and maintain basic item in-

formation including unit price, cost, attributes anddescriptions.

2. Purchase order: Record and issue purchase order tosuppliers.

3. Merchandise receiving: Update quantity on hand, unitcost and average unit cost of received items.

4. Inventory adjustment: A general inventory adjustmentfunction to correct inventory and to be used as astock-taking function.

5. Sales transaction: Search for items based on specifiedcriteria; perform item information lookup; calculatediscounts and totals; capture sales related informa-tion for inventory control processing.

4.2. Assortment planning and automatic replenishmentservices

Based on transactional data, higher-level functionscan be provided. Assortment planning and automaticreplenishment are higher-level services provided by theInventory Control Mediators. For buying purposes,merchandise is classified into two broad types of mer-chandise assortments: fashion merchandise and staplemerchandise. Fashion merchandise refers to thoseitems that have a high demand over a relatively shortperiod of time. Staple merchandise consists of thoseitems that are consistently in demand over long periodsof time. It is important to maintain an updated list offashion and staple merchandise because fashion mer-chandise may become staple merchandise over time.For staple items, since the demand is relatively stable, aperiodic reordering method can be applied for replen-ishment and it is suitable for applying automatic re-plenishment to reduce administration cost. For fashionmerchandise, a model stock plan is employed for re-plenishment.

Inventory Control Mediators in the system will pro-vide the following assortment planning and automaticreplenishment services.

4.2.1. Fashion and staple classificationThe classification of fashion and staple merchandise

is based on the four characteristics of staple items.1. A relatively long life cycle, with infrequent changes in

product characteristics.2. A predictable pattern of sales.3. A relatively short delivery period.4. A regular and frequent reorder period.

The Inventory Control Mediator actively searches thedatabase and classifies stocks into staple merchandisebased on the four characteristics above.

4.2.2. Automatic replenishment for staple merchandiseFor staple items, automatic replenishment can be

applied since the demand is relatively stable for longperiods of time. The automatic replenishment servicecalculates the reorder quantities based on the maximum/minimum stock level, rate of sale, delivery period andreorder period to generate purchase orders at the righttime to optimize inventory holding.

The automatic replenishment service aims to main-tain the stock level in Average Unit Stock to smooth thesupply and to avoid being out of stock. Average UnitStock can be determined by a formula that takes intoaccount minimum stock, the reorder period, and the rateof sale.

Different automatic replenishment models can be usedto calculate reorder quantities. Our system uses the sim-ple linear model, making the assumption that there is nobulk order discount and the demand for stock is linear, asthe purpose here is essentially to validate through pro-totyping the proposed architecture. The reorder pointunder this model will be triggered when the quantity of astock is less than the average unit stock for more than onevendor unit for ordering, or lower than the minimumstock level. For example, Stock A has the minimum stocklevel of 10 units, average unit stock is 16 units, and ven-dor unit for ordering is 5 units. The reorder will be trig-gered when the stock level is less than 11 units on hand.

4.2.3. Model stock planning for fashion merchandiseThis service gathers statistics about fashion mer-

chandise by specified selection factors such as price,colour, size and fabric within a price line to produce amodel stock plan. A Model Stock Plan shows the saledistribution of merchandises and quantity on hand forthe basket of selected merchandise. Different modelstock plans will be produced based on different selectionfactors that give different scenarios of merchandise as-sortment for the decision-maker to make the optimalreordering strategy.

5. XML-based mediation

In XML, DTDs can be used to build new DTDs. Thisfeature enables XML to be extended to a domain-spe-cific markup language such as the Inventory ControlMarkup Language (Inventory Control XML). The de-sign of Inventory Control XML strives for simplicityand extensibility for ease of use and future enhance-ment. Inventory Control XML is developed using ob-ject-oriented modeling techniques and documented inUML. However, it differs from the approach taken bySilberzhan (1998) which aims at developing truly object-oriented XML definitions for electronic patient records.The model for Inventory Control XML is object-basedrather than object-oriented. For example, it does not


support polymorphism that is realized by methodmembers. Several areas need to be improved beforeXML definitions can be built into a truly object-orientedsystem, including the implementation of method mem-bers in a dynamic interpreted language, and encoding ofthe schema in the XML documents themselves ratherthan predefined DTDs.

The document structure of the Inventory ControlXML is hierarchical. The Inventory Control XML DTDis a wrapper that encapsulates the details of other defini-tions being use and provide a common interface (Fig. 3).For basic data types and common elements, separateDTDs are used. This enables reuse and centralizes thecontrol of common elements. Other higher-level defini-tions for inventory control in retail build on the two basicDTDs. Finally, all are wrapped in the Inventory ControlXML DTD. It is expected that DTDs for other relatedapplications, such as Commerce XML (cXML) (Ariba,1999), and ebXML ebXML (2000), may make use of theInventory Control XML DTD. For example, cXML isdesigned to provide a simple XML-based protocol be-tween entities engaged in business-to-business e-com-merce transactions over the Internet. It supports sendingand responding to purchase orders. However, it does notcover inventory control applications and it is generallycomplementary with Inventory Control XML. In caseswhere it is necessary to translate between InventoryControl XML and similar models such as cXML, a con-version tool such as LMX (Tamura, 1998) can be used.

5.1. DTD for basic data type

The BasicDataType.DTD is used to define basic datatypes that will be used in the Inventory Control XML.Since XML only provides limited data types likeCDATA, PCDATA and ID, it is difficult for applica-tions to verify the data has the correct type. This DTD isused to define more date types that enables more vali-dations for application using Inventory Control XML.

Basic data types such as Boolean, Date, Numbers andString are defined in this DTD.

5.2. DTD for basic elements

The BasicElement.DTD contains definitions of dataentities that are commonly used in retail applications,such as Requester, Server, Name, TelephoneNumber,Contact, UnitOfMeasure, LeadTime, UnitPrice, etc.

5.3. DTD for high-level definitions

5.3.1. Service RequestThe Service Request DTD describes the format of

server requests. It involves the Request Header andRequest Body. The Request Header describes the URLand credential of both Requester and Service Provider.The Request Body contains the Requesting Service andService DTD. Fig. 4 shows the UML model for theService Request, while Fig. 5 shows the UML model forthe Buyer.

The following is an abbreviated version of the ServiceRequest DTD:

<!ELEMENT RequestHeader (Server, Requester)><!ATTLIST RequestHeader RequestID %GUID;#REQUIRED><!ELEMENT RequestBody (ServiceName, DTD-Name?, RequestXML?)><!ELEMENT ServiceRequest (RequestHeader, Re-questBody)>

The following is an abbreviated sample ServiceRequestXML file:

<ServiceRequest><RequestHeader RequestID¼ ’’0012345’’><Server><URL>www.retailXML.com</URL>. . .

</Server>. . .</RequestHeader><RequestBody><ServiceName Action¼ ’’add’’>Buyer Mainte-nance</ServiceName><RequestXML><Buyer><BuyerDetail><BuyerID>123455</BuyerID><Name>Tony Wong</Name>

</BuyerDetail><BuyerPerformance><SellingPeriod>. . .<Classification>. . .

</BuyerPerformance></Buyer>

</RequestXML></RequestBody>

</ServiceRequest>

Fig. 3. The structure of Inventory Control XML DTDs.


Other high level DTDs include Service Response,Resource Access, Resource Access Result, Buyer, Sup-plier, Item, Purchase Order, etc.

6. Inventory Control System architecture

Two XML processors have been developed for theInventory Control System. The Service Interface Pro-cessor is responsible for retrieving elements from XMLdocuments for the client applications and constructingXML documents based on input elements from the cli-ents. The Resource Access Interface Processor is re-sponsible for the translation between XML documentsand relational database schema and access of relationaldatabases. These two processors are mediators that

provide mediation services to other mediators and clientapplications.

The system architecture of the Retail InventoryControl System is illustrated in Fig. 6. The Service In-terface Processor is a Java Servlet on the Web server. Itreceives XML requests and routs them to the Dis-patching Mediator, making use of the Inventory Con-trol XML DTD stored in the Web server. TheDispatching Mediator is an application that communi-cates with the Service Interface Processor throughCORBACORBA. Based on the requests, it routes them to theappropriate mediator through CORBA. The function-specific mediators handle functions such as itemmaintenance, purchase orders, etc. The Resource AccessInterface Processor handles the actual database accesson behalf of other mediators. DTDs are also defined to

Fig. 4. UML model of Service Request.

Fig. 5. The UML model for Buyer.


control the database access. The DTDs are presentlystored in the Web server. When the system evolves, theDTDs have to be updated correspondingly.

Fig. 7 illustrates the structure and methods of theService Interface Processor Servlet, Fig. 8 illustrates theDispatching Mediator, and Fig. 9, the Buyer Mainte-nance Mediator class. The Resource Access InterfaceProcessor provides the bridge between XML andRDBMSs. It embeds SQL statements into an XMLdocument based on the ResourceAccess DTD, and thenexecutes the SQL to access the database. The result of thedatabase access is converted into an XML documentwhich complies with the ResourceAccessResults DTD.The Resource Access Interface Processor consists of se-ven classes. Fig. 10 illustrates themain class, theResourceInterface. We are working on an extension of the systemwhich supports the maintenance of the DTDs through aWeb-based interface similar to that between the clientapplications and the Service Interface Processor.

7. Implementation

The client has been implemented in the form of a JavaApplet that runs on a Java-enabled browser. In theprototype, Internet Explorer 5.0 has been used since it isa Java-enabled browser and it can display XML directlywithout converting to HTML by additional scripts orapplets. Netscape Enterprise Server 3.0 has been used as

a Web server that hosts the required Web pages andmaintains the directories for Inventory Control XMLdocuments and DTDs. The Dispatching Mediator hasbeen implemented in Java Servlet and CORBA. TheServlet receives client requests via port 8080 and trans-lates the request into CORBA client request to the

Fig. 7. The Service Interface Processor class.

Fig. 6. Detailed system architecture of the Inventory Control System.


Dispatching Mediator CORBA object. When the Dis-patching Mediator receives the request in XML docu-ment format, it parses the XML request and determineswhich Inventory Control Mediator’s service is being re-

quested. Then the Dispatching Mediator makes a COR-

BA CORBABA call to the CORBA object implementing the service.Under this implementation, the Dispatching Media-

tor and relating Inventory Control Mediators commu-nication with each other in a bus structure that is usuallyreferred to as CORBA Bus (Fig. 11).

7.1. Benchmarking of the prototype

The benchmarking was run on a machine with IntelPentium II 400 CPU, 64 MB RAM, and 6 GB hard disk.The table in Fig. 12 shows some benchmarking results ofBuyer Maintenance functions. The numbers shown arethe average for 10 runs.

The benchmarking shows that the slowest part is theloading of the BuyerApplet since the loading of the 10KBBuyer Applet class takes a certain amount of time, eventhough it has been designed as a thin client. In an actualdeployment of the e-commerce system, one can exploremeans to improve the system performance, e.g., by im-plementing some of the applet’s functions in HTML onthe client side, and others by scripts on the server side.

8. Summary and further work

XML has been used to develop a self-describing datamodel for mediators and their interfaces for mediator-based architectures. The specification of a common in-terface between client applications and the mediators,and between mediators and data resources, makes thesystem easier to maintain and evolve. In the process, wehave used XML to develop an application of XML(Inventory Control XML) for inventory control in retaile-commerce. We are currently working on developing aninterface for easier maintenance of the system, e.g., forchanging DTDs, through a Web-based interface similarto that between the client applications and the ServiceRequest Processor. The paper concentrates on present-ing the system architecture. Companion papers that dealwith the related problems of1. XML tags for inventory control (Chan and Dillon,

2001a),

Fig. 11. Illustration of the CORBA Bus of the prototype.

Fig. 9. Buyer Maintenance class.

Fig. 10. Resource Interface class.

Fig. 8. The Dispatching Mediator class.


2. the underlying implementation of mediators over aJava Servlet infrastructure (Chan and Dillon,2001b), and

3. a Web-enabling distributed object system (Chan andDillon, 2001c)

are under preparation. Further applications of thisXML-based mediator architecture include their use forbrokers in business-to-customer and business-to-busi-ness applications. In a related project, the authors areapplying the same architecture in the development of aprototype computer-aided learning system.

Acknowledgements

The work described in this paper was partially sup-ported by the Hong Kong Polytechnic University Re-search Grant H-ZJ82.

References

Ariba, 1999. cXML. Ariba, Inc.

Chan, S., Dillon T., 2001a. XML tags for inventory control in e-

commerce. Working paper.

Chan, S., Dillon T., 2001b. Implementation of mediators in a Java

Servlet infrastructure. Working paper.

Chan, S., Dillon T., 2001c. Web-enabling distributed object system.

Working paper.

ebXML 2000. Electronic business XML (ebXML) Requirements

Specification Version 1.0. Available at www.ebXML.org/spec-

drafts/ReqSpecv1-0.pdf.

Merle, P., Gransart, C., Geib, J., 1996. CorbaWeb: a generic object

navigator. In: Proceedings of Fifth World-Wide Web Conference,

May 1996. Available at www5conf.inria.fr/fich_html/papers/P33/

Overview.html.

Rees, O., Edwards, N., Madsen, M., Beasley, M., McClenaghan,

A., 1996. A Web of distributed objects. In: Proceedings of

the Fourth sInternational World-Wide Web Conference, vol. 1,

issue 1.

Silberzhan, N., 1998. Dealing with the electronic patient record

variability: object-oriented XML. In: GCA/XML Europe 98

Conference. Available at www.digitalairways.com/NiS/Pari-

sXML98.

Tamura, K., 1998. LMX (Language for Mapping XML) User’s Guide,

November 1998.

Tigue, J., Lavinder, J., 1998. WebBroker: distributed object commu-

nication on the Web. Available at www.w3.org/TR/NOTE-web-

broker-19980511.

Wiederhold, G., 1992. Mediators in the architecture of future

information systems. IEEE Computer, 38–49.

Wiederhold, G., 1995a. Value-added mediation in large-scale

information systems. In: Proceedings of the IFIP DS-6 Con-

ference. Available at www-db.stanford.edu/pub/gio/gio-pa-

pers.html.

Wiederhold, G., 1995b. Mediation and Software Maintenance. Lecture

Notes in Computer Science, vol. 1021, October 1995, Springer,

Berlin, pp, 1–20. Available at www-db.stanford.edu/pub/gio/gio-

papers.html.

Wiederhold, G., 1998. Value-added middleware: Mediators (Pre-

publication draft), March 1998, www-db.stanford.edu/pub/gio/

gio-papers.html.

Wiederhold, G., Bilello, M., Sarathy, V., Qian, X., 1996. A security

mediator for health care information. In: The proceedings of the

1996 AMIA Conference, October 1996, pp. 120–124. Available at

www-db.stanford.edu/pub/gio/gio-papers.html.

XSL, 1998. Extensible Stylesheet Language (XSL) Version 1.0. World

Wide Web Consortium Working Draft, December 16, 1998.

Available at www.w3.org/TR/1998/WD-xsl-19981216.

XML, 1998. Extensible Markup Language (XML) 1.0. W3C Recom-

mendation, February 10, 1998. Available at www.w3.org/TR/1998/

REC-xml-19980210.

Fig. 12. Some benchmarking data.


Documents

Applying a mediator architecture employing XML to retailing inventory control