Using XML to Facilitate Information Management Across Multiple

Proceedings of the 35th Hawaii International Conference on System Sciences - 2002

Using XML to facilitate information management across multiple local government agencies G.M. Bryan, J.M. Curry, C. McGregor, D. Holdsworth and R. Sharply Centre for Advanced Systems Engineering University of Western Sydney Locked Bag 1797 Penrith South DC NSW 1797 {g.bryan, jm.curry, c.mcgregor}@uws.edu.au Abstract The main barriers to the level of electronic data interchange required to seamlessly integrate services offered by legacy systems in an Internet environment are the need for applications to share a common data definition and the non-heterogeneity in database platforms. It is true that current web based services can prove effective as the foundation for small groups of collaborating organisations with an agreed standard ontology to conduct transactions over the Internet. This has been demonstrated by the retailing industry’s Collaborative Planning Forecasting and Replenishment initiative, and the PC manufacturing industry’s RosettaNet. However, some doubts remain as to whether these representations will scale to support automated commerce between large, loosely coupled groups wanting to access services and share data. These doubts are due to the wide variety of database systems in use and the way these systems are implemented and used. This paper details a collaborative research initiative between the Penrith City Council, Penrith Australia and the Centre for Advanced Systems Engineering (CASE) at the University of Western Sydney. It details the development of a fully functioning XML-based prototype system that provides effective integration of services offered by a collaborating group of legacy systems. The key contribution of this work is to provide an open systems based infrastructure that allows collaborating legacy systems, based on heterogeneous database and server platforms, to offer an integrated query service over the Internet. Keywords: XML, XSLT, Middleware, Distributed Information Systems.

1

Introduction

The universal adoption of the Internet has potentially created a global fully connected network. Such a network

gives raise to the possibility of an unprecedented level of information and services being available. However the reality of the current situation is that due to the lack of common data definitions and the non-heterogeneity in database platforms [1] the ability of both systems and individuals to freely exchange data is severely limited. While it is true that current web based services can prove effective as the foundation for small groups of cooperating organisations with an agreed standard ontology to conduct transactions over the Internet, these organisations tend to be focused on a given industry sector. Examples include, a US based group including Nabisco Food, Kimberly-Clark, Hewlett-Packard, Lucent Technologies, Procter & Gamble, and Warner-Lambert, and retailers Kmart, Circuit City Stores, and Wal-Mart who are piloting such a scheme, the Collaborative Planning Forecasting and Replenishment initiative [2]. This initiative aims to standardise the organisation of data and make it available to trading partners over the Internet, providing them with live sales data that they can use to optimise inventory in real time. Other groups are setting the ontology standards against which entire industries will architect electronic commerce solutions. RosettaNet [3] is developing a supply chain architecture to support the PC manufacturing industry in the US. However, some doubts have been expressed as to whether these representations will scale to support automated commerce between large, loosely coupled groups wanting to access services and share data [1]. These doubts are principally due to the wide variety of legacy systems in existence and the lack of effective methods for integrating the services offered by such systems into new services. These doubts would appear to be addressed by the emergence of standards such as Extensible Markup Language (XML) [4], Extensible Stylesheet Language (XSL) [5] and Extensible Stylesheet Language Transformations (XSLT) [5] coupled with the rapid development of middleware technology [6]. XML provides a mechanism for data transportation across the Internet. XML differs from markup languages

0-7695-1435-9/02 $17.00 (c) 2002 IEEE

Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02) 0-7695-1435-9/02 $17.00 © 2002 IEEE

1


such as HTML in that it inherently separates data from the presentation of that data while providing for an extensible method of user defined data tags. The XSL/XSLT complements XML in that it provides a style sheet language and transformation mechanism for XML documents. XSLT is used to describe how an XML source document is transformed into another XML document that uses the XSL formatting vocabulary. However, XSLT may be used for other general transforms as well, such as transforming a non-XML document types (ie: comma delimited or white space delimited documents). [7] Thus, through a combination of XML and XSL/XSLT, heterogeneous isolated independent data sources can be brought together for communications (providing there is an agreed ontology for the XML structure). In this paper the authors will discuss the implementation of an Information Brokerage utilising XML, XSL/XSLT and middleware technologies that will scale to support information exchange between large, loosely coupled groups wanting to access services and share data.

2

Project background

An Information Brokerage is a facility that will allow a client to search and consolidate data or obtain services, from a variety of sources. Other approaches to this type of information delivery have included the use of SOAP (Simple Object Access Protocol) and XAML (Transaction Authority Markup Language). However these technologies lack the brokerage facility, which is the core component of the Information Brokerage technology. The brokerage facility allows the Information Brokerage technology to offer “group services”, whereby a cooperating group of service providers can join together to offer a single service. The genesis of the Information Brokerage Project came from the idea that: There is a body of information / services that could be made available to prospective clients using the current Internet environment. By their very nature these services predominantly exist in legacy systems, distributed throughout the Internet environment. The distributed and heterogeneous nature of these service providers gives rise to the following questions: • How does the client obtain knowledge of the available services being offered within the Internet environment? • Having obtained this knowledge how does the client effectively access the service? and • How can a service provider effectively use the Internet environment to make services offered by a legacy system available to a broader range of clients?

The Information Brokerage implemented by the authors is built around an open systems architecture developed to allow a collaborating group of legacy systems, based on heterogeneous database and server platforms, to offer an integrated query service over the Internet. The work extends the services offered by traditional middleware solutions, which resolve heterogeneity, and facilitate communication and coordination of distributed components [6]. The Information Brokerage prototype includes user interface facilities, Internet-scale component distribution and a distributed service register in a self-extensible middleware environment. “A self-extensible middleware system is one in which new application-specific functionality needed for query processing is deployed to remote sites in an automatic fashion by the middleware system itself”[8]. A typical middleware approach to the integration of heterogeneous data repositories is to establish a service integrator. The service integrator can either be a data gateway or a mediator / translator. Both these approaches provide a client with a global view of the content of the collaborating data repositories and standardised methods for data retrieval. A typical, data gateway type system such as the Infomaster system [9] uses a commercial database management system to coordinate a centralised knowledge base to store details of each data repository that it has access to. When the Infomaster system receives a query it interrogates the knowledge base to obtain details of any data repository which may be able to solve the query. Using this information the system formulates the query in the appropriate syntax, wraps it in the appropriate communications wrapper and sends it to the appropriate data repository for processing. Other examples of gateway type systems include Oracle8i [10] and Arachne [11]. In mediator/translator [12,13] systems, the mediator contains a centralised knowledge base storing details of how to process a request for a specific type of information. A translator interfaces each data repository to a mediator. The translator converts incoming queries from a system standard format into a format that the underlying database management system can execute. The translator also converts the data resulting from a transaction to conform to the standard required. Examples of mediator / translator based systems include TSIMMIS [13], BEA System’s WebLogic [14] and IBM’s WebSphere [15]. In the MOCHA Project [8] Rodriguez-Martinez and Roussopoulosself introduced the concept of selfextensible database middleware. Self-extensible middleware is characterised by its ability to automatically deploy application-specific functionality needed to process a given query. MOCHA’s self-extensible capability is realised by deploying Java code containing

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


2


the required functionality. This approach differs from deployment techniques used in systems based on data gateway or mediator type systems where the required functionally to execute a query is installed in a library which is then replicated throughout system by the system administrator. The remainder of this paper is organised as follows. In section 3 we begin with a description of the Information Brokerage architecture. Section 4 then discusses the tools and interfaces provided to the client. Section 5 describes the Service Broker Environment and the mechanisms used to facilitate query processing. We then introduce a prototype implementation in Section 6 and describe its specific goals and objectives. Finally further research opportunities are described.

3

Architecture

3.1 Design philosophy In addressing the objectives of the project the underlining architecture adheres to the following design philosophies: • Modular Design The design of the system will be such that components of the system can be used by future systems requiring the same service. • Reusable Technology The technology used in the project should be documented such that it can be reused by future projects • Scalability The system shouldn't be so restrictive so as to prevent future enhancements and the possible expansion of future functionality. The system should also be scalable in terms of performance. That is, by using a server of twice the processing capacity it should be able to service twice the queries in the same time. • Open Standards The system must wherever possible be of a nonproprietary nature. That is, it must where possible use open standards throughout its implementation.

3.2

Transaction processing model

Haerder and Reuter [16] defined a transaction as “one meaningful short sequence of database activity in the user’s environment that is isolated from all other concurrent database activities”. Haerder and Reuter define a transaction has having four distinct properties: • Atomicity: a transaction represents the smallest unit of user activity, which cannot be subdivided into smaller units and must be executed in its entirety if the database is to be left in a valid state on completion of the transaction.

• • •

Consistency: upon completion of a transaction the contents of the database are in a valid state. Isolation: the activity of one transaction has no effect on any other transaction that may be executing concurrently. Durability: once completed the outcome of a transaction persist within the database until they are acted upon by another transaction.

These properties are often referred to as the ACID test of a transaction and are fundamental to the Information Brokerage transaction processing design. A typical client interaction with the Information Brokerage would start with a client wishing to access a service and obtaining details of the required service from the Business Exchange (Figure 1). The Business Exchange contains details of electronic services available to clients. The type of information held in a Business Exchange includes a description of the service being offered and details of the service’s input/output protocols in the form of two XML documents. 1. The Service Request XML document, which sets out the input requirements of the service and processing instructions. The processing instructions contained in the Service Request document are used by the Service Broker to execute the service. 2. The Output XML document, which, as the name implies, provides the client with a sample output from the system. Once the client has completed the Service Request document they forward it to a Service Broker. Both the Business Exchange and the Service Broker may be located on the client’s site or any external site on the Internet. Upon receipt of a Service Request document the Service Broker begins an ACID transaction. The Service Broker unpacks the document and using the Service Provider details (description of XML input and output documents and the URL of the service), processing instructions and input data it contains, executes the required service. Once the Service Broker has received replies from each of the Service Providers taking part in the transaction, it assembles the data into the correct format and returns the results to the client. When the Service Broker returns the results of a transaction to the client, the transaction is deemed to be complete. If any of the Service Providers fail to complete the transaction, then the Service Broker aborts the transaction and returns an error message to the client. This architectural approach of encapsulating the processing instructions within a Service Request document, thus allowing the Service Broker to be a generic piece of software designed only to unpack and execute a Service Request document, creates a significant capability to exploit the inherent structure of the Internet in a number of ways:

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


3


4.1 Data Repository

Data Repository

Data Repository

Service Provider 1

Service Provider 2

Service Provider 3

Service Provider Environment Service Broker Environment

Service Broker

Service selection

All services supported by the Information Brokerage are listed on a Business Exchange (Figure 2). In order to select a service, a client accesses the Business Exchange’s Service Provider Selection Process using an Internet browser. Using XSLT (eXtensible Stylesheet Language Transformation), the web browser then presents a series of drop down menus from which the client selects the required service and service provider.

Business Exchange

Business Exchange

Client Environment

Service Provider Selection Process

Client

Process Query Details

Figure 1. Conceptual Design •

•

4

As the Service Broker is a generic piece of software not associated with any particular client or Service Provider it may be replicated across the Internet on as many server nodes as required and Once an agency has established a Service Provider, the agency may offer that service in any number of ways, either as a stand-alone service or in a collaborative arrangement with other agencies. Each of these instantiations is covered by their own Business Exchange entry and subsequent Service Request document.

The client environment

The Client Environment provides the user with the tools necessary to build and maintain an interface with the Information Broker. The Client Environment consists of four principle components: • Service Selection: which allows the client to select a service from a Business Exchange and execute the service on a Service Broker. • EditX: an editor that allows the client to create XSL documents to transform both incoming and outgoing XML documents. • The Legacy System Interface; which allows the client to directly interface a legacy system to a Service Broker and • GenX: which generates XML documents from nonXML data formats using a sample document.

Client Browser

BX Data Repository

Sample Input Document Sample Output Document

Figure 2. The Business Exchange A similar service may be provided by a number of Service Providers. For example, a Building Development Application Lodgement service may be provided by a number of Local Government Agencies in which case the client would select a provider depending on the geographical location of the building in question. Once the client has selected a service the Business Exchange gives the client a detailed description of the service including service provider contact information and a list of any conditions placed on the use of the service. If the client wishes to proceed with the service, the Business Exchange downloads two documents to the client. 1. An input document - this document has two parts a sample XML document which sets out the data format required by the service providers, and the SQL processing instructions which will be used by the Service Broker to execute the service. 2. A sample of the XML output document the client will receive from the Service Broker at the completion of the transaction. At this point the client can either pass the input document on to the Client Servlet for processing or save it to be used by the Legacy System Interface.

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


Compile Service Listing

4


4.1.1 Client servlet design Figure 3. Client Servlet, shows the major functional units within the client servlet design and their relationship to both the transmission of the source XML and the handling of Service Broker responses. The Client Servlet expects to find a source XML document as one of its inputs. This XML document should contain all the relevant query details as specified in the sample input document provided by the Business Exchange. Once the Client Servlet successfully obtains the source XML document, a connection to the Service Broker via its specified URL is established. Provided that the servlet can successfully negotiate a connection to the Service Broker, it begins to transmit the source XML document as an XML stream over the HTTP-TCP/IP link. Before a response is received, the Client Servlet begins to initialise those elements that are involved in the processing of the XML response document. Such elements include the initialisation of the XSLT processor, the creation of a new SAX parser and the setting of properties relating to the XSL parsing and transformation. Having performed these tasks prior to receiving a response from the Service Broker ensures that minimal delay is incurred on the client side when the response is actually received. When the response is received, it is done so by directly extracting XML “off-the-wire”.

client’s browser window in a source view. The transformed output can then be saved with the appropriate file extension (e.g. .html for an HTML file, .txt for a plain text file, and so on). 4.1.2 Client Servlet Transformation Design Figure 4. Client Transformation Process shows the major functional units within the transformation process that are performed by the client servlet. The transformation process is one of the core functions of the Client Servlet as it allows the results of a given query to be transformed into another format, whether that other format is HTML, plain text, another XML format and so on. Provided that a particular format can be described within the rules of XSL, then it can be utilised within this system. Client Servlet

Response details from Service Broker

...

.....

Submission Submission Module Module

XML XML Source Source Document Document

XSL XSL Document Document Response details from Service Broker

...

Retrieve Retrieve Response Response

SAX SAX Parser Parser

Output Output Stream Stream

Transformed Transformed Result Result

Figure 4. Client Transformation Process

Client Servlet Query details to Service Broker

XSL XSL Document Document

Transformed Transformed Result Result

Parse Parse Response Response

The response details (in XML format) are obtained from the Service Broker and are supplied to the SAX Parser [17] (Simple API for XML)1. The XSL document (supplied by the client) provides the formatting rules that describe how the SAX parser should transform each element within the XML response document, for that particular client’s requirements. Once the two expected inputs, (the XML response document and the XSL

Figure 3. Client Servlet Having received the response from the Service Broker, the Client Servlet directs the incoming XML response document stream to act as the parser input. Given that the preliminary transformation steps have already been completed, the parsing and transformation of the XML response document stream, in conjunction with the specified XSL stylesheet, can commence. Due to the fact that the Demonstration Prototype has focused on a web browser based client, the results of the XML/XSL transformation is displayed directly to the

1

SAX is a popular event-based interface for any XML parser. The main concept behind SAX is to provide an interface by which any Java application can access any XML parser, provided the parser has a SAX driver. Virtually every major XML parser either supports the SAX interface directly or indirectly via third-party drivers. The XSL document is the second of the inputs expected by the SAX Parser.

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


5


Figure 5. A typical EditX Display transformation document) have been obtained, and the appropriate stylesheet handlers and XSLT processors have been initialised, the SAX-driven transformation can commence. The results of the transformation are saved to a temporary file. The results of the transformation are then displayed on the client’s web browser.

addition to these predefined formats, the user can create and add their own display formats. EditX provides the client with a useful tool to create and test XSL documents.

4.2

The Legacy System Interface (Figure 6) system makes use of the same tool set as used to interface to browser based systems, with the inclusion of the GenX software. In order to interface a Legacy System to the Information Broker, a client first selects the service they require from the Business Exchange. After selecting the service the client then must match the output from the Legacy System to the input requirements of the service provider(s). If the client’s Legacy System is capable of producing an XML document then this document can be transformed into the correct format using the appropriate XSL document. Loading the output format from the Legacy System into EditX can create this XSL document. The client then builds an XSL document to transform the

EditX

In order to allow the client to create and maintain XSL documents the Information Brokerage includes a full functioning XML/XSL WYSIWYG editor EditX (Figure 5). EditX has three user configurable workspaces or viewers. The XML input document is open in the XML workspace. The user then designs the appropriate XSL document to achieve the required transformation in the XSL workspace. Once the XSL document is completed, the transformed document can be viewed in the Output Viewer. The Output Viewer is capable of displaying the resulting document in any number of formats (ie HTML, Excel Spreadsheet, space delimited, XML etc). In

4.3

The legacy system interface

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


6


Legacy System’s output into the input required by the service provider(s). Once the XSL document has been created the output from the Legacy System can be streamed directly to the Service Broker via a Client Transformation Process (see Figure 4).

service data details to be able to access the required Service Provider, without requiring any modification to the other system components.

5.1 Service broker servlet Figure 7. Service Broker Design shows the major functional units within the Service Broker servlet and

Direct from database or via GenX Build XML Source Document

Legacy System

Service Service Broker Broker


Transform Transform Source Source

Transform Transform Source Source

Generated using EditX

XSL XSL Document Document

Service Service Manager Manager

Client Query

SB SB Interface Interface


SS H H A A R R E E D D O O B B JJ E E C C T T

Service Service Provider Provider 11 Interface Interface Service Provider 1



Response to Client

Figure 6. Legacy System Interface If the Legacy System cannot produce an XML format document then the client can stream the output from the Legacy System into the GenX2 software to generate an XML format document, which may then be transformed as required.

5

The service broker environment

As the name suggests, the Service Broker’s main focus is essentially acting as the “go-between” for the client and Service Provider(s). It handles all query dissection and assembly prior to the query reaching the opposite end of the transaction. One of the basic design philosophies of the Information Brokerage architecture was to enable new services to be added to the system with a minimum of disruption to the other Service Broker components. It is envisaged that if a new Service Provider is to be included, it would only be necessary to register it with the Business Exchange. This would provide the system with sufficient

2

GenX is a program that will accept a delineated data file and produce an XML document. Quite simply this program takes a sample XML document and inputs data elements between the tags. A more sophisticated version of this program is planned which will make use of an XML schema to format the XML document.

Figure 7. Service Broker Design their relationships to the incoming and outgoing data flows. Once the HTTP connection between the Service Broker and client has been negotiated, the Service Broker receives the client’s query in an XML tagged format by extracting XML “off-the-wire” via the Service Broker (SB) Interface module. The SB Interface module then calls upon the Service Manager module. This module is used in conjunction with the parsing of the client’s initial XML tagged query for the purpose of fragmentation (i.e. the creation of the query fragments specific to each Service Provider). These query fragments are then stored in the DbData groups, within the Shared Object module. Provided that the fragmentation stage is completed successfully, the formulation of the Service Provider specific SQL sub-queries can commence. However, before the sub-queries can be applied to the Service Provider databases, a connection to the Service Provider needs to be negotiated. This is accomplished through the connection details that have been provided within the initial client XML input stream. For the convenience of later operations, all of the Service Provider specific connection details and SQL queries (i.e. the DbData objects) are stored within a Java Vector, which is then returned to the SB Interface module.

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


7


The use of a Java Vector (populated with instances of DbData objects) allows the SB Interface module to create and populate DbData shared memory objects for use by each of the Service Provider Interface modules. This process essentially provides a shared storage location for the purposes of initiating the application of a client query (based on the query fragment details) and the extraction of Service Provider specific results. A reference to the appropriate shared data object is passed to the corresponding Service Provider so as to provide each Service Provider with a method of accessing the data to be used for each query. Using the details from the DbData shared objects the specific query details are applied to each Service Provider’s underlying database. All resultant data from the application of the query fragment is used to populate the response area of the corresponding DbData shared data object. Once all queries have been applied and each Service Provider has issued the results, the Service Broker can then begin to consolidate the results into a single package, fit for transmission, back to the client. In keeping with the rest of the Demonstration Prototype, this package is formulated into an XML tagged structure, again for purposes of content / presentation independence.

6 6.1

of schematic syntax and vocabulary, which are normally locally defined and not known to external clients. Using the Information Brokerage technology, we have demonstrated it is possible for Penrith City Council to give their clients a seamless interface into the databases of other agencies, providing the client with a consolidated view of the land information held by the each database.

Urban Planning Internet Connections Smart City Server Client

Water Supply Agency

Figure 8. A conceptual view of the prototype problem domain

Prototype implementation The problem domain

In this section, we present a case study. The Information Brokerage prototype system is used to allow a client, wishing to submit a development application to a local government agency (Penrith City Council), to search and consolidate data or obtain services, from a variety of source databases to find out further details about a parcel of land. Our goal is to demonstrate the concepts discussed so far using a concrete example by providing a facility that will allow a client to search and consolidate data from three heterogeneous sources. The demonstration prototype (Figure 8) is based on the scenario of a client wishing to undertake a development project in the Penrith council area. The client is able to search Penrith City Council’s databases to obtain details of vacant land with the correct zoning. As part of the same transaction they are then able to access details held on other agencies databases to find out further details about the identified parcel of land. This means that one client search can provide several associated service provider responses. The alternative to using the Information Brokerage approach would require a client to locate and search each database individually, which may involve the client having to physically visit the other agencies: a very time consuming task. This undertaking is further complicated by the differences between these data repositories in terms

The advantages to Penrith City Council clients are considerable savings in time and effort as well as enhancing their decision making capability.

6.2

Database server infrastructure

The upper section of Figure 7 is a representation of a high level view of typical Service Provider Environments. In general, it would consist of those components necessary to interface with and manage the systems of the individual database engines that a remote client wishes to access. This would include such components as JDBC– ODBC Bridge Servers, ODBC data source drivers, network services for remote connection to databases and so on. In the case of the Demonstration Prototype, the Service Provider environments consist of: Service Provider (1) RedHat Linux 6.2 operating system. Network Services provided by the portmap service daemon to enable access to PostgreSQL via JDBC 6.1.2 API. • A PostgreSQL database server that had a number of database tables populated with sample urban planning data. • •

•

Service Provider (2) Windows NT SP (6) operating system.

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


Penrith City Council

8


• • • •

Network Services via Windows-NT. ODBC data-source access via Windows-NT ODBC DataSource Administrator. Easysoft JDBC – ODBC Bridge server v1.0.0.6. A Microsoft SQL Server 7 database engine that had a number of database tables populated with sample data from Penrith City Council.

Service Provider (3) Windows NT SP (6) operating system. Network Services via Windows-NT. ODBC data-source access via Windows-NT ODBC DataSource Administrator. • Easysoft JDBC–ODBC Bridge server v1.0.0.6. • An Access database engine populated with sample data from the water supply agency. • • •

6.3

Further work

This research is currently being extended in the following ways: • Implementation of a full security layer including support for firewalls, secured XML documents, encryption of processing instructions and the certification of both clients and service providers, thus providing an increased level of security at all phases of the transaction. • Enhancement of the current query processing to offer support for complex transaction processing including commit and roll-back facilities.

Addition of service provider information management facilities, that allow the online creation, modification and deletion of service provider data directly to the Business Exchange.

In addition, work is being considered for an enhanced display component to develop scalable vector graphics and security technologies to support the display of geospatial information via an interactive web browser (Figure 9). Client’s View nt’s Clie nt Inte

Directory of adornment content provided by others i.e. Telco’s, Utilities, Planning Agencies, Health Authorities, Insurance Industry, Traffic Authorities

Functionality Achieved in the Prototype

The Information Brokerage prototype implemented by the authors, allowed a client to have a consolidated view of a group of services pertaining to three land information databases: Penrith City Council’s Properties Database, a water utilities assets database and a planning authority’s land zoning database. The prototype was built using an open systems architecture, developed to allow a collaborating group of three legacy systems to offer a number of integrated query services over the Internet. The prototype successfully demonstrated the services offered by traditional middleware solutions, by successfully resolving heterogeneity issues, and facilitating communication and coordination of distributed components. In addition, by implementing multiple Services Brokers and Business Exchanges, the prototype demonstrated component level distribution. Furthermore, by automatically distributing the SQL code needed for query processing to remote service providers, the prototype has demonstrated a selfextensible middleware environment.

7

•

Client Communication Object

Asset Locations Additional Content

Other providers of base Cadastre i.e. Local Government, and Statutory Corporations

Planning Information

Layers

Easements

Road Network Property Data Centralised Base Cadastre

Figure 9. An abstract view of the geophysical web browser's functionally Using the Information Brokerage technology a client will be able to obtain geospatial information from and communicate with, any number of distributed, heterogenous data sources to facilitate decision support in land and infrastructure management. Ultimately, this research could also be further applied to other areas beyond the requirements of local government agencies.

8

Acknowledgments

The Information Brokerage Project is a collaborative research initiative between the Penrith City Council, Penrith, Australia and the Centre for Advanced Systems Engineering (CASE) at the University of Western Sydney. The Project was funded under the Australian Government’s Business Entry Point initiative. The authors would like to thank Mr John Bijen from Business Entry Point and Mr Richard Baczelis from Penrith City Council for their ongoing support for this project.

9

References

[1] Ontology.Org , “The Need for Shared Ontology”, http://www.ontology.org/, May 2001

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


9


[2] Collaborative Planning, Forecasting and Replenishment Committee, http://www.cpfr.org/, May 2001

[17] Java Commerce.com “Using the SAX Parser” http://www.javacommerce.com/tutorial/xmldev/SaxParser 1.htm , May 2001

[3] RosettaNet, http://www.rosettanet.org/, May 2001 [4] W3C, [5]

Extensible Markup Language http://www.w3.org/XML/, May 2001 W3C, Extensible Stylesheet Language http://www.w3.org/Style/XSL/, May 2001

(XML), (XSL),

[6] Emmerich W., “Software Engineering and Middleware: A Roadmap”, Future of Software Engineering, Limerick, Ireland , pp 117-129, 2000

[7] Day

D.R., “Hands-on XML”, http://www106.ibm.com/developerworks/library/hands-on-xsl/, May 2001

[8] Rodriguez-Martinez M., Roussopoulos N., “MOCHA: A Self-Extensible Database Middleware System for Distributed Data Sources”. MOD 2000, Dallas, TX USA, pp213-225, 2000

[9] Genesereth, M.R., Keller, A.M., & Duschka, O., "Infomaster: An Information Integration System" in proceedings of 1997 ACM SIGMOD Conference, May 1997

[10] Oracle Corporation. “Oracle Transparent Gateways”, http://www.oracle.com/ ,May 2001

[11] Deibel, SRA, Ehresman, J. “The Arachne User's Guide” http://dsg.harvard.edu/public/dsg/projects/arachne.html, May 2001

[12] Wiederhold G., “Mediators in the architecture of future information systems”, IEEE Computer, vol 25, pp38-49, 1992

[13] Chawathe S., Garcia_Molina H., Hammer J., Ierland K., Papakonstantinon Y., Ullman J., and Widom J. “The TSIMMIS Project: Integration of Heterogeneous Information Sources” IPSJ Conf., pp. 7-18, Tokyo, Japan, October 1994.

[14] BEA Systems, http://www.bea.com/products/weblogic/server/index.shtm l, May 2001

[15] IBM WebSphere, http://www7b.boulder.ibm.com/wsdd/library/, May 2001

[16] Harder, T., and Reuter, A., "Principles of TransactionOriented Database Recovery", ACM Comp Surv 15 No. 4 (December, 1983).

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


10

Using XML to Facilitate Information Management Across Multiple

Using XML to Facilitate Information Management Across Multiple

Suggest Documents

Using a Dairy Management Information System to Facilitate Precision ...

transAlign: using amino acids to facilitate the multiple alignment of ...

Design Information Sharing Across Multiple Knowledge ... - Core

Using PhoTovoice To FaciliTaTe cUlTUral

hotel yield management practices across multiple ... - CiteSeerX

Using SDI and Web-Based System to Facilitate Disaster Management

Performance Measures Across Multiple Management Perspectives in ...

Using the Balanced Scorecard to Facilitate Strategic Management at ...

Using standard ICT & GIS to facilitate better nutrient management ...

XML Information Retrieval Using SQL2XQuery - CiteSeerX

XML Information Retrieval Using SQL2XQuery - Semantic Scholar

Using SDI and Web-Based System to Facilitate Disaster Management

Using a Common Pedagogy Across Multiple Disciplines to Improve

Using ICENI to run parameter sweep applications across multiple Grid ...

Information Acquisition using Multiple ... - Information Sciences Institute

CourseVis: Externalising Student Information to Facilitate ... - CiteSeerX

CourseVis: Externalising Student Information to Facilitate ... - CiteSeerX

transforming drought information to facilitate decision ...

Supplying Information to Facilitate Price Discrimination

Use of Information Technology to facilitate ...

Nurses' information management across complex health care ...

Using Digital Cameras to Facilitate Mathematics

Using Instructional Theory to Facilitate ... - Semantic Scholar

Using Annotations to Facilitate Power vs Quality