It is envisioned that the XML/Web Services based enterprise information architecture for the Police Service constitutes a three-tier architecture, as it is shown in Figure 1.

• Information and data stored in local police forces and in the Police National Computer (PNC), as well as those provided by other relevant government agencies (as business partners), form the core information assets for the Police Service. Such data and information are accessed via a wide rage of enterprise services.
• The Police National Network (PNN) and Criminal Justice eXchange (CJX) provide a secure/network backbone connecting the end users to the enterprise information base. Other middleware and service components in the middle tier offer information/service directory, switching and binding, security, and logging services.
• Police Users are the primary users accessing the enterprise information base using desktop computers and mobile devices. The public will soon be able to access non-confidential information via the Police Portal.

XML has been widely adopted internationally as the lingua franca for data interchange between computer systems; its impact on current and future development in all public and private sectors world-wide is enormous. In the UK, XML has been adopted as the basis for data standard and data interchange in all government ministries and agencies, through the e-Government Interchange Framework (e-GIF) [2]. Web Services, as it is defined by the W3C, is a software system identified by a URI whose public interfaces and bindings are defined and described using XML. As a result, its definition can be discovered by other software systems (as service requestors). These systems may then interact with the Web Services in a manner prescribed by its definition, using XML based messages conveyed by internet protocols [3][4][6].

The XML/Web Services based enterprise architecture provides a loosely coupled (and therefore more flexible) yet robust environment, that complies with the Information System Strategy for the Police Service. With such architecture, service requestors do not have to worry about the location of information assets and enterprise services requested, nor the operating systems/ programming languages/component models used to create or access these enterprise services. It is, therefore, ideal for integrating, modernizing and re-engineering Police IT systems.

Convergence of different system integration and re-engineering models that are currently deployed in the Police Service in the UK, to the XML/Web Services based enterprise architecture, is considered an important step towards the Information System Strategy for the Police Service. Different migration strategies may be adopted by each individual police force as part of its system re-engineering and modernization process, taking into consideration its existing system architecture, legacy application portfolio and on-going service development.

• Service publication using WSDL. This includes definition of enterprise services as a set of network endpoints or ports (which associate an address with a specific binding), and definition of messages using data types defined in the CorDM. Messages are grouped into operations, which are further mapped into a portType with a binding. Two WSDL primitives, request-response and solicit-response, are currently applied in the pilot project in the Metropolitan Police Service. The former is used for service request and request acknowledgement, and the latter for service delivery. The other two primitives, i.e. one way primitive and notification primitive, will be added when other messaging exchange patterns (MEPs) are implemented.

• Extending SOAP messaging, and making full use of its potential as a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized and distributed environment.

3.2.2 Web Services: registration, publication, and discovery

• Publish PNC registers its current services, adds new services, and issues its entity list to its partners and users;
• Find The PNC users (as service requestors) interrogate the PNC UDDI Registry, and discover the Web Services provided in the PNC, or by its partners;
• Interact The PNC UDDI Registry specifies how a service requestor connects to and interacts with the Web Services provided in PNC, and the associated access control and security requirement.

3.2.3 From data gateway to XML/Web Services based enterprise architecture

Figure 6 Centralized and regional data centres

1. To serve as a data gateway and/or meta-data centre, in which an entry in the object base points to the physical location of a specific entity in a local police force, or in the Police National Computer. In other words, the data centre provides some of the functionality of an UDDI registry, by providing the location information of the requested service/entity to service requesters (Figure 6);
2. To facilitate intra-legacy application data/information exchange by providing a standard data structure (which in most cases conforms to CorDM);
3. To act as an intermediate stage for system re-engineering, in the same way as using UDDI Registry as an intermediate for system re-engineering (Figure 5).
4. To provide intelligence and investigation services for the police forces, using data marts and data warehouse features to process and mine the entities and abstracted data stored in the object bases.

• Replacing and upgrading a) with UDDI registries, and extending the services by introducing advanced search and query capabilities. By converging the data gateway or meta-data centre service provided by different object bases, to a standardized UDDI information model (which conforms to CorDM), the service/entity directory service could be extended beyond the local and regional boundary, and become part of the enterprise directory. The rich services provided by the UDDI, such as the service type registration, white pages, yellow pages, and green pages, will be valuable for service discovery.
• It would be ideal to automatically populate a UDDI Registry in the enterprise, and automatically update the registered entities, as what has been implemented in the object bases. This will be discussed in more detail in Section 4.
• Feature b) can be replaced using the WSDL and SOAP messaging.
• Feature c) is still valid, for the same reason as is summarized on earlier in the paper (and Figure 5).
• Feature d) should remain as a valuable enterprise service, providing intelligence analysis and data mining functionality to the service requesters in the police forces. It remains as an open question whether it is necessary to pull the data into the object bases (as data warehouses) on a regular basis, so that data mining can be executed efficiently on such "snap-shot" data, or it is achievable to pull the distributed data into a data mart or data warehouse at run-time using SOAP messaging. This may largely be dependent on the scalability of SOAP messaging, which has not been fully addressed in the Web Services Architecture Working Group.

The Web Services Architecture Working Group (WSA WG) has published the Web Services reference architecture, which includes the basic architecture and extended architecture [3][4][6]. The Web Services Architecture places into relationship various components and technologies that comprise a Web Services "stack" or functional implementation. While valid implementations may include subsets or parts of the stack, they must at least provide the components defined in the basic architecture. Components and technologies that extend the basic architecture are represented within the extended architecture.

• Basic Architecture

• Extended Architecture

Some of these features, such as asynchronous SOAP messaging have been implemented in the various projects in the police forces such as the Metropolitan Police Service. Reliable SOAP messaging was implemented in our pilot projects with acknowledgement from the service providers, and using caching at the messaging components. Other advanced features, such as several messaging exchange patterns, are planned to be implemented in later stages of these projects.

A number of issues have been identified in our projects, which we believe have not been fully addressed by WSA WG. We summarize these issues as follows, as comments to the Web Services Architecture published by WSA WG [3], and as recommendations to the Web Services software developers/ manufacturers:

Messaging Exchange Pattern (MEP) An MEP is a specialized form of feature that describes a generalized pattern of message exchange between two services [3][4][8][9]. We found that the MEPs published by WSA WG are not comprehensive enough to cover some of the messaging patterns in our implementations. For instance, issues emerged in one of our projects that some or all of the following MEPs would be needed for the advanced features designed in the system:

• One-to-many messaging
• Broadcasting and multi-casting messaging
• One-request-multiple-responses messaging (ORMR) or multi-request-one-response (MROR) messaging
• Cascading messaging

We believe that some of these, called the composite MEPs, could be constructed by using a number of primitive MEPs or other composite MEPs. It is suggested that WSA WG look into the issues. If it is allowed to construct a MEP from other MEPs, rules should be specified as part of the Web Services Architecture.

Message authentication, confidentiality, security, and request/access control There exists a comprehensive security and confidentiality marking scheme covering all the enterprise services/networks in the Police Service, as well as all the entities and information stored in the Police IT systems. We believe that SOAP does not currently provide adequate message authentication and confidentiality features. We also identified that the security issue of Web Services needs to be addressed. Furthermore, request/access control should be enforced by the service provider before responding to a service request, ensuring that the confidential services and information would only be sent to the adequately "vetted" service requestors. Such an issue becomes even more challenging if other MEPs such as cascading messaging are permitted in the enterprise architecture.

Private UDDI registries We foresee two types of UDDI deployment scenarios in the Police Service and the CJIT community: 1) Internal Enterprise Application Integration UDDI - a secured UDDI Service Cloud inside the Police intranet [i.e., the Police National Network (PNN) and Criminal Justice Exchange (CJX)], which allows applications in different police forces, PNC, and other "vetted" partners to publish and find services. 2) Portal UDDI - the UDDI registry inside the PNN/CJX, but it allows external users to find operations on the registry that are accessible to the public [7].

Populating and updating UDDI registries As the enterprise services for the police forces could be highly time-critical, populating and updating the UDDI registries automatically needs to be implemented, by either "push" or "pull" deployment strategies.