Vuoi ricevere uno zainetto? Clicca qui
  |
Building E Government Web Service
by ManuelaCirronis, FabrizioGianneschi, July 2005
Building an eGovernment web service using Open Source toolsAbstract. This article describes the work done, using only Open Source and free tools, to implement an E-Government infrastructure that complies with state-of-theart of Italian Public Administration. In particular, the interaction between a client system and Registry-Office has been simulated through the request of certificates that comply to what the Department for Public Administration recommendations assert in the context of the ex Project A9. Even if only as a prototype, the simulation has also concerned the Protocol process and digital signature of requests to guarantee the legal value of documents produced. This work has been done in the context of the Plan for Territorial Development stipulated by Atlantis S.p.A. with the Department of Productive Activities. Keywords: E-Government, Open Source, Cooperazione Applicativa, Application Integration, Domain Gate, Porta di dominio, Java, J2EE, Web Services, Axis 1. IntroductionThe E-Government Action Plan [1] dated June 2000 and Legislative dispositions about administrative documentation (DPR 445/2000) [2] documents can be both considered as cornerstones of the technological development process of Italian State. These two acts have been very important for the innovation process of the Italian Public Administration (PA) and their positive effects have been tangible in the years following their publication. The Plan shaped a large part of the IT Italian landscape, stressing the concepts of interoperability and cooperation between the different Italian PA’s. It describes some basic concepts, like the policy to access the PA network, that should be implemented by using the application-gates with certified and secure systems implemented using standard interfaces exporting services. The Plan does not concern the criteria to design and implement the IT systems of each PA; this allows a high degree of local autonomy and does not prevent the progress of cooperative process. In this respect, the Plan introduces the concept of domain, defined as a collection of data, resources and expertises of a PA and characterized by well defined boundaries. Moreover, each administration is responsible inside its domain and must cooperate with the others through standards and interfaces as defined by the Plan. The National Network has therefore been organized as a federation of domains implemented through interconnection of peer networks to shape a so called “Federate Network”. The DPR 445/2000 asserts that whenever is possible to check their attributes, to verify their origin and integrity, digital documents are as legally valid as paper ones. The A9 project Closed on December 2002, the Project A9 [3], pilot project of the Department for Public Administration, has concerned the first implementation to the Public Registry following the requirements described in the E-Government Plan about application integration. In this regard, specific XML formats for exchange between applications, registry-office data and the certificate requests have been defined. These formats have been used as basis for our research and simulation work. 2. Technological viewAs already mentioned above, the norm does not say which technologies the PA must adopt. The state-of -the-art technologies must therefore be considered at the moment of implementing the IT systems oriented to the application integration. As specified in some attachments of the norm, it is made clear that all the systems have an architecture similar to the distributed architecture that cooperates by using Web Services. Consequently, the domain-gates are IT systems exporting Web Services that allow the PA to provide IT services and to query other systems. The list of available services can be accessed by UDDI registries that are published by the relevant PA or third-party administrations. These systems, even if not specified by the norm, use the information passing through the domain-gates to feed their own internal processes often based on workflow systems, e-mail and messengers. E-Government Envelope The main format, described by the norm for the data exchange in the application integration context, is called E-Government Envelope. This is a SOAP message with Attachments (SwA) composed of two parts:
 Fig. 1 –E-Government Envelope, as specified in the E-Government Plan With regard to the latest section, it is possible to include (optionally) in the body as attachment a third section complying with the PKCS#7 standard and to add all the documents we want to have a legal value. 3. Technical solutionsA PA that wants to implements an IT system oriented to the application integration has two choices: to use a commercial solution or to choose the Open Source way. Commercial solutions Since 2002, all main IT companies (some of which have contributed to the Plan writing) have started to provide E-Government commercial solutions that comply with the norm. We analysed the solutions provided by Oracle (deeply), Microsoft and SUN, and appreciated the architecture layout, the use of established and stable products and, finally, the total compliance with the standard. Last, but not least, involvement in the norm writing allowed those companies to gain an overall competitive advantage with respect to the Open solution, as we will see later. This fact has been highlighted by the availability of pre-configured components suitable for the E-Government Envelope and for the different XML format for applications. Open Source solution Not all the Administrations acquire a commercial solution. This is either because they cannot afford it or due to a specific strategic choice. Many of the technologies needed to implement the E-Government Plan have already been available in Open Source for a long time and can be considered mature and stable. Among the technologies involved, we can list the following:
4. Implemented solutionAfter having verified both the availability of suitable commercial solutions and the feasibility of an alternative solution, completely based on Open Source software, we decided to address our research towards the implementation of a prototype. Requirements and Use Cases The prototype aimed to simulate the application integration between two domain-gates, assuming an information exchange between a Municipality and a Registry-Office belonging to different domains. The XML document format, used for data exchange, was one that was suggested by the A9 Project. To make it simpler, the data exchange was implemented as synchronous, via RPC. From the technical point of view the prototype was built using:
The Use Cases analysed were the following: A. Request of the Family certificate for a given Person. B. Request of the Owners list for a given living address. The module simulating the Registry Office worked in this way:
The simulator has been implemented in Java technology (J2EE) given the availability and robustness of the Open Source software for that platform. The software packages used have been the following:
5 ConclusionsThe research work continued until the implementation of most, but not all, parts of the simulator, since this was not the aim of the research. Instead, the aim was to understand if the Open Source software was a valuable choice with respect to the commercial solution to implement the E-Government Plan. From a technical point of view, we can draw up the following conclusions: in this context the Open Source software has proved to be a valuable and flexible solution considering that the technologies used are stable (web development and digital certificates) but are also continuously progressing (web services). Moreover the zero cost licences and the lighter hardware requirements of, for example, GNU/Linux systems can surely be a competitive advantage. On the other hand, the compliance with the norm has pointed out some problems; first of all, the fact of being compelled to re-write from scratch all the creation and validation logic of the application document, complying with the examined Project. Also the management of the E-Government envelope pointed out some problems since we did not have enough information. As already stated, the commercial solutions are more competitive on this point and have pre-configured modules suitable for the Italian situation. In addition, not all the administration could have enough technical know-how to manage and develop an entire Open Source solution. The documentation available is enough (especially for Java) but is not so rich as the documentation provided by the commercial solution in the E-Government context. To summarize, we conclude that the Open Source can have a major role in the EGovernment scenario, especially in cases of problem domains or architecture that are not too complex or whenever the administration is provided with a good level of tools and technical know-how. References
|