Downloaded 21 times
Uploaded byJason Austin
Service Oriented Architecture
The document discusses Service Oriented Architecture (SOA). SOA has three main parts: the service provider, which creates and provides web services and access to data; the service broker, which routes requests to the appropriate provider; and the service requester, which calls services from providers. The document then discusses how BreweryDB, a database of breweries, implemented an SOA architecture with their data model as the service provider, their API as the service broker, and external users and applications as service requesters. This allowed them to improve maintainability, consistency, and decouple their data model from interfaces.
Service Oriented Architecture
- 1.
- 2. Who We Are Friday,May 17, 13
- 3. What is SOA •System Architectural Pattern • 3 Parts - Provider, Broker, Requester Friday, May 17, 13
- 4. Service Provider • Allabout Data • Creates a web service • Provides access to data layer to the Service Broker • Determines which services to expose Friday, May 17, 13
- 5. Service Broker • Allabout routing. Think Traffic Cop • Responsible for making the service available to any Service Requester • Connects the Requester to the Provider Friday, May 17, 13
- 6. Service Requester • Requeststhe desired web service form the Broker • Calls services from the Provider once connected Friday, May 17, 13
- 7. Theory & Principlesof SOA • Interoperability on different systems over a communication protocol • Service Statelessness • Service Encapsulation • Service Granularity • Service Discoverability Friday, May 17, 13
- 8. BreweryDB & SOA Friday,May 17, 13
- 9. BreweryDB 1.0 • Websitewith API • Maintainability - Tightly coupled • Data Model was small • Data structure inconsistencies Friday, May 17, 13
- 10. BreweryDB 2.0 Requirements •API First • A single way for everyone to consume the data model • Separate display from the data model • Consistency in all responses Friday, May 17, 13
- 11. BreweryDB SOA • ServiceProvider is our Data Model • MySQL + Elasticsearch + Models • Service Broker is our API • Endpoints • Service Requesters are everyone that uses BreweryDB Friday, May 17, 13
- 12. BreweryDB Data Model •Service Provider • Validation • Consistent input and output structure of data • Decoupled from response format (XML, JSON, PHP) • Decoupled from access control • Builds data relationships Friday, May 17, 13
- 13. BreweryDB API • ServiceBroker • Authentication • Return formats • Authorization • Resource routing • Error handling Friday, May 17, 13
- 14. Designing an API •Endpoint structure • Error handling • Status codes • Versioning • Return types • Request limits • Authentication Friday, May 17, 13
- 15. BreweryDB Consumers • ServiceRequesters • Single interface to our data • Documentation • Provisioning of accounts Friday, May 17, 13
- 16. What we Learnedabout SOA • Maintainability • Allows for fast iterations • Initial up front work is expensive • Not always the answer Friday, May 17, 13
- 17. Hurdles • Enumerated Fields •Website Authentication • Emails • Scaling & Performance Friday, May 17, 13
- 18.
- 19.
- 20.
- 21. DevelopmentTimeline • Planning tookroughly 3 months • Development of data model in a weekend. • Took an additional 6 months to finish the API Friday, May 17, 13
- 22. Solving the restof the Problem Friday, May 17, 13
- 23. PLA • Administration ofdata • Enumerated data fields • Data moderation • Analytics Friday, May 17, 13
- 24. BreweryDB.com • Authentication ofusers • Communication with end users • Documentation • API Key provisioning Friday, May 17, 13
- 25.