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

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

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

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

9. Identifying business services for SOA
With SLA
Fulfil shipment
Process order
Hire employee
Process invoice
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

10. Linking business services and system
With SLA
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
Logistics System
Sales System HR
System
Finance
System
Systems
JEE
.Net
CICS
On Mainframe
Technology
platforms

11. Relationship between a service and a system
Business Service
With SLA
Fulfil shipment
Process order
Hire employee
Process invoice
Generally, Services use one or more software components to satisfy some business functionality
For example, the “Fufill shipment” service may involve execution of many components (modules) in the underlying IT system
Fulfil shipment
Process order
Hire employee
Process invoice
Logistics System
Sales System HR
System
Finance
System
Systems
JEE
.Net
CICS
On Mainframe
Technology
platforms
Fulfil shipment:
Place request in queue
Schedule transport
Order transport if necessary
etc

12. Defining a SOA service from top to bottom
Business Service
With SLA
Fulfil shipment
Process order
Hire employee
Process invoice
Fulfil shipment
Process order
Hire employee
Process invoice
Business level . . . .
Service
description
Fulfil shipment
Process order
Hire employee
Process invoice
Interface level
Logistics System
Sales System HR
System
Finance
System
Systems
JEE
.Net
CICS
On Mainframe
Technology
platforms

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 14

15. Defining a SOA service from top to bottom – in more detail
Business Service
With SLA
Fulfil shipment
1. Description of the service with reference to business service
Fulfil shipment
Business level
2. High level technical description of the service
Service
description
3. Description of access mechanisms to service
Such as use of a queue or message format
Fulfil shipment
4.Description of interface in ‘native’ format (i.e. Java API)
Interface level
Logistics System
Systems
JEE
Technology
platforms

16. 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. 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
However, Web Services remains an implementation option for lighter weight requirements

18. 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
Fund/Contract
Generate
Adapt
Construct
Fund/Contract
Reuse
New
Services
Design
Implement
Test
Integration
Testing
Solution
Solution

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

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

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

24. Rules for designing services

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

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

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

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

29. Designing a service: Granularity
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 29 29

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