The Prototype was built on a Windows 2000 and .NET Platformwith a SQL Server database. All three applications available in the Prototype — Dog Licensing, Contact Repository, and Parcel Transfer Verification Check — used the gBIZ framework to authenticate users and manage profiles that defined individual user access to applications and features.
Building the Prototype on these common Internet technologies created a system with a low barrier to access — users required only a PC with an Internet connection and a web browser. No special hardware, software, or installation was required. This level of technical infrastructure was found to be universally available and not an impediment to use.
This set of common technologies also simplified the development process by starting with the simple requirements that the system be accessible over the Internet and require no special software for access. This decision provided a starting point for restricting the scope of the Prototype to a system that could be built within the constraints of the project while providing suitable functionality for evaluating the new business processes. The guiding design principles were as follows:
-
All user access should be available via a standard web browser.
-
All applications should run within the Prototype system.
-
The system should be self-contained and not integrate with existing production systems.
The Prototype’s user access control system increased user confidence in conducting G2G business using Internet technologies. Accounts and access rights to the Prototype and its applications were managed by a role-based access control system. Users logged into the system once using a single user name and password and were then able to access all appropriate applications. The Prototype used the roles to manage the applications available to individual users on their home pages.
While the Prototype was secure within the scope of the project, a production level State-Local Gateway would require much more attention to other areas of security such as financial transactions, data sets that have high security requirements, account maintenance, system availability, and client access. These different production level characteristics contain their own complex security requirements, which require careful planning, testing, policies, and deployment for continued ongoing operation.
Two of the Prototype’s design goals — make it easy for users to sign-in to access applications and where necessary, allow data to be shared between applications — required an integration approach to design and implementation. To keep development as simple as possible, each application made use of the common sign-in and access control system provided by gBIZ. This integration allowed users to use a single username and password to access the Prototype and its applications while reducing the amount of software that had to be developed. This made the development process more manageable within the project resource constraints.
In keeping with the project’s aim to simulate a real environment for local governments and state agencies, the Prototype applications were not all developed by the same corporate partner or based on exactly the same suite of technologies. CGI and Keane Inc. used different environments to develop their respective applications, but specifications for integration were shared among the development teams to ensure smooth integration when all the applications were completed. CGI designed and developed their applications on the gBIZ framework built on the Microsoft .NET 1.0 whereas Keane used the Microsoft .NET 1.0 environment directly to develop the Dog Licensing Application, but did not use the gBIZ framework. After completion of the Dog Licensing Application, Keane integrated it into the gBIZ framework.
The Contact Repository Application, which managed contact information and made it available to all prototype users through a Contact Directory allowed some users to search and view contact information while others had rights to change and manage the information. This required that data be shared between the Contact Repository Application and the accompanying Contact Directory. This was accomplished by developing both applications to access the same database. The sharing of the same database was a simple way to integrate the applications made possible because both applications were hosted on the same server with direct connectivity to the database system.
These two approaches to application integration worked well within the scope of the Prototype. In the development of a production level State-Local Gateway there would be a different set of constraints that affect the integration techniques and technologies used. The Prototype integration was also simplified by the fact that all software development teams used a common web application infrastructure of .NET, SQL Server 2000 and Windows 2000 Server.
The use of a single web application architecture may not be available in a production level State-Local Gateway. Applications may be developed by different companies with expertise in deploying different architectures. Preparing to develop a production level State-Local Gateway will require developing an integration architecture that defines how applications from different vendors and sources can be integrated into a State-Local Gateway.
© 2003 Center for Technology in Government

