doag 2012 - soa made simple: service design
DESCRIPTION
This presentation provides a summary of the Service Design chapter of the upcoming SOA Made Simple book. Services are key a key aspect of any SOA. Once you have identified what services your clients require, you can start designing these services by designing their operations, and the input and output of these operations. Service design principles indicate what qualities a service needs to have in order to be a usable building block in the architecture you are trying to achieve. When services are poorly designed or poorly implemented, your solution architecture will probably have little value for the business as well. What we need are sound design principles that help us as a service provider to create (re)useable services, and help us as service consumer to judge if the services that we use (or want to use) are well designed ones. This presentation includes several service design principles and quality-of-service aspects that can be used as checklist when creating, buying, or reviewing services. Such design principles include isolation and idempotency. Most important is that services need to be easy to use, must provide value, and that they can be trusted by (future) consumers.TRANSCRIPT
![Page 1: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/1.jpg)
1 | x
SOA Made Simple: Service Design
Ronald van Luttikhuizen
21-November-2012 | DOAG 2012
![Page 2: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/2.jpg)
2 | x
Ronald van Luttikhuizen • Managing Partner at Vennster
• Oracle ACE Director for Fusion Middleware and SOA
• Author of different articles, co-author Oracle SOA Book 11g book
• Upcoming book SOA Made Simple
• Architect, consultant, trainer for Oracle, SOA, EDA, Java
• More than 10 years of software development and architecture
experience
• Contact: [email protected]
• Blog: blog.vennster.nl
• Twitter: rluttikhuizen
![Page 3: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/3.jpg)
3 | x
Agenda
1. Introduction
2. Service Identification
3. Service Design
4. Service Implementation
5. Services and Oracle
6. Summary
![Page 4: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/4.jpg)
4 | x
Introduction
1. So why do we need SOA
2. The Solution
3. Service Design
4. Classification of Services
5. The Building Blocks of SOA
6. Solution Architectures
7. Creating a Roadmap
8. Lifecycle Management
9. Pick your Battles
10. Methodologies and SOA
Lonneke Dikmans 22-Nov-2012 | 13-14h
Approach to SOA Oracle OpenWorld 2011 slideshare.net/lonneked
![Page 5: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/5.jpg)
5 | x
What is a Service ?
Parts of a service
● Contract
● Interface
● Implementation
“Something useful a provider does for a
consumer”
![Page 6: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/6.jpg)
6 | x
What is a Service ?
[OASIS]
“A service is a mechanism to enable access to one or more capabilities, where the access is provided using a
prescribed interface and is exercised consistent with constraints and policies as specified by the service
description.”
![Page 7: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/7.jpg)
7 | x
What is a Service ? | example: SOAP Web Service
<wsdl:service name="OrderService">
<wsdl:operation name="orderProduct">
<wsdl:input message="order:OrderProductRequestMessage"/>
<wsdl:output message="order:OrderProductResponseMessage"/>
<wsdl:fault message="order:ProductNotInStockFaultMessage"
name="ProductNotInStockFault"/>
</wsdl:operation>
<wsdl:operation name="cancelOrder">
<wsdl:input message="order:CancelOrdeRequestMessage"/>
<wsdl:output message="order:CancelOrderResponseMessage"/>
<wsdl:fault message="order:UnknownOrderFaultMessage"
name="UnknownOrderFault"/>
</wsdl:operation>
</wsdl:service>
Types
● Business
● Information
● Technical
Example: SOAP WS
● Service
● Operation
● Input
● Output
● Fault
![Page 8: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/8.jpg)
8 | x
What is a Service ?
Roles
● Consumers
● Provider
● Owner
● Hosting provider
● Administrator
OrderService
Contract: Free to use, High availability (99,1%),
Response time < 5s, Owner
Interface: Web Service described by WSDL, WS-Security
UserName Token
Implementation: Java (JPA, JAX-WS)
![Page 9: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/9.jpg)
9 | x
Agenda
1. Introduction
2. Service Identification
3. Service Design
4. Service Implementation
5. Services and Oracle
6. Summary
“What services do we actually need based on
the requirements of our clients?”
![Page 10: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/10.jpg)
10 | x
Service Identification
Approaches
● Meet-in-the-middle
● Iterative
Scope
● In scope • Services
● Out of scope • Operations
• Input, output, faults
• Implementation
Governance
● Registry & repository
Gap-analysis
● Reuse, buy or make
Top-Down
Bottom-Up
OrderService
InvoiceService
DocumentService
PrintService
CustomerService
PaymentService
InventoryService
![Page 11: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/11.jpg)
11 | x
Service Identification
![Page 12: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/12.jpg)
12 | x
Agenda
1. Introduction
2. Service Identification
3. Service Design
4. Service Implementation
5. Services and Oracle
6. Summary
“I have identified the services that I need,
now what?”
Business Case
Real Project with Real
Customers
![Page 13: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/13.jpg)
13 | x
Service Design | what to do?
● Define the functionality it offers
● Design the interface
• Operations
• Effect, input and output (incl. faults)
• Test cases
● Design the contract
• Owner, cost, other contractual information
• Quality-of-Service (QoS): availability, load, security, and so on
● Design the implementation
• Tools, languages
• Components
• Tools for testing
![Page 14: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/14.jpg)
14 | x
Service Design | what’s important?
Guidelines
● Provide value
● Meaningful
● Hide implementation
● Interoperable
Guidelines
● Trustworthy
● Idempotent
● Isolated
Design Guidelines: How to build or buy usable service. Guidelines can be both technical and non-technical.
Build: Improve and speed-up implementation (supply), validate conformity and (re)usability (demand)
Buy: Compare offerings, validate conformity and usability
Considerations
● Granularity
● Reusability
![Page 15: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/15.jpg)
15 | x
Design Guideline | trustworthiness
No trust, no use…
● Contract
● Testing
● Security • Automated security mechanisms
• Interoperable security measures
• Include in contract
• Transport- vs message-level security
● Fault prevention and handling • Differentiate: business, user interaction,
technical/software
• Include business faults in interface
• Exception shielding
http://geekandpoke.typepad.com/
![Page 16: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/16.jpg)
16 | x
Design Guideline | idempotency
Invoking a service more than once should
yield the same result:
● Robust and predictable services
● Perception of trust
Idempotency and state
Example: SalaryService
• SalaryService.increaseSalary • SalaryService.setSalary
![Page 17: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/17.jpg)
17 | x
Design Guideline | isolation
Service operations need to be self-
sufficient:
● Ease of use (only invoke one
operation)
● Flexibility (no cascading changes)
Also known as autonomy, loose-coupling
or decoupling
Example: PrintService
• PrintService.print • PrintService.setProfile
![Page 18: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/18.jpg)
18 | x
Design Consideration | granularity
Services are of different importance based on the degree of value they add:
● Big enough to provide value on its own
● Small enough to be able to change it
● Derive granularity from functionality
● Hand in hand with transaction boundaries
Need for a classification
How granular should a service and its operations be?
or How big should my lasagna be?
![Page 19: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/19.jpg)
19 | x
Service Consideration | reusability
a service is used by more than one consumer or is meant to be used by more than one consumer in the future:
● Not a goal on its own
● Save money and time vs loss in flexibility
● Impact of changes on other consumers
Added value vs generic/specific vs reusability
![Page 20: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/20.jpg)
20 | x
Agenda
1. Introduction
2. Service Identification
3. Service Design
4. Service Implementation
5. Services and Oracle
6. Summary
![Page 21: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/21.jpg)
21 | x
Service Implementation | approaches
Bottom-Up Meet-in-the-Middle
Examples: Exposing DB using Adapter, Generating
WS for Java class
Examples: Combining Mediator and
Adapter, JAX-WS and JPA
Top-Down (Contract-First)
Example: Greenfield
![Page 22: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/22.jpg)
22 | x
Agenda
1. Introduction
2. Service Identification
3. Service Design
4. Service Implementation
5. Services and Oracle
6. Summary
![Page 23: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/23.jpg)
23 | x
Services and Oracle
![Page 24: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/24.jpg)
24 | x
Agenda
1. Introduction
2. Service Design
3. Service Implementation
4. Services and Oracle
5. Summary
![Page 25: DOAG 2012 - SOA Made Simple: Service Design](https://reader033.vdocument.in/reader033/viewer/2022052321/5566a442d8b42acd288b4d5e/html5/thumbnails/25.jpg)
25 | x
Summary
● Design guidelines help you to build and buy useable
services
● Don’t design before you have an actual consumer
Important guidelines
• Provide value, meaningful, hide implementation,
interoperable, isolated, trustworthy, and idempotent
● Important considerations:
• Granularity, reusability
● If you want to know more about services and SOA …