quality focused service registry development in service ... › librarywww › papers... · quality...

Quality Focused Service Registry Development In Service Oriented GDI

Kim, Won Jin March, 2005

Quality Focused Service Registry Development In Service Oriented GDI

by

Kim, Won Jin Thesis submitted to the International Institute for Geo-information Science and Earth Observation in partial fulfilment of the requirements for the degree of Master of Science in Geo-information Science and Earth Observation, Specialisation: Geo-Information Management

Thesis Assessment Board

Chairman: Prof. Ir. P. van der Molen External examiner: Prof. Dr. A.K. Bregt Supervisors: Dr. M. M. Radwan Dr. J.M. Morales R. Onchaga

INTERNATIONAL INSTITUTE FOR GEO-INFORMATION SCIENCE AND EARTH OBSERVATION ENSCHEDE, THE NETHERLANDS

Disclaimer This document describes work undertaken as part of a programme of study at the International Institute for Geo-information Science and Earth Observation. All views and opinions expressed therein remain the sole responsibility of the author, and do not necessarily represent those of the institute.

i

Abstract

The advances of technology have led a lot of changes in geographic information (GI) community. The ways of GI collecting, processing, managing, and sharing have been changed more effectively and efficiently. In this context, geospatial data infrastructure (GDI) has taken important role. However, the role of the GDI is currently changing form a simple data sharing mechanism to customer focused information and service provision. Customer requirements are changing rapidly. They want not only spatial data but also value-added products or more advanced geographic information services. Customers’ requirements however, are getting more elaborate and diverse, it seems more difficult to respond easily to customers’ needs by single GI provider. For that reason, GI providers and customers need that GDI support various services including data, operations, processing, or resources, and value added services from various service providers. Further, they want GDI that can support service collections of independent services. In order to make these needs real, proper description of services is required. Service description should include what the users want to know. One of the most important things would be the quality of such services. Generally, service descriptions can be found in registry. However, existing registries does not support service quality information. Lack of quality information in existing service description has some difficulties for service selection if there are several service providers they offer similar functions. Firstly, they can not answer who is the most suitable provider for specific requirement. Secondly, similar service can not be distinguished. Further, uncertainty of service can not be reduced. The main objective of this research work is identifying quality characteristics to extend quality-aware service registry development. This objective is carried out throughout the research. Firstly, current trend in GDI has been reviewed. Then, service quality characteristics have been researched. In order to figure out service quality characteristics, common view of quality definition and representations are reviewed first. Common view of quality helps to derive GI service quality representation. Further, user side quality requirements have been extracted from GI service quality. Finally, quality characteristics of GI services are derived and modelled by use of quality requirements. Service metadata is proposed in order to include quality information. Service metadata is proposed by analyzing current service description standards and use of their extensibilities. Proposed service metadata is used for service registry implementation. Service registry is modelled using Unified Modelling Language (UML) activity diagram, and implemented on the web by use of web application technology. After implementation, service registry is evaluated by a number of users. Through this research, important quality characteristics are defined, and those characteristics are used to describe services. These quality characteristics are regarded as valuable elements to users. For better use of service registry, standard ontology of quality characteristics and advanced technologies are required to study.

iii

Acknowledgements

There are a number of people who made this work possible. I am willing to express my gratitude to them. First of all, I appreciate Korea Army for giving me a chance to study at ITC. This chance gave me a lot of challenges and opportunities. I would like to express my deepest gratitude to my supervisor Dr. M. M. Radwan for his encouragement and scientific assistance to carry out this research. I could not have completed my work without his guidance. Special thank goes to my co-supervisor, Dr. J. Morales who gave me invaluable advice and constructive remarks. His advice was always critical and of value to my research. My sincere thanks should go to another co-supervisor Mr. R. Oncharga. His dedication and assistance will not be forgotten forever. He fuels me to complete my work during the whole period. I am also thankful to Prof. Ir. P. van. der Molen for his critical questions and suggestions during the proposal and mid-term presentation. I would like to thank my dear GIM friends, Adewale Akingbade from Nigeria, Alvaro Del Carpio from Peru, Homindra Divithura from Sri Lanka Yismaw Ewunetie from Ethiopia, Antony Lamba and Tom Otieno from Kenya, Young Ho Lee from Korea, Marisa Mei Ling from Indonesia, Anuvapura Seetharamaih Padmavathy from India, Dev Paudyal from Nepal, Caroline Tukugize from Uganda. The beautiful moments that I have spent with them will be kept in my heart deeply. Deep appreciation should go to family and friends in Korea. They always supported me through words of encouragement and made me comfortable. Most of all I would like to dedicate this thesis to my lovely wife, Jung Ae. Without her sincere support I would not have been able to complete this thesis. My gratitude extends to my newly born daughter, Mi Hyoun. She inspired me with her smile and made me happy at the toughest time in my study.

v

Table of contents

Abstract ................................................................................................................................................................... i Acknowledgements ...............................................................................................................................................iii Table of contents.................................................................................................................................................... v List of figures ......................................................................................................................................................viii List of tables .......................................................................................................................................................... ix

1. INTRODUCTION......................................................................................................................................... 1

1.1. BACKGROUND......................................................................................................................................... 1 1.2. RESEARCH PROBLEMS............................................................................................................................. 2 1.3. PRIOR RESEARCH .................................................................................................................................... 3 1.4. RESEARCH CONTEXT............................................................................................................................... 3

1.4.1. GDI................................................................................................................................................ 3 1.4.2. Service ........................................................................................................................................... 4 1.4.3. Registry.......................................................................................................................................... 5 1.4.4. Quality of Service .......................................................................................................................... 5

1.5. RESEARCH SCOPE.................................................................................................................................... 6 1.6. RESEARCH OBJECTIVES ........................................................................................................................... 6 1.7. RESEARCH QUESTIONS ............................................................................................................................ 7 1.8. RESEARCH METHODOLOGY ..................................................................................................................... 7

1.8.1. Literature Review .......................................................................................................................... 7 1.8.2. Required Quality characteristics Extraction ................................................................................. 7 1.8.3. Modelling proposed registry ......................................................................................................... 8 1.8.4. Implementation and Evaluation .................................................................................................... 8

1.9. THESIS STRUCTURE ................................................................................................................................. 8 1.10. OPERATIONAL PLAN .............................................................................................................................. 10

2. SERVICE ORIENTED GDI ...................................................................................................................... 11

2.1. INTRODUCTION ..................................................................................................................................... 11 2.2. GDI ...................................................................................................................................................... 11

2.2.1. GDI components.......................................................................................................................... 12 2.2.2. Clearinghouse component........................................................................................................... 13

2.2.2.1. The Servers.........................................................................................................................................13 2.2.2.2. Graphic User Interface........................................................................................................................13 2.2.2.3. Metadata (data set metadata) ..............................................................................................................14 1) What is metadata?...................................................................................................................................................14 2) The Metadata Standard...........................................................................................................................................15

2.3. SERVICE ORIENTED GDI ....................................................................................................................... 15 2.3.1. Open Geospatial Consortium (OGC) .......................................................................................... 16

2.3.1.1. Geospatial service architecture ...........................................................................................................16 2.3.1.1.1. Service chaining .................................................................................................................................17 2.3.1.1.2. Service metadata.................................................................................................................................17 2.3.1.1.3. Service information access .................................................................................................................17 2.3.1.1.4. Information Viewpoint: A Basis for Semantic Interoperability..........................................................18

2.4. CONCLUDING REMARKS ........................................................................................................................ 21

3. USER PERSPECTIVE ON QUALITY OF SERVICE............................................................................ 22

3.1. INTRODUCTION ..................................................................................................................................... 22 3.2. GENERAL QUALITY CONCEPTS .............................................................................................................. 22

vi

3.2.1. Quality of business process ......................................................................................................... 23 3.2.2. Quality in distributed system ....................................................................................................... 24 3.2.3. Data quality in geographic information processing.................................................................... 25 3.2.4. Common understanding of quality .............................................................................................. 26

3.3. QUALITY IN THE GI SERVICE ENVIRONMENT ......................................................................................... 26 3.4. USER REQUIREMENTS AND QUALITY CHARACTERISTICS IN GI SERVICE................................................. 27

3.4.1. User quality requirements ........................................................................................................... 28 3.4.2. User requirements and service quality characteristics ............................................................... 28


4. SERVICE METADATA MODEL............................................................................................................. 33

4.1. INTRODUCTION ..................................................................................................................................... 33 4.2. CRITERIA FOR ANALYSING CURRENT STANDARDS ................................................................................. 33 4.3. EXISTING STANDARDS ........................................................................................................................... 34

4.3.1. OGC Web Service........................................................................................................................ 34 4.3.1.1. Basic components ...............................................................................................................................34 4.3.1.2. Critical review ....................................................................................................................................36

4.3.2. WSDL .......................................................................................................................................... 36 4.3.2.1. Basic components ...............................................................................................................................36 4.3.2.2. Critical review ....................................................................................................................................38

4.3.3. UDDI........................................................................................................................................... 38 4.3.3.1. Basic components ...............................................................................................................................38 4.3.3.2. Critical review ....................................................................................................................................39

4.3.4. Overall findings........................................................................................................................... 39 4.4. QUALITY APPLIED METADATA DESIGN................................................................................................... 40

4.4.1. Feature component redesign ....................................................................................................... 40 4.4.1.1. Existing feature component ................................................................................................................40 4.4.1.2. Feature component design ..................................................................................................................40

4.4.2. Quality applied OWS service metadata....................................................................................... 43 4.5. CONCLUDING REMARKS ........................................................................................................................ 47

5. IMPLEMENTATION ................................................................................................................................ 48

5.1. INTRODUCTION ..................................................................................................................................... 48 5.2. BASIC CONCEPT OF SERVICE REGISTRY ................................................................................................. 48

5.2.1. Components................................................................................................................................. 48 5.2.2. Main actors ................................................................................................................................. 48 5.2.3. Core activities (functions) of the service registry ........................................................................ 49

5.3. SERVICE REGISTRY ARHITECTURE ........................................................................................................ 50 5.4. ACTIVITY MODELLING........................................................................................................................... 50

5.4.1. Log in / out .................................................................................................................................. 50 5.4.2. Search.......................................................................................................................................... 52 5.4.3. Publish......................................................................................................................................... 54 5.4.4. Update ......................................................................................................................................... 55

5.5. SERVICE REGISTRY IMPLEMENTATION................................................................................................... 58 5.5.1. Implementation scope.................................................................................................................. 58 5.5.2. Implementation environment....................................................................................................... 58 5.5.3. Implementation example.............................................................................................................. 59

5.5.3.1. Introduction of orthophoto .................................................................................................................59 5.5.3.2. Orthophoto production process ..........................................................................................................59 5.5.3.3. Orthophoto production service ...........................................................................................................61

5.5.4. Creating data base ...................................................................................................................... 61

vii

5.5.5. User interface .............................................................................................................................. 62 5.5.5.1. Register...............................................................................................................................................62 5.5.5.2. Log In / out .........................................................................................................................................63 5.5.5.3. Search .................................................................................................................................................63 5.5.5.4. Publish................................................................................................................................................65 5.5.5.5. Update ................................................................................................................................................66

5.6. EVALUATION......................................................................................................................................... 67 5.6.1. Evaluation method....................................................................................................................... 67 5.6.2. Evaluation results........................................................................................................................ 68

5.6.2.1. Evaluation as a web site......................................................................................................................68 5.6.2.2. Quality characteristics and registry function.......................................................................................69


6. CONCLUSIONS AND RECOMMENDATIONS .................................................................................... 71

6.1. INTRODUCTION ..................................................................................................................................... 71 6.2. CONCLUSIONS ....................................................................................................................................... 71 6.3. RECOMMENDATIONS............................................................................................................................. 72

REFERENCES .................................................................................................................................................... 74 APPENDIX A ISO 19115 Metadata package data dictionaries (Data quality metadata)............................. 76 APPENDIX B UDDI service description example (Microsoft Corporation).................................................. 80 APPENDIX C Service Registry Evaluation Paper ........................................................................................... 84 Appendix D Codes for service registry implementation................................................................................... 87

viii

List of figures

FIGURE 1.1 GSI ARCHITECTURE (MORALES 2004) ................................................................................................... 4 FIGURE 1.2 SCOPE OF RESEARCH .............................................................................................................................. 6 FIGURE 1.3 RESEARCH METHODOLOGY DIAGRAM.................................................................................................... 8 FIGURE 2.1 GDI COMPONENTS (MORALES 2004) ................................................................................................... 12 FIGURE 2.2 CONCEPTUAL SYSTEM ARCHITECTURE OF CLEARINGHOUSE (GROOT AND MCLAUGHLIN 2000)........... 13 FIGURE 2.3 CLEARINGHOUSE SERVER (GROOT AND MCLAUGHLIN 2000) .............................................................. 14 FIGURE 4.1 UDDI DATA TYPE (RIEGEN 2002) ........................................................................................................ 38 FIGURE 5.1 SERVICE REGISTRY ARCHITECTURE ...................................................................................................... 49 FIGURE 5.2 LOG IN/OUT ACTIVITY DIAGRAM........................................................................................................... 51 FIGURE 5.3 REGISTRATION ACTIVITY DIAGRAM ...................................................................................................... 52 FIGURE 5.4 SEARCH ACTIVITY DIAGRAM ................................................................................................................ 53 FIGURE 5.5 PUBLISH ACTIVITY DIAGRAM................................................................................................................ 55 FIGURE 5.6 UPDATE ACTIVITY DIAGRAM ................................................................................................................ 57 FIGURE 5.7 ORTHOPHOTO PRODUCTION PROCESS................................................................................................... 60 FIGURE 5.8 RELATED GEO-SERVICES IN ORTHOPHOTO PRODUCTION....................................................................... 61 FIGURE 5.9 USER AND SERVICE TABLE DETAILS...................................................................................................... 62 FIGURE 5.10 REGISTER INTERFACE ......................................................................................................................... 63 FIGURE 5.11 LOG IN INTERFACE ............................................................................................................................. 63 FIGURE 5.12 INITIAL SEARCH INTERFACE................................................................................................................ 64 FIGURE 5.13 SEARCH IN RESULTS INTERFACE ......................................................................................................... 64 FIGURE 5.14 PUBLISH INTERFACE ........................................................................................................................... 65 FIGURE 5.15 INTERFACE FOR USER AUTHENTICATION ............................................................................................ 65 FIGURE 5.16 SERVICE SELECTION INTERFACE ......................................................................................................... 66 FIGURE 5.17 UPDATE INTERFACE. .......................................................................................................................... 66

ix

List of tables

TABLE 2.1 RM-ODP VIEWPOINTS (OGC 2002) ..................................................................................................... 16 TABLE 2.2 GEOGRAPHIC SERVICES TAXONOMY (OGC 2002) ................................................................................. 18 TABLE 3.1 EXAMPLES OF QUALITY REQUIREMENTS................................................................................................ 22 TABLE 3.2 QUALITY DEFINITIONS ........................................................................................................................... 23 TABLE 3.3 SUMMARY OF DATA QUALITY ELEMENTS (KRESSE AND FADAIE 2004).................................................. 25 TABLE 3.4 QUALITY REPRESENTATION AND GI SERVICE CHARACTERISTICS........................................................... 27 TABLE 3.5 USER REQUIREMENTS AND QUALITY CHARACTERISTICS ........................................................................ 29 TABLE 3.6GI SERVICE QUALITY MODELS................................................................................................................ 31 TABLE 4.1 SECTION NAME VALUE AND CONTENTS ................................................................................................. 34 TABLE 4.2 PROPERTIES OF SERVICE COMPONENT IN WSDL (CHINNICI, GUDGIN ET AL. 2004) ............................... 36 TABLE 4.3 CHARACTERISTICS OF EXISTING STANDARDS......................................................................................... 39 TABLE 4.4 CONSIDERATIONS FOR CREATING METADATA........................................................................................ 40 TABLE 4.5 FEATURE COMPONENT SCHEMA ............................................................................................................ 40 TABLE 4.6 SUGGESTED FEATURE REPRESENTATION SCHEMA.................................................................................. 41 TABLE 4.7 REVISED PART OF SERVICEIDENTIFICATION METADATA ........................................................................ 43 TABLE 5.1 ADQ WEB SITE EVALUATION FORM (EDITED FROM TOMITA, 1999). ...................................................... 67 TABLE 5.2 QUALITY CHARACTERISTICS AND FUNCTIONAL PART EVALUATION FORM.............................................. 68 TABLE 5.3 ADQ WEB SITE EVALUATION RESULT .................................................................................................... 69 TABLE 5.4 RESULTS OF QUALITY CHARACTERISTICS EVALUATION ......................................................................... 70

1

1. Introduction

1.1. Background

The term “Geospatial Data Infrastructure (GDI)” was introduced to promote a better understanding of the complex of technical, organizational, and institutional requirements needed to facilitate effective data sharing. Traditionally, public organizations had taken charge in the main role in the GDI, and the main function was supplying data to customers. For that reason, in the early 90’s research has been focused on the concepts of GDI and on process to improve the performance of organizations that supply the fundamental data in the GDI. However, customers are requiring more customized, complex and value added services. In order to follow customers’ requirements, new developments in the industrial and service sectors are centring on the concept of Virtual Enterprises (VE). The objectives of the VE concept are better customer satisfaction, reduced time-to-market and adaptation to changes in the continuous change of requirements. VE is composed of functions provided by participating organizations (enterprises) and structured and managed in such way that they present themselves to third parties as one enterprise. Applied to the geospatial information industry such concepts take us beyond the GDI as just a mechanism for accessing geospatial data to include also demand oriented finished information services (Morales and Radwan 2002). Presently, with the advance of information technology, geospatial data and geographic functionalities (known as components) can be shared and consumed over the web. One of the major backings is the maturity of infrastructure for information exchange on the web. The infrastructures are geared towards interoperable platforms. This can be seen from the development of W3C’s standards on the areas of networking, middle-tier, and interchange formats. In the field of GIS, the concept of web service is implemented in the OpenGIS Service Architecture by the OGC (Aditya and Lemmens 2003). It seems that users have possibility to make a combination of one or more services into their applications. Without having to buy complete license of software, it is viable to bring GIS technologies more straightforward for the users. If we have several enterprises that can offer their services on the web, it makes sense to chain distributed data or functionalities fit to customized request. In order to work distributed services properly, services should be searched on the web by customers. In this environment, registry takes very important role in realization of the service transaction based on the web. Registry is mechanisms to publish what service providers want to describe about their services and to discover what customer wants know about services. Well organized registry would be the first step to make distributed system more effectively, and that is the why many leading organizations, such as Open Geospatial Consortium, Microsoft, IBM etc, are trying to develop registry.

2

1.2. Research problems

Currently, one of the main leading organizations in geographic information domain is Open Geospatial Consortium (OGC). As a leader, they have introduced lots of recommendations and specifications such as Web Feature Service, Web Coverage Service, Web Map service, Reference model etc, including collaborative work with international organization for standard (ISO). In addition, OGC offers how data set and service looks like using description method called metadata. By following ISO 19115 definition, “Metadata is data about data or a service. Metadata is the documentation of data. In human-readable form, it has primarily been used as information to enable the manager or user to understand, compare and interchange the content of the described data set. In the Web Services context, XML (eXtensible Markup Language)-encoded (machine-readable and human-readable) metadata stored in catalogs and registries enables services to use those catalogs and registries to find data and services” Metadata in OGC context can be classified dataset metadata and service metadata. Dataset metadata has been researched by various organizations and many collaborative works are being done. OGC and ISO have jointly developed metadata. In OGC and ISO context, metadata has lots of information including quality information. Such information is very close to what users want to know about data set, although sometimes it can be difficult to understand for inexperienced users. However, service metadata does not have enough information especially information about the quality of service. Lack of quality information in existing service metadata can not answer if there are several service providers they offer similar function;

� What is the most suitable service for specific requirement? � How can it be distinguished? � How the uncertainty of service selection can be reduced?

Having and registering quality information in service metadata, both service users and providers can take some benefits. Users can find the service that matched their priority of requirements, and service providers can take more possibilities that their service can be searched if their services are registered on the service registry in correct way. This research focuses on user perspective on quality factors and implementation on registry. .

3

1.3. Prior research

Many researches have been studied on the line of GDI development. Those researches include the change of GDI concept from geo-data provision to geo-information service provision. On this concept, web-service, service chaining and quality of service (QoS) have been researched. Some of those efforts are following

• Extending Geo-information services: A virtual architecture for spatial infrastructures (Morales and Radwan 2002) introduces the concept of Geo-information Service Infrastructure (GSI). And they address the advisable direction taking the advantage of existing GDI.

• Chaining distributed GIS services (Aditya and Lemmens, 2003) addresses technical perspective of

service chaining. They present the principle of building the user-defined chaining in the distributed environments.

• The changing role of the geo-data infrastructure; From a data delivery network to a virtual enterprise

supporting complex services (Morales, Onchaga et al. 2004) explains service chaining concept and components. In addition, quality-aware service chaining has been introduced.

• Modelling for quality of services in distributed geo-processing (Onchaga 2004) presents

architecture for quality of service (QoS)-aware service chaining and defines an extensible QoS model for GI services. Further, to facilitate the successful evolution of GI enterprise into effective service providing nodes on the GI service infrastructure, an integration framework for GI enterprises presented.

• The OpenGIS Abstract Specification, Topic 12: OpenGIS Service Architecture (OGC 2002) and ISO

19119 Geographic Information Services (ISO 2001) explain service chaining models and the model of service and service metadata.

• Model-driven Design of Geo-information Services (Morales 2004) addresses service based GDI

called Geo-information Service Infrastructure (GSI) and a method for the development of distributed geo-information systems.

However, those efforts has not been studied sufficiently that how to show the quality of services in service registry within GDI context.

1.4. Research context

1.4.1. GDI

In the early 90’s research has been focus on the concepts of Geospatial Data Infrastructure (GDI) and on process to improve the performance of organizations that supply the fundamental data in the GDI. In this concept, GDI has been defined the complex of institutional, organizational, technological, human, and

4

economic resources facilitating the sharing, access to, and responsible use of geospatial data at an affordable cost for a specific application domain or enterprise(Groot and McLaughlin 2000). However, new developments in the industrial and service sectors are centring on the concept of Virtual Enterprises (VE). That’s why we need service oriented GDI. GSI is one of the service oriented GDI concept. A GSI is system where specialised information products and services can be obtained by exploiting an infrastructure of inter connected data nodes (data repositories), data brokers, service providers, service brokers and clients (Morales and Radwan 2002). Main components of GSI are services (core and administration service), service portal and registry service. Using GSI, not only accessing data but also accessing diverse services are possible. New opportunities to facilitate and combine diverse services could create new business beyond one’s capacity. The architecture of GSI is explained in figure 1.1.

Figure 1.1 GSI architecture (Morales 2004)

1.4.2. Service

Due to the dramatically changing technology, especially internet technology, many services that were impossible before became real. For example, web mapping services, e-Commerce etc. The web services promise seamless interoperability between applications, in spite of platforms used (Schmelzer, 2002).

5

Service (web-based) can be defined and understood variously. Some of them are following. � Service is a computation performed by a software entity on one side of an interface in response to a

request made by a software entity on the other side of the interface. A collection of operations, accessible through an interface, that allows a user to evoke a behaviour of value to the user (ISO 2001).

� Web services are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web services perform functions that can be anything from simple requests to complicated business processes. Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service. (OGC)

� Web services are the next step in the evolution of the World Wide Web and allow programmable elements to be placed on web sites where others can access distributed behaviours(UDDI 2000).

In the GSI concept, web-based service could be defined that any data, functionalities, resources, combination of distributed services can be accessed and offered through internet.

1.4.3. Registry

Clearinghouse has been settled in the center of GDI as a spatial dada searching mechanism; however, registry is not only data but also service searching mechanism. The registry is publicly accessible set of implementations of the specification that allow businesses to register information about the Web service they offer so that other business can find them (UDDI 2000). According to GSI architecture, registry has or should have several functions such as publish, discovery, quality, bind and maintain self defined services. And each service can be represented through metadata described by service providers. Currently highlighted concept of service registry is just beginning stage. So various issue should be considered to develop it.

1.4.4. Quality of Service

One of the most important parts in quality is customer satisfaction. In other words, fulfilling user requirements is very essential when quality issue is mentioned. According to the definition of ISO 9000, quality is degree to which a set of inherent characteristics fulfils requirements (ISO 2000). In traditional concept of geo-information domain, quality has been stated to describe data accuracy of the spatial data. After digital spatial databases and GIS systems were introduced, the extent of spatial data quality was broadened not only accuracy but also other elements such as completeness, consistency, availability etc., and it gave more opportunities to share spatial data between distributed data user communities and to do something beyond their capacity. These changes led general definition of quality of spatial dataset as its fitness-for-use in an application context (Onchaga 2004), and data set metadata include quality part. Some of the quality factors can be seen on the data set metadata, though those quality factors are insufficient to satisfy customers’ quality related questions. However, change of GDI requires quality factors about service in service metadata. When we want include quality factors in service metadata it should be different from data set metadata, because services can be classified to various categories and users’ requirements can be different. Especially, when services are

6

performed through internet as an integrated form, their requirement can be diverse depend on the type of service. For that reason, some factors that are recognized very far from quality can be quality factors to specific users. Quality factor in this research can be not only well-recognized one but also customized one.

1.5. Research scope

As shown in figure 1.2, this research mainly deals with three subjects. Firstly, quality model is investigated using quality issues in some of relevant domains. User requirements are developed to quality characteristics and quality model. Secondly, extended service metadata is proposed in incorporation of existing standards. Finally, proposed metadata is implemented on sample registry to show how it looks like. Some web programming language and data base will be used to realize the idea.

Figure 1.2 Scope of research

1.6. Research objectives

The main objective of this research is identifying quality characteristics to extend quality-aware service registry development. In order to achieve the main objective, several sub objectives have to be achieved. These are listed below.

7

� To identify user perspective on quality characteristics of service

� To propose quality applied service metadata

� To implement quality applied service registry

1.7. Research questions

In order to achieve research objectives, the following questions need to be addressed. 1. What is the user perspective on service quality characteristics?

• Why are quality characteristics important in registry?

• What kinds of quality characteristics are required?

2. How can the quality factors be modelled?

• What are the elements of each quality factor?

• What kind of the constraints should be included?

• How can the quality characteristics be modelled?

3. How quality applied service metadata can be proposed?

• What are the existing service description methods and their characteristics?

• How can quality characteristics be applied on service metadata?

• What is the proposed service metadata?

4. How can service registry interface be modelled?

• What are the constraints of interface?

• How can those constraints be modelled?

5. How can the proposed registry be implemented and evaluated?

1.8. Research methodology

This research has been carried out under the following three main phases as depicted in figure 1.3: Literature review, quality characteristics extraction and Registry Design. Explanations of methods are given below;

1.8.1. Literature Review

Literature review is involved extensive research of various journal articles, conference proceedings, past thesis and reports, books, news articles and web references that detail information about traditional and service oriented GDI, Registry and Quality related literatures. This helps to answer all questions mentioned above mainly question 1 and 3.

1.8.2. Required Quality characteristics Extraction

Quality related characteristics are identified by literature study and analysis. Firstly, prototyping has been done by applying common quality concept onto geo-information services. User requirements are followed to check what kinds of quality related factors and constraints are required in geo-information services. Extracted

8

user requirements are mapped to quality characteristics. After above mentioned steps, quality related characteristics and relation among them are figured out to solve question 1 and 2.

1.8.3. Modelling proposed registry

Quality characteristics, service metadata, and registry interface are modelled in order to design proposed registry. Firstly, quality model is proposed using extracted quality characteristics. Service metadata model design is next step. In this step, existing service metadata model and quality characteristics are harmonized. Lastly, service provider and user interface are modelled to operate proposed registry. Question 2, 3, 4 and 5 are dealt with in this step.

1.8.4. Implementation and Evaluation

In this step, above mentioned models are implemented on the web using web programming language and database technology, and it is evaluated by number of users. Question 5 is answered by evaluation.

Figure 1.3 Research Methodology diagram

1.9. Thesis structure

Chapter 1 Introduction This chapter provides an overview of the research that includes background, research problems, objectives, important questions and methodology briefly. It presents the background to the study, the research problem, the research framework and key references to prior works done. It further outlines the objectives, the research questions and the methodology used to answer these questions. Finally, it gives an overview of the structure of the thesis.

9

Chapter 2 Service oriented GDI This chapter gives explanation of traditional GDI and some of the important components in GDI. Then new trend in GDI, named service oriented GDI, is reviewed mainly in the context of Open Geospatial Consortium (OGC). Some considerations are addressed in service oriented GDI. Chapter 3 User perspective on quality of service This chapter studies quality of service in user point of view. In the first of this chapter, general view of service quality is mentioned. In second part, one service sample is taken. From this example, quality characteristics and quality model is developed. Chapter4 Service metadata model This chapter gives quality characteristics applied service metadata. By reviewing current standards, possibility of incorporation among standards is studied. Then quality characteristics applied service metadata is proposed. Chapter 5 Implementation The proposed service metadata is implemented in this chapter. Implementation criteria and critical functions are studied. For implementation, web programming language and database are used and it can be seen on the web. Further evaluation is done by number of users. Chapter 6 Conclusion and recommendation Conclusions and further research recommendations have been given in this chapter.

10

1.10. Operational plan

2004 2005 Task Name

Sep Oct Nov Dec Jan Feb Mar

Literature review

User requirements extraction

Quality characteristics model

Service metadata design

Registry design

Implementation

Thesis writing

� Chapter 1

� Chapter 2

� Chapter 3

� Chapter 4

� Chapter 5

� Chapter 6

TITLE OF THESIS

11

2. Service oriented GDI

2.1. Introduction

Geospatial Data Infrastructure (GDI) has been focused on accessing and sharing geospatial data since it was introduced. Many countries have developed or are developing data sharing system, and it is being used. However, users’ needs are changing rapidly, and many of those needs can not be done by single organization. By reviewing change of GDI, trend in geographic information domain can be traced. The main objective of this chapter is to overview trend of GDI concept. In order to achieve this objective, conventional GDI and service oriented GDI concept are reviewed. Firstly, conventional GDI as a geographic data discover and access mechanism is reviewed including its main components. Especially, clearinghouse and metadata are focused. Then service oriented GDI concept is explained as an emerging trend in GDI. In order to review trend in GDI, GI service architecture is explained using OGC service architecture. Finally, some examples of OGC services are introduced for better understanding. By studying service oriented GDI concept, we seek further development of GDI.

2.2. GDI

One of the most important information in human activities would be location related information called geographic information. For that reason, lots of nations, organizations, and individuals have tried to improve the way of creation and use of geographic information. For example, maps, commonly used location related information, have used in various human related domains such as urban planning, disaster management, military operations etc. Further, maps have been represented various ways. As a result, we can use not only paper based map but also digital map on the screen include various functions. As importance of geographic information is getting increased people needs more improved way of creation, storage, processing, presentation and dissemination of geographic information. For many years of efforts make more and more geographic data, and the volume of data has been growing faster day by day. Development of geographic information technology makes use of geographic data more efficiently and easily. As users aware the usefulness of geographic data, geographic industry needs more data from reliable providers. As a result, the mechanism for accessing and sharing reliable data sources is needed. Share of existing data promised the opportunities lower cost and faster geographic information production process by reducing redundant effort for data collection or processing. The idea of data sharing mechanism has developed by geographic information community named Geospatial data infrastructure (GDI).

TITLE OF THESIS

12

The notion of a data infrastructure as a mechanism for providing more effective access to geospatial data first emerged in the early 1980s in Canada. GDI encompasses the networked geospatial databases and data handling facilities, the complex of institutional, organizational, technological, human, and economic resources which interact with one another and underpin the design, implementation, and maintenance mechanisms facilitating the sharing, access tom and responsible use of geospatial data at an affordable cost for a specific application domain or enterprise (Groot and McLaughlin 2000). The benefits of GDI are reduced data collection times and cost, fast and wider access to data, interoperability between geo-applications and generation of data for multiple uses. Internet technology acted as a facilitator for the evolution of this concept into a tangible reality (Morales 2004).

2.2.1. GDI components In order to make GDI concept real, various issues are required. Firstly, data format should be usable to users. Usability of data has to be considered the beginning of data production. This issue can be solved by using standard way of data format. International standards and advance of technology have been solving many of these problems. Producing and storing data by predefined way, users can use existing data if data is accessible. Secondly, data should be accessible to users. Accessibility of data can be viewed two considerations: how data is described, and where data can be found. Firstly, if data providers want to share their data, they should create clear description of data sets. This description should give clear idea, such as when, where, who, what, how, and why it is collected. These clear descriptions can give whether specific data is fit-to-use or not. This description is called metadata. Further, metadata should be expressed according to standard way. Secondly, data providers and users need somewhere to publish or find metadata. These functions can be done using clearinghouse. By following FGDC (Federal Geographic Data Committee), clearinghouse is defined ‘a system of software and institutions to facilitate the discovery, evaluation, and downloading of digital geospatial data’. Figure 2.1 shows GDI components (Morales 2004).

Figure 2.1 GDI components (Morales 2004)

TITLE OF THESIS

13

2.2.2. Clearinghouse component

GDI supports acquiring required data on the network connected environment. Users search the network for the databases containing the required data, and connect to those databases. Further users may retrieve what they want from that source. Clearinghouse plays important role in data searching. Main components of clearinghouse can be seen as like Figure 2.1. Clearinghouse is composed of servers (Local, clearinghouse server), user interface, and metadata (global, local metadata) (Groot and McLaughlin 2000). They are explained in coming sections.

Figure 2.2 Conceptual system architecture of clearinghouse (Groot and McLaughlin 2000)

2.2.2.1. The Servers

Servers can be viewed two types, local and the clearing house servers. The local server is composed of several modules to facilitate access, ordering, delivering, and sharing of a data set. And it has some functions to prevent unauthorized access and interception value of information. The clearinghouse server has two main functions: the metadata manager, and the query processor. Figure 2.2 shows Clearinghouse server. Service providers can publish or update their dataset metadata through metadata manager. Users can ask existing data in local servers through query processor using certain query form.

2.2.2.2. Graphic User Interface

In general, graphic user interface (GUI) can be told the part of a computer application (software program) that displays on the screen for the user to discover, select and order data and services. It is based on communication protocols such as TCP/IP built on top of web browsers such as Explorer, Netscape, etc (Reece 2004). The GUI mainly facilitate two types of user interaction: browse or query.

TITLE OF THESIS

14

By browsing, users can select only predefined categories of information; however query interface gives users to specify what users require using given query form. These communication protocols allow interaction between the clearinghouse gateway and local servers.

Figure 2.3 Clearinghouse server (Groot and McLaughlin 2000)

2.2.2.3. Metadata (data set metadata)

1) What is metadata?

Many people describe metadata simply saying data about data. According to FGDC in the United States, metadata is data about the content, quality, condition, and other characteristics of data. In terms of a GIS, metadata is used to describe how the geospatial and attribute data was collected and processed into its final form. Metadata enables the use of geographic data in the most efficient way by knowing its basic characteristics. It facilitates discovery, retrieval and reuse of geo-data (OGC 2003). When metadata is applied in specific application, level and contents of metadata should be considered. Various levels of metadata may be used. At the higher level, only a small description is required for the purpose of advertising or simply showing the contents of the data sets while at the lower level, a more detailed set of metadata is required to judge the fitness of use, to obtain, and actually use the data sets (Groot and McLaughlin 2000). The other side we need two different metadata contents, one for local metadata stored at each data provider and the other for global metadata in single site.

TITLE OF THESIS

15

2) The Metadata Standard

In order to use metadata in common, metadata should be formed standardized way. The metadata standard provides the common set of terminology and definitions for documentation when describing information holdings – such as spatial data, tabular data, and documents. And having an accepted standard means:

• Metadata are collected in a clear and systematic way. • Metadata for a particular data set remain consistent over time -- as the data set is updated or

added to. • Similar data sets can be compared to determine their similarities and differences. • The development of integrated access and input systems is encouraged. • Others can understand and easily determine the potential usefulness of the data.

Many international organizations have developed metadata standards. Some of those organizations are FGDC, International Organization for Standardization Technical Committee 211 (ISO TC211), and Open Geospatial Consortium etc. Including these organizations, existing standards are already sharing their ideas. Some of considerations for metadata creation are addressed below;

• Existing metadata standards: In metadata standard, reviewing existing standard is important. Sharing idea with Global standard, such as ISO, will be one of the good ways.

• Ease of input and use: If the system and the standard are too bulky, too complex, have too many mandatory components, or are too difficult to understand, it is not so acceptable to users.

• Meet client need: What would he/she need to know about a data set will be what and how metadata contain and looks like.

• Collect adequate detail: The metadata standard must collect enough information to appropriately describe the information holding.

Metadata related issues are addressed further in chapter 4.

2.3. Service oriented GDI

The role of the GDI is currently changing form a simple data sharing mechanism to customer focused information and service provision. Customer requirements are changing rapidly. They want not only conventionally provided data but also value-added products or more complicated geographic information services. In this context, a service can be considered as the contribution of a system or part thereof to its surrounding environment. This contribution can be defined in terms of data, operations, processing, resources, value-added products or any combination of them (Morales and Radwan 2004). Customer based complicated services normally have been done by combining group of functions by one organization. However, as customers requirements are getting more complicated and diverse it seems more difficult to follow customers’ needs. Users want GDI that can support service collections of independent services. And this new concept of GDI is called service oriented GDI in this research. One of the most important benefits in service oriented GDI is that service oriented GDI promise use of independent collections of services. By use of these collections, user can generate more complicated services those are impossible to create by single organization. In order to make this concept real, each

QUALITY FOCUSED SERVICE REGISTRY DEVELOPMENT IN SERVICE ORIENTED GDI

16

core service should be described, accessed, and combined to be used in complex system. Including collections of service (service chaining in OGC service architecture), this issues related studies can be found in OGC efforts. Next section looks at describing, accessing, and combining service issues are explored in the context of OGC specification.

2.3.1. Open Geospatial Consortium (OGC)

The Open Geospatial Consortium, Inc (OGC) is an international industry consortium of over 270 companies, government agencies and universities participating in a consensus process to develop publicly available interface specifications. OpenGIS Specifications support interoperable solutions that "geo-enable" the Web, wireless and location-based services, and mainstream IT. The specifications empower technology developers to make complex spatial information and services accessible and useful with all kinds of applications (OGC

��).

OGC has been doing lots of efforts on formalizing OGC specifications, organizing user requirements based projects, identifying user communities and potential markets, developing and harmonizing geo-processing standards with other standards etc. One of those efforts can be seen Geospatial services standard.

2.3.1.1. Geospatial service architecture

OGC have adapted ISO service architecture standards as OpenGIS abstract specification, topic 12: OpenGIS Service Architecture. By adapting ISO service architecture, OGC provides general concept of geographic information (GI) service. GI service architecture is a set of components, connections and topologies defined through a series of viewpoints. Table 2.1 explains various view points and definitions (OGC 2002).

Viewpoint Name Definition of RM-ODP Viewpoint Enterprise Focuses on the purpose, scope and policies for that system. Information Focuses on the semantics of information and information processing. Computational Captures component and interface details without regard to

distribution. Engineering Focuses on the mechanisms and functions required to support

distributed interaction between objects in the system. Technology Focuses on the choice of technology.

Table 2.1 RM-ODP Viewpoints (OGC 2002)

Each viewpoint includes details of services. Among them, service chaining, service description, and service information access are reviewed. Further, GI service taxonomy and some examples are followed in order to draw architecture more clearly.


17

2.3.1.1.1. Service chaining

ISO 19119 provides architecture patterns for service chaining. There are many options for the allocation of service chaining services to components. Various allocations of services can be distinguished by visibility of the services to users. Mainly three allocation approach can be considered. They are given below (ISO 2001):

� User defined (transparent) chaining: the Human user manages the workflow. � Workflow-managed (translucent) chaining: in which the Human user invokes a Workflow

Management service that controls the chain and the user is aware of the individual services. � Aggregate service (opaque): in which the user invokes a service that carries out the chain,

with the user having no awareness of the individual services. Difference between these service chaining depends on the degree of control by user. In transparent chaining is mainly controlled by the user. In translucent, user can affect a workflow service which controls the chain execution. In the aggregate pattern, the aggregate service is performed without user control. This service selection can be organized by use of well described service descriptions. Service metadata takes important role in this context.

2.3.1.1.2. Service metadata

As data set metadata plays important role in traditional GDI service metadata has important role in service oriented GDI. By using properly described service metadata, users could evaluate the fitness for use of a service in a specific context. ISO 19119 support service metadata. In OGC context, services are described by three main service metadata contents; service identification, operation metadata, and service provider metadata. Service identification describes the functionality provided by the service. Operation metadata describes the operations by which the service instance can be invoked. Finally, service provider describes who offer specific service including contact information. Detailed service metadata schema and xml encoded service example is explained in chapter 4. In order for service metadata works properly, service metadata should be accessed by users. In OGC service architecture, registry service takes that role.

2.3.1.1.3. Service information access

The first step to perform any services would begin with finding suitable services. OGC provides the concept of service finding mechanism. And it is called Registry or catalogue service. Registry service and catalogue service are used interchangeably. Registry Services provide a common mechanism to classify, register, describe, search, maintain and access information about resources available on a network. Resources are network addressable instances of typed data or services. Types of registries are differentiated by their role such as registries for cataloging data types (e.g., types of geographic features, coverages, sensors, and symbols), online data instances (e.g., datasets, repositories, and symbol libraries), service types and online service instances. Basic concept of registry services, support the ability to publish and search collections of descriptive information (metadata) for data, services, and related information objects, is more and less similar to clearinghouse concept. However, main distinction between them is whether service based or not.


18

2.3.1.1.4. Information Viewpoint: A Basis for Semantic Interoperability

Services can be viewed and defined various ways. Sometimes same service can be named differently depend on whom named service. For that reason, each particular service will need to define its syntactical interfaces through operations and its semantics through description of the meaning of the operations and their legal sequencing (OGC 2003). Information viewpoint support this issue. OGC service architecture defines the Extended Open Systems Environment (EOSE) model for geographic information. The EOSE defines classes of services based on the semantic type of computation that they provide. Six classes of information technology services are used to categorize geographic services. Descriptions of six categories are given below (OGC 2002):

• Human interaction services: services for management of user interfaces, graphics, multimedia, and for presentation of compound documents.

• Model/Information management services: services for management of the development, manipulation, and storage of metadata, conceptual schemas, and datasets.

• Workflow/Task services: services for support of specific tasks or work-related activities conducted by humans. These services support use of resources and development of products involving a sequence of activities or steps that may be conducted by different persons.

• Processing services: services that perform large-scale computations involving substantial amounts of data. Examples include services for providing the time of day, spelling checkers, and services that perform coordinate transformations (e.g., that accept a set of coordinates expressed using one reference system and converting them to a set of coordinates in a different reference system). A processing service does not include capabilities for providing persistent storage of data or transfer of data over networks.

• Communication services: services for encoding and transfer of data across communications networks.

• System management services: services for the management of system components, applications, and networks. These services also include management of user accounts and user access privileges.

Table 2.2 shows structure of service taxomony

� Geographic Human interaction services

� Geographic Model/Information management services

� Geographic Workflow/Task services

� Geographic Processing services

o Geographic Processing services – spatial

o Geographic Processing services – thematic

o Geographic Processing services – temporal

o Geographic Processing services - metadata

� Geographic Communication services

� Geographic System management services

Table 2.2 Geographic services taxonomy (OGC 2002)


19

The following provides some examples of geographic services within the geographic services taxonomy. A service catalogue compliant with ISO 19119 categorizes service metadata instances in the categories of the geographic service taxonomy Geographic human interaction service examples:

� Catalogue viewer. Client service that allows a user to interact with a catalogue to locate, browse, and manage metadata about geographic data or geographic services.

� Geographic viewer. Client service that allows a user to view one or more feature collections or coverages. This viewer allows a user to interact with map data.

� Geographic feature editor. Geographic viewer that allows a user to interact with feature data, e.g., displaying, querying. Supports feature annotation.

Geographic model/information management services:

� Feature access service. Service that provides a client access to and management of a feature store.

� Map access service. Service that provides a client access to a geographic graphics � Coverage access service. Service that provides a client access to and management of a

coverage store. � Catalogue service. Service that provides discovery and management services on a store of

metadata about instances.

Geographic workflow/task management services: � Chain definition service. Service to define a chain and to enable it to be executed by the

workflow enactment service. � Workflow enactment service. Interprets a chain and controls the instantiation of services and

sequencing of activities. Geographic processing services – spatial:

� Coordinate conversion service. Service to change coordinates from one coordinate system to another coordinate system that is related to the same datum. In a coordinate conversion the parameters’ values are exact. Coordinate conversion services include map projection services. ISO 19111 is relevant to coordinate conversion.

� Coordinate transformation service. Service to change coordinates from a coordinate reference system based on one datum to a coordinate reference system based on a second datum. A coordinate transformation differs from a coordinate conversion in that the coordinate transformation parameter values are derived empirically: therefore there may be several different estimations (or realizations). ISO 19111 is relevant to coordinate transformation.

� Subsetting service. Service that extracts data from an input in a continuous spatial region either by geographic location or by grid coordinates.

� Rectification service. Service for transforming an image into a perpendicular parallel projection and therefore a constant scale.


20

� Orthorectification service. A rectification service that removes image tilt and displacement due to terrain elevation. Orthorectification requires use of digital elevation data, usually in grid form.

Geographic processing services – thematic:

� Geoparameter calculation service. Service to derive application-oriented quantitative results that are not available from the raw data itself.

� Thematic classification service. Service to classify regions of geographic data based on thematic attributes. Classification of coverages (including images) subdivides a coverage into regions based on attribute values. Classification of features sorts features into groups based on attribute values or feature associations.

� Feature generalization service. Service that generalizes feature types in a feature collection to increase the effectiveness of communication by counteracting the undesirable effects of data reduction.

� Subsetting service. Service that extracts data from an input based on parameter values. Geographic processing services – temporal:

� Temporal reference system transformation service. Service to change the values of temporal instances from one temporal reference system to another temporal reference system. ISO 19108 is relevant to temporal reference systems. Using the terminology of ISO 19108, a temporal reference system transformation service replaces the TM_Position value of a given TM_Instant with an equivalent TM_Position value associated with a different temporal reference system.

� Subsetting service. Service that extracts data from an input in a continuous interval based on temporal position values.

� Sampling service. Service that extracts data from an input using a consistent sampling scheme based on temporal position values.

� Temporal proximity analysis service. Given a temporal interval or event, find all objects with a given set of attributes that are located within an user-specified interval from the interval or event.

Geographic processing services – metadata:

� Statistical calculation service. Service to calculate the statistics of a data set, e.g., mean, median, mode, and standard deviation; histogram statistics and histogram calculation; minimum and maximum of an image; multiband cross correlation matrix; spectral statistics; spatial statistics; other statistical calculations

� Geographic annotation services. Services to add ancillary information to an image or a feature in a Feature Collection (e.g., by way of a label, a hot link, or an entry of a property for a feature into a database) that augments or provides a more complete description.

Geographic communication services:

� Encoding service. Service that provides implementation of an encoding rule and provides an interface to encoding and decoding functionality. A standard relevant to encoding is ISO 19118.


21

� Transfer service. Service that provides implementation of one or more transfer protocols, which allows data transfer between distributed information systems over off-line or on-line communication media. To successfully transfer data between two systems the sender and receiver need to agree on the transfer protocol to be used. A standard relevant to transfer is ISO 19118. For some geographic data sets large data object transfer is required.

� Geographic compression service. Service that converts spatial portions of a feature collection to and from compressed form.

� Geographic format conversion service. Service that converts from one geographic data format to another.

Geographic system management services:

� No geographic-specific system management services have been identified.

2.4. Concluding remarks

This chapter addressed traditional concept of GDI and service oriented GDI. Traditional GDI concept was explained using requirements from technical perspective of GDI. Among those requirements clearinghouse and its components were reviewed mainly. Main interest in traditional GDI was clearinghouse server and the value of metadata. These two contents are used and studied further in chapter4. Service oriented GDI has defined as ‘GDI that can support service collections of independent services to support complicated customer requirements’. And then relevant issues in current GI domain have reviewed using OGC service architecture. Service chaining, service description and service information accessing have focused to support service oriented concept. Finally, standard way of service taxonomy and some examples have been explained for better understanding. Some findings in this chapter, such as considerations for creating metadata clearing house components and server, currently developed services in OGC, are used to propose service metadata and to implement service registry.


22

3. User perspective on quality of service

3.1. Introduction

The main objective of this chapter is to define quality requirements and identify quality characteristics that are relevant in a geographic information (GI) service environment. In order to achieve this objective, some commonly used definitions of quality are reviewed. In particular, we look at quality in business process, distributed system and geographic data. In each case, we review how quality is defined and represented. Based on quality review, we present a definition of quality relevant to GI service environment. After this, quality requirement and characteristics are derived. This chapter is organized as follow. Section 3.2 reviews three relevant quality concepts: quality in business process, quality in distributed system, and quality of geospatial data. The aim of the review is to evolve a definition of quality that is appropriate to GI service environment. Section 3.3 presents quality in GI services. Section 3.4 extracts quality requirements of GI services. Using these quality requirements, appropriate quality characteristics are modelled.

3.2. General quality concepts

Quality is an abstract term. Therefore the meaning and representation of quality can be different depending on who uses this term. Some examples are given in Table 3.1.

Area Meaning/Representation Airlines On-time, comfortable, low-cost service Health Care Correct diagnosis, minimum wait time, lower cost, security Postal Services fast delivery, correct delivery, cost containment Consumer Products Properly made, defect-free, cost effective Insurance Payoff on time, reasonable cost Military Rapid deployment, decreased wages, no graft Communications Clearer, faster, cheaper service

Table 3.1 Examples of quality requirements

Having standardized definition of quality across all domains is clearly difficult, and as a result there are many quality definitions. In order to understand quality better, general definitions of quality have to be reviewed. By reviewing general definitions, basic concept of quality is studied, and it helps to understand quality concept in other domains. The International Standards Organization (ISO) has done efforts to unify the different views of quality in a general definition. ISO defined quality as


23

“totality of characteristics of a product that bear on its ability to satisfy stated and implied needs (ISO 2000)”. Table 3.2 shows sample definitions in different areas.

Target Definitions

Customer-based � Quality consists on the capacity to satisfy wants (Edwards 1968). � Quality is fitness for use (Juran 1988).

Manufacturing -based

� Quality is the degree to which a specific product conforms a design of specification (Gilmore 1974).

� Quality means conformance to requirements (Crosby 1979).

Product-based � Quality refers to the amount of the unpriced attributes contained in

each unit of the priced attribute (Leifler 1982).

Value-based � Quality is the degree of excellence at an acceptable price and the

control of variability at an acceptable cost (Broh 1982).

Table 3.2 Quality definitions

In order to develop the understanding of quality concept, qualities in various domains are studied in this section. First, quality of business process quality is studied in section 3.2.1. Quality in distributed system and GI data are followed in section 3.2.2 and 3.2.3. Then quality of distributed system and GI data are followed. The aim of this section is reviewing quality definitions and representation in various domains relevant to GI service environment.

3.2.1. Quality of business process

A business process is a collection of activities designed to produce a specific output for a particular customer or market (Sparks 2000). This definition emphasizes on how the work is done, and not what the business process produces. Conventionally, the quality of a business process is checked by the quality of product. However, quality of business process has more than quality of product. If we have to spend a lot of cost or time to make a product of a little bit higher quality, we can not say that quality of business process has improved. In order to check business process quality, we refer to performance of business process. Performance can be explained as the overall productivity of a system including quality of product, cost and delay. Quality of product can be measured by expected functional character. For example, quality of car can be checked whether it works in the expected way, with fewer defects, high security, less noisy etc. The cost issue in business process can be viewed in two ways, production cost and price of output to consumer. Production cost is highly related to the efficiency of business process, and its influence to the price of output. Price of output is related to quality of product and requirements from market. Generally, higher quality and more requirements from the market lead to high price. Delay is related to the responsiveness of business process. Production time and delivery time are considerations in delay. Production time is the time duration from the beginning of producing process to the end of producing process. Delivery time is the time duration between when the product is sent by the producer to that time when the product is received by consumer. In this context, quality is related to not only the quality of product itself but also to the efficiency of business process and market related factors. For that reason, considerations in business process should


24

be founded on the way to improve product quality (functional properties related factors) and the way to improve performance of process (non- functional properties related factors).

3.2.2. Quality in distributed system

According to Maarten van Steen’s definition (Steen 2001), distributed system is viewed as “a piece of software that ensures that a collection of independent computers appears to its users as a single coherent system”. Distributed databases can be an example of distributed system. Distributed database is a database that consists of two or more data files located at different sites on a computer network. Because the database is distributed, different users can access it without interfering with each other. However, the database system keeps track as to where the data is so that the distributed nature of the database is not visible to users. Decentralized system has following characteristics (Emmerich 1997):

� Multiple autonomous components � Components are not shared by all users � Resources may not be accessible � Software runs in concurrent processes on different processors � Multiple Points of control � Multiple Points of failure

Because of the above characteristics, users can use any hardware, software or data anywhere in the system. In system perspective, work load of the system can be dispersed. If distributed system works properly, these characteristics can lead to better cost/performance trade-offs, improved system availability, enhanced resource sharing, although distributed system has some handicaps such as difficulty in fault detection, control, etc. In order to make distributed system work more effectively, quality related issues have to be identified. Because the performance of distributed system can be extremely different depending on how well it is managed. As mention above, the character of distributed systems involves multiple components working together as one system. It means failure of badly performed single component can affect overall system. If we assume distributed system as a chain of activities, the performance is only as good as its weakest link” Quality of a distributed system can be viewed as performance, reliability, scalability, security, etc. In terms of performance, users need at least same as currently given centralized system. Although distributed system can offer flexibility and broad possibility, if it is more expensive and more time consuming, it doesn’t become acceptable by users. In reliability, many issues can be considered. Users want to know whether a service is available at any moment or how available a service is. Is the output or input of service trustable? These kinds of information are not included in current service information, but it’s critical to users.


25

Flexibility of distributed system can be supported by scalability. System should not need to be changed when increases scale of a system. Security is important issue in distributed system. Characteristics of distributed system are sharing resources and multipoint access. It means that the system has more insecure variables. For that reason, secure system should be emphasized.

3.2.3. Data quality in geographic information processing

Geo-processing mainly uses geographic data, and GI service is composed of single or a number of geo-processing. It means the quality of geographic data is one of the most important factors in GI service quality. And then it is worthy to study the quality of geographic data. The value of geographic data is directly related to their quality. The views on quality can be different among the various user communities. For example, cadastral domain requires a positional accuracy within a few centimetres even millimetres whereas a nautical chart requires a positional accuracy within a few meters. Geographic datasets are being increasingly shared, interchanged, and used for purposes other than their producer’s intended purposes. The purpose of describing the quality of geographic data is to facilitate the selection of the geographic data set best suited to application needs or requirements (Kresse and Fadaie 2004).

Character Element Description

Completeness Presence and absence of features, their attributes and relationships

Logical consistency Degree of adherence to logical rules of data structure, attribution and relationships

Positional accuracy Accuracy of the position of features Temporal accuracy Accuracy of the temporal attributes and temporal

relationship of features

Quantitative

Thematic accuracy Accuracy of quantitative attributes and the correctness of non-quantitative attributes as well as the classification of features and their relationships

Purpose Description of the rationale for creating a dataset and information about its intended use

Usage Description of the application for which a dataset has been used

Non- quantitative

Lineage Description of the history of a dataset and, in as much as it is known, recounts the life cycle of a data set from collection and acquisition through compilation and derivation to its current form

Table 3.3 Summary of data quality elements (Kresse and Fadaie 2004)


26

For long, data accuracy was the sole concern resulting in elaborate models and techniques to analyze error and its propagation in measurements (Groot 2001). Development of digital spatial databases and GIS systems enlarge the extent of spatial data quality to include other elements like completeness, consistency, lineage etc. These spatial data quality can be viewed on the metadata. Table 3.3 shows summary of data quality related metadata elements defined by ISO. A complete list of data quality metadata elements in ISO 19115 is included in Appendix A. These quality elements are used to answer data related requirements. By answering, the quality of geographic data and products can be evaluated. Many of barriers which decrease quality of data or products on the geo-processing have been improved thanks to those efforts.

3.2.4. Common understanding of quality

Quality related issues have been reviewed in various ways. Quality of business process is related to not only quality of product but also performance of business process. Quality can be viewed as the quality of the product, cost and delay. Quality of the product highly related on functional characteristics of product. Cost of product generation and price in market are important things in cost issue, and delay have viewed time to producing and time to market. In distributed system, quality is viewed as performance, reliability, scalability and security. When distributed system promises to lower cost and less time, the system results to high quality. Reliability, as another important part of quality measurement, includes availability, trustworthy, and up-to-date etc. Scalability is needed for flexibility of system. Further, security of system is important characteristics in a distributed environment. Finally, quality in geographic data can be viewed as fit for use. Quality elements have been specified as data quality metadata in ISO19115. Data quality is represented by completeness, consistency, accuracy, purpose, usage and lineage. By defining data quality metadata, user can imagine the level of quality, and it can make fulfil some of user requirement. Common to all the above definitions, satisfying the customers' requirements is the main theme. For that reason, it is necessary for providers to identify such requirements at the beginning of products and/or service cycle. There are two important terms in quality: requirements and customer satisfaction. Requirement means need or expectation that is stated, generally implied or obligatory. Customer satisfaction means customer’s perception of the degree to which the customer’s requirements have been fulfilled.

3.3. Quality in the GI service environment

A number of quality concepts were explored in the previous section to evolve a definition of quality relevant to the GI service environment. . A GI service can be considered as the contribution of a geo-information system or part thereof to its surrounding environment. This contribution can be defined in terms of data, operations, processing, resources, value-added products or any combination of them (Morales and Radwan 2004). Following the OGC service architecture (OGC 2002), the definition of


27

geographic information service includes a variety of applications with different levels of functionality to access and use geographic information. Previous section defines quality in the GI service as quality of product, cost, delay and credibility. These are generally appeared issues on every domain, although each domain may represent them little bit different terms. GI services comprise heterogeneous computing elements connected via communication networks and have the following characteristics:

� Volume of data: Comparing to text based data; volume of geo-data is huge. It normally exceed several MB even GB. For that reason, geo-processing or transmitting time can be a lot.

� Complicated operation: Many other web services have been done message based and automatically however, complexity of GI service need additional operations by human operator in many case. For that reason, GI services can not be able to be done sometimes. It makes lack of reliability or availability. Comment: I don’t understand!

� Graphical information: Many of GI services are graphic related ones. In graphical information, resolution of service can be important role. Depend on purpose, users may require different resolution of service, and variation of service resolution need various resolution of input and output data.

� Diverse source: Over 80% of data in our society related to geographic data. It means lots of data can be generated by diverse producer, and it increase uncertainty of GI service. Although data set metadata has lineage element, it is difficult to be checked credibility of source data in GI service.

Table 3.4 shows relation between characteristics of GI services and quality representation.

Quality representation GI service characteristics

Quality of product Complicated operation, graphical information, Diverse source Cost Volume of data, complicated operation, graphical information Dealy Volume of data, complicated operation Credibility Complicated operation, diverse source

Table 3.4 Quality representation and GI service characteristics

These quality representations are developed to user quality requirements and quality characteristics in section 3.4.

3.4. User requirements and quality characteristics in GI service

Previous section addressed general quality issues in a GI service environment. This section addresses user quality requirements and quality characteristics. User quality requirements are what user wants to know relate to quality of service. Quality characteristics are components that affect quality requirement. For example, credibility of service can be a user quality requirements while service reputation, reliability can affect credibility of service, and they can be called quality characteristics.


28

Firstly, quality requirements are derived from quality issues in GI service, and quality characteristics are explored based on the derived user quality requirements.

3.4.1. User quality requirements

User means end-user who consume final output of GI service whether he or she knows the detailed process behind the service or not. If user has some requirements about specific service, the extent to which those requirements are fulfilled is an indicator of the service quality. So, the first step to satisfying users is to know the user requirements. We identify cost, delay, credibility of service and quality of deliverable product as important quality requirements in GI service environment. These are outlined below:

• Quality of product: Product quality refers fitness-for-use. In GI product, it can be seen quality of data resource (radiometric accuracy for instance) and quality of geometric process (geometric accuracy for instance). It depends on mainly the purpose of the product usage. In case of radiometric accuracy, it refers to graphical quality and geometric accuracy refers positional accuracy. It is difficult to calculate radiometric quality by quantitative way, but it is very important factor to a user. Geometric accuracy can be expressed in quantitative way using mathematical methods such as Root Mean Square Error of known points. When the user want to use the product, a detailed case such as cadastral application and geometric accuracy becomes critical to the user.

• The price of service: The money that a user has to pay for the consumption of service. While

cost includes both provider and user’s perspective, price only contain user’s view only. Price of service is essential factor that can influence selection of service to the user, because there can be many service providers to provide similar function with different price. Although, other quality characteristics may vary, if those quality characteristics are not so critical, a user may choose a service with a lower price.

• The delay of service: The time duration from a service is requested to a service is received by

requester. GI services deal with relatively huge data sets. Huge datasets means it can take a lot of time to get a required service. For that reason, response time is a critical factor. Also huge datasets influence other factors such as user and provider network bandwidth, processing time, load of service etc, and it also influence the cost of service.

• Credibility of service: Trustworthiness of service. Users need direct or indirect indicator that

can give them the general idea of service credibility. Credibility can be derived from user side factors and the provider side factors.

We define service quality characteristics from requirements.

3.4.2. User requirements and service quality characteristics

Quality characteristics related to each user requirement are derived in this section. Decisive characteristics that affect each user requirements are shown in Table 3.5


29

Requirements Quality characteristics

Quality of product • Quality of data resource • Quality of geometric process • User Reputation

Price of service • Price

Delay

• Processing time • Transmission time • Availability • Reliability

Credibility of service

• Availability • Reliability • User Reputation • Service provider

Table 3.5 User requirements and quality characteristics

1. Quality of product

This requirement can be described by a number of characteristics. We define three common characteristics;

• Quality of data resource: Checking the quality of data resource from the output of GI service can be difficult, because data has been manipulated by some process. Data set metadata quality information could be used.

• Quality of geometric process: It can be checked measuring such as Root Mean Square Error of known points.

• User Reputation: User reputation is Degree of user’s satisfaction about specific service. Usually, it contains user’s experience that is influenced by not only quality of product but also all of service characteristics. Therefore, user reputation is indirect way to check quality of products. We assume that if low quality product has low use reputation, and high quality product leads high user reputation.

2. The price of service Price of service is one of the most important factors in service selection. Generally, users prefer cheaper services among various services that offer similar function.

• Price: The amount of money that service requester has to pay for executing an operation or consuming a service Price is related most quality characteristics such as time spent in providing service, amount of information or data processed, application used, etc.

• Generally, higher quality of product leads higher price of product. All product quality related characteristics affect price of service.

• Better performance leads higher price in general.


30

3. The delay of service One of the main characteristics of web-service is how fast it is. These are time related characteristics.

• Processing time: Processing is the time it takes to execute an operation. It contains the time duration from request when it is received to finishing specified operation including waiting time. It depends on the load of process.

• Transmission time: It contains the time to receive a request from client to service and the time to send output of service to the client.

• Availability: The probability that the service is accessible over some fixed period time. If service is not available then it takes more time than expected time.

• Reliability: The probability that the service is executed within published time duration. High reliability promise required service may finish expected time.

4. Credibility of service Acquiring confidence from user is very important to service providers, because confidence makes user royalty of service.

• Availability: Higher availability can give user more credibility. • Reliability: Higher reliability can give user more credibility. • User Reputation: User reputation can be regarded as general opinion of user community. For

that reason, user reputation can affect credibility of service. • Service provider: User can have special preference to specific service provider due to

experience or provider name called brand power. User requirements and quality characteristics are shared in this section. Some of them have been used in data sets or service metadata, and some of them have not. For example, we have “fees” elements in service identification metadata and provider information service provider metadata. However, reliability or availability can not be found. Further, some of those characteristics are quantitative and some are not. As explained in quality of product, radiometric accuracy can not be expressed by quantitative way but geometric accuracy. Although most of these characteristics can be regarded in quality characteristics, we choose quality characteristics that can be expressed quantitative way and service provider side performance related characteristics. They are price, availability, reliability, processing time and reputation. Quality characteristics in GI services are important to enable provision of services that satisfy user requirements. Table 3.6 summarises the quality model and presents relevant formula showing how each characteristics can be computed.


31

Quality characteristic Formula Example

Price sp PQ ==== 10Euro/km2

Availability a

aa P

TQ ==== 0.87

Reliability t

rr N

NQ ==== 0.56

Processingtime swpt TTQ ++++==== 1200sec

Reputation re

tre N

RQ ��==== 4

Table 3.6GI service quality models

Element Name: Price

Definition: The amount of money that service requester has to pay for executing an operation or consuming a service.

Comment: Price can be different depending on the types of customers, the amount of information has to be processed or service provider’s specific purpose. Further the currency has to be considered. Price can be expressed i.e.10Euro/km2. Price can be

expressed sp PQ ==== ( sP : price of service)

Element Name: Availability

Definition: The probability that the service is accessible over some fixed period time.

Comment: Availability can be calculated aaa PTQ ==== ( aT : Total amount of time that the

service is available, aP : The fixed period of time that the observation has been done).

aP can vary depending on the provider’s environment. For that reason, aP is considered

weekday and office hours? Further, Greenwich Mean Time (GMT) is used to express common understanding about time difference, e.g. if some service provider has +1 hour time difference with GMT and availability is 0.876, the availability can be expressed by 0.876(GMT+1).

Element Name: Reliability

Definition: The probability that the service is executed within published time duration.

Comment: Reliability can be calculated trr NNQ ==== ( rN : the number of times that the

service has been done within published time. tN : Total number of invocations that were

requested.). This can be checked by service provider.

Element Name: Processing time Definition: The time it takes to execute an operation.


32

Comment: Processing time can be calculated swpt TTQ ++++==== ( wT : time duration between the

instance a request if received and the instant operation starts to run, sT : duration required

to run operation to produce the service result.). Processing time is highly influenced by amount of data. In this research processing time is expressed by second (Sec.).

Element Name: (User) Reputation

Definition: Degree of user’s satisfaction about specific service. Comment: User reputation contains user’s opinion about specific service. Different users

may have different opinions on the same service depending on their experiences. User can measure by rating such as 1 to 10, and registry manager can provide user reputation information about individual services. Reputation can be calculated by following formula

retre NRQ ��==== (�� tR : Sum of whole user rating for one service, reN : Total number

of times reputation has been done). Result of above formula can be float type but it will be represented as integer for practical use.


The main purpose of this chapter was to define user quality requirements and quality characteristics relevant in geographic service environment. To achieve this purpose, different quality concepts were explored and a definition of quality in the context of GI services presented. User quality requirements were identified and on corresponding characteristics defined. User quality requirements are quality of product, cost of service, delay of service and credibility of service. From these requirements, quality characteristics are extracted. They are quality of data resource, quality of geometric process, price, availability, reliability, processing time, transmission time, and reputation. Among them, five quality characteristics were redefined and modelled to use further study. They are price, availability, reliability, processing time, and reputation. These five characteristics can be expressed by quantitative way, and they are provider side performance related characteristics. In next chapter, whether current service metadata has quality characteristics and how these characteristics can be applied in service metadata are studied.


33

4. Service Metadata model

4.1. Introduction

This chapter aims at defining the quality characteristics that can be applied to service metadata design. Existing standards are evaluated to check the descriptions of services that are used currently. Service metadata is data about the service, describing the operations and geographic information available at a server. Service metadata play an important role in finding and publishing service information on the registry. Three existing standards are analyzed in this chapter. By the use of OGC Web Service concept, the research considers the standard way of service representation in the geographic information domain. In addition, UDDI (Universal Description, Discovery and Integration) is explored to check industrial domain service representation. Then, one of the service describing methods, Web Services Description Language (WSDL) is used to confirm the method of service description. The purpose of this analysis is to check following four main points;

1. Existence of quality component or characteristics in current service description 2. Extensibility of quality characteristics inclusion 3. Human readability of current service description 4. and inclusion of functional part of registry

The analysis of existing standards helps to decide the redesign method of service metadata. After the analyzing phase, quality characteristics applied service metadata and metadata schema is proposed. This chapter is organized as follow. Section 4.2 addresses criteria for analysing current standards. Section 4.3 gives introduction of basic component in existing standards and result of analyzing. Section 4.4 suggests quality applied service metadata and its schema.

4.2. Criteria for analysing current standards

This section seeks to analyze existing service related standards. In the analysis, the basic component of each standard is explained first, and then the criteria given below are checked.

1. Quality component or quality characteristics: quality component and proposed quality characteristics in existing standards have to be explored directly or indirectly

2. Possibility to include quality characteristics: some components in existing standard may include possibility to include quality characteristics

3. Human readability: proposed service metadata is used in service registry, and it should be compared by human. For that reason, readability of service metadata is important


34

4. Inclusion of functional part of registry: If current standards have functional parts of registry, such as search, publish etc, physically or conceptually, those concept can be used to registry implementation

OWS service metadata, WSDL and UDDI are analyzed for investigating current standards.

4.3. Existing standards

Development efforts of OGC have resulted in OGC interface specifications for operations on a Web Map Server (WMS), Web Coverage Server (WCS) or Web Feature Server (WFS) etc. The specs all differ in their purposes and details, but a number of elements are common to most or all of them. There is a desire by service users to have a single entry point (or at most a few) and protocol to search for service types of interest. In order to meet this goal, there is required to have an interface that populates a database of service descriptions and an interface to query the description database to discover service locations (OGC 2002). To achieve that desire, proper service descriptions and service metadata are core issue. The need of service description is essential not only in Geo-information domain but also in almost all industry domains especially in web-base service environment. In this section, service description schema in OGC Web Service, UDDI, and WSDL is researched mainly focusing on quality.

4.3.1. OGC Web Service

4.3.1.1. Basic components

Section name Contents

Service Identification

Metadata about specific server. � Service type � Service type version � Title � Abstract � Keywords � Access constraints � Fees

Service Provider Metadata about the organization operating specific server. � Provider name � Provider site � Service contact

Operations Metadata Metadata about the operations specified by service and implemented by specific server, including the URLs for operation requests.

� Operation � Parameter � Constraint � Extended capabilities

Table 4.1 Section name value and contents

35

OWS service metadata can be viewed mainly in four important sections and various sub sections (Service metadata schema is attached in Appendix B). Main sections are service identification, service provider identification, operation metadata and contents. Among them, contents section includes information about data used in the service. Table 4.1 shows three other sections and their elements (Booth 2004). Using these sections service providers can describe their services. In order for better understanding XML encoded service metadata example is given. <?xml version="1.0" encoding="UTF-8"?> <Capabilites xmlns="http://www.opengis.net/ows" . . . >  <ServiceIdentification> <ServiceType>OGC:WMS</ServiceType> <ServiceTypeVersion>1.2.0</ServiceTypeVersion> <ServiceTypeVersion>1.1.1</ServiceTypeVersion> <Title>Acme Corp. Map Server</Title> <Abstract> ... </Abstract> <Keywords> ... </Keywords> <Fees>NONE</Fees> <AccessConstraints>NONE</AccessConstraints> </ServiceIdentification> <ServiceProvider> <ProviderName>Acme Corporation</ProviderName> <ProviderSite xlink:href="http://hostname/"/> <ServiceContact> <IndividualName>Jeff Smith, Server Administrator</IndividualName> <PositionName>Computer Scientist</PositionName> <ContactInfo> <Phone> ... </Address> </ContactInfo> </ServiceContact> </ServiceProvider> <OperationsMetadata> <Operation name="GetCapabilities"> <DCP> <HTTP> <Get xlink:href="http://hostname:port/path?"/> </HTTP> </DCP> <Parameter name="Format"> <Value>text/xml</Value> </Parameter> </Operation> <Operation name="GetMap"> . . . </Operation> <Parameter name="ExceptionFormat"> <Value>text/xml</Value> </Parameter> <Constraint name="MaximumLayerLevels"> <Value>5</Value>

. . . </Constraint> </OperationsMetadata> </Capabilites>


36

4.3.1.2. Critical review

1. Quality component and quality characteristics: While dataset metadata has quality components, service metadata does not have quality component. “Fees” element is included in service identification section. Other characteristics are not included in existing service metadata

2. Extensibility to include quality characteristics: OGC attempts to incorporate other standards such as ISO, WSDL, and UDDI etc. If those standards have quality characteristics and it works properly, OGC can adapt those characteristics into service metadata.

3. Human readability: Although some elements can be difficult to understand for inexperienced users, OWS service metadata is readable and can be interpreted by human.

4. Inclusion of functional part of registry: OGC catalogue service addressed these functions in an abstract level and explains the required functions in catalogue. Main functions are Discovery, Access and Librarian function. Discovery is explained by searching information using query function. By access, user can copy whole or part of dataset. Librarian function gives an ability to define, modify or destroy catalogue interface. However, most of their efforts are focused on data set, and physical registry does not exist yet.

4.3.2. WSDL


The Web Services Description Language (WSDL) is a draft specification from W3C to describe networked services in terms of what they can do, where they reside on the network and how to invoke them. A service provider uses WSDL documents to publish Web services, to find published services and to bind to services dynamically (OGC 2003). WSDL components can be explained by interfaces, bindings and services. Among these components, interest of this research is Service. A Service component describes a set of endpoints on which a particular deployed implementation of the service is provided. Service component is explained in table 4.2.

Property Description

name Name that is used to name specific service. target namespace Predefined schema that specific name is referred Interface Describes sequences of message that a service sends and /or receives Endpoints Specific endpoint at which a given service is available.

Features Abstract piece of functionality typically associated with the exchange of messages between communicating parties.

Properties Properties architecture represents a named runtime value which affects the behaviour of some aspect of a Web service interaction, much like an environment variable (WSDL, 2004)

Table 4.2 Properties of service component in WSDL (Chinnici, Gudgin et al. 2004)


37

WSDL service description example is given below (Chinnici, Gudgin et al. 2004). This example explains how user can access availability and reservation functions, and opCheckAvailability operation contains feature component. However this service description can be check only when we entered specific webpage. <?xml version="1.0" encoding="utf-8" ?> <description xmlns="http://www.w3.org/2004/08/wsdl" targetNamespace= "http://greath.example.com/2004/wsdl/resSvc.wsdl" xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc.wsdl" xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc.xsd" xmlns:wsoap= "http://www.w3.org/2004/08/wsdl/soap12" xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <documentation> This document describes the GreatH Web service. Additional application-level requirements for use of this service -- beyond what WSDL 2.0 is able to describe -- are available at http://greath.example.com/2004/reservation-documentation.html </documentation> <types> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://greath.example.com/2004/schemas/resSvc.xsd" xmlns="http://greath.example.com/2004/schemas/resSvc.xsd"> <xs:element name="checkAvailability" type="tCheckAvailability"/> <xs:complexType name="tCheckAvailability"> <xs:sequence> <xs:element name="checkInDate" type="xs:date"/> <xs:element name="checkOutDate" type="xs:date"/> <xs:element name="roomType" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:element name="checkAvailabilityResponse" type="xs:double"/> <xs:element name="invalidDataError" type="xs:string"/> </xs:schema> </types> <interface name = "reservationInterface" > <fault name = "invalidDataFault" element = "ghns:invalidDataError"/> <operation name="opCheckAvailability" pattern="http://www.w3.org/2004/03/wsdl/in-out" > <feature uri=http://example.com/avail required="true"/> <input messageLabel="In" element="ghns:checkAvailability" /> <output messageLabel="Out"element="ghns:checkAvailabilityResponse"/> <outfault ref="tns:invalidDataFault" messageLabel="Out"/> </operation> </interface> <binding name="reservationSOAPBinding" interface="tns:reservationInterface" type="http://www.w3.org/2004/08/wsdl/soap12" wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"> <operation ref="tns:opCheckAvailability" wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"/> <fault ref="tns:invalidDataFault" wsoap:code="soap:Sender"/> </binding> <service name="reservationService" interface="tns:reservationInterface"> <endpoint name="reservationEndpoint" binding="tns:reservationSOAPBinding" address ="http://greath.example.com/2004/reservation"/> </service> </description>


38


1. Quality component and quality characteristics: WSDL does not contain quality component or property. Further, there is no defined quality characteristics in WSDL

2. Extensibility to include quality characteristics: Feature component has extensibility to include quality characteristics. Although WSDL poses no constraints on the potential scope of such features, examples might include “reliability”, “security”, “correlation”, and “routing” (W3C 2004). The presence of feature component in a WSDL can give various possibilities of quality inclusion.

3. Inclusion of functional part of registry: As a web service description language, WSDL can be service metadata, but it does not support registry function.

4. Human readability: comparing to OWS service metadata, WSDL describe how service is invocated. Comparing to OWS service metadata it has less information about what the service is. For that reason, users may have some difficulties to understand service using description only.

4.3.3. UDDI


OGC explains UDDI that "Universal Description, Discovery, and Integration, a standard for a platform-independent, open framework for describing services on the Internet, suggested by, among others, IBM, Ariba and Microsoft, September 6, 2000. UDDI is intended mainly for business to business enhancement and is based on the W3C s̀ XML standard and, especially on SOAP". UDDI provides a mechanism for clients to dynamically find other Web services. A UDDI registry has two kinds of clients: businesses that want to publish a service (and its usage interfaces), and clients who want to obtain services of a certain kind and bind programmatically to them (Vasudevan 2001).

Figure 4.1 UDDI data type (Riegen 2002)


39

Core UDDI data type is consist of Business entity, business service, binding template, and tModel. They are explained in figure 4.1. The example of UDDI service description is attached in appendix B.


1. Quality component and quality characteristics: Quality component and characteristics can not be searched in UDDI.

2. Extensibility to include quality characteristics: tModel has possibility to link WSDL. However there is no consideration for quality related things in UDDI service description.

3. Human readability: Some information such as provider and contact is explained readable way. However, unique keys are used to describe services most case. For that reason, it is difficult to understand service.

4. Inclusion of functional part of registry: As a working registry, UDDI gives the way of searching, publishing and updating mechanism.

4.3.4. Overall findings

1. Quality component: There is no quality component in three standards 2. Existence of quality characteristics: OWS service metadata has “Fees” information, but no

quality characteristics can be searched in existing standards except “Fees”. 3. Extensibility to include quality characteristics: WSDL has feature component, although no

property is defined in feature component. OGC is trying to incorporate other standards. 4. Human readability: OWS service metadata is relatively readable to human. UDI service

description is relatively unreadable to general user. 5. Inclusion of functional part of registry: As an existing UDDI shows how to search, publish

and update services. OGC gives conceptual idea of cataloguing mechanism. Their characteristics are compared in table 4.3

OWS service metadata WSDL UDDI

Quality information low low Low Extensibility mid high low Readability high mid low Registry function mid low high

Table 4.3 Characteristics of existing standards

Based on this result, service metadata redesign and registry implementation is performed by following step.

1. WSDL feature component redesign (section 4.4.1) 2. OWS service metadata redesign by applying WSDL feature component (section 4.4.2) 3. Service registry design by adapting UDDI registry function and redesigned OWS service

metadata. (Chapter 5)


40

4.4. Quality applied metadata design

In this section, quality applied service metadata incorporated with existing standards is suggested. Firstly, a new feature component in WSDL is researched then it is applied on OWS service metadata. Further, considerations have been addressed in chapter2 are dissolved in proposed service metadata. Considerations and use of them are given below in table 4.4

Considerations Use of considerations

Existing metadata standards Studied in section 4.3 existing standards Ease of input and use UDDI concept is used to apply in chapter 5 implementation Meet client need Studied in chapter 3 user perspective on quality characteristics Collect adequate detail Focused on quality of service information

Table 4.4 Considerations for creating metadata

4.4.1. Feature component redesign

WSDL has recognized the potential properties of feature, although why and what quality characteristics are needed was not specified. Existing feature schema, considerations for feature component design and proposed feature schema are following.

4.4.1.1. Existing feature component

Existing feature component is expressed by Universal Resource Identifier (URI). However, “URI” based use of feature component has some problem, when we want to use it on quality applied service registry. Users can not compare various services directly within certain criteria in the registry, because one “URI” can represent metadata of single service. We need to define properties of feature component. Feature component schema is given in Table 4.5.

<xs:element name="feature" type="wsdl:FeatureType"/> <xs:complexType name="FeatureType" mixed="false">

<xs:complexContent mixed="false"> <xs:extension base="wsdl:ExtensibleDocumentedType">

<xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:any namespace="##other" processContents="lax"/> </xs:choice> <xs:attribute name="uri" type="xs:QName" use="required"/> <xs:attribute name="required" type="xs:boolean" use="optional"/>

</xs:extension> </xs:complexContent>

</xs:complexType>

Table 4.5 Feature component schema

4.4.1.2. Feature component design

Basically, contents in feature component are given by service providers. For that reason, one of the most important issues would be clear guidance for publishing feature contents on registry. Here we have quality characteristics suggested in 3.7 and some considerations for designing feature contents.


41

Table 4.6 shows suggested feature representation schema.

<xs:element name="feature"> <xs:complexType>

<xs:sequence>

<xs:element name="price" maxOccurs="unbounded"> <xs:complexType>

<xs:simpleContent> <xs:extension base="xs:double">

<xs:attribute name="currency" type="xs:string"/> <xs:attribute name="pricingstandard" type="xs:string"/>

</xs:extension> </xs:simpleContent>

</xs:complexType> </xs:element> <xs:element name="availability">

<xs:complexType> <xs:simpleContent>

<xs:extension base="xs:decimal"> <xs:attribute name="timegap" type="xs:string"/>


</xs:complexType> </xs:element> <xs:element name="reliability" type="xs:decimal"/> <xs:element name="processingtime">

<xs:complexType> <xs:simpleContent>

<xs:extension base="xs:double"> <xs:attribute name="timeunit" type="xs:string"/>


</xs:complexType> </xs:element>

<xs:element name="reputation" type="xs:decimal"/>

</xs:sequence>

</xs:complexType> </xs:element>

Table 4.6 suggested feature representation schema

1. Price

Mainly, two issues may be dealt with price. Firstly thing is use of currency. Whether price supports diverse currencies or supports specific currencies only. The other issue is pricing standard. Price can be given by area, volume of data etc. Currency unit and pricing standard have to be compared in specific service type to differentiate similar services.


42

2. Availability While some services can be done automatically by machine, other services require human intervention to put some parameters by human to perform correct operation. Sometimes, results can be very different depend on who does the operation. For that reason, some services can be accessed only in office hours. In case of these services, standard duration for availability calculation should be office hours. The other time related problem is the period that is used to calculate availability. For instance, this can be availability of last one month, last half a year, last three years etc, and the results can be different up to used period.

3. Reliability The period of reliability calculation is an important key to measure reliability. Depending on the period the result can be different. This standard should be offered by service metadata schema.

4. Processing time Comparing to text-based data, geo-processing deals with huge volume of data, and it can be taken several minutes or hours. For that reason, unit of processing time can vary up to the volume of data and type of processing.

5. Reputation Reputation is customer based quality characteristics. The period of reputation calculation is needed to mention, although it is managed by registry manager. These considerations support consistent way of service representation among various service providers. Suggested feature representation schema is given below; Using suggested schema, service feature can be expressed. If we have a service with following feature,

� Price: 5Euro/km2 � Availability: 0.876 and 8hours time difference between GMT � Reliability: 0.805 � Processing time: 20seconds � Reputation: 7.2

The service feature can be represented as follow <?xml version="1.0" encoding="UTF-8"?> <feature xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xsi:noNamespaceSchemaLocation="MetaData\feature.xsd"> <price currency="Euro" pricingstandard=" km2">5</price> <availability timegap="GMT+8">0.876</availability> <reliability>0.805</reliability> <processingtime timeunit="Second" >20</processingtime> <reputation>7</reputation> </feature> Suggested feature representation schema is applied on OWS service metadata in following section.

43

4.4.2. Quality applied OWS service metadata

To propose quality applied OWS metadata, one service metadata section, service Identification, has been chosen as a parent service metadata. Service identification explains what the service is, and quality characteristics distinguish one service among similar services. After parent service metadata chosen, feature component applied on service identification metadata. Table 4.7 describes revised service Identification metadata contents.

Original Name

Revised name

Data type

Multiplicity and use

Fees Price Number type Default “NONE” means free of charge

One or more (mandatory)

Availability Number type Default “NONE” means no availability data

one

Reliability Number type One(mandatory) Processing Time Number type

Default “NONE” means free of charge One(mandatory)

Reputation Number type Default “NONE” means no reputation data

One, given by registry manager

Table 4.7 Revised part of ServiceIdentification metadata

By adding revised serviceIdentification metadata, quality applied serviceIdentification metadata schema is given below; <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.opengis.net/ows" xmlns="http://www.w3.org/2001/XMLSchema"

xmlns:ows="http://www.opengis.net/ows" xmlns:xlink="http://www.w3.org/1999/xlink" elementFormDefault="qualified" version="0.1.4" xml:lang="en">

<annotation> <appinfo>owsServiceIdentification.xsd 2004/1/11</appinfo> <documentation>

<description>This XML Schema encodes the common "ServiceIdentification" (formerly part of the "Service") section of the GetCapabilities operation response, known as the Capabilities XML document. This section encodes the SV_ServiceIdentification class of ISO 19119 (OGC Abstract Specification Topic 12). Primary editor: Arliss Whiteside. </description>

<copyright>Copyright (c) 2004 OpenGIS, All Rights Reserved. </copyright> </documentation>

</annotation>  <include schemaLocation="ows19115subset.xsd"/>  <element name="ServiceIdentification">

<annotation> <documentation>General metadata for this specific server. This XML Schema of this section shall be

the same for all OWS. </documentation> </annotation> <complexType>

44

<sequence>

<element name="ServiceType" type="ows:CodeType"> <annotation>

<documentation>A service type name from a registry of services. For example, the values of the nameSpace attribute and name and name string may be "OGC" and "catalogue." This name is normally used for machine-to-machine communication. </documentation>

</annotation> </element> <element name="ServiceTypeVersion" type="ows:VersionType" maxOccurs="unbounded">

<annotation> <documentation>Unordered list of one or more versions of this service type implemented by

this server. This information is not adequate for version negotiation, and shall not be used for that purpose. </documentation>

</annotation> </element> <element name="Title" type="string">

<annotation> <documentation>Title of this server, normally used for display to a human. </documentation>

</annotation> </element> <element name="Abstract" type="string" minOccurs="0">

<annotation> <documentation>Brief narrative description of this server, normally used for display to a

human. </documentation> </annotation>

</element> <element ref="ows:Keywords" minOccurs="0" maxOccurs="unbounded"/> <element name="AccessConstraints" type="string" minOccurs="0" maxOccurs="unbounded">

<annotation> <documentation>Unordered list of access constraints applied to assure the protection of

privacy or intellectual property, and any other restrictions on retrieving or using data from or otherwise using this server. The reserved value NONE shall be used to mean no access constraints are imposed. If this element is omitted, no meaning is implied. </documentation>

</annotation> </element>  <element name="feature">

<annotation> <documentation>Non-functional characters of service are included in this element. Refer to

below addressed feature expression example.

<!-- expression example <feature >

<price currency="Euro" pricingstandard=" km2">5</price> <availability timegap="GMT+8">0.876</availability>


45

<reliability>0.805</reliability> <processingtime timeunit="Second" >20</processingtime> <reputation>7</reputation>

</feature> End of example-->

</documentation> </annotation> <complexType>

<sequence>

<element name="price" maxOccurs="unbounded"> <annotation>

<documentation>Price is the amount of money that service requester has to pay for operation. Price should include currency and pricing standard. ex) 10(Euro/ km2) </documentation>

</annotation> <complexType>

<simpleContent> <extension base="double">

<attribute name="currency" type="string"/> <attribute name="pricingstandard" type="string"/>

</extension> </simpleContent>

</complexType> </element>

<element name="availability" minOccurs="0">

<annotation> <documentation>Availability is the probability that the service is accessible.This

is calculated aaa PTQ ==== ( aT : Total amount of time that the service is

available, aP : 09:00 ~ 17:00 from monday to friday last 6 months).ex) 0.875

(GMT+8) </documentation> </annotation> <complexType>

<simpleContent> <extension base="decimal">

<attribute name="timegap" type="string"/> </extension>

</simpleContent> </complexType>

</element>

<element name="reliability" type="decimal"> <annotation>

<documentation>Reliability is the probability that the service is executed within expected time duration. This is calculated trr NNQ ==== ( rN : the number of

times that the service has been done within expected time. tN : Total number of

invocations last 6months).</documentation> </annotation>

</element> <element name="processingtime">

<annotation> <documentation>Duration between a request is received and the response is

generated.This is calculated swpt TTQ ++++==== ( wT : time duration between the

46

instance a request if received and the instant operation starts to run. sT :

duration required to run operation to produce the service result.).This should include timeunit. ex)120second </documentation>

</annotation> <complexType>

<simpleContent> <extension base="double">

<attribute name="timeunit" type="string"/> </extension>

</simpleContent> </complexType>

</element> <element name="reputation" type="decimal">

<annotation> <documentation>Reputation is user � s perspective of trustworthy about specific

service..Reputation is calculated retre NRQ ��==== (�� tR : Sum of whole user

rating, reN : Total number of times reputation has been done). However, this is

managed by registry.</documentation> </annotation>

</element> </sequence>

</complexType> </element>



</sequence> </complexType>

</element>  <simpleType name="VersionType">

<annotation> <documentation>Specification version for OWS operation. The string value shall contain one x.y.z

"version" value (e.g., "2.1.3"). A version number shall contain three non-negative integers separated by decimal points, in the form "x.y.z". The integers y and z shall not exceed 99. Each version shall be for the Implementation Specification (document) and the associated XML Schemas to which requested operations will conform. An Implementation Specification version normally specifies XML Schemas against which an XML encoded operation response must conform and should be validated. See Version negotiation subclause for more information. </documentation>

</annotation> <restriction base="string"/>

</simpleType>

</schema>


47


Searching for suitable services can be demanding, because a lot of service providers who have similar functions can exist on the web. Service metadata can take an important role if it has decisive factors to distinguish services that have similar function. Unfortunately, existing service description methods do not have enough information non-functional but important factors, named quality characteristics, to users when they select user-fit services. Existing standards, OWS service metadata, WSDL and UDDI, have been analyzed with in certain criteria. They are presence of quality characteristics, extensibility, readability of service description and applicability in registry. All standards do not have quality characteristics. However, each standard has its own characteristics. OWS service metadata has high readability. WSDL has feature component, and it makes WSDL extensible. UDDI, as an existing registry, gives clear example how registry works and what are required functions. In order to apply quality characteristics on service metadata, WSDL feature component has been redesigned. And then redesigned feature component has been applied on OWS service identification metadata. By doing those step, quality applied service metadata has been suggested. Service registry is implemented in chapter 5. When registry is implemented important functions in UDDI are adapted.


48

5. Implementation

5.1. Introduction

The main objectives of this chapter are to model, implement, and evaluate a service registry prototype. In order to achieve these objectives, the general concept of a registry and important terms are explained first. In addition, the registry architecture is presented. UML activity diagrams are used to model the functions and interactions the registry supports. In order to test service registry model, implementation has been done by following order. Firstly, implementation scope is introduced. Then implementation environment is introduced. Service registry implementation has been done using PHP (web programming language), MySQL (interactive database), and Apache (web server software). Further implementation case is explained. Physical implementation is done from creating database. In order to create database, proposed service metadata in Chapter4 is referred. Finally each components of registry interface are implemented. After implementation, service registry is evaluated within two views: quality characteristics and their use, and characteristics of web site.

5.2. Basic concept of service registry

This section describes the components, the main actors and the main activities of a service registry.

5.2.1. Components

Registry is composed of mainly three components that are; web server, database, and service metadata. General definitions of service registry components are given below;

� Web Server: A Web server is a device (not just a computer) that is on a network and that runs special software in the background. This software constantly monitors for any HTTP (Hyper Text Transfer Protocol) requests for services coming into the device (Hunrey 2004).

� Database: Database is a set of related information created, stored, or manipulated by a computerized management information system.

� Service metadata: Service metadata is information about a service Service metadata include metadata that describe the service's interface (its input and output) as well as information that aids in effective use of the service (e.g., range of possible values returned). Service metadata also describe access methods or protocols (Hanisch 2002).

5.2.2. Main actors

Main actors in service registry are explained below; � General users: Users who want to search service information to find services to exploit.

General users cannot publish service metadata. � Service provider: Users who have published their services on the registry.


49

� Registry (manager): People or machine that maintains the service metadata and enables providers to publish and update service metadata and general users to search and query the metadata.

5.2.3. Core activities (functions) of the service registry

� Registration: This process provides the authentication of registry users. All new users that want to access services with restricted access must first register and they are automatically redirected to the registration process.

� Log in / Log out: This process controls opening and closing user’s authentication. Authentication is explained as a process used to confirm the identity of a person or to prove the integrity of specific information. The most common form of authentication is user name and password, although this also provides the lowest level of security.

� Search: This process provides to user browse published service information. Users have to do “log in” first.

� Publish: this process provides the method to publish service information by registered service providers. Service providers have to do “log in” first.

� Update: this process provides the method to edit published service information by service provider. Service providers have to do “log in first”.

Figure 5.1 Service registry architecture


50

5.3. Service Registry arhitecture

The general idea of service registry is similar to clearing house server introduced in section 2.2.1. However, service registry maintains service metadata. Service registry is composed of server, database, and service metadata. Main functions of service registry are managing service metadata and query process. Through user interface service providers can publish or update their services. These service metadata are stored in repository. Users search required service metadata using query processor. These processes are depicted in figure 5.1. This service architecture is used in next section for modelling.

5.4. Activity modelling

Main activities of proposed service registry are searching, publishing and updating. In this section, required functions in each activity are modelled by UML activity diagrams. The following are considerations for activity modelling.

� Users have to do “log in” to use service registry. � Registration process should be linked in log in process � For security, user ID and password have to be checked when service providers do “publish”

or “update” � A service provider can only “update” service metadata which the provider published.

5.4.1. Log in / out

Log in process is basic process in most web portals, and it can offer basic security method by preventing use of unauthorized users. The goal of this process is to get authenticate the user.

1. Basic steps Step 1: User open web portal Step 2: Registry opens “log in” page Step 3: User type user ID and password Step 4: User Click “log in” button Step 5: Registry provide authentication to user Step 6: Click log out Step 7: Return to log in page

2. Alternatives Alternative 1 (condition: not registered user)

- Click register button and do registration process – step 2 Alternative 2 (condition: invalid user ID or password)

- Open log in form again step 4 – step 2 Log in/out activity diagram is given in figure 5.2, and Registration activity diagram is given in figure 5.3.


51

��

��

��

��

��

��

��

��

�� !��

�� "��

��

��# ��

��

��

��# �� !�

Figure 5.2 Log in/out activity diagram


52

��

��# ��

��!� �� !��

�$�

�� $�

��

�%��# ��

�%��# ��

��

��

��# ��&�

��

��

��&� ��

Figure 5.3 Registration activity diagram

5.4.2. Search

Searching required service metadata is one of the most important reasons we implement service registry. Registered services have to be browsed by customer. For that reason, registry should offer clear and easy way of searching with well organized query functions. General users are dealt with this process.

1. Basic steps Step 1: User clicks search button Step 2: Registry opens search form Step 3: User types required service type using given form (required) Step 4: User types query condition and order of display parameters (optional) Step 5: User clicks query button


53

Step 7: Registry shows list of matched services Step 8: User selects description of services that are fit to user’s requirements Step 9: Registry shows description of service

2. Alternatives Alternative 1 (condition: query form is not correctly filled out)

- Open alert message move step 5 – step 2 Alternative 2 (condition: queried results are too many or not satisfied with results)

- Query again step 7 – step 2

3. Considerations Results can be compared by quality characteristics. Registry gives explanation about query contents Activity diagram is given in figure 5.4.

Figure 5.4 Search activity diagram


54

Important issues in searching are a well organized query form and error handling. Query form should include clear instruction of each query parameters. Quality characteristics can be understood different way depend on user’s experience. For that reason, metadata schema or examples should be supported. In addition, if user uses invalid query expression, registry should be ale to control error, i.e. JavaScript popup alter message.

5.4.3. Publish

Publishing service metadata is basic requirement to organize service registry. Publishing metadata can be done by registered users only. Some error handling functions are needed (what are the error handling functions and why are they needed?). The goal of this process is to publish services. Service providers are dealt with this process.

1. Basic steps Step 1: User click publish button Step 2: Registry open publish form Step 3: User fills out given form Step 4: User click save button Step 5: Registry save input data

2. Alternatives Alternative 1 (condition: Invalid user ID or password, required field is not filled out)

- Open alert message move step 4 – step 2

3. Considerations Publish should be done only by registered users, ID and password are needed to be checked again when users publish their services. Registry has to give clear guidance of publish activity. Published time has to be updated automatically Activity diagram is given in figure 5.5.


55

Figure 5.5 Publish activity diagram

5.4.4. Update

By use of update activity, service providers can edit their service information. This process enables provision of up-to-date service information to users. Most important function in update is giving update activity to authorized user only. ID checking and downloading published service registry are the basic functions that are required.

1. Basic steps Step 1: User click update button Step 2: Registry open ID check form Step 3: User type ID and password Step 4: Click IDcheck button Step 5: Registry show list of published services Step 6: User selects one of service ID Step 7: Registry show published data Step 8: User edits published data


56

Step 9: User click save button Step 10: Registry save edited data

2. Alternatives Alternative 1 (condition: ID or password is incorrect)

- Open alert message move step 4 – step 2 Alternative 2 (condition: fill out update form incorrectly)

- Query again step 9 – step 7

3. Considerations Update of a given metadata set should be done only by the service provider who published the metadata. For the security reason, ID and password have to be checked again before user opens published service metadata. Update time has to be updated automatically Activity diagram is given in figure 5.6.


57

��&�� '��&��

��# �� %��# ��

��

�� &��

�� '��

��

�� &��

��

��&�

��

(�� )��

��# ��&� �!��

��

��

��

��

Figure 5.6 Update activity diagram


58

5.5. Service registry implementation

The basic activities of service registry have been reviewed in section 5.4. This section implements service registry on the web. This section includes implementation scope and environment, implementation case, and a description of implemented service registry.

5.5.1. Implementation scope

Main interest in this implementation is managing and searching quality applied service metadata in registry. In this implementation, service identification metadata proposed in Chapter 4 is used for implementation. Other parts of service metadata in existing registry concept such as “serviceProvider” or “operationsMetadata” are not be searched in registry. However, to show general service description “GetCapability” is provided. We assume that existing services are functionally matched to customer’s requirements. Here are considerations for registry implementation.

� Searched services should be able to be compared with each other. It means various services have to be shown on one web page so that searched services can be compared with each other.

� Registry should support ordering function so that services can be ordered by user’s priority i.e. ordered by price.

� Each service should be checked by all users when updates are made (why? What do you mean).

� Registry user interface should offer clear instructions on publishing and updating for new service providers

5.5.2. Implementation environment

Various web based software are available to create web site. In this research, we need web programming language, database and web server. Among various alternatives, given below software have been chosen to implement sample registry.

� Web programming language: PHP (Professional HTML Pre-processor) � Database: MySQL � Web server: Apache (A PAtCH sErver)

The characteristics of implementation software is following (Lee 2004) Character of PHP

� Free ware: We can download without charge � PHP support most O/S: It supports various O/S such as UNIX, Window, and Linux etc. and

above 95% of encoded source can be used the other O/S. � High speed performance: Especially when it is run with database. � Support most database: PHP can be used with various database software such as Oracle,

MySQL, mSQL, Dbase, Informix etc. � Open source: User can edit PHP source to make specific form.


59

Character of MySQL � Free ware: we can download it without charge � Support various platform(HW + O/S) including window version � Easy to handle and test: Comparing to commercial database such as Oracle, MySQL is easy

to handle and test Character of Apache

� Free ware: We can download without charge � Secure server: It has been used for long time and very broadly (around 60%) � Open source: User can edit Apache source to make specific form

These reasons, softwares can be acquired easily on the Web. And service registry could be tested easily.

5.5.3. Implementation example

This section introduce implementation example. Orthophoto production process is used to implement on registry as an example. Firstly, orthophoto and orthophoto production process are introduced. Then orthophoto process is mapped into business process and services. Finally, each core service of orthophoto production service is introduced. These core services are described by proposed service metadata in Chapter4, and they are published, searched and updated. Further, service registry evaluation is done using these services

5.5.3.1. Introduction of orthophoto

An orthophoto is a photograph showing images of objects in their true orthographic positions. Orthophotos are therefore geometrically equivalent to conventional line and symbol planimetric maps which also show true orthographic position of objects. Because orthophotos are planimetrically correct, orthophotos can be sued as maps for making direct measurements of distances, angels, positions, and areas without making corrections for image displacements. Orthophotos are widely used in connection with geographic information systems, where they serve as planimetric frames of reference for performing analyses, and are also used for generating layers of information for databases (Wolf and Dewitt 2000). Digital orthophotos provide an excellent coordinate or map reference as the foundation layer in a GIS data base, thus facilitating the development and registration of coverage to the map coordinate system (Corbley 1996).

5.5.3.2. Orthophoto production process

In this section, the process of orthophoto production is explained. The process can be varied depend on the image acquisition and status of image. In this example, assume that digital image is used as an input data. The brief process is shown in figure 5.7.


60

Figure 5.7 Orthophoto production process

Activities have to be performed to generate orthophoto are following.

1. Using several Ground Control Points and the relation between points on the image, the mathematical transformation parameters are computed to establish the relationship between the ground (X, Y, Z) and the image (x, y) coordinates. The algorithmic approach depends upon the type of rectification method to be used (i.e., polynominal, projective, etc. detail in Annex B). A simple affine polynominal approach will require a minimum of 3 well distributed GCPs. Regardless of the approach, more than the minimum number of GCPs should be employed in order to obtain an optimum solution.

2. After previous step, the digital photo is rectified to the ground coordinate system. During rectification the scanned photo is resampled and the pixel size modified as required to correspond with other raster data sets that may be part of the database.

3. Different rectification requires an additional step and employs terrain height data from a DEM (DEM can be generated from the aerial photography by photogrammetric techniques and automated stereocorrelation, derived from contours digitized from existing maps or, perhaps, acquired from government or commercial sources(Welch 1990) to correct for relief displacements in the image.

4. The output of previous steps is orthophoto.

Process to generate orthophoto and required activities were explained above. The process activities are mapped onto geo-services as described in the next section


61

5.5.3.3. Orthophoto production service

Orthophoto production process can be mapped into several core geo-services. Geo-services are referred from ISO service architecture. Orthophoto production process can be mapped into geo-service as below figure 5.8.

Figure 5.8 Related geo-services in orthophoto production

ISO definitions about above services are given below.

• Rectification service: Service for transforming an image into a perpendicular parallel projection and therefore a constant scale.

• Orthorectification service: A rectification service that removes image tilt and displacement due to terrain elevation. Orthorectification requires use of digital elevation data, usually in grid form.

• Image coordinate conversion service: A coordinate transformation or coordinate conversion service to change the coordinate reference system for an image.

• Sampling service: Service that extracts data from an input using a consistent sampling scheme either by geographic location or by grid coordinates.

In implementation phase, these services are published on the registry, and users use these published service descriptions for required service selection. Services that are required to perform orthophoto production service are searched on implemented registry. And then users evaluate service registry.

5.5.4. Creating data base

Database is one of the most important components in service registry. All of services and users information are stored in database. Many database softwares are available. Among then MySQL is used in this research, because MySQL is open-source. It means we can use database software freely. And it offer flexibility of use.


62

Service metadata schema suggested in 4.4.2 is used as basic contents of service table. Among them OSE field is added as a higher level service category of service type. Database consists of two tables in this research. They are user and service. User means every registered people or organization including service provider in this implementation. User table has user information including User ID, password, and e-mail address. Service table name ‘sid2’ contain service information including service provider, service type, and service type version etc. figure 5.9 shows details of two tables

Figure 5.9 User and service table details

5.5.5. User interface

5.5.5.1. Register

Registration process provides the authentication of registry users. Generally, registration process contains user including user ID, password, etc. Many web portals require various elements. For example, IBM registration process requires ID, password, first and last name, e-Mail address, home address, company address, telephone number, job, etc. Other web portals require similar elements. However, registration in this implementation contains only three elements: user ID, password, e-mail address.


63

Implemented interface is given figure 5.10.

Figure 5.10 Register interface

5.5.5.2. Log In / out

Log in / out process provides the authentication of registry users. By use of log in, registry can notice authorized user enters in the registry. Log in / out function gives basic level of security. This process includes exception case handling method. For example, if user enters wrong ID or password, popup message coded by java script is opened. Figure 5.11 shows log in interface.

Figure 5.11 Log in interface

5.5.5.3. Search

Search process can be viewed two types: initial search interface, search interface within results. Search interface should support query function and ordering functions. Service type is mandatory content that users have to choose. Query and order parameters are given in the form. Figure 5.12 shows initial search interface, and figure 5.13 shows search in results interface.


64

Figure 5.12 Initial search interface

Figure 5.13 Search in results interface


65

5.5.5.4. Publish

Publish function can be done service providers who are registered. For security reason, publish form has UserID and password contents. These contents check whether register service provider or not. Service type contents are designed as select box for standardized way of service type expression. For guidance, service metadata schema is linked. Reputation should be derived from users and given by registry manager, but in this research it is given by service providers. Publish interface is given in figure 5.14.

Figure 5.14 Publish interface

Figure 5.15 Interface for User authentication


66

5.5.5.5. Update

Update should be done by service providers only. Further, service providers should be able to access their own service metadata. User authentication interface given in figure 5.15 is used to check service providers, and it will help to find their own service metadata. Figure 5.16 Shows service selection interface. One service provider can have various services and by using service selection interface service providers can choose one service that they want to update.

Figure 5.16 Service selection interface

Figure 5.17 Update interface.

Figure 5.17 shows update interface. Update interface should show published service metadata. Service providers can change contents in opened service metadata. Further, update date is changed automatically.


67

5.6. Evaluation

5.6.1. Evaluation method

Evaluation has been done by number of students who study geographic information management. They have been asked to select various services for orthophoto production service explained in section 5.5.3. Before they test service registry, some general quality characteristics have been asked. As general users, what are required quality characteristics and priorities? Then they have tested service registry (Evaluation paper is given Appendix C). Evaluation criteria are structured two ways. Firstly, service registry is evaluated as a website. Service registry website evaluation is executed based on ADQ (Administration, Design, and Quality) Web Site Evaluation Method (Tomita, 1999). ADQ evaluation form is modified, because some of ADQ evaluation elements are not applicable. Evaluation characteristics are given in table5.1. Secondly, quality characteristics and registry functions are evaluated by user. Main criteria of evaluation are inclusion of required quality characteristics and functions in service registry. Evaluation form is given in table 5.2.

Characteristics Findings

Web Site (Is the web site user-friendly for the target population?)

1. Is there a consistent design across ALL web pages? 2. Are pages arranged in a logical order? 3. Are pages arranged in a modular format?

(Not having to scroll down long pages) 4. Is there a choice to view the web site in frames or

no frames? 5. Is it easy to find the information you're looking for?

Y / N Y / N Y / N Y / N Y / N

Web Page 1. Do the pages load quickly? 2. Are postings in an At-A-Glance format? 3. Can you view the completed page on your monitor? 4. Moving and distracting objects on pages? 5. Hyperlinks work? 6. Dates when pages published or updated?

Y / N Y / N Y / N Y / N Y / N Y / N

Objectivity 1. Any biases in the content? 2. Do authors inform users of any inherent biases?

Y / N Y / N

Coverage (Are the materials covered in depth and appropriate for the intended user?)

1. Are the materials detailed enough? 2. Are the materials complete on the subject? 3. Are the materials appropriate for the age of the

user? 4. Is complexity of information consistent with you?

Y / N Y / N Y / N Y / N

Presentation

1. Is hypertext used logically? 2. Are video, audio, and graphics used modestly? 3. Are colors used properly?

Y / N Y / N Y / N

Usefulness 1. Is the information useful for the intended target population?

Y / N

Table 5.1 ADQ web site evaluation form (edited from Tomita, 1999).


68


General user quality requirements

Your priority of quality related characteristics? ( ) Price ( ) Availability ( ) Reliability ( ) Processing time ( ) User reputation ( ) Transmission time ( ) Provider information ( ) Radiometric accuracy ( ) Geometric accuracy

Quality characteristics in service registry (missing and or unnecessary characteristics)

Does registry include required characteristics? Missing characteristics => Unnecessary characteristics ( ) Price ( ) Availability ( ) Reliability ( ) Processing time ( ) User reputation ( ) Transmission time ( ) Provider information ( ) Radiometric accuracy ( ) Geometric accuracy

Functional part in service registry (missing or unnecessary functions)

Does registry include required functions? Missing functions => Unnecessary functions ( ) Register ( ) Log in/out ( ) Search ( ) Publish ( ) Update

Table 5.2 Quality characteristics and functional part evaluation form.

5.6.2. Evaluation results

5.6.2.1. Evaluation as a web site

Implemented service registry has been evaluated as a web site using ADQ web site evaluation form. Web site, web page, objectivity, coverage, presentation, and usefulness of web site have been evaluated by user. Web site, web page and objectivity and usefulness got relatively higher mark. Representation of web site was not so satisfied. Especially, this registry does not support when web


69

pages published and updated. In addition, the color and graphical part are regarded not so satisfied. Table 5.3 includes overall result of evaluation as a web site.

Results Characteristics Question Yes No

Web Site

1. Is there a consistent design across ALL web pages? 2. Are pages arranged in a logical order? 3. Are pages arranged in a modular format 4. Is there a choice to view the web site in frames or no frames? 5. Is it easy to find the information you're looking for?

7 7 4 4 7

0 0 3 3 0

Web Page

1. Do the pages load quickly? 2. Are postings in an At-A-Glance format? 3. Can you view the completed page on your monitor? 4. Hyperlinks work? 5. Dates when pages published or updated?

5 6 5 4 0

2 1 2 3 7

Objectivity 1. Any biases in the content? 6 1

Coverage

1. Are the materials detailed enough? 2. Are the materials complete on the subject? 3. Are the materials appropriate for the age of the user? 4. Is complexity of information consistent with you?

4 4 5 5

3 3 2 2

Presentation

1. Is hypertext used logically? 2. Are video, audio, and graphics used modestly? 3. Are colors used properly?

6 3 2

1 4 5

Usefulness 1. Is the information useful for the intended target population? 7 0

Table 5.3 ADQ web site evaluation result

5.6.2.2. Quality characteristics and registry function

Firstly, users answered priority of quality characteristics and for orthophoto production service in their own perspectives. Then users have answered that priority of quality characteristics and necessary or unnecessary quality characteristics. Lastly, they have answered functional components of service registry. Generally, users agree the components of service registry. These functions have used in many web site including UDDI registry. They are familiar to most users. Quality characteristics have been regarded variously depend on personal preference. Overall result about quality characteristics are given in table 5.4. The rank of priority has been calculated sum of priority results. Processing time was the most important quality characteristics for users while user reputation was the least important to users. Geometric accuracy and transmission time has been answered important than availability. Provider information has regarded relatively less important quality characteristics. However, one user has answered provider information is the most important quality characteristics. Further, one user have answered that user reputation is not necessary quality characteristics in service registry.


70

After questionnaire, some users have been interviewed. One of the important things in evaluation is users understand each terms by their own experience. For example, reliability has been recognized as quality of orthophoto for some user. Although quality characteristics have been defined, users can understand different way. This result is influenced absence of standard quality definition. In order to make service registry more effective, quality characteristics should be recognized or should be seen on the registry clearly.

User’s priority Priority Quality characteristics

Total U1 U2 U3 U4 U5 U6 U7

1 Processing time 17 2 5 2 3 1 1 3 2 Reliability 23 5 2 1 1 2 8 4 3 Price 29 8 4 6 6 3 2 1 4 Geometric Accuracy 30 4 1 4 2 5 6 7 5 Transmission time 37 3 8 5 4 7 4 6 6 Availability 38 6 6 3 5 4 9 5 7 Radiometric accuracy 45 9 3 8 7 9 7 2 8 Provider information 45 1 7 9 8 6 5 9 9 User reputation 51 7 9 7 9 8 3 8

Table 5.4 Results of quality characteristics evaluation


In this chapter, two main tasks were discussed; modelling and implementation of the service registry. To achieve these tasks general terms and registry architecture have been introduced first. In modelling phase, four main processes have been modelled. They are log in/out, search, publish and update. In order to model these processes, basic steps, alternatives and considerations for model have been explained. Using these basic concepts, each process has been modelled by UML activity diagram. In implementation phase, suggested models are implemented on the web. Firstly, implementation scope has been limited in quality characteristics applied service identification metadata only, and orthophoto production process is used for implementation case. In orhtophoto production process, orthorectification service has been used to apply on service registry. Implementation has been done using web programming (PHP), web server (Apache), and database (MySQL) software. Modelled activities are implemented on service registry. Finally, service registry has been evaluated by some users. Firstly, service registry has been evaluated as a web site. Secondly, quality characteristics and functions in service registry have been evaluated. Although most of quality characteristics are regarded as important factors for service selection, users can have different idea about each characteristic depending on their personal experiences. For that reason, standard ontology for quality characteristics is required for proper use of service registry.


71

6. Conclusions and Recommendations

6.1. Introduction

The following sections provide conclusions of this research and recommendations for further research. The main objective of this research is identifying quality characteristics to extend quality-aware service registry development. In order to achieve this objective, following issues have been answered; 1) user perspective on quality characteristics, 2) quality applied service metadata, and 3) service registry design and implementation. The main findings of this research are following.

6.2. Conclusions

1. Quality can be represented various ways depending on the domain in which quality is defined.

Quality in business process is represented by quality of the products, cost and delay. In distributed

system, quality is viewed as performance, reliability, scalability, and security. Quality of geographic

data is represented by completeness, consistency, accuracy, purpose, usage and lineage. Common to

all above domains, satisfying customer’s requirements is the main goal. This can be interpreted in

GI services as quality of products, cost, delay, and credibility of service.

2. User quality requirements in GI services are quality of products, price of service, delay of service,

and credibility of service. Each quality requirement are mainly influenced by following quality

characteristics; 1) quality of products can be assumed by quality of data source (radiometric

accuracy for instance), quality of geometric process (geometric accuracy for instance), and user

reputation 2) although price of quality is measured by the price of service, it is influenced by almost

all quality characteristics 3) delay of service is determined by processing time and transmission time,

but availability and reliability can be used as important variables 4) credibility of service is referred

to availability, reliability, user reputation and provider information. Among them, price, availability,

reliability, processing time and user reputation have been modelled for quality applied service

metadata design and service registry implementation.

3. Existing service representation standards, OWS service metadata, WSDL, and UDDI, have been

analyzed for quality applied service metadata design. Existing standards do not include service

quality information. However, there are some possibilities to include quality information. Feature

component in WSDL has high extensibility to include quality information. In addition, OWS

service metadata high human readability. Incorporating these characteristics, most acceptable

service metadata redesign process would be following step. 1) Specify quality characteristics in

feature component. 2) Service metadata redesign for feature component inclusion using OWS


72

service metadata, especially service identification section. Suggested service metadata is included in

Chapter 4.

4. During service registry implementation, web development shareware has been used for easiness and

flexibility of implementation. However, query results are incomplete sometimes. It is assumed that

unstable database system results this problem. Although this problem was not happened often, this

result implies potential risk of shareware or open-source.

5. Implemented service registry has been evaluated by number of users. Evaluation has been done to

check two main points. Firstly, users’ priority of service quality characteristics and functional part

of registry has been asked. Most of quality characteristics are regarded as important measurements

for service selection. However, some of users were confused about meaning and practical use of

user reputation. Functional part of registry was useful for most users.

6. Service registry has been evaluated as a “web site” using ADQ web site evaluation form. Various

perspectives considered such as Web site, web page, objectivity, coverage, presentation, and

usefulness of web site. Generally, web site was regarded acceptable, but representation (visual

design) does not make users satisfied.

6.3. Recommendations

1. Although this research addressed individual service quality model, this can be applied to

aggregated services. In order to apply to aggregates service, influence of service aggregation

to each characteristic should be studied further. In addition, aggregated service quality

model can be researched further.

2. Service registry has been implemented to represent quality characteristics in service

identification. However, service registry should include whole service metadata for real use.

In this context, service registry need to be designed to include whole service metadata and

advanced query function.

3. Recently, XML based application and metadata representation is used commonly. Because

of its interoperability, XML has been taken as a standard in web environment. Although

implemented service registry support service metadata schema and service description as

XML type, this registry does not use XML database. XML based database need to be

studied for potential use.

4. Although meaning of each quality characteristics have defined in this research, each term

has been understood differently depending on users’ personal knowledge. Standard ontology

of quality characteristics should be investigated.


73

5. In this research, each service description should be input and updated manually by service

providers. For better performance, it is required to study automated service metadata

updating system. Standard ontology of quality characteristics can help to realize automated

service metadata by improving machine readability of terms.


74

REFERENCES Aditya, T. and R. Lemmens (2003). "Chaining distributed GIS services." Booth, D. (2004). Web Services Description Language (WSDL) Version 2.0 Part 0: Primer. http://www.w3.org/TR/2004/WD-wsdl20-primer-20041221/. Broh, R. A. (1982). "Managing quality for higher profits." Chinnici, R., M. Gudgin, et al. (2004). Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. http://www.w3.org/TR/2004/WD-wsdl20-20040803/wsdl20.pdf. Corbley (1996). San Francisco hills challenge orthorectification process, EOM. Crosby, P. B. (1979). "Quality is free." Edwards, C. D. (1968). "The meeting of quality." Emmerich, W. (1997). Distributed system principles. Gilmore, H. L. (1974). "Product conformance cost." Groot, R. (2001). "Reform of government and future performance of national surveys." Groot, R. and J. McLaughlin (2000). Geosptial Data Infrastructure: concepts,, cases and good practice. New York, Oxford University Press. Hanisch, B. (2002). Resource and Service Metadata for the Virtual Observatory. http://us-vo.org/pubs/files/ResourceServiceMetadataV4.pdf. ISO (2000). Quality management systems - Fundamentals and vocabulary (ISO 9000:2000), European Commitee for Standardization (CEN); Netherlands Normalisatie Instituut (NNI). ISO (2001). ISO19119 Geographic Information - Services. 2004. Juran, J. M. (1988). "Quality control handbook." Kresse, W. and K. Fadaie (2004). "ISO Standards for geographic information." Lee, Y. M. (2004). PHP5, Kame publication. Leifler, K. B. (1982). "Ambiguous chainges in product quality." Morales, J. M. (2004). Model-driven design of geo-information services. Enschede, ITC.


75

Morales, J. M., R. Onchaga, et al. (2004). "The changing role of the geo-data infrastructure; From a data delivery network to a virtual enterprise supporting complex services." Morales, J. M. and M. M. Radwan (2002). Extending Geo-information services: A virtual architecture for spatial infrastructures. In proceedings of the joint International Symposium on Geospatial Theory, Processing and Applications of the ISPRS Commission IV, Ottawa, Canada. Morales, J. M. and M. M. Radwan (2004). "Architecting distributed geo-information services: beyond data infrastructure." OGC (2002). The OpenGIS Abstract Specification, Topic 12: OpenGIS Service Architecture, Version 4.3. G. Percivall. http://www.opengis.org/docs/02-112.pdf, accessed 19, August, 2004. 2004. OGC (2003). OpenGIS Reference Model, version 0.1.2. K. Buehler. http://www.opengis.org/docs/03-040.pdf, OpenGIS Consortium. 2004. OGC (2005). Vision & Mission. http://www.opengeospatial.org/about/?page=vision, accessed 10/Oct/2004. Onchaga, R. (2004). Modelling for quality of services in distributed geo-processing. ISPRS proceeding, Istanbul. Reece, K. (2004). Defining and evaluating the criteria for effective implementation of a national geospatial data clearinghous in Jamaica. Enschede, ITC: 119p. Riegen, C. v. (2002). http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm. http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm. Sparks, G. (2000). The business process model. http://www.sparxsystems.com.au/WhitePapers/The_Business_Process_Model.pdf. Steen, M. v. (2001). Computer networks. http://www.cs.vu.nl/cs/os-cn/cn-sheets/notes.01.pdf. UDDI (2000). UDDI Technical white paper. http://www.uddi.org/pubs/Iru_UDDI_Technical_White_Paper.pdf. Vasudevan, V. (2001). A web services primer. http://www.calnet.com/itsolutions/webserv_art2.html. 2005. W3C (2004). Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. http://www.w3.org/TR/2004/WD-wsdl20-20040803/. 2004. Welch, R. (1990). "3-D Terrain modeling for GIS applications." GIS World.


76

APPENDIX A ISO 19115 Metadata package data dictionaries (Data quality metadata)

A Data quality information Name Definition Obligation / Condition

78 DQ_DataQuality Quality information for the data specified by data quality scope

Use obligation from referencing object

79 Scope The specific data to which the data quality information applies

M

80 Role name: report Quantitative quality information for the data specified by the scope

C / scope.DQ_Scope.level equals “dataset”?

81 Role name: lineage Non-quantitative quality information about the lineage of the data specified by the scope

C / scope.DQ_Scope.level equals “dataset”?

A.1 Lineage information 82 LI_Lineage Information about the events or sour data us

ed in constructing the data specified by the scope or lack of knowledge about lineage


83 statement General explanation of the data producer’s knowledge about the lineage of a dataset

C / (DQ_DataQuality.scope.DQ_Scope.level = “dataset” or “series”) and source and processStep not provide

d? 84 Role name: processS

tep Quantitative quality information for the data specified by the scope

C / statement and source not provided?

85 Role name: source Non-quantitative quality information about the lineage of the data specified by the scope

C / statement and ProcessStep not provided?

A.1.1 Process step information 86 LI_ProcessStep Information about the events in the creation

process fr the data specified by the scope Use obligation from r

eferencing object 87 Description Description of the event, including related p

arameters or tolerances M

88 Rationale Requirement or purpose for the process step O 89 Date Time Date and time or range of date and time on

or over which the process step occurred O

90 Processor Identification of, and means of communication with, person(s) and organization(s) associated with the process step

O


77

91 Role name: source Information about the source data used in creating the data specified by the scope

O

A.1.2 Source information 92 LI_ProcessStep Information about the events in the creation

process fr the data specified by the scope Use obligation from r

eferencing object 93 Description Description of the event, including related p

arameters or tolerances M

94 Rationale Requirement or purpose for the process step O 95 Date Time Date and time or range of date and time on

or over which the process step occurred O

96 Processor Identification of, and means of communication with, person(s) and organization(s) associated with the process step

O

97 Role name: source Information about the source data used in creating the data specified by the scope

O

98

A.2 Data quality element information 99 DQ_Element Type of test applied to the data specified by

a data quality scope Use obligation from r

eferencing object 100 nameOfMeasure name of the test applied to the data O 101 measureIdentificati

on Code identifying a registered standard procedure

O

102 measureDescription

Description of the measure being determined

O

103 evaluationMethodType

Type of method used to evaluate quality of the dataset

O

104 evaluationMethodDescription

Description of the evaluation method O

105 evaluationProcedure

Reference to the procedure information O

106 date Time Date or range of dates on which a data quality measure was applied

O

107 Result Value (or set of values) obtained from applying a data quality measure or the out come of evaluating the obtained value (or set of values) against a specified acceptable conformance quality level

M

108 DQ_Completeness Presence and absence of feature, their attributes and their relationships


109 DQ_CompletenessCommission

Excess data present in the dataset, as described by the scope



78

110 DQ_CompletenessOmmission

Data absent from the dataset, as described by the scope


111 DQ_LogicalConsistency

Degree of adherence to logical rules of data structure, attribution and relationships (data structure can be conceptual, logical or physical)


112 DQ_ConceptualConsistency

Adherence to the rules of the conceptual schema


113 DQ_DomainConsistency

Adherence of values to the value domains Use obligation from referencing object

114 DQ_FormatConsistency

Degree to which data is stored in accordance with the physical structure of the dataset, as described by the scope


115 DQ_TopologicalConsistency

Correctness of the explicitly encoded topological characteristics of the dataset as described by the scope


116 DQ_PositionalAccuracy

Accuracy o the position of features Use obligation from referencing object

117 DQ_AbsoluteExternalPositionalAccuracy

Closeness of reported coordinate values to values accepted as or being true


118 DQ_GriddedDataPositionalAccuracy

Closeness of gridded data position values to values accepted as or being true


119 DQ_RelativeInternalPositionalAccuracy

Closeness of relative positions of features in the scope to their respective relative positions accepted as or being true


120 DQ_TemporalAccuracy

Accuracy of the temporal attributes and temporal relationships of features


121 DQ_AccuracyOfATimeMesurement

Correctness of the temporal references of an item (reporting of error in time measurement)


122 DQ_TemporalConsistency

Correctness of ordered events or sequences if reported


123 DQ_TemporalValidity

Validity of data specified by the scope with respect to time


124 DQ_ThematicAccuracy

Accuracy of quantitative attributes and the correctness of non-quantitative attributes and of the classifications of features and their relationships


125 DQ_ThematicClassificationCorrectness

Comparison of the classes assigned to features or the attributes to a universe of discourse


126 DQ_NonQuantitativeAttributeAccuracy

Correctness of non-quantitative attributes Use obligation from referencing object


79

127 DQ_QuantitativeAttributeAccuracy

Accuracy of quantitative attributes Use obligation from referencing object

A.3 Result information 128 DQ_Result Generalization of more specific result

classes Use obligation from r

eferencing object 129 DQ_Conformance

Result Information about the outcome of evaluating the obtained value (or set of values) against a specified acceptable conformance quality level


130 specification Citation of product specification or user requirement against which data is being evaluated

M

131 explanation Explanation of the meaning of conformance for this result

M

132 pass Indication of the conformance result where 0=fail and 1=pass

M

133 DQ_QuantitativeResult

Information about the value (or set of values) obtained from applying a data quality measure


134 valueType Value type for reporting a data quality result

O

135 valueUnit Value unit for reporting a data quality result O 136 errorStatistic Statistical method used to determine the

value O

137 value Quantitative value or values, content determined by the evaluation procedure used

M

A.4 Scope information 138 DQ_Scope Description of the data specified by the sco

pe Use obligation from r

eferencing object 139 level Hierarchical level of the data specified by t

he scope M

140 extent Information about the spatial, vertical and temporal extent of the data specified by the scope

O

141 levelDescription Detailed description about the level of the data specified by the scope

C / level not equal “dataset” or “series”?


80

APPENDIX B UDDI service description example (Microsoft Corporation)

<?xml version="1.0" encoding="utf-8"?> <businessEntity xmlns:xsd="htp://www.w3.org/2001/XMLSchema"

mlns:xsi="http://www.w3.org/2001/XMLSchema-instance" businessKey=" 0076b468-eb27-42e5-ac09-9955cff462a3" operator="Microsoft Corporation"

authorizedName="Bruce Farr" xmlns="urn:uddi-org:api_v2"> <discoveryURLs>

<discoveryURL useType="businessEntity">http://uddi.microsoft.com/discovery? businesskey=0076b468-eb27-42e5-ac09-9955cff462a3</discoveryURL>

</discoveryURLs> <name xml:lang="en">Microsoft Corporation</name> <description xml:lang="en">Empowering people through great software - any time, any place and on

any device is Microsoft's vision.</description>

<contacts> <contact useType="Corporate Contact Information">

<description xml:lang="en">Corporate Mailing Addresses</description> <personName>Luc Clement</personName> <phone useType="Corporate Headquarters">(425) 882-8080</phone> <address sortCode="~" useType="Corporate Headquarters">

<addressLine>Microsoft Corporation</addressLine> <addressLine>One Microsoft Way</addressLine> <addressLine>Redmond, WA, 98052-6399</addressLine> <addressLine>USA</addressLine>

</address> </contact> <contact useType="Technical UDDI Contact">

<description xml:lang="en">Microsoft.com Operations</description> <personName>Bruce Farr</personName> <email useType="">[email protected]</email>

</contact> </contacts>

<businessServices>

<businessService serviceKey="17b29861-2f33-402c-98f0-fd16cf5b8e9c" businessKey="0076b468-eb27-42e5-ac09-9955cff462a3"> <name xml:lang="en">Home Page</name> <description xml:lang="en">Corporate Home Page</description> <bindingTemplates>

<bindingTemplate bindingKey="a98278c6-b8d5-4fc2-83af-577316fd8cf2" serviceKey="17b29861-2f33-402c-98f0-fd16cf5b8e9c"> <description xml:lang="en">Corporate Home Page URL</description>


81

<accessPoint URLType="http">http://www.microsoft.com</accessPoint> <tModelInstanceDetails>

<tModelInstanceInfo tModelKey="uuid:68de9e80-ad09-469d-8a37-088422bfbc36"> <description xml:lang="en">HTTP Address</description>

</tModelInstanceInfo> </tModelInstanceDetails>

</bindingTemplate> </bindingTemplates>

</businessService>

<businessService serviceKey="491e8f93-e90f-42e3-a048-726744453659" businessKey="0076b468-eb27-42e5-ac09-9955cff462a3"> <name xml:lang="en">Online Shopping</name> <description xml:lang="en">This site is designed to help you easily learn about and order

Microsoft® software and hardware and Microsoft Press® titles that can enhance your computing.</description>

<bindingTemplates> <bindingTemplate bindingKey="fc6368ad-9216-4538-8ee3-92438e955b20"

serviceKey="491e8f93-e90f-42e3-a048-726744453659"> <description xml:lang="en">eShop web site</description> <accessPoint URLType="http">http://shop.microsoft.com</accessPoint> <tModelInstanceDetails>




</businessService> <businessService serviceKey="4de36949-e757-4de1-a3bd-b3f1d4350325"

businessKey="0076b468-eb27-42e5-ac09-9955cff462a3"> <name xml:lang="en">Microsoft Developer Network</name> <description xml:lang="en">MSDN, the Microsoft Developer Network, is the essential resource

for developers. MSDN developer programs make it easy to find timely, comprehensive development resources, including software subscription programs, technical information, and Web sites.</description>

<bindingTemplates> <bindingTemplate bindingKey="beed8fbd-9e2b-4d2c-9009-5416151f0c4e"

serviceKey="4de36949-e757-4de1-a3bd-b3f1d4350325"> <description xml:lang="en">MSDN Web Site</description> <accessPoint URLType="http">http://msdn.microsoft.com</accessPoint> <tModelInstanceDetails>




</businessService>


82

<businessService serviceKey="f9d39c6f-aa09-4c5c-bc7b-6b26b0ba016d" businessKey="0076b468-eb27-42e5-ac09-9955cff462a3">

<name xml:lang="en">Technet</name> <description xml:lang="en">TechNet provides in depth "how-to" technical information on

Microsoft products as well as a chance to interact with peers — and Microsoft. You can access forums for sharing best practices with others and provide feedback directly to Microsoft.</description>

<bindingTemplates> <bindingTemplate bindingKey="53c0e056-d698-40fc-8bb1-1d6bb27cfcba"

serviceKey="f9d39c6f-aa09-4c5c-bc7b-6b26b0ba016d"> <description xml:lang="en">Technet web site</description> <accessPoint URLType="http">http://www.microsoft.com/technet</accessPoint> <tModelInstanceDetails>




</businessService>

<businessService serviceKey="367df918-7d5e-4b00-8cf6-afe56367c2d6" businessKey="0076b468-eb27-42e5-ac09-9955cff462a3">

<name xml:lang="en">Volume Licensing Select Program</name> <description xml:lang="en">The select program for volume licensing user guide for the Select

CD application.</description> <bindingTemplates>

<bindingTemplate bindingKey="3a58bb39-6e7b-462b-bfa7-6698755c2a0e" serviceKey="367df918-7d5e-4b00-8cf6-afe56367c2d6"> <description xml:lang="en">Volume Licensing Select Web Site</description> <accessPoint URLType="http">http://selectug.mslicense.com</accessPoint> <tModelInstanceDetails>




</businessService> <businessService serviceKey="bd9b1a10-4668-42e9-ac69-d3da905c314d" businessKey="0076b468-eb27-42e5-ac09-9955cff462a3">

<name xml:lang="en">Electronic Business Integration Services</name> <description xml:lang="en">EBIS EDI information</description> <bindingTemplates>

<bindingTemplate bindingKey="b4743b69-52eb-4331-97c8-573fad839e7f" serviceKey="bd9b1a10-4668-42e9-ac69-d3da905c314d"> <description xml:lang="en">EBIS overview web site</description> <accessPoint URLType="http">http://www.microsoft.com/edi</accessPoint> <tModelInstanceDetails>

<tModelInstanceInfo tModelKey="uuid:68de9e80-ad09-469d-8a37-088422bfbc36">


83

<description xml:lang="en">HTTP Address</description> </tModelInstanceInfo>

</tModelInstanceDetails> </bindingTemplate>

</bindingTemplates> </businessService>

</businessServices> <identifierBag>

<keyedReference tModelKey="uuid:8609c81e-ee1f-4d5a-b202-3eb13ad01823" keyName="D-U-N-S" keyValue="08-146-6849"/>

</identifierBag> <categoryBag>

<keyedReference tModelKey="uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2" keyName="NAICS: Software Publisher" keyValue="51121"/>

</categoryBag>

</businessEntity>


84

APPENDIX C Service Registry Evaluation Paper

Dear GIM students This is the questionnaire for service registry evaluation. Please read this paper carefully and try to follow given scenario.

You are going to create orthopho using distributed geo-processing in service oriented GDI. Orthophoto production service is composed various core services. They are rectification, image coordinate conversion, sampling, and orthorectification service. Figure C.1 shows core services for orthophoto production service.

Figure C.1 Core geo-services for orthophoto production

Description of each core services are given below

• Rectification service: Service for transforming an image into a perpendicular parallel projection and therefore a constant scale.

• Orthorectification service: A rectification service that removes image tilt and displacement due to terrain elevation. Orthorectification requires use of digital elevation data, usually in grid form.

• Image coordinate conversion service: A coordinate transformation or coordinate conversion service to change the coordinate reference system for an image.

• Sampling service: Service that extracts data from an input using a consistent sampling scheme either by geographic location or by grid coordinates.

Please open this web address http://84.31.108.43/KIM/index.php.

1. Try registering process using “register” included in index page.

2. Do “Log in” using your registered ID and password.

3. Try to publish your service. You can publish geographic processing service only.

4. Try to update your service.

5. Try to search required services that are assigned above.

If you finish all processes mentioned above, please answer following evaluation form.


85

Form1. Quality characteristics and functional part evaluation form.


General user quality requirements

Your priority of quality related characteristics?

( ) Price

( ) Availability

( ) Reliability

( ) Processing time

( ) User reputation

( ) Transmission time

( ) Provider information

( ) Radiometric accuracy

( ) Geometric accuracy

Quality characteristics in service registry

Does registry include required characteristics?

Missing characteristics

=>

Unnecessary characteristics

( ) Price

( ) Availability

( ) Reliability

( ) Processing time

( ) User reputation

( ) Transmission time

( ) Provider information

( ) Radiometric accuracy

( ) Geometric accuracy

Functional part in service registry

Does registry include required functions?

Missing functions

=>

Unnecessary functions

( ) Register

( ) Log in/out

( ) Search

( ) Publish

( ) Update


86

Form2. Web site evaluation form


Web Site (Is the web site user-friendly for the target population?)

1. Is there a consistent design across ALL web

pages?

2. Are pages arranged in a logical order?

3. Are pages arranged in a modular format?

(Not having to scroll down long pages)

4. Is there a choice to view the web site in frames

or no frames?

5. Is it easy to find the information you're looking

for?

Y / N

Y / N

Y / N

Y / N

Y / N

Web Page

1. Do the pages load quickly?

2. Are postings in an At-A-Glance format?

3. Can you view the completed page on your

monitor?

4. Moving and distracting objects on pages?

5. Hyperlinks work?

6. Dates when pages published or updated?

Y / N

Y / N

Y / N

Y / N

Y / N

Y / N

Objectivity

1. Any biases in the content?

2. Do authors inform users of any inherent

biases?

Y / N

Y / N

Coverage (Are the materials covered in depth and appropriate for the

intended user?)

1. Are the materials detailed enough?

2. Are the materials complete on the subject?

3. Are the materials appropriate for the age of the

user?

4. Is complexity of information consistent with

you?

Y / N

Y / N

Y / N

Y / N

Presentation

1. Is hypertext used logically?

2. Are video, audio, and graphics used modestly?

3. Are colors used properly?

Y / N

Y / N

Y / N

Usefulness 1. Is the information useful for the intended target

population?

Y / N

Thank you for your cooperation.


87

Appendix D Codes for service registry implementation

D.1 Main page frame (RegistryDesign.php) <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>Untitled Document</title> </head> <frameset rows="80,*" cols="*" frameborder="NO" border="0" framespacing="0">

<frame src="/KIM/top.php" name="topFrame" scrolling="NO" noresize> <frameset rows="*" cols="100,*" framespacing="0" frameborder="NO" border="0"> <frame src="/KIM/Left.php" name="leftFrame" scrolling="NO" noresize> <frame src="/KIM/main.php" name="mainFrame">

</frameset> <body> </body> </html>

D.2 Connect database (p_conpig.php)

� Code for database connection <?php $db=mysql_connect("localhost","user","password"); mysql_select_db("test", $db); ?>

D.3 Log in D.3.1 Log in form (index.php)

� Input ID and password, and execute logincheck.php <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>Untitled Document</title> </head> <body bgcolor="white"> <div align="center"> <p> </p> <p>Please Input your ID and password</p> <form action=logincheck.php method=post> <table width=194 border=1 cellpadding=1 cellspacing=1 bgcolor="white">

<tr> <td width=40 align=left>I D</td> <td align=left width="150"> <INPUT type=text name=pid size=20 maxlength=20> </td> </tr> <tr>


88

<td width=40 align=left>Pass</td> <td align=left width="150"> <INPUT type=password name=pass size=20 maxlength=20> </td> </tr> <tr> <td colspan=15 align=center><input type=submit value="Log In"> </td> </tr>

</table>

<table width=580 border=0 cellpadding=0 cellspacing=0 bgcolor="white"> <tr>

<td align="center"><p> </p> <p>Please <a href="U_inputform.php" target="_self">Click:Register</a>,<br>

If you are not registered. </p></td> </tr>

</table> </form> </div> </body> </html>

D.3.2 Check database (logincheck.php) � Check ID and password, and execute logincheck.php. If ID and password are right, go to

main page. If ID or password is wrong, return to previous page. <html> <head> </head> <body topmargin=10 leftmargin=10 text=blue> <center>

<?php

// Connect database - - > include "p_config.php"; // Query for user ID check $result=mysql_query("select * from pid2 where p_id='$pid' order by id", $db); $row=mysql_fetch_array($result); // Check input value and stored values if ($pid!=$row[p_id]) { // when id is correct echo (" <script> alert('You have typed unregistered ID $row[id], please insert correctly') history.go(-1) </script> "); exit; } else if ($pass!=$row[pass]) { // when id is correct echo (" <script> alert('You have typed wrong password, please insert correctly') history.go(-1) </script> "); exit; } else { echo ("<meta http-equiv='Refresh' content='0; URL=registrydesign.php ' >");} ?> </body> </form>


89

</div> </body>

D.4 Registration D.4.1 Register form (U_inputform.php)

� Input required fields, and execute U_insert.php

<html> <head> </head> <body> <title><b>Registration</b></title> <center> <BR> <form action=U_insert.php method=post> <table width=500 border=0 cellpadding=2 cellspacing=1 bgcolor="#009896"> <tr> <td width=80 align=left>I D</td> <td align=left> <INPUT type=text name=p_id size=30 maxlength=30> </td> </tr> <tr> <td width=80 align=left>Password</td> <td align=left> <INPUT type=password name=pass size=33 maxlength=30> </td> </tr> <tr> <td><b>e-Mail: </b></td> <td> <INPUT type=text name=email size=30 maxlength=30> </td> </tr> <td colspan=15 align=center>

<input type=submit value="Save"> <INPUT type=reset value="Reset"> <INPUT type=button value="Return" onclick="history.back(-1)">

</td> </tr>

</table> </form> </center> </body> </html>

D.4.2 Registration process (U_insert.php) � Check ID to determine whether input data is stored in database or not

<?php include "p_config.php"; $qry="select p_id from pid2 where p_id='$p_id' ";


90

$result=mysql_query($qry); $num2=mysql_num_rows($result); // check input and stored values if ($num2) { echo (" <script> alert('Registred ID, Please change ID') history.go(-1) </script> "); exit; } else{ echo " Usable ID\n"; } $query = "insert into pid2 values ('','$email','$p_id','$pass')"; $result=mysql_query($query, $db); mysql_close($db); echo("<meta http-equiv='Refresh' content='1; URL=index.php'>") ?> <center> <FONT face=roman size=2 color=silver>success.</font>

D.5 Search D.5.1 Initial search form (Searchform.php)

� Input query parameters and execute U_insert.php <html> <body> <center> <BR> <form action=query_insert.php method=post> <p><font size="+3"><strong><em>Search service</em></strong></font></p> <p><strong><font size="+2">Service Type selection</font></strong></p> < !-- Table for service type selection - - > <table width=507 height="50" border=0 cellpadding=2 cellspacing=1 bgcolor="#009896">

<tr> <td width=96 height=52 align=left >OSE category</TD> <td width=383 height=52 align=left bgcolor=#ffffff>

<select name=ose><option < <? echo "<option value=0>Select OSE"; ?>

<option value=human>Geographic Human Interaction services <option value=model>Geographic Model/Information management services <option value=work>Geographic Workflow/Task management services <option value=process>Geographic Processing services <option value=communication>Geographic Communication services <option value=system>Geographic System management services


91

</select> <font color="#FF0000">**</font> </td>

</tr> <tr>

<td width=96 align=left>Service Type</td> <td width=383 height=50 align=left bgcolor=#ffffff>

<select name=servicetype><option < <? echo "<option value=0>Select service type"; ?> <option value=CoordinateConversionService>Coordinate conversion service <option value=CoordinateTransformationService>Coordinate transformation service <option value=CoverageVactorConversionService>Coverage/vector conversion service <option value=ImageCoordinateConversionService>Image coordinate conversion service <option value=RectificationService>Rectification service <option value=OrthorectificationService>Orthorectification service

</select> <font color="#FF0000">** </font> </td>

</tr> </table>

<p><strong><font size="+2">Service Condition selection</font></strong></p>

< !-- Table for query parameters selection - - > <table width=555 height="279" border=2 cellpadding=2 cellspacing=1 bgcolor="#009896">

<tr bgcolor="#FF9900">

<td width=66 align=left><div align="center"><strong>Condition Factors</strong></div></td> <td width="140" align=left> <div align="center"><strong>Minimun value</strong></div></td> <td width="140" align=left><div align="center"><strong>Maximum value</strong></div></td> <td width="145" align=left><div align="center"><strong>Range of value</strong></div></td>

</tr> <tr>

<td width=66 align=left>Price</td> <td width="140" align=left> <INPUT type=double name=price1 size=20 ></td> <td width="140" align=left> <INPUT type=double name=price2 size=20 > </td> <td width="145" align=left>0 ~ unlimit Euro/MB</td>

</tr> <tr>

<td width=66 align=left>Availability</td> <td align=left> <INPUT type=double name=availability1 size=20 ></td> <td align=left> <INPUT type=double name=availability2 size=20 > </td> <td width="145" align=left>0 ~ 1</td>

</tr> <tr>

<td width=66 align=left>Process Time</td> <td align=left> <INPUT type=double name=processtime1 size=20 ></td> <td align=left> <INPUT type=double name=processtime2 size=20 > </td> <td width="145" align=left>0 ~ unlimit Second/MB</td>

</tr> <tr>

<td width=66 align=left>Reputation</td> <td align=left> <INPUT type=double name=reputation1 size=20 ></td> <td align=left> <INPUT type=double name=reputation2 size=20 > </td> <td width="145" align=left>0 ~ 10 </td>

</tr> <tr>

<td width=66 align=left>Order by</td> <td align=left height="20">

<select name=sort1> <option <<? echo "<option value=0>Select order factor"; ?> <option value=price>Price <option value=availability>Availability <option value=processtime>Process time


92

<option value=reputation>Reputation </select>

</td> <td align=left height="20">

<select name=sort2> <option <<? echo "<option value=0>Select order factor2"; ?> <option value=price>Price <option value=availability>Availability <option value=processtime>Process time <option value=reputation>Reputation

</select> </td> <td align=left height="20">

<select name=sort3> <option <<? echo "<option value=0>Select order factor2"; ?> <option value=price>Price <option value=availability>Availability <option value=processtime>Process time <option value=reputation>Reputation

</select> </td>

</tr> <td colspan=15 align=center>

<input type=submit value="Query"> < input type=reset value="Reset">

</td> </tr>

</table> <p><font color="#FF0000"><strong>** <font color="#000000">Mandatory</font></strong></font></p> </form> </center> </body> </html>

D.5.2 query_insert.php � Check consistency of query � Show query results including query form

<html> <body topmargin=10 leftmargin=10 text=blue> <center>

<p><strong><font size="+3">Query results</font></strong></p>

<?php /* Alter incorrect query OSE and Service type are mandatory content to type */ if (!$servicetype || !$ose){ // when id is correct echo (" <script> alert('You have not input mandatory field') history.go(-1) </script> "); exit; } /* connect database */ include "p_config.php";

93

/* If query parameters are not selected then use minimum and maximum values as following */ if (!$price1){$price1=0;} if (!$price2){$price2=999999999999;} if (!$availability1){$availability1=0;} if (!$availability2){$availability2=1;} if (!$processtime1){$processtime1=0;} if (!$processtime2){$processtime2=9999999999;} if (!$reputation1){$reputation1=0;} if (!$reputation2){$reputation2=1;} /* Query condition for service selection Compare input value and data in database */ $result=mysql_query("select * from sid2 where servicetype='$servicetype' && $price1<price && $price2>price&& $availability1<availability && $availability2>availability && $processtime1<processtime && $processtime2>processtime && $reputation1<reputation && $reputation2>reputation order by '$sort1', '$sort2', '$sort3'", $db); $row=mysql_fetch_array($result); ?> <BR>  <form method="post"> <table width=692 border=5 cellpadding=5 cellspacing=5 bgcolor=pink>

<tr> 

<td height=20 align=center bgcolor=blue> <font color=white><B>Service ID</B></font> </td> <td height=20 align=center bgcolor=blue> <font color=white><B>Service Type</B></font> </td> <td height=20 align=center bgcolor=blue> <font color=white><B>Title</B></font> </td> <td height=20 align=center bgcolor=blue> <font color=white><B>Price</B></font> </td> <td height=20 align=center bgcolor=blue> <font color=white><B>Availability</B></font> </td> <td height=20 align=center bgcolor=blue> <font color=white><B>Process Time</B></font> </td> <td height=20 align=center bgcolor=blue> <font color=white><B>Reputation</B></font> </td> <td height=20 align=center bgcolor=blue> <font color=white><B>Last update</B></font> </td>

<td width="88" height=20 align=center bgcolor=blue> <font color=white><B>Service Description</B></font>

</td> </tr>

<!—Matched query results --> <? while ($row=mysql_fetch_array($result)) { ?> <tr> <td width=59 align=left><?=$row[sid]?></td> <td width=71 align=left><?=$row[servicetype]?></td>

94

<td width=71 align=left><?=$row[title]?></td> <td width=35 align=left><?=$row[price]?></td> <td width=37 align=left><?=$row[availability]?></td> <td width=85 align=left><?=$row[processtime]?></td> <td width=82 align=left><?=$row[reputation]?></td> <td width=82 align=left><?=$row[date]?></td> <td width=84 align=left><a href="<? echo $row[sid] ?>.xml" target="_blank">XML Document</td> </tr> <? } // end While //disconnect database. mysql_close($db); ?> </table>  <p> </p> </form> <center> <form action=query_insert.php method=post> <p> </p> <!— Query in query part --> <table width=555 height="50" border=0 cellpadding=2 cellspacing=1 bgcolor="#009896">

<tr> <td width=99 height=52 align=left >OSE category</TD> <td width=445 height=52 align=left bgcolor=#ffffff>

<select name=ose><option < <? echo "<option value=$ose>$ose"; ?> <option value=human>Geographic Human Interaction services <option value=model>Geographic Model/Information management services <option value=work>Geographic Workflow/Task management services <option value=process>Geographic Processing services <option value=communication>Geographic Communication services <option value=system>Geographic System management services </select>

<font color="#FF0000">**</font> </td> </tr> <tr>

<td width=99 align=left>Service Type</td> <td width=445 height=50 align=left bgcolor=#ffffff>

<select name=servicetype><option < <? echo "<option value=$servicetype>$servicetype"; ?> <option value=CoordinateConversionService>Coordinate conversion service <option value=CoordinateTransformationService>Coordinate transformation service <option value=CoverageVactorConversionService>Coverage/vector conversion service <option value=ImageCoordinateConversionService>Image coordinate conversion service <option value=RectificationService>Rectification service <option value=OrthorectificationService>Orthorectification service

</select> <font color="#FF0000">** </font></td> </tr>

</table> <table width=555 height="279" border=2 cellpadding=2 cellspacing=1 bgcolor="#009896"> <tr bgcolor="#FF9900"> <td width=66 align=left><div align="center"><strong>Condition Factors</strong></div></td> <td width="140" align=left> <div align="center"><strong>Minimun value</strong></div></td>


95

<td width="140" align=left><div align="center"><strong>Maximum value</strong></div></td> <td width="145" align=left><div align="center"><strong>Range of value</strong></div></td> </tr> <tr> <td width=66 align=left>Price</td> <td width="140" align=left> <INPUT type=double name=price1 size=20 ></td> <td width="140" align=left> <INPUT type=double name=price2 size=20 > </td> <td width="145" align=left>0 ~ unlimit Euro/MB</td> </tr> <tr> <td width=66 align=left>Availability</td> <td align=left> <INPUT type=double name=availability1 size=20 ></td> <td align=left> <INPUT type=double name=availability2 size=20 > </td> <td width="145" align=left>0 ~ 1</td> </tr> <tr> <td width=66 align=left>Process Time</td> <td align=left> <INPUT type=double name=processtime1 size=20 ></td> <td align=left> <INPUT type=double name=processtime2 size=20 > </td> <td width="145" align=left>0 ~ unlimit Second/MB</td> </tr> <tr> <td width=66 align=left>Reputation</td> <td align=left> <INPUT type=double name=reputation1 size=20 ></td> <td align=left> <INPUT type=double name=reputation2 size=20 > </td> <td width="145" align=left>0 ~ 10 </td> </tr> <tr> <td width=66 align=left>Order by</td> <td align=left height="20"> <select name=sort1><option < <option <<? echo "<option value=0>Select order factor2"; ?> <option value=price>Price <option value=availability>Availability <option value=processtime>Process time <option value=reputation>Reputation </select> </td> <td align=left height="20"> <select name=sort2><option <<? echo "<option value=0>Select order factor2"; ?> <option value=price>Price <option value=availability>Availability <option value=processtime>Process time <option value=reputation>Reputation </select> </td> <td align=left height="20"> <select name=sort3> <option <<? echo "<option value=0>Select order factor2"; ?> <option value=price>Price <option value=availability>Availability <option value=processtime>Process time <option value=reputation>Reputation </select> </td> </tr> <td colspan=15 align=center> <input type=submit value="Query"> <INPUT type=reset value="Reset"> </td> </tr> </table> <p><font color="#FF0000"><strong>** <font color="#000000">Mandatory</font></strong></font></p>


96

</form> </center> <p> </p></center> </body> </html>

D.6 Publish D.6.1 s_inputform.php

� Publish form <html> <body> <title><b>Publish</b></title> <center> <BR> <form action=s_insert.php method=post> <table width=513 height="279" border=0 cellpadding=3 cellspacing=2 bgcolor="#009896">

<tr> <td width=70 align=left>UserID</td> <td align=left> <INPUT type=text name=pid size=30 ></font> </td> </tr> <tr> <td width=70 align=left>Password</td> <td align=left> <INPUT type=password name=pass size=30 ></font> </td> </tr> <tr> <td width=70 align=left>Title</td> <td align=left> <INPUT type=text name=title size=30> </td> </tr> <tr> <td width=70 height=20 align=left >OSE category</TD> <td width=342 height=20 align=left bgcolor=#ffffff> <select name=ose>

<option <<? echo "<option value=0>Select OSE category"; ?> <option value=human>Geographic Human Interaction services <option value=model>Geographic Model/Information management services <option value=work>Geographic Workflow/Task management services <option value=process>Geographic Processing services <option value=communication>Geographic Communication services <option value=system>Geographic System management services

</select> </td> </tr> <tr> <td width=70 align=left>Service Type</td> <td width=342 height=20 align=left bgcolor=#ffffff> <select name=servicetype>

<option <<? echo "<option value=0>Select service type"; ?> <option value=CoordinateConversionService>Coordinate conversion service <option value=CoordinateTransformationService>Coordinate transformation service <option value=CoverageVactorConversionService>Coverage/vector conversion service


97

<option value=ImageCoordinateConversionService>Image coordinate conversion service <option value=RectificationService>Rectification service <option value=OrthorectificationService>Orthorectification service

</select> </td> </tr> <tr> <td width=70 align=left>Service Type Version</td> <td align=left height="20"> <INPUT type=text name=stversion size=30 > <font color="#FF0000"> </font> </td> </tr> <tr> <td width=70 align=left>Price</td> <td align=left> <INPUT type=text name=price size=30 >Euro/MB

</td> </tr> <tr> <td width=70 align=left>Availability</td> <td align=left> <INPUT type=text name=availability size=30> Time gap: </td> <td width=85 height=20 align=left bgcolor=#ffffff> <select name=timegap>

<option <<? echo "<option value=0>GMT+0"; ?> <option value=-12>GMT-12 <option value=-11>GMT-11 <option value=-10>GMT-10 <option value=-9>GMT-9 <option value=-8>GMT-8 <option value=-7>GMT-7 <option value=-12>GMT-6 <option value=-11>GMT-5 <option value=-10>GMT-4 <option value=-9>GMT-3 <option value=-8>GMT-2 <option value=-7>GMT-1 <option value=-12>GMT+1 <option value=-11>GMT+2 <option value=-10>GMT+3 <option value=-9>GMT+4 <option value=-8>GMT+5 <option value=-7>GMT+6 <option value=-12>GMT+7 <option value=-11>GMT+8 <option value=-10>GMT+9 <option value=-9>GMT+10 <option value=-8>GMT+11 <option value=-7>GMT+12

</select> </td> </tr> <tr> <td width=70 align=left>Process Time</td> <td align=left> <INPUT type=text name=processtime size=30 maxlength=30> Second/MB

</td> </tr> <tr> <td width=70 align=left>Reputation</td> <td align=left> <INPUT type=text name=reputation size=30 maxlength=30>


98

</td> </tr>

<td colspan=15 align=center> <input type=submit value="Save"> <INPUT type=reset value="Reset"> <INPUT type=button value="Return" onclick="history.back(-1)"> </td>

</tr> </table> </form> Pleas check Metadata <a href="owsServiceIdentificationWithFeature.xsd" target="_blank"><strong><font color="#0000FF" size="+2">schema</font></strong></a> </center> </body> </html>

D.6.2 s_insert.php � Check consistency of input data � Save published service information in database

<?php /* connect database */ include "p_config.php"; $result=mysql_query("select * from pid2 where p_id='$pid'", $db); $row=mysql_fetch_array($result); // compare input value if ($pid!=$row[p_id] ) { // when id is correct echo (" <script> alert('You have typed unregistered ID $pid , please insert correct ID?') history.go(-1) </script> "); exit; } else if($pid==$row[p_id] && $pass!=$row[pass]) { // when password is correct echo (" <script> alert('Wrong Password, check please?') history.go(-1) </script> "); exit; } Else { echo " Your information was published.<p>\n"; } $query = "insert into sid2 values ('','$pid','$pass','$title','$ose','$servicetype','$stversion','$price','$availability','$timegap','$processtime','$reputation',now() )"; $result=mysql_query($query, $db); /* Close database */ mysql_close($db); echo("<meta http-equiv='Refresh' content='1; URL=s_inputform.php'>") ?> <center> <FONT face=roman size=2 color=silver>success.</font>


99

D.7 Update D.7.1 IDCheck.php

� Check user ID and password. If user is authorized user execute edit.php. <html> <body> <div align="center"> <p> </p> <p>Please Input your ID and password</p> <form action=edit.php method=post> <table width=580 border=3 cellpadding=5 cellspacing=5 bgcolor="green"> <tr> <td width=30 align=left>I D</td> <td align=left> <INPUT type=text name=pid size=30 maxlength=30> </td> </tr> <tr> <td width=30 align=left>Password</td> <td align=left> <INPUT type=password name=pass size=30 maxlength=30> </td> </tr> <tr> <td colspan=15 align=center> <input type=submit value="ID Check"> </tr> </table> <table width=580 border=0 cellpadding=0 cellspacing=0 bgcolor="white"> <tr> <td align="center"><p> </p> <p>If you have published your service, you can use this funtion.<br> If not, <a href="U_inputform.php">register</a> your service first. </p></td> </tr> </table> </form> </div> </body> </html>

D.7.2 edit.php � Show the list of published services those are published by authorized user

<html> <body topmargin=10 leftmargin=10 text=blue> <center>

<?php // Connect database include "p_config.php"; $result=mysql_query("select * from sid2 where pid='$pid' order by sid", $db); $row=mysql_fetch_array($result); // compare input value if ($pid!=$row[pid] || $pass!=$row[pass]) { // when id is correct echo (" <script> alert('You have typed unregistered ID or wrong password, please insert correctly') history.go(-1) </script> ");

100

exit; } ?> <BR>  <form method="post"> <table width=600 border=5 cellpadding=5 cellspacing=5 bgcolor=pink> <tr>  <td height=20 align=center bgcolor=blue> <font color=white><B>Service ID</B></font> </td> <td height=20 align=center bgcolor=blue> <font color=white><B>Title</B></font> </td> <td height=20 align=center bgcolor=blue> <font color=white><B>Service Type</B></font> </td> <td height=20 align=center bgcolor=blue> <font color=white><B>Service Type Version</B></font> </td> </tr>  <? while ($row=mysql_fetch_array($result)) { ?> <tr> <td width=60 align=left><a href=update.php?sid=<?=$row[sid]?>><b><?=$row[sid]?></b></a></td> <td width=60 align=left><?=$row[title]?></td> <td width=60 align=left><?=$row[servicetype]?></td> <td width=60 align=left><?=$row[stversion]?></td> </tr> <? } // end While // Close database mysql_close($db); ?> </table>  <p> Click Service ID that you want to update</p> </form> <p> </p></center> </body> </html>

D.7.3 update.php � Show selected service information in order to edit

<html> <body> <title><b>Publish</b></title> <center> <?php


101

// Connect database include "p_config.php"; $result=mysql_query("select * from sid2 where sid='$sid'", $db); $row=mysql_fetch_array($result); ?> <BR> <form action=s_update.php method=post> <table width=470 border=0 cellpadding=2 cellspacing=1 bgcolor="#009896"> <tr> <td width=114 align=left>Service ID</td> <td align=left> <INPUT type=text name=sid size=30 value=<?=$row[sid]?>> </td> </tr> <tr> <td width=114 align=left>Title</td> <td align=left> <INPUT type=text name=title size=30 value=<?=$row[title]?>> </td> </tr> <tr> <td width=114 height=20 align=left >OSE category</TD> <td width=345 height=20 align=left bgcolor=#ffffff> <select name=ose> <option <<? echo "<option value=0>$row[ose]"; ?> <option value=human>Geographic Human Interaction services <option value=model>Geographic Model/Information management services <option value=work>Geographic Workflow/Task management services <option value=process>Geographic Processing services <option value=communication>Geographic Communication services <option value=system>Geographic System management services </select> </td> </tr> <tr> <td width=114 align=left>Service Type</td> <td width=345 height=20 align=left bgcolor=#ffffff> <select name=servicetype> <option <<? echo "<option value=0>$row[servicetype]"; ?> <option value=coorcon>Coordinate conversion service <option value=coortran>Coordinate transformation service <option value=covveccon>Coverage/vector conversion service <option value=imgcoorcon>Image coordinate conversion service <option value=recti>Rectification service <option value=orthorecti>Orthorectification service </select> </td> </tr> <tr> <td width=114 align=left>Service Type Version</td> <td align=left> <INPUT type=text name=stversion size=30 value=<?=$row[stversion]?>>

<font color="#FF0000"> </font> </td> </tr> <tr> <td width=114 align=left>Price</td> <td align=left> <INPUT type=text name=price size=30 value=<?=$row[price]?>> <font color="#FF0000"> </font> </td> </tr> <tr> <td width=114 align=left>Availability</td> <td align=left>


102

<INPUT type=text name=availability size=30 value=<?=$row[availability]?>> </td> </tr> <tr> <td width=114 align=left>Process Time</td> <td align=left> <INPUT type=text name=processtime size=30 value=<?=$row[processtime]?>> </td> </tr> <tr> <td width=114 align=left>Reputation</td> <td align=left> <INPUT type=text name=reputation size=30 value=<?=$row[reputation]?>> </td> </tr> <tr>

<td colspan=15 align=center> <INPUT type=submit value="Save"> <INPUT type=reset value="Reset"> <INPUT type=button value="Return" onclick="history.back(-1)"> <INPUT type=button value="Query" onclick="qeury.php">

</td> </tr> </table> </form> </center> </body> </html>

D.7.4 s_update.php � Save edited service information in database

<? // Connect database include "p_config.php"; // query for update $query = "Update sid2 set title='$title',ose='$ose',servicetype='$servicetype',stversion='$stversion', price='$price', availability='$availability', processtime='$processtime',reputation='$reputation' date=now() where sid=$sid"; $result=mysql_query($query,$db); // Close database mysql_close($db); echo ("<meta http-equiv='Refresh' content='1; URL=main.php'>"); ?> <center> <font size=2>edited successfully</font>

quality focused service registry development in service ... › librarywww › papers... · quality...

Documents