In most cases, the organizations and government agencies need the personal information of individuals. The same personal data/information is stored by the different agencies’ diverse systems However; this operation causes technical and economical loads for the agencies and companies. In the model proposed for Turkey, it is recommended that this type of information should be stored in a central location. In addition, this data/information should be interoperable with the agencies and their legacy systems.
In this research, the prototype software called patient registration system was produced. This software is considered to demonstrate the registration procedure of the hospital. Instead of storing the e-citizens’ demographic data/information, this system stores the unique number that is called TCKIMLIKNO that identifies the individuals and stands for abbreviation of Turkish Republic Citizen Identification Number. The unique number TCKIMLIKNO is the part of the MERNIS project and consist of 11 characters. (See details of the MERNIS project in APPENDIX B) The demographic data/information about the e-citizen retrieved from a central location by using a web service and after this operation; only the TCKIMLIKNO data is stored in the system. This operation has been shown in Figure 4.10.
Figure 4.10 Demographic Data Recording
If the e-citizen does not know his/her TCKIMLIKNO, the software provides a functionality to get the needed TCKIMLIKNO via another web service. By this web
service, the user of the software can search the e-citizen’s TCKIMLIKNO by use of specific demographic information of individual as shown in Figure 4.11
Figure 4.11 TCKIMLIKNO Searching
When the button “Sorgula” is pressed then the parameters on figure 4.11 are transferred to the WebMethod which declaration is written below. After the parameters processed, the TCKIMLIKNO information is returned to the client.
[WebMethod]
public DataSet SearchMernisData(string ad, string soyad, string anaAdi, string babaAdi, string dogumYeri, string dogumTarihi)
In the same logic, the VERGINO is retrieved from a central location for the insurance and the billing procedures. In this case, the produced software uses another web service. The user sends citizens’ TCKIMLIKNO and gets his/her VERGINO by use of the software functionality as shown in Figure 4.12.
Figure 4.12 VERGINO Searching and Recording
In figure 4.12, if the TCKIMLIKNO parameter is sent to the WebMethod by clicking the button “Ara” then this parameter is processed by the method and then, the VERGINO information is returned back to the client. The declaration part of this function is written below.
[WebMethod]
public string GetVergiNo(string kimlikNo) {
The purposes of the designed web services are to make a small reorganization for exchanged XML messages, SOAP actions and created WSDL documents between client and server like e-citizen and agency. These web services can be called directly from the other application programs and those programs can use the result XML document/message. In addition, the client browser as shown in Figure 4.13 can directly call the web services.
Figure 4.13 Web Service Introduction Page
When the web service (Maliye.asmx) is called from the client’s browser, the “service name” and its “service method name” are shown in the browser window. Then the web service can be used by just clicking on its service method name, “GetVergiNo”.
Figure 4.14 Web Method of the Web Service Maliye
The web method shown in Figure 4.14 takes the TCKIMLIKNO as a parameter from the client (e-citizen) and gives VERGINO back to the client. The required parameter TCKIMLIKNO should be written in prompt box displayed on the screen. Afterward, if the invoke button is pressed then web method of the web service is processed and result is sent to the client as “XML document (soap response/message)”. This web interface, shown in figure 4.14, uses the same WebMethod GetVergiNo (see declaration on page 47). It means that, after the web services and their methods declared once, and then application programs (Figure 4.12) or web pages (Figure 4.14) can access these web services. This is the one of
Figure 4.15 Web Methods of the Web Service Mernis
The other web service is Mernis, illustrated in Figure 4.15, which is responsible for retrieving and searching the demographic data/information of individuals from a central location. This web service is consisting of two web methods. First web method is the GetMernisData and it is responsible for retrieving demographic information. The interface of this method and its output are shown in Figures 4.16 and 4.17.
Figure 4.16 the web method GetMernisData
The method declaration of the GetMernisData is written below. The TCKIMLIKNO information is received by the method and then demographic information of an individual is returned back to the client as a dataset.
[WebMethod]
public DataSet GetMernisData(int kimlikNo) {
Method implementation (See appendix B) }
It is very important that, the web interface of the GetMernisData (Figure 4.16) is very similar to the method declaration above. There are SOAP request and the SOAP response parts in the web interface. The method parameter (kimlikNo) is placed in the SOAP request part in the web interface, and returned value (DataSet/Schema) of the method is placed in the SOAP response in the interface. It means that the communicated parties (client and server) know the type of the information before the data transmission has been started. This functionality is provided by the usage of the schema technology as illustrated in Figure 4.16. In this figure, the type of the requested/response data specified in schema before the “Invoke” button is pressed.
Figure 4.17 the output of GetMernisData
The figure 4.17 shows the schema output of the method (GetMernisData) in the form of XML document. Since the method (on page 51) returns the dataset in its
declaration, the schema elements are defined as “complexType” and their names are specified as “Table” which encapsulates pieces of data. In the implementation part of the method GetMernisData, the demographic information of an individual are retrieved from a central database and these information transferred to the client as illustrated in figure 4.17. Since the returned value of the method is in the form of XML (Figure 4.17), another application program or a web service can use this XML document. The second web method “SearchMernisData” that is responsible for getting the TCKIMLIKNO that belongs to e-citizen. The interface of the web method “SearchMernisData” and its output can be shown in Figures 4.18 and 4.19.
Figure 4.19 the Output of SearchMernisData
At this point, it is needed to deal with the important part of this research that is SOAP message, shown in Figures 4.20 and 4.21. The term “soap message” stands for the XML messages/documents that interchanged between client (e-citizen) and server (agency). There are two SOAP messages in data interchanging procedure between client and server. First message is SOAP Request (Figure 4.20) and second message is SOAP Response (Figure 4.21).
<soap:Body>
<GetVergiNo xmlns="http://localhost/ThesisDemo/ "> <kimlikNo>321321</kimlikNo>
</GetVergiNo> </soap:Body>
<soap:Body>
<GetVergiNoResponse xmlns="http://localhost/ThesisDemo/ "> <GetVergiNoResult>111111</GetVergiNoResult>
</GetVergiNoResponse> </soap:Body>
Figure 4.21 Soap Response
In Figure 4.20, the TCKIMLIKNO parameter is placed between the <kimlikNo></kimlikNo> tags and name of these tags (TCKIMLIKNO) is used as a parameter in the implementation part of the web service. The method name and its parameter can be shown in the SOAP request. In Figure 4.21, the VERGINO parameter is placed between the <GetVergiNoResult></GetVergiNoResult> tags and value between these tags stand for the “result of web service method” and the result (111111) is sent to the client as XML document. In the model, all data interchanging operations can be realized in the form of extensible and platform independent XML documents.
The produced software is the application example of the proposed data interchange model where the agencies can have diverse systems. For example, the agencies can have different types of database management systems. Besides, the web services that are used in the agencies can have different types of technologies. In addition, the agencies’ software can be produced by use of different types of programming languages. However, the proposed data interchange model integrates these diverse systems into e-government architecture by use of the common standards since the proposed model is independent of the legacy systems used in agencies. By this way, all agencies and diverse systems can speak in the same language and understand each other.
4.5 Assumptions and Limitations