Speaker Deck Pro
May 08, 2012
An overview of how and when to use Service-Oriented Architecture principles in your web application.
May 08, 2012
More Decks by Barun Singh
See All by Barun Singh
Other Decks in Programming
See All in Programming
See All Featured
Using SOA… in moderation Barun Singh firstname.lastname@example.org Founder & CTO
Principles of SOA Nomenclature & details on SOA are confusing.
The basic idea is simple.
Principles of SOA “The Motherload” Service A Service B Service
C System 2 System 3
Principles of SOA • Your app does lots of things
• These things are related, but distinct • Think of these things as services
A service should: • Be capable of running independently •
Have a distinct purpose • Have a well-deﬁned protocol for interaction • Provide business value
A “service” is like… Object Oriented Business!
A “service” is like… Classes Modules Engines Services } The
same basic principles at different levels
A “service” is like…
Advantages Separation of concerns Simpler code Easier onboarding More business
opportunities Environment ﬂexibility
Disadvantages Serialized requests Network overhead Multiple apps More staging environments
Synchronization Deployment Irrelevant tests
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?
Should I split X oﬀ into a service? Look at
your ERD to evaluate the cost. High cost Low cost
aka The Awesome Real-world example
aka The Awesome Pull data from utilities Analytics Visualization Benchmarking
aka The Awesome Analytics Visualization Benchmarking Compliance aka The Extractor
data Pull data from utilities Business opportnuity + technical need
aka The Awesome Analytics Visualization Benchmarking aka The Extractor data
Pull data from utilities aka The Ofﬁcer 5oh Compliance Business opportnuity + technical need Simplicity + Relevance
SOA is a hammer. Not everything is a nail.