• Save
SOA Made Simple | Introduction to SOA
Upcoming SlideShare
Loading in...5
×
 

SOA Made Simple | Introduction to SOA

on

  • 1,881 views

A lot of organizations are implementing, or want to implement, Service Oriented Architecture to support their goals. Service Oriented Architecture is a natural step in the evolution of Information ...

A lot of organizations are implementing, or want to implement, Service Oriented Architecture to support their goals. Service Oriented Architecture is a natural step in the evolution of Information Technology; we started out with big systems in universities and banks, and moved to desktop computers in the workplace and at home. We are now moving to solutions in the cloud, offering services to consumers and businesses alike, adding mobile computing to the mix. So what is a service? A service is something that has value. Service orientation is not a difficult concept to grasp, everyone knows services and uses them daily; think of a hotel that offers a shuttle service to the nearest airport. Or the hairdresser that cuts your hair. This presentation introduces SOA, using a practical and simple approach. It is done without overly complex abstractions, but with examples from different industries and hands-on experience.

Statistics

Views

Total Views
1,881
Views on SlideShare
1,856
Embed Views
25

Actions

Likes
3
Downloads
0
Comments
0

1 Embed 25

https://twitter.com 25

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    SOA Made Simple | Introduction to SOA SOA Made Simple | Introduction to SOA Presentation Transcript

    • 1 | 23 SOA Made Simple: Introduction to SOA Ronald van Luttikhuizen 2-October-2013 | Development team meeting
    • 2 | 23 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: ronald.van.luttikhuizen@vennster.nl • Blog: blog.vennster.nl • Twitter: rluttikhuizen
    • 3 | 23 SOA Made Simple 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
    • 4 | 23 Agenda 1. Why SOA 2. What is a service 3. Service Identification 4. Service Design 5. Service Implementation 6. Services and Oracle 7. Summary
    • 5 | 23 Why SOA | Duplication of functionality
    • 6 | 23 Why SOA | Mismatch business and IT
    • 7 | 23 Why SOA | Duplication of functionality 1. Flexibility Services are small building blocks with a limited and clear set of capabilities. 2. Standardization Based on open standards. 3. Cost reduction Reuse instead of duplicate functionality and data. 4. Increase in quality More consumers use a service, it is better tested. Less data duplication, single point of access to data.
    • 8 | 23 Agenda 1. Why SOA 2. What is a service 3. Service Identification 4. Service Design 5. Service Implementation 6. Services and Oracle 7. Summary
    • 9 | 23 What is a Service ? Parts of a service ● Contract ● Interface ● Implementation “Something useful a provider does for a consumer”
    • 10 | 23 What is a Service ? Roles ● Consumers ● Provider ● Owner ● Hosting provider 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)
    • 11 | 23 Agenda 1. Why SOA 2. What is a service 3. Service Identification 4. Service Design 5. Service Implementation 6. Services and Oracle 7. Summary “What services do we actually need based on the requirements of our clients?”
    • 12 | 23 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 ● Buy or make Top-Down Bottom-Up OrderService InvoiceService DocumentService PrintService CustomerService PaymentService InventoryService
    • 13 | 23 Agenda 1. Why SOA 2. What is a service 3. Service Identification 4. Service Design 5. Service Implementation 6. Services and Oracle 7. Summary “I have identified the services that I need, now what?” Business Case Real Project with Real Customers
    • 14 | 23 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
    • 15 | 23 Service Design | what’s important? Guidelines ● Provide value ● Meaningful ● Hide implementation ● Interoperable Guidelines ● Trustworthy ● Idempotent ● Isolated Design Guidelines: How to create and buy usable services. Build: Improve and speed-up implementation (supply), validate conformity and (re)usability (demand) Buy: Compare offerings, validate conformity and usability Considerations ● Granularity ● Reusability
    • 16 | 23 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/
    • 17 | 23 Design Guideline | idempotency Invoking a service more than once should yield the same result: ● Robust and predictable services ● Perception of trust Idempotency and state (cluster) Example: SalaryService • SalaryService.increaseSalary • SalaryService.setSalary
    • 18 | 23 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
    • 19 | 23 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?
    • 20 | 23 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
    • 21 | 23 Agenda 1. Why SOA 2. What is a service 3. Service Identification 4. Service Design 5. Service Implementation 6. Services and Oracle 7. Summary
    • 22 | 23 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
    • 23 | 23 Agenda 1. Why SOA 2. What is a service 3. Service Identification 4. Service Design 5. Service Implementation 6. Services and Oracle 7. Summary
    • 24 | 23 Services and Oracle
    • 25 | 23 Agenda 1. Why SOA 2. What is a service 3. Service Design 4. Service Implementation 5. Services and Oracle 6. Summary
    • 26 | 23 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 …
    • 27 | 23 Thank you! Ronald van Luttikhuizen ronald.van.luttikhuizen@vennster.nl