service based architecture of access egov system n.
Skip this Video
Loading SlideShow in 5 Seconds..
Service-based architecture of Access-eGov system PowerPoint Presentation
Download Presentation
Service-based architecture of Access-eGov system

Service-based architecture of Access-eGov system

117 Views Download Presentation
Download Presentation

Service-based architecture of Access-eGov system

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Service-based architecture of Access-eGov system Martin Tomášek, Karol Furdík {Martin.Tomasek, Karol.Furdik} InterSoft, a.s., Floriánska 19, 040 01 Košice

  2. Contents Access-eGov project • Basic information • Objectives and functionality • Pilot applications Architecture design • Description framework • Architecture context • Conceptual architecture • Logical architecture • Physical architecture Future work

  3. Access-eGov project Full title: Access to e-Government Services Employing Semantic Technologies • Starting date: January 1st, 2006 • Duration: 36 months • EC Funding: 1.983.000 € • Total Budget: 2.279.243 € Main goal: to develop and validate a platform for composition of government services into complex process definitions (covering life events/business episodes) enabling semantic interoperability of particular e-Government services.

  4. Objectives & Functionality Access-eGov system: a framework / platform for eGov services, based on Semantic Web technologies. Provided services: • Meta-service will identify proper eGov services relevant to the given life event or business episode (according to the semantically expressed user‘s needs & requirements), • Scenarios consisting of elementary eGov services (of „hybrid“ nature, i.e. a combination of traditional and electronic eGov services), • Virtual Personal Assistant - a tool that will guide users in the space of available services.

  5. Pilot Applications In Slovakia: land-use planning and processing a request for a building permit. In Poland: establishing an enterprise taking into account the process of company registration. In Germany: an upgrade and field test based on the existing good practice, the so-called “Zustaendigkeitsfinder” ("Responsibility Finder"), by introducing a semantic layer (securing semantic interoperability between national and local governments). In Egypt (German University of Cairo): searching for eGov services provided by an EU country. Use case: applying for a work permit in an EU country.

  6. Architecture Description Framework : WHY? WHAT? HOW? WITH WHAT?

  7. Architecture context Security requirements: Privacy (secure personal info), Communication security (data encrytion), Access Control, Trust between nodes. General functional reqs:Reliability (Maturity, Recoverability, Fault tolerance - SoA: components not tightly coupled), Efficiency (caching, effective storage layer). User reqs:eSignature for transactional operations (e. g. invoking services, filling in electronic forms), XML based interface available (including exchange of user information if user permits), Tracing business processes, Retrieval of services / life events, Scenario construction, Personalisation, Multilinguality, etc. Data reqs:Changeability (esp. on Ontology level), Reusability (Knowledge storage is decoupled from other components), Suitability (rich set of knowledge concepts for semantic descriptions).

  8. Conceptual Architecture (1) Security view • Single-Sign-On (SSO) functionality • Solution allows public agencies to keep their own preferred technology for user authentication Functional view • Annotation of services, effective data storage • Retrieval of services according to certain citizen requests • Stringing annotated services together to form new “meta services” - scenarios Data view • Ontologies - semantic description of real-world concepts • Ontologies used: • Life events ontology • Service profiles ontology • Access-eGov Domain ontology

  9. Conceptual Architecture (2) Functional description : Information provider view

  10. Conceptual Architecture (3) Functional description : Information consumer view

  11. Logical Architecture (1) Platform taken : Web Services + service oriented Peer-to-Peer architecture System architecture - Component groups:

  12. Logical Architecture (2) Use Case “Service Discovery”:

  13. Logical Architecture (3) Use Case “Service Composition”:

  14. Logical Architecture (4) Use Case “Service Execution”:

  15. Logical Architecture (5) Data view:

  16. Physical Architecture WSMX Architecture:

  17. Future work Specification of components: (almost finished) Annotation services & Ontologies: design and development of data repositories and functional components for semantic description and annotation of eGov services Implementation of the core Access-eGov system Pilot applications, development and customization of the system for particular pilot application Testing, evaluation

  18. Thank you for your attention. {Martin.Tomasek, Karol.Furdik}