Service oriented architecture - an introduction
•Transferir como KEY, PDF•
1 gostou•368 visualizações
Deciding on a software architecture that promotes modularity, scalability, clear separation of concerns and code reuse is an important part of any big software project. Service Oriented Architecture helps you do this. In this talk I'll give an introduction to SOA in general, and how you can apply it to the design of web applications.
Recomendados
Mais conteúdo relacionado
Último
Último (20)
Destaque
Destaque (20)
Service oriented architecture - an introduction
- 1. Service-oriented Architecture an introduction
- 2. Frank van den Brink • Software Craftsman • 10+ years of software development • 1+ month at WEBclusive
- 3. What is SOA?
- 5. Benefits
- 8. Benefits • reusability • agility • promotes good design
- 9. Benefits • reusability • agility • promotes good design • scalability
- 10. Benefits • reusability • agility • promotes good design • scalability • testability
- 11. Implementation
- 12. Discovery
- 14. Communication
- 15. Communication • web services are easiest
- 16. Communication • web services are easiest • standardize
- 17. Communication • web services are easiest • standardize • think it through
- 18. Considerations
- 19. Considerations • separation of concerns
- 20. Considerations • separation of concerns • keep it simple, stupid
- 21. Considerations • separation of concerns • keep it simple, stupid • mind your data model
- 22. Considerations • separation of concerns • keep it simple, stupid • mind your data model • stay pragmatic
- 23. Conclusion • SOA can be a powerful tool • Relatively easy to implement
- 24. Questions?
- 25. Thank you! • frank@webclusive.com • twitter.com/fvdb • Please rate me: joind.in/4446
Notas do Editor
- \n
- - who am i\n- story about recreating things over and over again\n- contents/outline (what, benefits, implementation)\n
- - when researched, a lot of material is available\n- definition is somewhat unclear\n- community around the concept is fragmented\n- even results in SOA manifesto\n- simple explanations are hard to find\n
- - at the core, SOA software components > reusable services\n- example: user service, search service, logging service\n- should be familiar to most web devs\n- BUT, key requirements\n - interoperability across systems & platforms\n - federation of services; standardization\n
- - reusability: services are created for the org as, DRY, faster time to market\n bigger business value\n- agility: autonomous development, not tied to techs, room to experiment\n allows for evolving functionality vs creating a perfect architecture\n promotes innovation\n- promotes g design: decoupling, generalization, SepOfConcern, easier to test, easier to scale\n
- - reusability: services are created for the org as, DRY, faster time to market\n bigger business value\n- agility: autonomous development, not tied to techs, room to experiment\n allows for evolving functionality vs creating a perfect architecture\n promotes innovation\n- promotes g design: decoupling, generalization, SepOfConcern, easier to test, easier to scale\n
- - reusability: services are created for the org as, DRY, faster time to market\n bigger business value\n- agility: autonomous development, not tied to techs, room to experiment\n allows for evolving functionality vs creating a perfect architecture\n promotes innovation\n- promotes g design: decoupling, generalization, SepOfConcern, easier to test, easier to scale\n
- - reusability: services are created for the org as, DRY, faster time to market\n bigger business value\n- agility: autonomous development, not tied to techs, room to experiment\n allows for evolving functionality vs creating a perfect architecture\n promotes innovation\n- promotes g design: decoupling, generalization, SepOfConcern, easier to test, easier to scale\n
- - reusability: services are created for the org as, DRY, faster time to market\n bigger business value\n- agility: autonomous development, not tied to techs, room to experiment\n allows for evolving functionality vs creating a perfect architecture\n promotes innovation\n- promotes g design: decoupling, generalization, SepOfConcern, easier to test, easier to scale\n
- - nothing really new, uses tech most of us already know\n- there are however, two key things that you need to get right\n
- - discovery is the act of finding your services and knowing how to talk to them\n- to have a federation, this should be standardized\n- could be a static list, or you could create a lookup service\n
- - one way, a dedicated service broker which manages and serves service descriptions\n- could be WSDL and SOAP\n- could be REST and a simple lookup file\n- Standardize, and think it through\n- can be hard to change later\n
- - communication between your applications and the services\n- several ways to do this, easiest is web services\n- could also use CORBA, or a message bus, or pubsubhubbub\n- as long as you standardize, stay consistent\n- will be very hard to change once in use\n
- - communication between your applications and the services\n- several ways to do this, easiest is web services\n- could also use CORBA, or a message bus, or pubsubhubbub\n- as long as you standardize, stay consistent\n- will be very hard to change once in use\n
- - communication between your applications and the services\n- several ways to do this, easiest is web services\n- could also use CORBA, or a message bus, or pubsubhubbub\n- as long as you standardize, stay consistent\n- will be very hard to change once in use\n
- - SoC: services should focus on one thing, and one thing only\n single purpose, and know as little as possible about the outside\n- KISS: keep services dumb, stateless, and assume as little as possible about the outside world\n interfaces should be clean and straightforward\n- Data: Law of Demeter, Principle of Least knowledge\n- Pragmatism\n
- - SoC: services should focus on one thing, and one thing only\n single purpose, and know as little as possible about the outside\n- KISS: keep services dumb, stateless, and assume as little as possible about the outside world\n interfaces should be clean and straightforward\n- Data: Law of Demeter, Principle of Least knowledge\n- Pragmatism\n
- - SoC: services should focus on one thing, and one thing only\n single purpose, and know as little as possible about the outside\n- KISS: keep services dumb, stateless, and assume as little as possible about the outside world\n interfaces should be clean and straightforward\n- Data: Law of Demeter, Principle of Least knowledge\n- Pragmatism\n
- - SoC: services should focus on one thing, and one thing only\n single purpose, and know as little as possible about the outside\n- KISS: keep services dumb, stateless, and assume as little as possible about the outside world\n interfaces should be clean and straightforward\n- Data: Law of Demeter, Principle of Least knowledge\n- Pragmatism\n
- - Increase reuse, and innovation, increasing business value\n- Considering concerns, uses technologies we already know and use regularly\n- I think it’s worth to look at if you develop lots of apps or want to scale\n- Now I hope you do too\n- THANK YOU!\n
- \n
- - If you want to contact me, you can do so via EMAIL or TWITTER\n- I would really appreciate it if you could rate me on joind.in to tell me how I did and how I can do better\n- THANKS AGAIN\n
- \n