Service Oriented Architectures

1. Service Oriented Architectures

2. SOA: Business and Technology • SOA is a business concept as well as a technology concept • Attempts to fit IT within the enterprise business mission. • Capturing the interrelated services within and between organisations. • SOA technologies must be architected to serve these business needs. • Help business users understand the benefits of integration and infrastructure • SOA can be about Business Transformation as much as Technology Transformation

3. What is SOA about? Some definitions from around the web… • SOA aims to deliver greater business agility while at the same time substantially reducing the cost and business risk associated with developing and maintaining new solutions. • SOA represents business functions as shared, reusable services • SOA designs treat parts of business processes as standardised components (services) that can be reused and combined to address changing business priorities • SOA also implements a lot of what is already good enterprise architecture practice. • IT Governance is central to SOA • This requires well defined business services which can be easily and quickly used and used again.

4. What are business services? • Business services are facilities provided by 1 business department to another (the shared services model) • E.g. invoice processing, shipping • Many business have moved to or are moving to a business service model with associated Service Level Agreements • Shared services centrally or inter-department services • SOA assumes that these business services can be defined and will be automated. • And will be reused • The same service must be potentially useful to multiple departments. • Otherwise, there is little benefit in using SOA and the additional effort it requires.

5. Why SOA has emerged now Acceptance of the shared services and service provider business model General acceptance of standards Allows focus to move from whether integration is possible to how it can be best achieved. Tools and open standards required in integration have matured and interoperate more easily J2EE, .Net, SOAP/WSDL, JMS, etc… Greater levels of integration are already in place through use of Web Services, EAI and reliable messaging This makes SOA possible Increased need to share data and information more generally A maturing understanding of the cost and issues associated with previous approaches to integration.

6. Implementing a SOA • SOA is an architecture • Can be implemented using many different technologies • But architecture must come first • Technology Implementation Options • Custom code • J2EE + Custom code • EAI • Enterprise Service Bus • SOA-centric version of EAI • Web Services • All of the above

7. Web Services != SOA? • Initially SOA and Web Services were seen as almost interchangeable terms because both emerged around the same time. • Web Services is a distributed architecture and set of standards • SOA is an integration architecture and can be used with many standards • Early SOA projects often based around web services only: • Web services running over HTTP • Every business service built into a web service • Web Services typically lack core capabilities for the enterprise • HTTP unreliable, causing transmission failures • Web Services QoS standards not yet widely used • However, Web Services remains an implementation option for lighter weight requirements

8. SOA requires a new development model Traditional SOA Analyse Requirements Order & Requirements Service Component Reuse Library SOA Best practices Fund/Contract Component Component Fund/Contract Generate Adapt Construct Fund/Contract Fund/Contract Reuse New Services Design Implement Test Integration Testing Solution Solution

9. Traditional Software Development Model • Systems are developed by a single organization • Undergo a phased development process with multiple phases of review, inspection, testing • Systems are designed to solve known problems. • Hard to evolve or reuse • The entire system is released as part of a single schedule • The system will have its own design, data model and component interfaces. • Successful of each project is evaluated in isolation upon completion.

10. SOA Development Model • Balance your projects goals in terms of long-term business and short-term business goals. • It is hard to get buy-in to long-term only • Map project requirements to SOA software development and deployment processes • Use best practices, policies, deployment, governance, etc. • Encourage collaboration vehicle for constant review of service implementations and priority levels • Identify common components to be leveraged cross-functionally • Focus on reuse/sharing of existing components/services • Select and incorporate technology incrementally as required for QoS, brokering and managing services, monitoring, auditing, change control. • Calculate profitability and project ROI within the SOA programme context • Introduce early proof points

11. Identifying business services for SOA • If the business services are automated, they may be the basis for a SOA service. • Some services are 1-off but many will be used by multiple internal customers. • These potentially reused services are the building blocks for SOA • Across an organisation there may be many potential business services which can be included with the SOA

12. SOA Services SOA Services are reusable units providing business functionality that are: Clearly defined using standard policies, practices, and frameworks Clearly described (usually with XML) Autonomous Abstractions of the underlying business logic and functionality Generally, Services use one or more software components to satisfy some business functionality For example, the “Schedule Mortgage Closing” service may involve execution of many components (modules) in the underlying IT systems

13. Services as Well-Defined Contracts In order to interact successfully with a service, you must know at least two things: What you expect to get from the service What information you have to provide the service so that it can get the job done A well-defined “contract” from the service provider spells out the business and technology requirements for using the service (the “interface”) and how to invoke the service A service contract reflects specific business knowledge and is the basis for sharing and reusing services Maintenance of service “contracts” becomes critical over time Contracts are stored in a service registry This is equally true from both the business and technology perspectives

14. Designing a service: Business Start with the business case for the service Without a business case, this is just distributed computing Make the business value clear Services should be understandable to the business community Can be included in business process definitions Published service interface should include functional descriptions, not just technical specifics Published interface is a contract Should include messages the service sends/receives Should include policies to be enforced Should include description of business function performed A business service should ideally have a business owner who is responsible for ensuring reuse 14

15. Designing Services for reuse Services representing business functionality will be much more complex than those that merely provide simple data access and must be designed for reuse Reuse requires Access to the service should not be restricted to specific languages (e.g. Java) or environments (e.g. .Net) The service’s data model is neutral and appropriate for a wide range of clients. Service should support loose coupling Service should be coarse grained

16. Designing a service: The implicit data model Services expose a data model implicitly in the way the data is passed into the service and returned from the service. Service design must include data modeling and data models must be included within the overall governance structures. The implicit data model can be Bad: Close to the internal data model of the application Easy for the developer of the application but requires consumers to map to that data model which may be hard. Bad: Close to the data model of the first consumer Data model can’t be simply designed for the first consumer as the requirements may not suit other consumers. Good: A neutral model designed to promote reuse Requires analysis of likely requirements as well as known requirements.

17. Designing a service: Loose coupling Loose coupling means the ability to change a service provider without impacting the client And vice versa Loose Coupling allows for just-in-time integration A new consumer can be added without changing the service provider Requires clear service definitions and clear semantic separation. The consumer only requires the service definition and supporting semantic descriptions are typically human readable text descriptions. No implicit knowledge of the server is embedded in the consumer Technical interoperability is essential for loose coupling 17

18. Loose Coupling Analogy In a car… Was the accelerator pedal connected to the motor using a chain, cable, mechanical links, hydraulics, or electronics? You don’t need to know As long as the car “goes” when the accelerator is used, only car mechanics really care how it happens The “Acceleration Service” is loosely-coupled, the automobile operator accelerates or decelerates without concern to exactly how the service is performed. It can be implemented differently in different cars And the user only makes the decision to use the service when it is required.

19. Granularity is the scope of functionality of a service Fine-grained services could return a single value in response to a request for data A service to return each account name Coarse-grained services could expose the result of a business process composed of multiple functions A service to calculate and return end of year accounts. In general coarse grained is better The coarser the granularity of a service, the more business value they typically offer Can be used to build composite applications more easily Fine grained services often not loosely coupled or well designed Designing a service: Granularity 19

20. Designing a service: Coarse-Grained Communication Services are more coarse-grained than typical IT objects and components and frequently services map directly to a business function or activity Coarse-grained interactions are simpler and require fewer messages to use the service, and thus, fewer messages on the network and less complexity for the consumer of the service. Designing services and interactions may be complex since the different aspects of providers and consumers must be reconciled into a simple set of course grained communications. E.g. Pass the entire “Purchase Order” as a coarse-grained unit rather than breaking it into PO Header and PO Detail Lines as you might have done in the past

21. SOA Governance • The cultural and process transformation required by SOA is harder to achieve than any of the technical issues. • Architecture requires involved participants • From top management to staff involved in the process • Big bang doesn’t work, the only alternative is incremental deployment • Big Bang requires too much upfront investment and risk • Core to achieving it is governance of the SOA programme • Create consensus and elicit management support • Helps to foster business changes needed for the kind of agility SOA promises • Similar requirement to an ERP project except that SOA programmes are federated and hence focus on governance (setting policies) rather than project management (controlling activities).

22. Traditional IT Governance • Command and control of IT resource • Component management (hardware and software) and software reuse • Control of production, distribution and consumption • Assumes: • Systems are fairly static • A central authority manages system upgrades and modifications • A central authority manages the data flows among components within the environment • The system can be tested as a single, static entity

23. SOA Governance • No single authority across the components and interactions • Component management (hardware and software) and software reuse is driven from the business lines • Market controls production and consumption • Useful services get used • Assumes: • Constant change occurs across the enterprise • Encourage and enable service utilization and opportunistic integration (mash-ups) • A central authority maintains governance rules • No system can be tested in isolation

24. Roles of SOA Governance • Governance is needed to: • Make sure multiple services don’t provide the same functionality • Understand who is responsible for a given service • Prioritize and control change requests • Determine that services conform to standards • Ensure that contracts are accurate • Provide a level of comfort that advertised services work and can be accessed as described by their contract • Be sure that services are cataloged and can be located

25. Planning an SOA Idealised approach to SOA planning Define SOA strategy in terms of long-term business goals, but don’t forget to meet short-term business goals Define best practices, policies, deployment, governance, etc. Identify common components to be leveraged cross-functionally and deploy early Adjust Software development and deployment processes to fit new architectural requirements (governance activities) Create collaboration vehicle for constant review of service implementations and priority levels Select and incorporate technology required for brokering and managing services, monitoring, auditing, change control, etc. Calculate profitability and project ROI

26. Planning an SOA Pragmatic and most common approach to SOA planning Constraints: no enterprise architecture team, no available resources, limited funding Step 1: Focus on a good-fit project (with a plan and a manager) Project should be well suited to SOA and achievable in a short amount of time Plan should include identification of short term and long term goals, followed by tasks associated with defining a roadmap Step 2: Staff project with resources from other area to ensure dissemination of success and findings Find cross-functional representatives, domain experts (credibility of team members is the key) Carry out tasks on plan (roadmap identification) Step 3: Publicise findings of ad-hoc team Ask for more time or money or people

27. Real-world advice: Planning an SOA Step 4: Start building key SOA artifacts incrementally Define best practices and policies and socialise with application development teams Identify common services or components that can be delivered as part of ongoing or separate development efforts Start to build governance model from initial findings Steps 5-*: Accept that SOA will be built step by step and incrementally improve on SOA artifacts and results Continue to put tasks in buckets, or iterations Continuously sanity-check your approach - research available case studies, gather feedback from cross-functional teams, gather metrics where possible Focus on quantifying and proving the business case for SOA

28. Example: Irish Government A Bearing Point presentation from Mitre eGov conference Andrew S. Townley Principal Architect Reach Public Services Broker Ronan Bradley’s comments are Shown like this.

29. Agenda • Reach and its mission • Key project requirements • PSB technical overview • Lessons learned Public Service Broker

30. The Reach Mission: “To radically improve the quality of service to personal and business customers of Government and to develop and deploy the Public Services Broker to help agencies achieve that improvement” “In particular Reach is to develop and implement an integrated set of processes, systems and procedures to provide a standard means of access to public services, to be known as the Public Services Broker (PSB)." The Reach Agency • Established by Irish Government legislation in 1999 and 2000 to: • Develop a strategy for the integration of public services • Develop and implement the framework for electronic government

31. Public Service Reform Social Security Information Society Reach Governance • Governance Structures • Cabinet Committee (chaired by PM) • Secretary General Group (permanent heads of Depts.) • Assistant Secretary Group (CIOs) • Reach Board (DSFA, Prime Minister, Finance) • Governance Instruments • Primary Legislation & Secondary Regulation • Government Decisions • Government (Prime Minister /Finance) Circulars • Funding decisions (Information Society Fund & Annual Estimates) • “Name & Shame” at Central Groups Office of the Prime Minister Department of Social and Family Affairs Department of Finance Reach Note the emphasis on governance

32. Reach Agency Objectives • Provide Standards & Regulations for e-Government • Develop and maintain a common data exchange format across agencies • Provide interaction policies and guidelines for agency service delivery • Establish the legislative and regulatory framework allowing service delivery • Provide Coordination & Leadership of e-Government Initiatives • Advance the e-Government program across the public service agencies • Coordinate and manage projects relating to e-Government service delivery • Devise the communications and marketing strategy for services offered by the PSB • Provide Implementation & Delivery of e-Government services • Procure the implementation of the PSB core architecture • Actively engage with public service agencies to deliver new services Governance Promote reuse Provide the core messaging through which integration happens

33. Public Service Broker Objectives • Interoperability • Create a standards-based architecture • Define standardized, structured business documents • Common Service Catalogue • Provide shared access to services to both citizens and agencies • Centralize management and access control • Reusability • Services provide distinct business operations • Once deployed, services are available to authorized PSB users and agencies • Single Access Point • Centralized interface for both businesses and citizens • Visibility of pending service requests across all participating agencies

34. Pilot Projects (2001-2003) • Initial reachservices.ie portal • Initially launched in April 2002 with development started in 2001 • Allowed individuals to self-register • Registration details verified against governmental databases • Provided initial point of access and government service taxonomy • Provided electronic forms delivery capabilities, but no forms delivered • Inter-Agency Messaging Service (IAMS) • Developed between 2002-2003 based on discussions in 2001 • Proof-of-concept for the XML messaging broker • Provides delivery of life events between 3 government agencies • Initial cost of €81K with total expenditure < €200K for development • Delivers real business value reducing time of benefits payment receipt from 22 to 2 days

35. Reach Interoperability Guidelines (RIGs) • A set of documents intended to ensure interoperability of the PSB • Baseline • Intended to define the core interoperability architecture • Define the Reach XML Profile and Reach Canonical Form (RCF) • Define XML Namespace and W3C Schema profiles • Define Unicode, internationalization and versioning policies • Define a REST-style reliable messaging transfer protocol • Provide general service development guidelines • Define the structure of the Reach Envelope • Data Model • Define canonical XML elements for shared business data elements • Service Interface Protocols • Defines message exchange patterns and external policies for available services • For more information, see http://sdec.reach.ie

36. Key Requirements for the PSB

37. Centralized Access to Public Services • Ubiquitous access • Self-service via Web, phone and kiosk • Assisted phone services • Assisted walk-in services • Automated interactions • Aggregated services • Unified status reporting • User-centric • Self-management of personal details • Targeted service delivery through personalization

38. <XML/> Architectural Flexibility and Coherence RPC HTTP BTF MQSeries SOAP JMS

39. AA CS – Credential Service AA – Agency Application Reach Project Scope CS CS Identity Management for e-Government

40. PSB Technical Overview

41. Logical Architecture

42. reachservices.ie portal is just another service HTTP-based protocol boundary Architectural Layers

43. Send a message Must be in a Reach Envelope Put in “mailbox” Asynchronous operation Reach Envelope Source Destination Message type Identities Message ID Message body Receive a message Will be in a Reach Envelope Retrieve from “mailbox” Asynchronous operation Messaging Infrastructure Send <ReachEnvelope> <Version>1.7</Version> <MessageType Local=””>R1752</MessageType> <MessageSource Local=””>MXXX</MessageSource> <MessageDestination Local=””>M029</MessageDestination> <Identities> <Submitter>{TrustedHost-Principal}</Submitter> <Requestor Type=”MXXX”>{Local user name}</Requestor> <Subject Type=”PPSNo”>3853527D</Subject> </Identities> ... <Body> <R1752:PSI200FindIdentity xmlns:...> ... </R1752:PSI200FindIdentity> </Body> </ReachEnvelope> Receive

44. <R1750:PSI500AuthenticationRequest xmlns:R1750="http://sdec.reach.ie/rigs/rigs/rig1750/v0_6/schemas" xmlns:R0101="http://sdec.reach.ie/rigs/rig0101/v0_7/schemas“ xmlns:R0111="http://sdec.reach.ie/rigs/rig0111/v0_5/schemas" xmlns:R0113="http://sdec.reach.ie/rigs/rig0113/v0_8/schemas" xmlns:R0114="http://sdec.reach.ie/rigs/rig0114/v0_6/schemas" xmlns:R0115="http://sdec.reach.ie/rigs/rig0115/v0_4/schemas" xmlns:R0133="http://sdec.reach.ie/rigs/rig0133/v0_1/schemas"> <R0133:Reference> <R0133:RequestDate>2005-02-10T09:00:00</R0133:RequestDate> <R0133:RequestReference>qwerty</R0133:RequestReference> <R0133:RequestLanguageContext LanguageCode="en" /> </R0133:Reference> <R0101:PublicServiceIdentity PPSNo="1956525F"> <R0101:PersonIdentitySet> <R0111:PersonName> <R0111:FirstName Type="Forename1">RICHARD</R0111:FirstName> <R0111:LastName Type="Surname">O'DONOGHUE</R0111:LastName> <R0111:OtherName> <R0111:LastName Type="MothersBirthSurname">MURPHY</R0111:LastName> </R0111:OtherName> </R0111:PersonName> <R0101:AddressDetails Type="residential" Usage="ie.welfare.psi"> <R0114:Country> <R0114:CountryCode>IE</R0114:CountryCode> <R0114:CountryName>Ireland</R0114:CountryName> <R0114:AdministrativeArea Type="County"> <R0113:AdministrativeAreaName Code="C" Type="ie.reach.sdec.CountyName">CORK</R0113:AdministrativeAreaName> <R0114:Locality> <R0114:AddressLine Type="Line1">2 MOURNE AVE</R0114:AddressLine> <R0114:AddressLine Type="Line2">DILLONS CROSS</R0114:AddressLine> </R0114:Locality> </R0114:AdministrativeArea> </R0114:Country> </R0101:AddressDetails> <R0115:PersonInfo> <R0115:Sex>1</R0115:Sex> <R0115:BirthInfo> <R0115:BirthDate>1951-08-29</R0115:BirthDate> <R0115:DOBVerified>true</R0115:DOBVerified> </R0115:BirthInfo> </R0115:PersonInfo> </R0101:PersonIdentitySet> </R0101:PublicServiceIdentity> </R1750:PSI500AuthenticationRequest> Document-oriented Message includes all necessary context Generated by requestor agent based on user input Self-describing Each element in schema Full URI of XML schemas Modular & versioned Element re-use from 6 separate schemas “Tied together” by RIG1750 Full versioning of each separate schema RIG0133:Reference RIG0101:PublicServiceIdentity RIG0111:PersonName RIG0114:Country RIG0113:AdministrativeAreaName RIG0115:PersonInfo Example Service Request Message

45. <R1751:PSI500AuthenticationStatus xmlns:R0101="http://sdec.reach.ie/rigs/rig0101/v0_7/schemas" xmlns:R0104="http://sdec.reach.ie/rigs/rig0104/v0_5/schemas" xmlns:R0111="http://sdec.reach.ie/rigs/rig0111/v0_5/schemas" xmlns:R0113="http://sdec.reach.ie/rigs/rig0113/v0_8/schemas" xmlns:R0114="http://sdec.reach.ie/rigs/rig0114/v0_6/schemas" xmlns:R0115="http://sdec.reach.ie/rigs/rig0115/v0_4/schemas" xmlns:R0123="http://sdec.reach.ie/rigs/rig0123/v0_4/schemas" xmlns:R0124="http://sdec.reach.ie/rigs/rig0124/v0_4/schemas" xmlns:R0133="http://sdec.reach.ie/rigs/rig0133/v0_1/schemas" xmlns:R1751="http://sdec.reach.ie/rigs/rig1751/v0_6/schemas"> <R0133:Reference> <R0133:RequestDate>2005-02-10T09:00:00</R0133:RequestDate> <R0133:RequestReference>qwerty</R0133:RequestReference> <R0133:RequestLanguageContext LanguageCode="en"></R0133:RequestLanguageContext> </R0133:Reference> <R1751:Status> <R1751:StatusCode>1.5001</R1751:StatusCode> <R1751:StatusComment>Identity Confirmed</R1751:StatusComment> </R1751:Status> <R1751:PSISent> <R0101:PublicServiceIdentity PPSNo="1956525F"> <R0101:PersonIdentitySet> <R0111:PersonName> <R0111:Title></R0111:Title> <R0111:FirstName Type="Forename1">RICHARD</R0111:FirstName> <R0111:FirstName Type="Forename2"></R0111:FirstName> <R0111:MiddleName Type="OtherForenames"></R0111:MiddleName> <R0111:LastName Type="Surname">O'DONOGHUE</R0111:LastName> <R0111:Suffix></R0111:Suffix> <R0111:OtherName> <R0111:LastName Type="MothersBirthSurname">MURPHY</R0111:LastName> </R0111:OtherName> <R0111:FormerName Type="BirthSurname"> <R0111:LastName Type="Surname"></R0111:LastName> </R0111:FormerName> </R0111:PersonName> <R0101:AddressDetails Type="residential" Usage="ie.welfare.psi"> <R0114:Country> <R0114:CountryCode>IE</R0114:CountryCode> <R0114:CountryName>Ireland</R0114:CountryName> <R0114:AdministrativeArea Type="County"> <R0113:AdministrativeAreaName Code="C" Type="ie.reach.sdec.CountyName">CORK</R0113:AdministrativeAreaName> <R0114:Locality> <R0114:AddressLine Type="Line1">2 MOURNE AVE</R0114:AddressLine> <R0114:AddressLine Type="Line2">DILLONS CROSS</R0114:AddressLine> <R0114:PostalCode></R0114:PostalCode> </R0114:Locality> </R0114:AdministrativeArea> </R0114:Country> </R0101:AddressDetails> <R0101:AddressDetails Type="correspondance" Usage="ie.welfare.psi"> <R0114:Country> <R0114:AdministrativeArea Type="County"> <R0113:AdministrativeAreaName Code="" Type="ie.reach.sdec.CountyName"></R0113:AdministrativeAreaName> <R0114:Locality> <R0114:AddressLine Type="Line1"></R0114:AddressLine> <R0114:PostalCode></R0114:PostalCode> </R0114:Locality> </R0114:AdministrativeArea> </R0114:Country> </R0101:AddressDetails> <R0115:PersonInfo> <R0115:Sex>1</R0115:Sex> <R0115:BirthInfo> <R0115:BirthDate>1951-08-29</R0115:BirthDate> <R0115:DOBVerified>true</R0115:DOBVerified> </R0115:BirthInfo> <R0115:DeathInfo></R0115:DeathInfo> <R0123:Nationality>IE</R0123:Nationality> </R0115:PersonInfo> </R0101:PersonIdentitySet> </R0101:PublicServiceIdentity> </R1751:PSISent> <R1751:PSIReturned> <R0101:PublicServiceIdentity PPSNo="1956525F"> <R0101:PersonIdentitySet> <R0111:PersonName> <R0111:Title>MR</R0111:Title> <R0111:FirstName Type="Forename1">RICHARD</R0111:FirstName> <R0111:FirstName Type="Forename2"></R0111:FirstName> <R0111:MiddleName Type="OtherForenames"></R0111:MiddleName> <R0111:LastName Type="Surname">O'DONOGHUE</R0111:LastName> <R0111:Suffix></R0111:Suffix> <R0111:OtherName> <R0111:LastName Type="MothersBirthSurname">MURPHY</R0111:LastName> </R0111:OtherName> <R0111:FormerName Type="BirthSurname"> <R0111:LastName Type="Surname"></R0111:LastName> </R0111:FormerName> </R0111:PersonName> <R0101:AddressDetails Type="residential" Usage="ie.welfare.psi"> <R0114:Country> <R0114:CountryCode>IE</R0114:CountryCode> <R0114:CountryName>IRELAND</R0114:CountryName> <R0114:AdministrativeArea Type="County"> <R0113:AdministrativeAreaName Code="C" Type="ie.reach.sdec.CountyName">CORK</R0113:AdministrativeAreaName> <R0114:Locality> <R0114:AddressLine Type="Line1">2 MOURNE AVE</R0114:AddressLine> <R0114:AddressLine Type="Line2">DILLONS CROSS</R0114:AddressLine> <R0114:PostalCode></R0114:PostalCode> </R0114:Locality> </R0114:AdministrativeArea> </R0114:Country> </R0101:AddressDetails> <R0101:AddressDetails Type="correspondance" Usage="ie.welfare.psi"> <R0114:Country> <R0114:AdministrativeArea Type="County"> <R0113:AdministrativeAreaName Code="" Type="ie.reach.sdec.CountyName"></R0113:AdministrativeAreaName> <R0114:Locality> <R0114:AddressLine Type="Line1"></R0114:AddressLine> <R0114:PostalCode></R0114:PostalCode> </R0114:Locality> </R0114:AdministrativeArea> </R0114:Country> </R0101:AddressDetails> <R0115:PersonInfo> <R0115:Sex>1</R0115:Sex> <R0115:BirthInfo> <R0115:BirthDate>1951-08-29</R0115:BirthDate> <R0115:DOBVerified>true</R0115:DOBVerified> </R0115:BirthInfo> <R0115:DeathInfo></R0115:DeathInfo> <R0123:Nationality>IE</R0123:Nationality> </R0115:PersonInfo> </R0101:PersonIdentitySet> </R0101:PublicServiceIdentity> </R1751:PSIReturned> </R1751:PSI500AuthenticationStatus> Complete Response Message

46. Requestor Agent Provider Agent Integration Framework End-to-end Message Delivery

47. Canonical Service Agent Architecture JMS API MSMQ API RM4GS/JCA Apache Sandesha freebXML JBI Binding Component WS-BPEL Proprietary process language Custom code Business Process Logic Service Activator Messaging Gateway Message Transfer Protocol WS-Reliability WS-ReliableMessaging ebMS BTF RRMTP IIOP .NET Remoting WebLogic Integration BizTalk Server Engine Message-driven EJB Session EJB JBI Service Engine Custom code

48. Enforced separation of concerns Personal users cannot directly send messages Agency fulfillment users cannot access personal services Independent identity proofing Maximum registration level dependent on community Identity proofing process tailored to each community Identity Assertion Combination of registration level and authentication level Attempts to account for the integrity of the access channel reachservices.ie Personal Users Integration Framework Principals Agency Service Fulfillment Users PSB Identity Management Communities

49. 1. Can the principal access the URI? XML Principal Service Request 2. Can the principal send messages to the service? PSB Service IDMACS Access Check ServiceAccess Control Agency Service Service UI

50. What We’ve Learned So Far