Figure 1. A Web services scenrio.
Figure 1: Web services scenario
Keywords: Web services, Web services composition, Quality of Service
Biography
Michael Hu is the Lead Solutions Architect in the Police Information Technology Organisation (PITO) in the UK. He is responsible for the information and technical architecture of the Police National Computer (PNC) Modernisation Programme and the Information System Strategy for the Police Service (ISS4PS) Programme. He has a Ph.D on global information systems from University College London, and has been working in the areas including telecommunciation, electronic documentation, information search and retrieval.
In this paper, we discuss the challenge and our experiences of re-engineering legacy police IT systems and transforming them into well orchestrated and co-ordinated Web Services. We use the Web Services Flow Graph (WSFG) to analyse the issues associated with Web Services composition, orchestration, as well as quality of service (QoS).
While QoS composition is to leverage, aggregate and bundle the individual Web services component's quality of service properties to derive the composite service component's QoS, we focus in this papper on QoS factoring, which is to work out a set of sub Web services components that could collectively fulfill the functionalities and meet requirements of the complex process within its QoS bound. We present an algorithm that is proposed for QoS factoring; we also disucss, as a case study, application of the algorithm in an ongoing national Web Services project involving service providers such as the Police National Computer (PNC), the New Scotland Yard, and several other forces in the UK.
1. Introduction
2. Web Services and Web Services Composition
2.1 Web Services Composition
2.2 Web Services Orchestration
3. QoS of Web Services
3.1 Quality of Service Composition
3.1.1 Web Services Flow Graph
3.2 Quality of Service Factoring
4. WEB SERVICES FOR THE POLICE SERVICE AND THE CRIMINAL JUSTICE COMMUNITY
5. CONCLUSION
Bibliography
There exists a wide range of IT systems that have been developed in the last several decades for the Police Service and criminal justice community in the UK. Modernizing and integrating these systems with service oriented XML/Web Services based enterprise architecture formulates part of the national Information Systems Strategy for the Police Service (ISS4PS) [1].
Some pioneering Web services initiatives and projects have been planned and implemented in the last few years, noticeably in PNC, the Metropolitan Police Service (the New Scotland Yard), and other police forces and government agencies. However, it is widely acknowledged that most of these services are built upon the basic Web services architecture [2]. The challenge now is to aggregate these stand-alone basic services into more sophisticated and complex service components. They can consequently be deployed to address more challenging business needs such as crime and intelligence.
In this paper, we focus on transforming and integrating basic service components into well orchestrated and co-ordinated Web services. We use the Web Services Flow Graph (WSFG) to analyze the issues associated with Web Services composition and orchestration, as well as quality of service (QoS).
The rest of this paper is organized as follows. First, in Section 2, we give an overview of Web services and its current status in terms of standardization and development. In particular, we focus on the Web services composition and orchestration. In Section 3, we discuss the issues associated with quality of service, with focus on QoS factoring. In Section 4, we present as a case study the ongoing Web services demonstrator project we have been undertaking before reaching the conclusion in Section 5.
Web Services, as it is defined by the World Wide Web Consortium (W3C), is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format. Other systems interact with the Web services in a manner prescribed by its description using Simple Object Access Protocol (SOAP) based messages, typically conveyed with HTTP with an XML serialisation in conjunction with other Web-related standards [2]. Moreover, composite services can be created by aggregating a number of services, either atomic or composite, by following a certain composition pattern and rules in order to achieve more complex business goals.
In Figure 1, for instance, a service client (b) utilises services provided by service providers D and E. It in turn provides a service to other service clients (e.g, x). In this way, it acts as a Web service aggregator consolidating multiple services (i.e., Web services D and E) and its own service into a new, single service offering (B). The procedure in which a set of services are grouped together, by following well-defined rules and explicitly specified quality and service level agreement, to achieve collective objectives, is called Web Services composition and orchestration.
Web services composition follows the componentized model in the software engineering, in which services formulate necessary building blocks (called Web service components), out of which new services can be created. As it is suggested in Figure 1, Web service compositions may themselves become services, making composition a recursive operation. Service composition provides a mechanism for application integration that seamlessly supports cross-enterprise (business-to-business) and intra-enterprise application integration.
Several specifications have been proposed recently, most notably Business Process Execution Language for Web Services (BPEL4WS, or BPEL for short) for service composition, Web Service Coordination (WS-Coordination) and Web Service Transaction (WS-Transaction) for service co-ordination and transaction respectively. Microsoft, IBM, Siebel systems, BEA, and SAP coauthored version 1.1 of BPEL4WS, which models behaviour of Web services in a business process interaction and provides an XML-based grammar for describing the control logic required to co-ordinate Web services participating in the process flow [3][4]. WS-Coordination [5] and WS-Transaction [6], on the other hand, are part of an extensible framework that are under proposal and standardisation process in W3C, for providing protocols that co-ordinate the actions of distributed applications.
We use Web services orchestration in this paper to cover two overlapping terms, orchestration and choreography, in the literature. Web services orchestration, defines the sequence and conditions in which one Web Service invokes other services in order to realize some useful function, i.e., an orchestration is the pattern of interactions that a Web Service agent must follow in order to achieve its goals [7]. Web services choreography, on the other hand, concerns the interactions of services with their clients/users; it is model of the sequences of operations, states, and conditions, which control how the interactions occur [8][9]. Successfully following the pattern of interaction prescribed by a choreography should result in the completion of some useful function, for example, making inquiry of vehicle registration number, finding out the detail of the registered owner, and his or her accident records, or putting the system into a well-defined error state. Web services choreography permits the description of how Web Services can be composed, how roles and associations in the Web services can be established, and how the state, if any, of composed services is to be managed.
The issues related to publishing an aggregated service, and to advertising collective service capabilities, unified interface, a co-ordinated behaviour, and most importantly, the combined service level agreement (SLA) and QoS, is the main focus of discussion in the rest of paper.
Quality of service (QoS) formulates part of service level agreement that specifies the qualities or properties of a service that each party can reasonably expect and what responsibilities each has in order for the agreement to be binding. In this paper and in our projects, we use the QoS properties introduced in [13], including availability, reliability, integrity, scalability, performance, response time, throughput, security, authentication, privacy .
QoS composition is to leverage, aggregate and bundle the individual Web services component’s quality of service properties to derive the composite service component’s QoS [10][11].
We introduce the Web Service Flow Graph (WSFG) in our analysis of QoS composition [13]. Figure 2 shows the same Web services scenario of Figure 1 with a Web Service Flow Graph. A directed edge between nodes x (as a service client or service aggregator) and A (as a service provider), indicates such a client-provider relationship. The label on the edge (x, A), called the relative visit ratio, is the average number of times that the service provided by A is utilised when per visit to node x. QxA establishes a quantitative measure or upper bound of property of the service that is provided by A, and Qx that of x.
The committed SLA and QoS that x receives and offers subsquientlly to other Web services clients as a service aggregator, as well as the realtionship between Qx and SLA/QoS of other Web services providers or aggregators in Figure 2 can be worked out by using the algorithm introduced in [13].
QoS factoring is opposite process to QoS composition. Given the QoS properties and service-level agreement of a complex process (e.g., x), QoS factoring is to work out a set of sub Web services components which could collectively fulfill the functionalities and meet requirements of the complex process, but more importantly, complete such tasks within the QoS bound and SLA of x.
For instance, in Figure 2, the QoS factoring process of Qx, by taking (2.1) and (2.2) of [13], would lead to QxA and QxB that respectively set the upper bound of QoS property for two sub Web services components a/A and b/B. However, the QoS factoring process for A and B is more challenging, as both a/A and b/B are clients of Web services provided by the provider D.
In the next section, we outline our experience of applying a proposed QoS factoring algorithm in our planning and implementation of complex Web services that involved distributed services provided by different service providers in the police and criminal justice communities in the UK.
Figure 3 presents an overview of the national Web Services demonstrator project for the Police Service and Criminal Justice communities in the UK. The Web Services Infrastructure and UDDI Registry is provided and maintained centrally by the Police Information Technology Organisation (PITO), and service providers include PITO, the PNC, the Metropolitan Police Service (the New Scotland Yard), and several other police forces in the England, Wales and Scotland. Each provider offers its data/enquiry capabilities to other forces and government agencies in the format of Web Services, with a fully committed service level agreement and binding QoS. The following services are currently offered or scoped in the pilot project:
In a typical operational scenario that has been being implemented in the demonstrator project, a suspicious vehicle with the number plate “xxxxxxxxx” has been identified by a police officer in northern England, who launches a formal police enquiry about the vehicle including its registration record, its insurance details, the registered owner’s criminal records (if any) and DNA/fingerprint, as well as checking the vehicle’s movement in the last 24 hours at key points in Scotland. Figure 4 shows the part of the busienss process of the above operational scenario, whereas its WSFG is identical to that in Figure 2.
The QoS factoring of a composite service (e.g., Police Enquiry as x in Figure 2) is to work out a set of Web services components (e.g., A and B) which could collectively fulfill the functionalities and meet requirements of the complex process x within the QoS bound and SLA of Qx. By applying (2.1) and (2.2) of [13], we can work out QA and QB. Simularly, by applying those to other nodes in the WSFG, the QoS bound and SLA of other service components (e.g., D) can be worked out.
By applying the algorithm, we have implemented this Web services scenario shown in Figure 3 and discussed above. Some examples of SOAP messages exchanged among Web services clients and providers in the scenario are given as follows.
The search results (e.g., the retrieved vehicle details) from the received SOAP messages are presented.
In this paper, we discuss the challenge and our experience of modernising and integrating the legacy police IT systems in the UK, basing on the service oriented XML/Web Services based enterprise architecture that are being set up as part of the national Information System Strategy for the Police Service. As more and more police data and services from 52 forces across the country will be published and become available as Web services, we expect the number of services provided, as well as the number of service clients/users and transactions, to expand exponentially in the next few years. The service-to-service interactions and co-ordination will also become more complex and challenging. As the result, it is our objectives to develop rules and national strategy for Web services composition, choreography and orchestration, and to analyse issues relating to quality and service level agreement. We use the Web Services Flow Graph (WSFG) in our analysis; we also introduced an algorithm that is directly applicable for deriving individual sub service components’ QoS from that of a composite service component, in QoS factoring process. We include in the paper as a case study an ongoing national Web Services demonstrator project involving service providers such as the Police National Computer, the New Scotland Yard, and several other police forces throughout the country.
XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.
