A wide range of IT systems have been developed during the last decades within the fifty-two police forces in the United Kingdom, serving a wide range of users from police officers on duty to the criminal justice community. Modernising and integrating these systems with service oriented XML/Web Services based enterprise architecture formulates part of the national Information System Strategy for the Police Service.

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, partition, and quality of service (QoS). We also include in the paper as a case study an ongoing national Web Services project that is under planning and implementation with service providers such as the Police National Computer, the New Scotland Yard, and several other forces throughout the UK.

The rest of this paper is organised as follows. First, in Section 2, we give an overview of Web services and its current status in terms of standardization and development; we also present the scope and issues of Web service composition, choreography and orchestration, as well as the QoS matrix used in this paper and in our project. Thereafter, in Section 3, we present the Web services infrastructure we have been building up and a national Web Services project for the police and criminal justice communities in UK. Our focus is on aggregating basic Web services provided by different service providers into well-choreographed and co-ordinated, and quality assured composite service to meet the business needs. We conclude in Section 4 with issues and lessons learnt in this project.

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 service 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 [1].

Figure 1 shows an operation scenario (including publication, discovery, service invocation and binding) that produces or utilizes a basic (atomic) Web service. A service is offered by the service provider, an organisation that procures the service implementation, supplies its service description, and provides related technical and business support. The published service description is registered in the Web Services Registrar and is used to advertise the service capabilities, interface, behaviour, and quality. A service client explores and discovers the Web service through the Web Services Registrar, and thereafter, invokes the service provided by sending a SOAP message using the published interface of service.

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 2, for instance, a service client (x) utilises services provided by service providers A, B and C. It in turn could provide the a service to other service clients. In this way, it acts as a Web service aggregator consolidating multiple services (i.e., Web services A, B, and C) into a new, single service offering. 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, choreography and orchestration. 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.

WEB SERVICES COMPOSITION

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 service can be created. As it is shown in the example of Figures 2 and 3, 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 (BPEL4PS, 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 BPEL4PS, 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 [2][3]. WS-Coordination [4] and WS-Transaction [5], 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.

CHOREOGRAPHY AND ORCHESTRATION

While overlapping somewhat, the two terms orchestration and choreography describe two aspects of creating business processes from composite Web services [6]. Web services choreography 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 [7]. 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 World Wide Web Consortium is in the process defining and publishing the Web Services choreography description language that provides a formal, machine-processable language for defining specific choreographs [7][8]

An orchestration, on the other hand, defines the sequence and conditions in which one Web Service invokes other services in order to realise 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 [6][9]. In other words, Web services orchestration refers to an executable business process that can interact with both internal and external Web services. The interactions occur at the message level. They include business logic and task execution order, and they can span applications and organisations to define a long-lived, transactional, multi-step process model [6]. While orchestration always represents control from one party's perspective, chereography concerns more on interaction and collaboration, and allows each involved party to describe its part in the interaction.

QUALITY OF SERVICE COMPOSITION

QoS composition is to leverage, aggregate and bundle each individual Web service component's quality of service properties to derive the composite service component's QoS [9][10]. In this paper and in our project, we use the following QoS matrix that represents a combination of qualities or properties of a service:

Availability is the percentage of time that a service is operating.

Reliability establishes some tangible measure (i.e., the reliability measurement) that a service is expected to achieve.

Integrity includes both (syntactic and semantic) integrity of a service, and the data/message integrity during the service transaction.

Scalability refers to a service's capability of presenting mechanisms or adding capacity as load increases. Such load includes the number of clients (users), transactions, and messages, as well as types of transactions and their complicity, and types of messages and their complicity, etc.

Performance properties include the numeric measurement such as average and percentile response time, network and system latency, mean and peak throughput, etc.

Response time is the time a service takes to respond to various types of requests. Response time is a function of load intensity, which can be measured in terms of arrival rates (such as requests per second) or number of concurrent requests. QoS takes into account not only the average response time, but also the percentile (95th percentile, for example) of the response time.

Throughput is the rate at which a service can process requests. QoS measures can include the maximum throughput or a function that describes how throughput varies with load intensity

Security properties include the existence and type of authentication mechanisms that service offers, confidentiality, non repudiation of requests or messages, and resilience to denial-of-service attacks.

Authentication includes the mechanisms for verifying the authenticity of service clients (and users), as well as the authenticity of the data/message/service provided by a service provider.

Privacy refers to the privacy guarantee that a Web service or service provider offers to its clients, including the client (user) privacy, data privacy, and service privacy.

WEB SERVICES FLOW GRAPH

We introduce the Web Service Flow Graph (WSFG) in our analysis of QoS composition. Figure 4 shows the same Web services scenario of Figure 3 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. In order to achieve the service level agreement and commit the quality of service contract between x and A, we have:

(2.1) Q_xA ≥ V_xAx Q_x

(2.2) Q_xB ≥ V_xBx Q_x

Thus, the upper ground of property of the consequential service of x can be established by combining (2.1) and (2.2):

(2.3) Q_x ≤ min {Q_xA / V_xA, Q_xB / V_xB}

Similarly, we have

(2.4) Q_a ≤ min {Q_A, Q_aC / V_aC}

(2.5) Q_xA = Q_a

(2.6) Q_aC = Q_C

(2.7) Q_b ≤ min {Q_B, Q_bD / V_bD, Q_bE / V_bE}

(2.8) Q_xB = Q_b

(2.9) Q_bD = Q_d ≤ min {Q_D, Q_dF / V_dF}

(2.10) Q_bE = Q_E

(2.11) Q_dF = Q_F

Applying the above algorithm to each property in the QoS matrix, we can establish the QoS composition of x, including its availability, reliability, integration, and scalability, as well as its performance and security properties. In the next section, we outline our experience of applying the proposed QoS composition 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 UK.

Figure 5 presents an overview of the national Web Services pilot project for the Police Service and Criminal Justice communities in 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 Police National Computer (PNC), the Metropolitan Police Service (the New Scotland Yard), and other police forces in the England, Wales and Scotland. Each of providers 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:

Name or Nominal Enquiry

Vehicle Enquiry

Automatic Number Plate Recognition (ANPR)

Fingerprint and Fingerprint Enquiry

Vehicle Insurance and Enquiry

In a typical police enquiry scenario, a suspicious vehicle with the number plate "xxxxxxxxx" has been identified by a police officer in the northern England, who launches a formal police enquiry about the vehicle including its registration record, its insurance detail, the registered owner's criminal records (if any) and fingerprint, as well as trail of the vehicle movement in the last 24 hours in the England and Scotland. As it is shown in Figure 6, this business process can be abstracted into the following complex Web Services, which is identical to that presented in WSFG in Figure 4.

The QoS composition of a composite service (e.g., Police Enquiry in Figure 6) can be worked out by applying the algorithm introduced in Section 2.

To keep its simplicity in this paper, we assume that the relative visit ratio of all the nodes in Figure 6 is equal to 1. For instance, if a numeric figure (%) is used as the reliability measure that each service is expected to achieve, and assuming that

RELIABILITY_A = 99.999%, RELIABILITY_B = 99.999%, RELIABILITY_C = 94.999%, RELIABILITY_D = 99.999%, RELIABILITY_E = 90.999%, RELIABILITY_F = 99.999%,

Following (2.1) to (2.11), we have

RELIABILITY_a = 94.999%, RELIABILITY_b = 90.999%, RELIABILITY_d = 99.999%,

And therefore, RELIABILITY_x = 90.999%.

Another key QoS property in our project is the average and the percentile (95th percentile, for example) response time (second). If we assume that the network latency is zero, and assume the following average response time is provided and supported by each individual service provider respectively:

RESPONSE_TIME_A = 2.5 sec, RESPONSE_TIME_B = 2.5 sec, RESPONSE_TIME_C = 6.5 sec RESPONSE_TIMED = 5.5 sec, RESPONSE_TIME_E = 7.5 sec, RESPONSE_TIME_F = 10 sec

Taking (2.1) to (2.11), we have

RESPONSE_TIME_a = 6.5 sec, RESPONSE_TIME_b = 10 sec, RESPONSE_TIME_d = 10 sec,

And finally, RESPONSE_TIME_x = 10 sec

We are still at the early stage of integrating and modernising the police IT systems in UK, setting up and expanding the national Web Service infrastructure, and developing and publishing new Web services. A wide range of legacy data and systems exist in the police forces throughout the country, re-engineering and componentizing these systems, and putting well-defined Web services interfaces in place for these systems, takes time, effort, and investment from both the central government agencies to local police forces. For the time being, the number of services available in the pilot project is limited; the services tend to be basic, and service-to-service interactions and co-ordination primitive. The detailed information about available Web services in the pilot project that are provided by both local or regional police forces and government agencies as service providers, as well as design/implementation of these services in the national Web services infrastructure, will be presented during the conference.

Due to the above reason, the Web services composition and co-ordination is fairly straightforward at this stage in our project, the QoS composition given as the example in this paper is simple. As more and more police IT systems from 52 police forces across the country will be published and available as Web services (as part of roll-out of the national Information System Strategy for the Police Service), we expect the number of services provided, as well as the number of service clients/users and transactions, expand exponentially in the next few years. Retaining a highly reliable and scalable Web service infrastructure, and providing a set of high quality and high performance Web services would be crucial. Service composition and choreography/ orchestration will become an increasingly important issue, and QoS composition getting more and more complicated. Nonetheless, we believe that the QoS composition algorithm presented in this paper should be sufficiently robust and flexible for coarse-grain QoS estimation and planning of complex Web services. It could also be used as a starting point in us developing more sophisticated algorithms to accommodate more detailed or fine-grain QoS composition and in more complex and larger scaled business scenarios.

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 [11]. 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, and introduce an algorithm that is directly applicable for deriving a composite service component's QoS properties from those of each individual service component. We include in the paper as a case study an ongoing national Web Services project that is under planning and implementation with service providers such as the Police National Computer, the New Scotland Yard, and several other forces throughout the country. Our example shows how the proposed algorithm is used to get the QoS properties include reliability, response time, etc.

1. W3C, Web Services Architecture, Working Draft 8 August 2003

2. Business Process Execution Language for Web Services, version 1.1., www.ibm.com/developerworks/library/ws-bpel/, May 2003

3. S. Weerawaranan and C. Francisco, Busienss Process with BPEL4WS: Understanding BPEL4WS, Part 1" research report, IBM developer Works, Aug. 2002

4. W3C, Web Services Co-ordination (WS-Coordination), Working Draft, September 2003

5. W3C, Web Services Transaction (WS-Transaction) September 2003

6. C. Peltz, Web Servcies Orchestration and Choreography, IEEE Computer, pp. 46 - 52, October 2003.

7. W3C, Web Services Choreography Requirements, Working Draft 12 August 2003

8. W3C, Web Service Choreography Interface (WSCI) version 1.0, 8 August 2003

9. M. P. Papazoglou and D. Georgakopoulos, Service-Oriented Computing, Communications of the ACM, Vol. 46, No. 10, pp. 25 - 28, October 2003

10. Daniel A. Menasce, QoS Issues in Web Services, IEEE Internet Computing, November/December 2003, pp. 72 - 75.

11. Michael Hu, System Integration and Re-engineering Using XML/Web Services, Proceedings of World Wide Web 2003 (WWW2003), pp. 159 - 165.