DOAG 2012 - SOA Made Simple: Service Design
26
1 | x SOA Made Simple: Service Design Ronald van Luttikhuizen 21-November-2012 | DOAG 2012
-
Upload
ronald-van-luttikhuizen -
Category
Documents
-
view
595 -
download
2
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 of DOAG 2012 - SOA Made Simple: Service Design
1 | x
SOA Made Simple: Service Design
Ronald van Luttikhuizen
21-November-2012 | DOAG 2012
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
3 | x
Agenda
1. Introduction
2. Service Identification
3. Service Design
4. Service Implementation
5. Services and Oracle
6. Summary
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
5 | x
What is a Service ?
Parts of a service
● Contract
● Interface
● Implementation
“Something useful a provider does for a
consumer”
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.”
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
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)
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?”
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
11 | x
Service Identification
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
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
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
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/
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
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
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?
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
20 | x
Agenda
1. Introduction
2. Service Identification
3. Service Design
4. Service Implementation
5. Services and Oracle
6. Summary
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
22 | x
Agenda
1. Introduction
2. Service Identification
3. Service Design
4. Service Implementation
5. Services and Oracle
6. Summary
23 | x
Services and Oracle
24 | x
Agenda
1. Introduction
2. Service Design
3. Service Implementation
4. Services and Oracle
5. Summary
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 …
