Service Oriented Architectures

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

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.

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

A shared service is something that would have been carried out in each department and is now carried out centrally by one department. Examples... HR – hiring process, annual reviews Finance – purchase requisition

Example of inter-departmental services Requests to inventory for availability information

SOA and business 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.

In SOA, reuse is achieved with integration through service definitions: A service allows an existing application capability to be accessed (and hence reused) by other applications in the enterprise The system is accessed by multiple other systems to utilise a particular

capability of that system Distinct from code reuse when the same code is built into multiple

systems

Why SOA has emerged now…Technology drivers

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 JEE, .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

Leads to the natural maturing of approaches and ability to increase the level of abstraction Once technology is well understood and mature, IT typically moves to a more abstract level

required to address the next level of problems

Why SOA has emerged now…Business drivers

Acceptance of the shared services and service provider business model

Increased need to share data and information more generally

Recognition of the cost and impact on agility of duplication of system functionality

A maturing understanding of the cost and issues associated with previous approaches to integration. This has encouraged both business and IT to consider how integration can

be better achieved

8

Implementing a SOA SOA is an architecture

Can be implemented using many different technologies But architecture must come first

Aims of the architecture: Increase reuse and agility Span the entire enterprise = work across technology platforms

Technology Implementation Options all of Custom code JEE + Custom code EAI/ Enterprise Service Bus Web Services

Identifying business services for SOAFulfil

shipmentProcess

orderHire

employeeProcess invoice

Business ServiceWith SLA

If the business services are automated, they may be the basis for a SOA service Capabilities should already be available in a system

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

Linking business services and system

Fulfil shipment

Process order

Hire employee

Process invoice


The business services must then be linked to the existing system’s capabilities in a way which is Clearly defined using standard policies, practices, and frameworks to

make it easier for users in other parts of the organisation to use the service

Clearly described (usually with XML) Abstractions of the underlying business logic and functionality

independent of technology platform and implementation

CICSOn

Mainframe.NetJEE

Logistics System

Sales System

HR System

FinanceSystem Systems

Technology platforms

Relationship between a service and a system

Fulfil shipment

Process order

Hire employee

Process invoice


Generally, Services use one or more software components to satisfy some business functionalityFor example, the “Schedule Mortgage Closing” service may involve execution of many components (modules) in the underlying IT system

CICSOn

Mainframe.NetJEE

Logistics System

Sales System

HR System

FinanceSystem Systems

Technology platformsFulfil shipment:

(1)Place request in queue(2)Schedule transport(3)Order transport if necessary(4)etc

Fulfil shipment Process order Hire employee Process

invoice

CICSOn

Mainframe.NetJEE

Defining a SOA service from top to bottom

12

Logistics System

Fulfil shipment

Process order

Hire employee

Process invoice

Sales System

HR System

FinanceSystem


Systems


Fulfil shipment Process order Hire employee Process

invoice

Service description

Business level

Interface levelFulfil shipment Process order Hire employee Process

invoice

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

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

JEE

Defining a SOA service from top to bottom – in more detail

15

Logistics System

Fulfil shipment


Systems


Fulfil shipment

Service description

Business level

Interface levelFulfil shipment

1. Description of the service with reference to businessservice

2. High level technical description of the service

3. Description of access mechanisms to serviceSuch as use of a queue or message format

4.Description of interface in ‘native’ format (i.e. Java API)

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

17

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

Web Services != SOA?

18

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/ContractReuseDesign

ImplementTest

Traditional SOA

19

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.

20

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

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

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

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: 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

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

APPENDIX: RULES FOR DESIGNING SERVICES

Not part of the examinable material

28

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

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.

31

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.

33

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 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

Documents

Service Oriented Architectures