Service-Oriented Architecture

An overview of how and when to use Service-Oriented Architecture principles in your web application.

Transcript

1. Using SOA… in moderation Barun Singh bsingh@wegowise.com Founder & CTO
2. Principles of SOA Nomenclature & details on SOA are confusing. The basic idea is simple.
3. Principles of SOA “The Motherload” Service A Service B Service C System 2 System 3
4. Principles of SOA •  Your app does lots of things •  These things are related, but distinct •  Think of these things as services
5. A service should: •  Be capable of running independently •  Have a distinct purpose •  Have a well-defined protocol for interaction •  Provide business value
6. A “service” is like… Object Oriented Business!
7. A “service” is like… Classes Modules Engines Services } The same basic principles at different levels
8. A “service” is like…
9. Advantages Separation of concerns Simpler code Easier onboarding More business opportunities Environment flexibility
10. Disadvantages Serialized requests Network overhead Multiple apps More staging environments Synchronization Deployment Irrelevant tests
11. Should X be a service? •  Is X a core component of your main app? •  Is it useful outside of your main app? •  Does it have special environment needs •  Does it make sense standing on its own?
12. Should I split X off into a service? Look at your ERD to evaluate the cost. High cost Low cost
13. aka The Awesome Real-world example
14. aka The Awesome Pull data from utilities Analytics Visualization Benchmarking Compliance
15. aka The Awesome Analytics Visualization Benchmarking Compliance aka The Extractor data Pull data from utilities Business opportnuity + technical need
16. aka The Awesome Analytics Visualization Benchmarking aka The Extractor data Pull data from utilities aka The Officer 5oh Compliance Business opportnuity + technical need Simplicity + Relevance
17. SOA is a hammer. Not everything is a nail.
19. Questions? bsingh@wegowise.com