Main content

Communication Architecture


The Austrian eGovernment strategy requires active participation in creating inter-administrative standardised interfaces and drafting specifications that are effective nationwide as part of the cooperation between the Federal Government, the provinces, cities and municipalities. The results from the working groups are based wherever possible on international norms and standards, or use them as a model.

The typical eGovernment elements that are needed in administrative and back-office processes join together to form a big picture of eGovernment architecture, as illustrated in the following figure. Along with the individual base components, it includes online application modules and components in the citizen card concept. The protocols (specification documents and conventions) used in the communication architecture function figuratively, in the sense of interoperability, as the mortar (interfaces) which holds the components and services together, whereby the individual XML specifications are often built using a layered concept.

The following XML specifications mostly cover the data layer, while the styleguide deals with online forms, online dialogs and web applications, the user interface, layout and processes on a more general level.

XML Entry Protocol

Applications, notices, petitions and other data can be sent to public authorities from diverse systems using many different technical methods. Logging functions for tracking the input of this data into a record system must be made available. This is needed in order to record the successful transfer of data to the electronic input entry point so that confirmation messages can be sent back to the user’s dialog window. The XML Entry Protocol (XML-e) defines a standard for input data, regardless of whether it is sent from a public authority Web form or any other point. The electronic entry point creates an XML data set and stores it on an ELAK or an archive system so that it can be processed by different applications when needed.

The XML Entry Protocol forms the framework for all data which is used as input. This includes the actual data contained in an application form, any log data that is attached to it, as well as any additional data needed internally by the authority.

XML Structures for Business Objects

XML business objects (XML-g) is a recommendation for an efficient procedure for modelling XML structures for communicating between public authorities' applications. The modelling recommendations are applicable to the creation of electronic application forms, amongst other things.

XML Toolbox

The XML toolbox describes a convention containing organisational and technical specifications for the design of XML data structures for electronic application forms. These should build upon the public authority's uniform base elements and types, for which design requirements and the organisational expansion process are described. Furthermore, recommendations for the use of base types and elements are specified in a separate schema. The elements and types defined in the XML toolbox for the input data element of the XML Entry Protocol are used in the implementation of electronic procedures.

XML Structure for Personal Data

The PersonData record is used to uniquely describe a natural and non-natural person through interconnected information blocks called Person, Address, Telephone, etc. It is used in all eGovernment procedures that handle personal data.

Applications that are built on this XML structure can derive it further, make restrictions or expand it as necessary to fit their own requirements. The top level generic Person object defines elements for both natural and legal persons. The elements that define a natural person include such attributes as names, alternative names (e.g., stage names), marital status, gender, place of birth, date of birth, citizenship, etc. The elements that describe a legal person include the full name, alternative names, the legal organisation form, etc.

The schema also includes a description for an abstract Address object with different formats for telephone number, Web or postal address, along with elements specific to each attribute type.


EDIAKT was developed as a standard format for communication between different public institutions (public authorities, courts of law, public businesses). Although all had record management systems that work with electronic records, business cases, and sub-cases including documents, the objects were specific to the manufacturer of the software and not built according to a uniform standard. In the course of further development and increased distribution of ELAK systems, the standard was updated to its current format, EDIAKT II. Data is packaged as EDIAKT objects which are comprised of:

  • meta-data that describes a record, business case, sub-case or document
  • process data for process instances and activities in accordance with the XPDL standard of the Workflow Management Coalition 
  • content of the record, business case, sub-case and document
  • procedure-specific data that may be attached to every type of object

To satisfy the different requirements of institutions using ELAK systems, EDIAKT implemented a hierarchical structure with four layers. At the bottom is the document, which contains the file in its original format. If the file is not saved in a standard format, a document with a standard format must be attached.

One or more documents are wrapped in a business sub-case. This repre-sents the smallest package of objects that can be sent in EDIAKT II. This business sub-case may further be wrapped along with other sub-cases in a higher level business case.

Public authorities that do not have their own ELAK system can still read EDIAKT packages using the free EDIAKT Viewer  The current version can be used to:

  • read all meta-data and process data,
  • show embedded documents and
  • verify digital signatures.

EDIAKT is used for more than just as an interface between different electronic record systems. Increasingly, it will be used for internal data exchange between special applications and archive systems. EDIAKT II, together with the EDIAKT Viewer and EDIAKT Creator, and supplemented by the standard document format PDF/A  establishes the basis for the long-term archiving of records .

In the future, this format could play an increasingly central role for presenting original records that is required for different courts of jurisdiction.

An extension of the existing EDIAKT II specification based on empirical values and/or technical boundary conditions for EDIDOC is in the process of being implemented.

ELAK Transactions

EDIAKT created a uniform standard for the transmission of record information. The ELAK transaction convention takes it a step further and defines special information and electronic record management system functions and interfaces for the automated exchange of EDIAKT packages over Web services. This eliminates the need to export EDIAKT packages, save them temporarily and re-import them after they have been successfully transmitted.

Many public authorities today are already working with electronic record management systems. Inter-administrative information systems, such as central registers, are gaining in popularity with electronic public administration. The convention implements a standard that makes it easier to couple diverse information systems together using product-independent interfaces and to increase interoperability of management systems and make them easier to integrate. Data that may be used and is needed in administrative procedures can be integrated more efficiently into workflow processes.

The ELAK transaction specification is built on various base specifications of the ICT Strategy. Its goal is the implementation of the following use cases:

  • transmission of records, business cases and sub-cases between ELAK systems.
  • transmission of records, business case and sub-cases back and forth between record management systems and special information systems.

The existing specifications for ELAK transactions are positioned as follows in the specification framework of Austrian eGovernment, and make use of the following base specifications:

  • XML Toolbox
  • XML Entry Protocol
  • PersonData
  • SOAP faults

ELAK Transaktion

From a technical point of view, ELAK transactions build on the XML Entry Protocol, which is used for inter-administrative purposes. This means that some of the specified transactions must be embedded in the XML Entry Protocol. Some ELAK transactions can be used on their own due to their low complexity or because they are used internally in the organisation.

XML Search Queries

The XML specification for search queries (XML-sw) provides a standardised framework for the development of interfaces for searches, queries and information retrieval from eGovernment applications, such as registers.

This convention identifies two use cases: searching by attributes, which can return many hits, and searching using result recognition from a previous search that returns exactly one result. It provides common XML elements for all search queries in both use cases, a paging mechanism for queries that return large result sets, wildcard conventions, error codes and standards for creating new codes. Whenever possible, this convention is based on existing implementations with real register queries. 

SOAP Faults

Keeping in line with the principles of the ICT Strategy, the international open standard SOAP  is to be used for communication between eGovernment applications. Messages, along with the corresponding information about transport, are transmitted in XML format using established Internet protocols such as HTTP or SMTP. With these types of connections, problems can occur which cause errors to be returned by the calling application. Protocols such as HTTP define error messages (e.g., 404 error: File not found) which are returned to the application. However, there are not any cross-application standardised error codes available for SOAP.

In general, the SOAP Faults  convention (XML-sf) recommends that public administration applications in Austria should return error codes. In development environments, error exceptions are thrown which must be caught accordingly. This ensures the standard handling of errors on the technical side for communication between Web service-oriented eGovernment applications. In addition, classes of error codes are defined to allow the source of the error to be identified and make the organisational handling of the error easier.

Diacritical Symbols

In eGovernment, diacritical symbols must be taken into account. Systems must be able to recognise, process and reproduce letters that have small marks above or below, such as dots, lines, curves, or curls, which indicate a special pronunciation or emphasis. The Federal Ministry of Finance has organised a federal licence for the library of diacritical characters (on the basis of the central register of residents). The licence and maintenance costs are paid for by the Federal Ministry of Finance. The implementation is done via BRZ GmbH. This software library incorporates the transformation, verification, presentation and input of diacritical characters (in an input mask). The technical possibilities for use extend to Java and .NET platforms.