Service oriented architecture - an introduction

475 views

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
475
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
63
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \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
  • Service oriented architecture - an introduction

    1. 1. Service-oriented Architecture an introduction
    2. 2. Frank van den Brink• Software Craftsman• 10+ years of software development• 1+ month at WEBclusive
    3. 3. What is SOA?
    4. 4. Benefits
    5. 5. Benefits• reusability
    6. 6. Benefits• reusability• agility
    7. 7. Benefits• reusability• agility• promotes good design
    8. 8. Benefits• reusability• agility• promotes good design• scalability
    9. 9. Benefits• reusability• agility• promotes good design• scalability• testability
    10. 10. Implementation
    11. 11. Discovery
    12. 12. Communication
    13. 13. Communication• web services are easiest
    14. 14. Communication• web services are easiest• standardize
    15. 15. Communication• web services are easiest• standardize• think it through
    16. 16. Considerations
    17. 17. Considerations• separation of concerns
    18. 18. Considerations• separation of concerns• keep it simple, stupid
    19. 19. Considerations• separation of concerns• keep it simple, stupid• mind your data model
    20. 20. Considerations• separation of concerns• keep it simple, stupid• mind your data model• stay pragmatic
    21. 21. Conclusion• SOA can be a powerful tool• Relatively easy to implement
    22. 22. Questions?
    23. 23. Thank you!• frank@webclusive.com• twitter.com/fvdb• Please rate me: joind.in/4446

    ×