service oriented architectures an architectural model for integration
Post on 20-Dec-2015
215 Views
Preview:
TRANSCRIPT
Service Oriented Architectures
An architectural model for integration
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
What is SOA about?
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 requires well defined business services to be defined which can be easily and quickly used and used again.
SOA also implements a lot of what is already good enterprise architecture practice.
IT Governance is central to SOA
What are business services?
Business services are facilities provided by 1 business department to another E.g. invoice processing, shipping, registration of a new student
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.
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
Implementing Business Services with SOA
Services are reusable units providing business functionality that are implemented as software services which: Are defined using standard policies, practices, and frameworks Are clearly described (usually with XML) Are autonomous Are 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
A software system supporting a service is called a service provider. The client system accessing the service is called a service consumer.
SOA and Existing Applications
Many existing applications already expose some of their functionality as services
Most vendors of software now provide mechanisms to create services to access existing functionality
Business processes and data that are currently “trapped in silos” can be exposed via SOA
However, they should only be made services if there is a business need.
SOA 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
9
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
However, Web Services remains an implementation option for lighter weight requirements Alternatively, SOA can be implemented in JEE, .Net, or anything else or any
combination of the above
Is Web Services the same as SOA?
Why SOA emerged
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.
Guidelines for designing SOA services
Note: These rules apply to any service definition in distributed computing because SOA leverages best practice
12
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
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
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.
Designing a service: The implicit data model
The implicit data model can be
Close to the internal data model of the application: Bad Approach: Use the existing internal data model and expose it through the
service. Easy for the developer of the application but requires consumers to map to that
data model which may be hard.
Close to the data model of the first consumer: Bad Approach: design the service to make access by the first consumer easy –
typically by designing the data model to be easy for that first consumer to use. Data model can’t be simply designed for the first consumer as the requirements
may not suit other consumers.
A neutral model designed to promote reuse: Good Approach: Design the data model to match short term requirements and longer
term requirements- Requires analysis of likely requirements as well as known requirements.
16
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
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.
18
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
Designing a service: Coarse-Grained Communication
Services in SOA should map directly to a business function or activity Will be more coarse-grained than typical IT objects and components
and frequently services
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. 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
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.
20
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
SOA Implementation
22
SOA requires a new development model
Order &Requirements
Fund/Contract
Solution
AnalyseRequirements
Solution
SOABest practices
New Services
Service ComponentReuse Library
ComponentComponentGenerate
AdaptConstruct
IntegrationTesting
Fund/ContractFund/ContractFund/Contract
ReuseDesignImplement
Test
Traditional SOA
23
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.
24
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
25
SOA Development Model
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
26
The need for 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).
27
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
28
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
Roles of SOA Governance
Governance is needed to police and enable: 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
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
Planning an SOA
Pragmatic and most common approach to SOA planning Constraints: Limited funding and resources Step 1: Focus on a good-fit project
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 (individuals from other business
areas) and domain experts (individuals with knowledge of particular types of problems)
Complete project Step 3: Publicise findings of initial project
If the project is successful, this will ensure funding of future projects
Real-world advice: Planning an SOA
Step 4: Start building key SOA artifacts incrementally Define best practices and policies and disseminate to other
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 implement individual SOA projects 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
Example: Irish Government
A Bearing Point presentation from Mitre eGov conference
Andrew S. Townley
Principal ArchitectReach Public Services Broker
Ronan Bradley’s comments areShown like this.
34
Agenda
Reach and its mission
Key project requirements
PSB technical overview
Lessons learnedPublic Service Broker
35
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
“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)."
“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 Mission:
36
Reach Governance
Social Security
Information Society
Public Service Reform
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 thePrime Minister
Department of Socialand Family Affairs
Department ofFinance
Reach
Note the emphasis on governance
37
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
38
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
39
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
40
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
Key Requirements for the PSB
42
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
43
Architectural Flexibility and Coherence
<XML/>
HTTPBTF
RPC
MQSeries SOAP
JMS
44
Identity Management for e-Government
CSCS
AACS – Credential ServiceAA – Agency Application
Reach ProjectScope
PSB Technical Overview
46
Logical Architecture
47
Architectural Layers
HTTP-based protocolboundary
reachservices.ieportal is just
another service
48
Messaging Infrastructure
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
Send
Receive
<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>
49
Example Service Request Message <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
RIG0101:PublicServiceIdentity
RIG0114:Country
RIG0113:AdministrativeAreaName
RIG0115:PersonInfoRIG0115:PersonInfo
RIG0133:Reference
RIG0111:PersonName
50
Complete Response Message <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>
51
End-to-end Message Delivery
Integration FrameworkRequestor Agent Provider Agent
52
Canonical Service Agent Architecture
BusinessProcess
Logic
ServiceActivator
MessageTransferProtocol
MessagingGateway
WS-BPELProprietary process language
Custom code
JMS APIMSMQ API
RM4GS/JCAApache Sandesha
freebXMLJBI Binding Component
WS-ReliabilityWS-ReliableMessaging
ebMSBTF
RRMTPIIOP
.NET Remoting
WebLogic IntegrationBizTalk Server Engine
Message-driven EJBSession EJB
JBI Service EngineCustom code
53
PSB Identity Management Communities
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
Agency Service Fulfillment Users
Integration Framework Principals
reachservices.ie Personal Users
54
Service Access Control
IDMACS Access Check
PSB Service
Principal Service UI
XML
ServiceRequest
Agency Service
1. Can the principal access the URI?
2. Can the principal send messages to the service?
What We’ve Learned So Far
56
When to Use “Standards”
If they are sufficiently mature Can be based on individual assessment or vendor implementations You understand the parts that are missing or broken The fundamental aspects are not under revision Just because a specification is published doesn’t make it a standardJust because a specification is published doesn’t make it a standard
If they fit the problem you’re trying to solve Pay attention to the 80/20 rule Does the benefit justify the cost? Technology and specifications are notare not in the driver’s seat
Everything should be made as simple as possible, but no simpler– Albert Einstein
57
Technology Operational Costs
Allow incremental adoption based on ROI for the participants No more “big bang” deployments SOA means as long as you do the what the how isn’t as important
Pay attention to licensing and upgrade costs Understand your platform and deployment constraints Be prepared for unexpected adoption rates that could affect TCO
Minimize assumptions and dependencies Service implementations should be “black boxes” Just because a service is deployed here today doesn’t mean it won’t be deployed in
another environment tomorrow
Monitoring, diagnosis and manual intervention is critical Operations needs consistent, accurate views of the running system Don’t forget about “priority manual intervention” and build in the mechanisms
58
Interoperability It’s about the messages
Identify the fundamental information used by a business process The data will be around a lot longer than the systems that process it
Specify the essentials, let the rest vary Core data elements and their meanings Reliability constraints Invocation interface Think “the Internet”
Embrace loose coupling Tools, technologies and techniques are generally transient Isolate the moving parts—hide them behind standardized interfaces Minimize centralized control—let the participants own their
processes
59
Engagement with Government Agencies Don’t underestimate organizational dynamics
Each agency has a unique personality and way of doing things Encourage collaboration, not mandatory adoption of “one true way” “You can lead a horse to water…”
Set realistic expectations Early adopters will likely bear the brunt of the costs ROI will be incremental, and generally not immediate Spell out data and process ownership, reconciliation and failure recovery
scenarios Offer added value
Federated identity management provides access to registered user base Auditing, logging and non-repudiation of message exchanges
Offer incremental adoption Agency capabilities are not all equal Essential to deliver capabilities to the SOA quickly and cost-effectively
60
Service Implementation
Build the right levels of abstractions Easy to make services too fine-grained Don’t worry about details not relevant to what the service does
Strive for portability Design and build for change Well-defined interfaces between business logic and message transfer
Strive for cost-effective scaling Scale out, not up Minimize statefulness Don’t accidentally depend on tools and capabilities you don’t really need
Build a service, not an application The service should be generally useful, not tied to a given requestor
61
Further Information The reachservices portal: http://www.reachservices.ie/ The Services and Data Exchange Catalog (SDEC): http://
sdec.reach.ie/ PSB Service Design Guidelines, rig0019:
http://sdec.reach.ie/rigs/rig0019/ The Reach Envelope, rig0100: http://sdec.reach.ie/rigs/rig0100/ RRMTP, rig0007: http://sdec.reach.ie/rigs/rig0007/ PSB requirements and tender documents: http://www.reach.ie
/procurement/ Inter-Agency Messaging Service information: http://
www.reach.ie/iams/ EU e-Government case study #625 on REACH IAMS (2003):
http://unpan1.un.org/intradoc/groups/public/documents/other/unpan022024.pdf
62
top related