application/vnd.ms-powerpoint icon SOAworkshop_v05DECLERQ.ppt ...

385 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
385
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Introduction Slide Two Findings Two case studies Preliminary conclusion Content of the presentation Based on Deloitte experiences in projects, we have found 2 elements which are a key success particular importance for Clear description and development of business services accelerate the adoption of the Services Architecture government specific requirements are essential for egovernment servicessuccess. 2 Case studies to illustrate this finding Conclusions
  • <key message: SOA adoption is accellerating when busieness services are beeing defined.> What you see: Basid SOA maturity model. Consists of 5 stages. In all 5 stages there is growth in Business Benefits / technology maturity / scope / ROI and type of services which are being used. We have observed that the growth of SOA is really accellerating when we are starting to talk about business services. . Let me explain: Stage 1 & 2 , technical services, mushroom phases. (soa is growing, but slowly, it is growing in a dark cave.) SOA is used, but not well known. Starting from phase 3 business processes come into play. User groups start understanding this soa is all about, and what it can do for them. use is really increasing with the definition of business services. Growth means – increased users / different user communities / different applications / different domains /
  • <Key Message: > Finding 2: when defining services in a soa, Now, before embarking on the case studies I want to take a discuss the the specificity of a business service in an eGovernment environment. When designing services in a you explicitely or implicitely take into account a numbe of design principles and requirements. On the slide you find a number of these principle. I’ve highlighted the design prinicple wh Division of responsibility: The ability to more easily allow business people to concentrate on business issues, technical people to concentrate on technology issues, and for both groups to collaborate using the service contract. Provide citizen-oriented services: Provide services to citizens every time they need them, wherever they are, and shielding them from a complex government organisations. Ease public administration interoperability: Allow integration of legacy systems and use a loosely coupled interaction among agencies by assembling on-demand Web services to automate e-government seamless service delivery Respect the autonomy of the single administration: Administrations in general have specific tasks and objectives. It is the combination of tasks which makes the government usefull for most citizens. The task specificity should be reflected in the services with finer granulatiry. It is the combination and orchtestration of the services which will make them usefull for citizens and administrations
  • <Key message: Setting the context for the project, the city of rotterdam> In 2009 the law “Wet algemene bepalingen omgevingsrecht (Wabo)” will pass. The environmental permission is one integrated permission that should lead to: Less administrative work for companies and citizens Better service by the government Shorter procedures No contra dictionary regulation. Ex
  • Complex because the decission environmental decision are taken on different governmental levels. On top of that some of the advisory was outsourced in private sector. Explain front office – Back office. Previously the problem was attacked with office tools (word, excel) Basic services which mediate between the front office and back office Calendaring service: supports into agreeing on the date. Request manager: Process Manager:
  • Geïntegreerd gebruikers- en toegangsbeheer Doel Het geïntegreerd gebruikers- en toegangsbeheer wil waarborgen dat enkel toegangsgerechtigde zorgverleners/zorginstellingen toegang krijgen tot die persoonsinformatie waartoe zij toegang mogen hebben overeenkomstig de wet, de machtigingen van de Afdeling Gezondheid van het Sectoraal Comité opgericht binnen de Commissie voor de Bescherming van de Persoonlijke Levenssfeer en/of de toestemming van de patiënten, en enkel m.b.t. de patiënten waarover zij de betrokken persoonsinformatie nodig hebben voor de zorgverstrekking. Beheer van loggings Doel Gezien de gevoeligheid van persoonlijke informatie die via de portaalsite van het eHealth-portaal kan verlopen, is een methode voorzien worden om het gebruik ervan te controleren. Hiervoor dient de module voor SecurityLogging. Met behulp hiervan kan op eenvoudige wijze elke opvraging bijgehouden worden. Functionaliteiten De logging classes houden het antwoord bij op vier grote vragen: WIE, OVER WIE, WANNEER en HOE. WIE: het identificatienummer van de sociale zekerheid (INSZ) van de opvrager. Indien de opvraging gebeurde in naam van een organisatie, ook de identificatie van organisatie. WAT: het identificatienummer van de sociale zekerheid (INSZ) van de persoon waarover informatie werd opgevraagd WANNEER: het tijdstip waarop de informatie werd opgevraagd; dit veld wordt automatisch gegenereerd bij het aanmaken van een nieuwe log entry HOE: de toepassing via dewelke de informatie werd opgevraagd Praktijkvoorbeeld voor deze basisdienst De Authorizer webservice , gebruikt door MyCareNet: voor elke gebruiker die wordt geauthoriseerd moeten gevoelige gegevens worden opgevraagd. Voor elke opvraging komt er een lijn in de logs. Doel eHealth biedt aan haar partners een dienst aan voor timestamping. Deze bestaat uit twee delen: een klassieke timestamping, om te kunnen aantonen dat het ondertekende document bestond op een bepaald tijdstip, en een consultatiedienst om eerdere timestamps opnieuw op te vragen. Normaal is het de bedoeling dat elke gebruiker enkel zijn eigen timestamps kan opvragen. In sommige gevallen is het echter ook mogelijk dat een toezichthoudende instantie toegang heeft tot de timestamps van anderen. Functionaliteiten De klassieke timestamping is geïmplementeerd volgens de OASIS-standaard. Deze beschrijft slechts één methode, waar men een document als invoer geeft en een RFC 3161 timestamp als uitvoer krijgt. De eHealth-timestamping webservice zal daarnaast ook nog het originele document, samen met zijn timestamp en de identiteit van de aanvrager, opslaan in een database. Deze identiteit wordt bepaald door de gegevens in de SOAP-headers. Via de consultatiedienst kan een partner de documenten opvragen die hij eerder heeft laten ondertekenen. Het is ook mogelijk om een lijst te krijgen van alle timestamps tussen twee tijdstippen. Service Level Agreement (SLA) Praktijkvoorbeeld van deze basisdienst Momenteel wordt deze dienst gebruikt door een pilootgroep van vijf Belgische ziekenhuizen, die de uitgeschreven geneesmiddelenvoorschriften laten ondertekenen. Omdat het hier gaat om gevoelige informatie, laten zij niet het oorspronkelijke voorschrift ondertekenen, maar een hash van dat voorschrift. Naast het ziekenhuis zelf heeft het RIZIV als toezichthoudende instantie toegang tot de op deze manier ondertekende documenten. Codering en anonimisering Doel Deze module moet er voor zorgen dat de persoonsgegevens m.b.t. de gezondheid omgezet worden naar gecodeerde of anonieme gegevens waaruit uiteraard de identiteit van de patiënt en/of zorgverlener niet rechtstreeks of onrechtstreeks kan worden afgeleid. Functionaliteiten Om deze doelstelling te bereiken is het niet voldoende om enkel de identificatiesleutel te coderen maar er moet ook gezorgd worden dat door het combineren van gecodeerde gegevens geen heridentificatie mogelijk is naar de patiënt en/of de zorgverlener. Om de onafhankelijke werking van deze dienst te waarborgen zal het eHealth-platform nooit zelf onderzoek verrichten en de gegevens niet langer bewaren dan strikt noodzakelijk voor de coderings- of anonimiseringsopdracht. Om longitudinaal onderzoek echter mogelijk te maken, kan het platform wel het verband bijhouden tussen identificatienummer van de sociale zekerheid (INSZ) en de code, uiteraard geen andere persoonsgegevens. Dit kan enkel wanneer de bestemmeling dit uitdrukkelijk vraagt en motiveert en als de Afdeling Gezondheid van het Sectoraal Comité dit toelaat. Praktijkvoorbeeld van deze basisdienst Therapeutische projecten : Omwille van privacyredenen kan deze toepassing niet werken met een INSZ ter identificatie van een patiënt. Daarom wordt er gebruikt gemaakt van de webservice codering en anonimisering om een gecodeerde versie van een INSZ aan te maken, het zogenaamde UPP nummer, en om bepaalde gegevens in te delen in klassen, zodat ook een onrechtstreekse heridentificatie van de patiënt niet mogelijk is. Beveiligde elektronische brievenbus Doel Een beveiligde elektronische brievenbus ter beschikking stellen van elke actor in de gezondheidszorg waarin andere actoren berichten kunnen plaatsten die voor de eerstvermelde actor bestemd is. Functionaliteiten Deze brievenbus vervangt het gebruik van afgedrukte formulieren en documenten door een elektronische gegevensstroom. Dit maakt het uitwisselen en behandelen van gezondheidsgegevens sneller en efficiënter. Publicatie Elke actor in de gezondheidszorg kan een bericht, document of nieuwsbrief publiceren die gericht is naar een actor of een groep van actoren (ziekenhuis, bejaardentehuis…). Zo kan bijvoorbeeld worden gevraagd om een specifieke aangifte in te vullen ontvangstbewijzen van aangiften worden overgemaakt informatie worden verstrekt over nieuwe mogelijkheden van een elektronische toepassing Consultatie Elke zorgverlener heeft toegang tot een individuele en beveiligde zone waarop hij zijn elektronische brievenbus kan raadplegen. Hij vindt er alle documenten die gepubliceerd werden door de andere actoren. Praktijkvoorbeeld van deze basisdienst MyCarenet : beschikbaar stellen van de updates bij verwerking van de facturatie gegevens. Authentieke Bronnen kadaster van de zorgverleners beheerder: FOD Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu bevat informatie over het diploma en de specialiteit van een zorgverlener geïdentificeerd aan de hand van zijn identificatienummer sociale zekerheid (INSZ) Bestand van zorgverleners voor terugbetaling door de ziekteverzekering Aanbieder Rijksinstituut voor ziekte- en invaliditeitsverzekering Omschrijving Het RIZIV is een federale instelling die, net als de ziekenfondsen, een cruciale rol speelt inzake gezondheidszorg en arbeidsongeschiktheidsuitkeringen. Het RIZIV organiseert, beheert en controleert die "verplichte verzekering" in België. Het RIZIV staat onder het toezicht van de minister van Sociale Zaken. Het Instituut organiseert ook het overleg tussen de verschillende actoren van de verzekering voor geneeskundige verzorging en uitkeringen. Om deze opdracht te bewerkstelligen beschikt het RIZIV over gegevens van alle personen en instellingen die prestaties kunnen leveren die voldoen aan de voorwaarden voor terugbetaling door de ziekteverzekering. Gebruik door eHealth Het eHealth-platform kan gebruik maken van het RIZIV om te controleren of een bepaalde persoon of instelling prestaties kan leveren die voldoen aan de voorwaarden voor terugbetaling. De authentieke bron van het RIZIV kan onder andere antwoorden op volgende vragen Is deze persoon een erkend professional in de gezondheidszorg? Is deze instelling een erkende instelling? Wat zijn de adresgegevens van deze instelling? Kadaster van de gezondheidsberoepen Aanbieder Federale Overheidsdienst Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu Omschrijving De federale databank van de beoefenaars van de gezondheidsberoepen (Wet van 29/01/2003; BS 26/02/03) wordt kortweg 'het kadaster' genoemd. De wet voorziet in drie doelstellingen voor het kadaster. Samengevat komt het hier op neer gegevens verzamelen die noodzakelijk zijn voor de uitvoering van de opdrachten van de Planningscommissie de uitvoering van de opdrachten van de administratie en de openbare instellingen mogelijk maken de communicatie met en tussen de beoefenaars van de gezondheidszorgberoepen verbeteren Dit project past mee in het kader van de doelstellingen van eHealth, en kan daarom gebruikt worden als authentieke bron. Gebruik door eHealth Het eHealth-platform kan van het Kadaster gebruik maken om de hoedanigheid van zorgverleners in de gezondheidszorg te controleren. De authentieke bron van het kadaster kan antwoorden op volgende vragen Beschikt de gegeven persoon over een bepaald diploma binnen de gezondheidszorg? Beschikt de gegeven persoon over een visum, met andere woorden is de gegeven persoon gerechtigd om prestaties te leveren als professional in de gezondheidszorg? Wat is de lijst van titels die de gegeven persoon mag dragen? Wat is de lijst van particuliere competenties waarover de gegeven persoon beschikt? Het Rijksregister en de Kruispuntbankregisters Aanbieder Het Rijksregister van de natuurlijke personen, hierna kortweg het Rijksregister genoemd, wordt beheerd door de federale overheidsdienst Binnenlandse Zaken. De Kruispuntbankregisters worden beheerd door de Kruispuntbank van de Sociale Zekerheid. Omschrijving Het Rijksregister bevat de volgende persoonsgegevens over de natuurlijke personen die zijn ingeschreven in de bevolkings- en vreemdelingenregisters van de gemeenten, in de registers van de diplomatieke zendingen en de consulaire posten in het buitenland of in de wachtregisters van de vreemdelingen die zich vluchteling verklaren of vragen om als vluchteling te worden erkend: de naam, de voornamen, de geboorteplaats, de geboortedatum, het geslacht, de nationaliteit, de hoofdverblijfplaats, de plaats van overlijden, de datum van overlijden, het beroep, de burgerlijke staat en de opeenvolgende wijzigingen van deze persoonsgegevens evenals hun geldigheidsperiodes. Elke natuurlijke persoon die in het Rijksregister is opgenomen, beschikt bovendien over een rijksregisternummer. Niet alle natuurlijke personen die eenduidig geïdentificeerd moeten zijn, zijn echter opgenomen in het Rijksregister en beschikken over een rijksregisternummer (bijvoorbeeld grensarbeiders die in het buitenland verblijven maar in België werken of natuurlijke personen die recht hebben op Belgische uitkeringen inzake sociale zekerheid maar nooit in België hebben verbleven). Daarom beheert de Kruispuntbank van de Sociale Zekerheid een aanvullende persoonsgegevensbank. De zogenaamde Kruispuntbankregisters bevatten de volgende persoonsgegevens over deze natuurlijke personen: de naam, de voornamen, de geboorteplaats, de geboortedatum, het geslacht, de nationaliteit, de hoofdverblijfplaats, de datum van overlijden en de burgerlijke staat en de opeenvolgende wijzigingen van deze persoonsgegevens. Ook natuurlijke personen die ooit in het Rijksregister opgenomen zijn geweest en over een rijksregisternummer beschikken maar van wie de persoonsgegevens inmiddels niet meer door het Rijksregister worden geactualiseerd, worden (met behoud van hun rijksregisternummer) in de Kruispuntbankregisters opgenomen. Voor zover een natuurlijke persoon die in de Kruispuntbankregisters is opgenomen niet beschikt over een rijksregisternummer wordt hem door de Kruispuntbank van de Sociale Zekerheid een zogenaamd Kruispuntbanknummer toegekend. Bij de uitwisseling van persoonsgegevens met tussenkomst van het eHealth-platform wordt voor de identificatie van de betrokken natuurlijke personen verplicht gebruik gemaakt van het zogenaamde Identificatienummer van de Sociale Zekerheid (INSZ), dat is ofwel het rijksregisternummer (indien de betrokkene daarover beschikt), ofwel het Kruispuntbanknummer. Zowel de toegang tot het Rijksregister als het gebruik van het rijksregisternummer vergen een voorafgaande machtiging vanwege het sectoraal comité van het Rijksregister, opgericht binnen de Commissie voor de Bescherming van de Persoonlijke Levenssfeer. De toegang tot de Kruispuntbankregisters vergt een voorafgaande machtiging vanwege het sectoraal comité van de sociale zekerheid en van de gezondheid, opgericht binnen de Commissie voor de Bescherming van de Persoonlijke Levenssfeer. Het gebruik van het Kruispuntbanknummer is daarentegen vrij. Centraal bestand van de verzorgingsinstellingen (CIC) Aanbieder Federale Overheidsdienst Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu Omschrijving De doelstelling van het CIC-project (Centrale Instellingen / Institutions Centralisées) bestaat erin een gecentraliseerde databank van de verzorgingsinstellingen in België te creëren. Deze gecentraliseerde databank bevat volgende gegevens beschrijvende gegevens van de instellingen contactinformatie gegevens over de erkenningen gedetailleerde beschrijvingen van de omkadering van de zorgactiviteiten Deze databank wil in de eerste plaats voor coherentie zorgen binnen de Federale Overheidsdienst op het vlak van de identificatie en de structuur van de verzorgingsinstellingen. Dit project past mee in het kader van de doelstellingen van eHealth, en kan daarom gebruikt worden als authentieke bron. Gebruik door eHealth Het eHealth-platform kan van het CIC gebruik maken om de gegevens van instellingen in de gezondheidszorg op te vragen. De authentieke bron van het CIC kan antwoorden op volgende vragen Is deze instelling een geldige erkende instelling? Wat is de officiële benaming van deze instelling? Wat zijn de volledige adresgegevens van deze instelling? Gegevensbank voor de opvolging van de pandemische griep in het ziekenhuis (eH1N1) Kankerregistratie Partner Private Stichting Kankerregister Doelstelling De kankerregistratie vormt de basis voor epidemiologisch onderzoek. Deze toepassing streeft naar een vereenvoudiging en standaardisering van de registratie en laat tevens een online kwaliteitscontrole van de gegevens toe. De formulieren voor de facturatie van het Multidisciplinair Oncologisch Consult, bestemd voor de ziekenfondsen, kunnen ermee uitgeprint worden. De zorgprogramma's voor oncologische basiszorg kunnen via deze toepassing voldoen aan de kwaliteitsnormen voor de verplichte kankerregistratie zoals beschreven in het Koninklijk Besluit van 21 maart 2003. Elektronische raadpleging van verzekerbaarheid in de ziekteverzekering door verplegers (groeperingen) Partner MyCareNet (Nationaal Intermutualistiche College) Doelstelling Deze toepassing moet toelaten aan verpleegkundigen en groeperingen van verpleegkundigen om de verzekerbaarheidsgegevens van hun patiënten op te vragen. Functionaliteiten opvragen van de verzekerbaarheidsgegevens van een patiënt Doelgroepen en toegangsregels Deze toepassing is toegankelijk voor verpleegkundigen, groeperingen van verpleegkundigen en hun volmachthouders. In totaal geeft dit zes mogelijke scenario's verpleegkundige lid van groepering volmachthouder van verpleegkundige volmachthouder van groepering lid van organisatie met volmacht van verpleegkundige lid van organisatie met volmacht van groepering Het bereik van deze toepassing zal in de (nabije) toekomst nog worden uitgebreid naar andere groepen van zorgverlevers (o.a. apothekers). Gebruikte basisdiensten portaalsite geïntegreerd gebruikers- en toegangsbeheer beheer van loggings beveiligde elektronische brievenbus
  • <key message: definition of the building blocks typically used in the government, fill in the metamodel> What you see here is the a visual overview of the Layers of the SOA Reference Architecture, as documented in the the draft specification by the open group. Open group which is most know for the support for the develop TOGAF. The Soa reference architectrue specification we is the result of abstracting and using a SOA Reference Architecture based on multiple projects in different industries, commencing from 2002. This meta-model defines a number of layers, architectural building blocks, architectural and design decisions, patterns, options and the separation of concerns needed to design or evaluate an architecture. The usage of the SOA Reference Architecture is a key enabler for the achievement of the value propositions of a Service-oriented Architecture. This specification presents a SOA Reference Architecture (SOA RA), which provides guidelines for making architectural, design, and implementation decisions. The goal of the SOA Reference Architecture is to provide a blueprint for creating or evaluating an architecture Additionally, it provides patterns and insights for integrating these fundamental Elements of an SOA as exemplified in the layers of an SOA. The SOA RA is used as a blueprint and includes templates and guidelines for architects. These facilitate and ultimately enable automation and streamlining the process of modelling and documenting the architectural layers, the architectural building blocks (ABB) within them, options for layers and ABBs, mapping of products to the ABBs and architectural and design decisions that contribute to the creation of a SOA. <key message: this slide is proviceds more detail and visualisation on what a possible reference model for SOA in the government can be> What you see here is a detail of the services layer of the previouse slide: In order to really push forward SOA in the govermnet We should start to focus on the definition of the services. We should start drawing the lines of the services, necessary in the govenment. This will have positive effect on the developement of services We have serveral exiting framework, we know on an abstract layer what should be in the Services in the
  • application/vnd.ms-powerpoint icon SOAworkshop_v05DECLERQ.ppt ...

    1. 1. Service Oriented Architecture Workshop Service Oriented Architecture pushed to the limit in eGovernment Koert Declercq Brussels, February 17th, 2010 SOA reference framework for public services v2
    2. 2. Content <ul><li>Two Findings </li></ul><ul><li>Two case studies </li></ul><ul><li>Preliminary conclusion </li></ul>Service Oriented Architecture pushed to the limit in eGovernment
    3. 3. Maturity and adoption of SOA architecture Focus on business services is pivotal at level three Maturity Service Oriented Architecture pushed to the limit in eGovernment <ul><li>Web services Standards and some Components </li></ul><ul><li>Limited SOA run-Time </li></ul><ul><li>Use of XML </li></ul>Time <ul><li>Some services developed, with limited exposure </li></ul><ul><li>SOA development and run-time environment </li></ul><ul><li>Web services </li></ul><ul><li>XML messaging </li></ul><ul><li>Business Services are defined </li></ul><ul><li>Services are being orchestrated </li></ul><ul><li>Business Process Modeling is in use </li></ul><ul><li>Broad use of SOA infrastructure </li></ul><ul><li>Broad use of XML </li></ul><ul><li>SOA governance in place </li></ul><ul><li>Business Process Models defined and managed </li></ul><ul><li>Business activity monitoring </li></ul><ul><li>Business process simulation </li></ul><ul><li>Multiple BU/business services domains are defined </li></ul><ul><li>Service reuse is occurring </li></ul><ul><li>Extensive SOA environment </li></ul><ul><li>Public services being leveraged and choreographed </li></ul><ul><li>Extensive services library </li></ul><ul><li>Extensive services reuse </li></ul><ul><li>Web 2.0 with collaboration and mash-Ups </li></ul><ul><li>Multiple services partners </li></ul>Stage 1: Basic SOA Stage 2: Limited SOA Services Stage 3: Orchestrating SOA Services Stage 4: Performance Mgmt + SOA Stage 5: Public SOA
    4. 4. Requirements for business Services Government services add specific requirements to services in a Service Oriented Architecture <ul><li>Discoverable </li></ul><ul><li>Service Maintenance </li></ul><ul><li>Interface Granularity </li></ul><ul><li>Division of responsibility </li></ul><ul><li>Loose technology coupling </li></ul><ul><li>Self-Contained </li></ul><ul><li>Modularity </li></ul><ul><li>Interoperability </li></ul><ul><li>Reusability </li></ul><ul><li>Efficiency </li></ul>Service Oriented Architecture pushed to the limit in eGovernment Citizen-oriented Ease public administration interoperability Respect the autonomy of the single administration
    5. 5. Case study 1: City of Rotterdam <ul><li>New law (Wabo 2009) which forces the councils to deliver environmental permission is an integrated way with the objective to: </li></ul><ul><li>Less administrative work for businesses and citizens. </li></ul><ul><li>Better service by the government </li></ul><ul><li>Shorter procedures </li></ul><ul><li>No contra dictionary regulation. </li></ul>Service Oriented Architecture pushed to the limit in eGovernment
    6. 6. Case study 1: City of Rotterdam Citizen-oriented services are the core of the Service Oriented Architecture Service Oriented Architecture pushed to the limit in eGovernment Process Manager Request Management Calendaring service Business Registry Geographical data Actors Data sources Business Services Channels City Councils Environment Administration Building Administration ... Mid Office: Back office: Front office: email – Phone - Internet Citizens Administrations Businesses
    7. 7. Case Study 2: Belgian e-Health platform ( www.ehealth.fgov.be) Service Oriented Architecture pushed to the limit in eGovernment End‐to‐end Encryption Identity and access management Index of Medical Professions Time Stamping Coding and Anonimisation Logging Services Authorized medical beneficiaries Citizen registry Data access services Social security registry Company registry Manage Registration and vaccination of eH1N1 Cancer Registry E-Birth (in development) … Data sources Services Actors *www.ehealth.fgov.be Channel (Value added services) Basic interoperability service and respect for the autonomy of the single administration Portal Health care actors- Administrations
    8. 8. SOA Reference Model Building a specific governance architecture End‐to‐end Encryption Process Manager Logging services Authenticationservices e-Procurement Log auditing Collaboration Orchestration e-Payment e-Voting Document Management Process Traceability e-Citizen Counter Personal document storage e-Forms e-Tax Service Oriented Architecture pushed to the limit in eGovernment Coding & anonimisation

    ×