Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2006 - DDD4: Decoupling service oriented backend systems

  • Be the first to comment

  • Be the first to like this

2006 - DDD4: Decoupling service oriented backend systems

  1. 1. Decoupling Service Oriented Backend Systems Michael Willers Senior Software Architect Daniel Fisher(lennybacon) Software Architect
  2. 2. Objectives  You at least heared of that SOA thing ;-)
  3. 3. Questions  Decoupling  What is it good for?  What can/should be decoupled? And why?  How can it be achived?
  4. 4. Isn’t it amazing? • No computers • No workflow engine • No spreadsheets • No spell check • No email • No databases • No document store • No phone at every desk • And yet, it worked…
  5. 5. • Risk Assessment • Rate Calculations • Claims Handling • Sales Support • Accounting • Archiving • Marketing • Mail Handling • … Departments
  6. 6. The Mail Boys • Formal communication is relayed “by foot” • Files are picked up and delivered by a small army of mail boys • Central dispatching from mail office or direct • Routing via notes on folders or files The Mail Office
  7. 7. Processes Clerk knows what’s next Decisions influence next step and destination Steps triggered by input, yield outputDept A Dept Q Dept T
  8. 8. Formalized Communication • Efficient communication flow requires formalization • Information easier to find • Information easier to supply • Safer from legal perspective
  9. 9. Department = Service • Offers specialized expertise and renders a set of well-known, well-defined services to the organization • Publishes or otherwise advertises the concrete services offered • Formalizes communication for how information must be supplied for services to be carried out
  10. 10. Department Function = Operation • A specific task rendered by a department • “Write invoice reminder” offered by accounts receivables • Requires existing invoice as input • May be triggered from within department (receivables management) or form outside
  11. 11. Employee = Service Instance • Employee is an instance of a service – Plays one or more roles in a workflow • Might maintains “session” for context – Notes, file about customer, activities • “Employees” may be people or “digital” – Deterministic work is a good candidate for digital employee work
  12. 12. Letters & Files = Messages • Routed through organization • Drive the workflow • Each employee knows where to route to based on workflow instruction and decision made Dept A Dept Q Dept T
  13. 13. Consequences • Process drives the organization • Everything and everybody acts as service • Everything and everybody consumes and yields messages • To the process it doesn’t matter whether a service is implemented by software or people
  14. 14. What does it mean? • Avoid Coupling / Autonomy – Services control their own contract. – Services can evolve independent of others.
  15. 15. Confused Already? • “Service Oriented” – Policy – Explicit Boundaries – Avoid Coupling – Contract and Schema • “SOA” Service – Policy – Explicit Boundaries – Autonomy – Contract and Schema Even in software architecture, there are two concepts floating for SO/SOA: Implication: Interoperability and loose coupling Implication: Interoperability and loose coupling plus autonomous computing! This is what was meant when the tenets were defined This is what was written when the tenets were defined
  16. 16. Service Orientation Resource Orientation Service Orientation vs. Resource Orientation
  17. 17. BlueBooks • Service Oriented Example Application • Architectural blueprint for service oriented backend systems • Implements "yet another" online bookstore  • Implementation based on Windows Communication Foundation
  18. 18. A Service Unit • Egde – Separates protocol and transport details from the business logic – Acts as the security boundary • Host – Provides the execution environment for the agent • Agent – Forwards calls to the core implementation – Performs additional activities (e.g. Logical message delivery) • Core – The business logic
  19. 19. A Service Unit Trust Boundary Edge Job Queue Database NT Service Implementation Event Log
  20. 20. Summary • This project is a architectural blueprint for service oriented backend systems • Service Orientation is really about autonomous computing • Autonomous computing is about decoupling • Decoupling enables asyncronicity and scalability

    Be the first to comment

    Login to see the comments

Views

Total views

275

On Slideshare

0

From embeds

0

Number of embeds

1

Actions

Downloads

1

Shares

0

Comments

0

Likes

0

×