Enabling Collaboration amongst Multi-Country Public Administration Systems by Employing the Web Services Paradigm: The Case of Registration of a New Company Prof. Konstantinos Tarabanis University of Macedonia, Egnatia 156 Str. Thessaloniki, Greece. Tel: +30 310 891578 [email protected] Ioannis Magnisalis University of Macedonia, Egnatia 156 Str. Thessaloniki, Greece. [email protected] Abstract In this paper we present our initial work1 related to the implementation of cross-country public service provision in the European Union. Conducting e-government transactions in a multi-country setting and in a transparent as possible manner for the citizen has proven to be a complicated task from both the conceptual design and technology implementation points of view. In this paper we present initial attempts in implementing such Public Administration services by employing the Web services paradigm with XSLT, WSDL, XML schemas and UDDI Registries Using the case of a new Italian company wanting to set up a new business in Greece, we have tested this approach and the initial findings are presented.

1. Problem Definition In February 2001, the EU working group on egovernment came up with a set of indicators that could be used for benchmarking the e-government maturity and readiness in all 15 member countries [1]. Two subsets were defined, the first consisting of services addressed to the citizen while the second to the business. More specifically a list of the later follows: 1. Social contribution for employees (4) 2. Corporation tax: declaration, notification (4) 3. VAT: declaration, notification (4) 4. Registration of a new company (4) 5. Submission of data to statistical offices (3) 6. Customs declarations (4) 7. Environment-related permits (incl. reporting) (4) 1

This work has been partially funded by the European Commission under the project EU-Publi.com, IST-2001-35217

Vassilios Peristeras United Nations Thessaloniki Centre, 25D Koletti Street, 54627 Thessaloniki, Greece. Tel. +30 310 530825 [email protected] Nickolaos Kouiroukidis University of Macedonia, Egnatia 156 Str. Thessaloniki, Greece. [email protected] 8. Public procurement (4) The number in brackets indicate the stage of egovernment feasible to be achieved, the (4) standing for “Transaction: case handling; decision and delivery (payment)” and the (3) for “Two-way interaction: processing of forms, incl. authentication”. In the work described in this paper we are focusing on the fourth indicator trying to achieve the functionality defined by stage (4) as presented above. However our aim is broader in that we are working on achieving “transaction” type of service not only at a national level but are exploring to facilitate “transaction” between administrations belonging in different EU countries [2]. A strong drive towards this direction comes mostly from the goals of EU integration, the creation of a single market, free people movement and the vision of a common “European Administrative Space” [3]. In order to deal with Public Administration service provision across countries, in addition to the integration issues that exist at the national level (IS integration, reengineering of existing processes, etc), additional inconsistencies arise from: a) different administrative processes (pre & post conditions and consequences), b) different legal frameworks, c) different semantics (different meaning for the same word, different words for the same meaning), d) different language per se. In the following example scenario we show specific difficulties arising from offering transaction type services between administrations belonging in different EU countries: An Italian manufacturing company decides to establish a branch in Thessaloniki, Greece. They ask the Prefecture (responsible PA agency for issuing permission) to be informed on the process and the certificates needed.

During the process a series of inconsistencies occur regarding the certification needed: • A certification needed by the Greek Authority does not exist as such in Italy. • Another certification required in Greece is part of a broader certification in Italy. • In a third certification the meaning of a term is not the same in both countries. • The pre-conditions and the consequences for startingup a manufacturing entity in Greece are different than those in Italy. The aim of our work is to provide a transparent system acting as a broker between the two administrations that will automatically handle the above-mentioned inconsistencies or inform for the part of the process that will demand human involvement.

2. Approach In our approach we try to handle these inconsistencies with the employment of XML schemata. Our intention is to create either commonly agreed upon and accepted XML descriptions for concepts in the domain of Public Administration or to enable translations, mappings, correspondences amongst those that have not been commonly agreed upon. These schemas will be designed as specializations of existing XML and derivative XML (e.g. ebXML) schemas. Further to this, the Web Service paradigm will be employed to realize service provision [4]. Web Services can be employed in a variety of cases already familiar to human users: querying of databases, catalogs, digital libraries, and other types of information repositories, searches and classification services provided by portals, business-to-consumer (B2C) transactions, business-tobusiness (B2B) transactions, etc. It is worth noting that Web Services are not limited to the two-party, client-server approach most commonly used. Web Services can involve any number of parties, with complex patterns of interaction amongst them. For example, a business-to-business transaction may well involve a buyer, a seller, a financer, and a shipper. The requirement of service transparency to the user is another reason for our architectural choice of Web Services for Public Administration service provision.

3. Description of the scenario In this section we present in the form of a sequence diagram (see Figure below) the example scenario that has been implemented at this stage. The roles in the scenario involve: 1) the Customer, in this case an Italian company that would like to set up a new company in Greece and more specifically in the Prefecture of Thessaloniki,

2) the Greek Gateway offering one-stop Public Administration services as well as communicating and brokering services amongst 3) Greek PAs, in this case involved in new business registration, 4) the Italian Gateway providing a similar access point to Italian PAs. As shown in the Figure below, the UDDI Registry plays a central role in this scenario [5]. The UDDI Registry is used to publish and thereafter find and utilize the Web Services that participate in accomplishing the scenario. For clarity we do not present all the calls to the UDDI Registry. The details hidden constitute the standard sequence of transactions concluding at the point the Service Requester is able to call the desired service. This sequence comprises of: a) the service provider publishing the service, b) the service requester finding the service, and c) binding to the service provider to use the service in demand. Whenever an arrow in the sequence diagram goes through the Registry the aforementioned procedure. A short description of the whole scenario follows: 1) An Italian company wishes to start a new business in Greece and accesses the Greek gateway, which provides this as a service. The foreign company will receive the “New Business Certificate” as a proof of its successful completion. 2) The Greek gateway processes the initial data provided by the Italian company (e.g. Company Name) and performs background checking of this data with the Italian Gateway. The contact is done of course though discovery of the relevant service in the UDDI registry. 3) The Italian gateway verifies the data provided by the Italian company. 4) The Greek gateway looks up the Certificates required by Greek law and Public Administration procedures for the issuance of a “New Business Certificate”. 5-6) The required Greek Certificate types (e.g. in the form of XML schemas) are sent by the Greek gateway to the Italian gateway with a request to map these Certificate types to relevant Italian Certificate types covering all the elements (i.e. evidence) the Greek Certificates include. 7-8-9) The Italian gateway assembles a set of Italian Certificate types that cover the elements of the Greek Certificate types. The full logic employed to perform the mapping is a topic of further research. In our current example, we use perform correspondence amongst XML element types based on widely accepted core elements taken from ‘Dublin Core’ [6] and enhanced following the directions proposed by the office of “e-Envoy” of the “UK ON LINE” project [7]. 10) The Italian gateway provides the Italian Certificates (i.e. the instantiations of the Italian Certificate types for the company at hand) to the Greek gateway.


 

 
  ! "


11) The Italian Certificates are ‘parsed’ in an attempt to crosscheck that these Italian Certificates actually cover the evidence requirements needed by Greek Authorities. 12) Now, the checked Italian Certificates are sent to the Greek Public Administration agency that will finally store the Italian Certificates and use them to issue the Greek “New Business Certificate”. 13) A notification is sent to the Greek gateway that the “New Business Certificate” has been issued and provides the location where it is stored by the Certificate issuer. 14) The Greek gateway sends the Certificate to the Italian company.

4. Architecture of the system C ustomer

Gr eek Gateway

PA/Leg acy ISs

UDDI Reg istr y

Italian Gateway

PA/Legacy ISs

IBM web services toolkit to perform searches in the UDDI registry. Names of the methods that are exposed from a specific service are described in the element of the WSDL documents. To produce the WSDL files wsdlgen tool was used from IBM’ web services toolkit. This tool generates the requested WSDL files for a Java class or Enterprise Java Bean by specifying the URL where the service resides and the URL where the generated WSDL files will be hosted. Also, the proxygen tool from the same toolkit was used in the client side to produce the necessary stub infrastructure for the client to be able to access the WSDL files and the offered services. For XML processing DOM parsing was used from Xerces-j. For XML transformations Xalan-j from the Apache project was used. These APIs were used whenever in the service implementation was necessary to parse an XML document or to transform it into another XML or HTML document for the needs of the specific scenario.

1 : StartUp Serv ice( ) 2 : R equ est Pro of for Italian Co mpany ()

Architectural view CERTH

3 : Pr oof fo r Italian Co mp any Ex istence()

2/7/2002

4: Sear ch f or Greek C ertificates( ) 5 : Greek Certif icates() C ER TIFIC ATE

Legacy IS

Italian Gateway

6 : R equ est Map Greek to Italian Certificates() 7: Fin d I talian C ertificates()

Certificate Template

PA

8: I talian C ertificates()

9 : M ap Greek to Italian C ertificates() C ER TIFIC ATE

1 0: M ap ped C ertif icates()

1 1: Process Italian Cer tificates( )

Service Provision Customer

Legacy IS

Greek Gateway

Certificate Template

1 2: Sen d Valid C ertif icates() 13: Issue n ew Certificate( ) 14: Pro vide C ertificate()

The architecture is based on the ‘Web Services’ paradigm Using web services deployed and registered in a UDDI registry gives flexibility to the whole service deployment since new services can be assembled from constituent sub-services (e.g. in our scenario, the integration of Italian and Greek Public Administration services). We will expand on a specific point of our scenario so as to better clarify how the Web Services model is employed. When the Greek gateway finds out the Greek Certificates types needed in order to proceed with the issuance of the ‘New Business Certificate’, it requests mapping of them. To achieve this, it asks for a Service that provides relevant Italian Certificate types and their location from the UDDI registry. The process of publishing, finding and using a service can be visualized and summarized in the ‘service provision’ element of our Architectural picture. In the following we describe the technical elements of the system. The implementation uses the services of IBM’s UDDI Registry. Any client uses the uddi4j API from the

UDDI Registry


 $#% %&'!)(* ,+-  .
(*/(0 

5. Demonstration of part of scenario A part of our scenario is demonstrated here. Two screen shots (Fig.3) are provided. The first is the entry to the Greek service gateway/broker. The second corresponds to the Certificates types that are required by Greece (and more specifically the Prefecture of Thessaloniki) (see step 4
of  our 12 sequence   34diagram). .(5! Lastly the ‘Start-Up’ Certificate returned to the Italian Company is presented in HTML format (Fig.4).

PA


 768 %(  (9;:=- 5("
?
 (*3
A@B%CEDFGE( This has been generated using a XSLT document that transformed the XML Certificate (Fig.5) in HTML format.


 H2 >I ("
0
 (*E
KJ-CEDL  "(

We shall explain in more detail the technical aspects related to the last two Figures, which are a representative part of the whole scenario. In order for a new business registration certificate to be issued, we assume that the Greek public administration requires Greek Certificate Types (valid in Greece) structured as XML documents containing particular evidence types. In our scenario these certificate types are sent as parameters in a SOAP message to the Italian gateway using the uddi4j PI. This API allows every potential ‘service requester’ to call the ‘service provider’ after searching and finding a service in IBM’s UDDI registry a) by the service name, or b) by the name of the business that implements that service, or c) by the



unique identifier of a messaging interface (TmodelKey).

In our case, we search for a service provider that can provide Italian certificate types in XML format taking as input Greek XML document types and covering all the elements (eg evidence types) the Greek certificates consist of. We assume that correspondence between element types contained in public administration certificates can be achieved. To be specific, this search is done by a service interface, or more accurately by TmodelKey. The result of this search returns the Italian gateway as the appropriate service provider. At this stage, we extract from the registry with the proxygen tool the location of the service and the manner the Greek public administration can call it (i.e. the name of the ‘remote method’ and the sequence of its necessary parameters). The above information is contained in the WSDL files that the Italian gateway has already registered with the wsdlgen tool and some methods of the uddi4j PI specific to this job (eg setOverviewURL, setOverviewDoc, setBindingTemplateVector). This is done at the moment of service ‘publication’. After successfully discovering and contacting the Italian gateway (Step 6 of the sequence diagram), the Greek public administration receives a SOAP message (Step 10) containing the Italian certificates covering all the elements the corresponding Greek certificates contained. What remains for the Greek public administration is to check that the certificate just received are sufficient. This is done with the DOM API, which is oriented towards XML document parsing and validation. After that, the Italian documents are forwarded to the Prefecture of Thessaloniki, which is the responsible organization for issuing the new business registration certificate. This PA authority generates the new certificate in XML format (see Fig.5) after parsing some elements needed (eg company VAT number) from the Italian XML documents, again using DOM. Finally, the Prefecture of Thessaloniki transforms this XML Certificate to HTML format (see Fig.4) aided by XSLT methods from Xalan-j API.

6. Conclusion Towards the direction of implementing cross-country public administration service provision, the case of an Italian company wanting to set up a new business in Greece has been presented. Employing technologies linked to the Web services paradigm, our work demonstrates the feasibility of this approach. Furthermore, this approach holds advantages over other implementation alternatives. Besides simplicity of implementation, the advantage of modularity enables the “repackaging” of existing Public Administration services into new, composite Public Administration services for the e-government era.

1. European Commission, List of eEurope Benchmarking Indicators, 2001, available at http://europa.eu.int/information_society/eeurope/benchmarking/i ndicator_list.pdf, as accessed in 30 June 2001 2. Tarabanis, K. and V. Peristeras. Towards Interoperability amongst European Public Administrations. In 13th Database and Expert Systems Applications Conference (DEXA).2-6 September, 2002. Aix-en-Province, France. 3. Peristeras, V., T. Tsekos, and K. Tarabanis. Realising eGovernment: Architected/Centralised versus interoperable/Decentralised ICTs and Organizational Development. In European Group for Public Administration Annual Conference 2002 (EGPA Conference 2002).4-7 September 2002. Potsdam, Germany. 4. World Wide Web Consortium, Web Services Activity, 2002, available at http://www.w3.org/2002/ws/, as accessed in 2 Aug. 2002 5. UDDI.org, UDDI Executive White Paper, 2001, available at http://www.uddi.org/pubs/UDDI_Executive_White_Paper.pdf, as accessed in 8 Aug. 2002 6. Dublin Core Metadata Initiative, Dublin Core Metadata Element Set, Version 1.1: Reference Description, 1999, available at http://dublincore.org/documents/1999/07/02/dces/, as accessed in 2 Aug. 2002 7. UK Office of e-Envoy, e-Government Metadata Standards (eGMS) -Draft for consultation, 2002, available at http://www.govtalk.gov.uk/documents/eGovt_Metadata_Standard_v0_2.pdf, as accessed in 8 Aug. 2002