SOA Systems Design
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

SOA Systems Design

on

  • 205 views

Service Oriented Architecture Systems Design Patterns.

Service Oriented Architecture Systems Design Patterns.

Statistics

Views

Total Views
205
Views on SlideShare
205
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 1. Network is reliable. Message/data canbe lost when sent over the wire. Failure bySwitch goes up in smoke, power outage, someone trips over networkcord, new security settings Firewall/SP21. Solutions: reliable messaging infrastructure (MSMQ, Sql Server service broker). Rollyourown. Ack& retry, Store & Forward2. LatencyReasonably small for a LAN, not so small for a WAN, and significant over the internet~ 1000 times slower than in-memory accessIf a remote object has 10 properties and you access them one by one, you pay 10 round-trips crossing the network 20 times2. Solutions: Don’t cross the networkifyoudon’t have to. Ifyouneedto cross it, take all the data you MIGHT needwithyou.3. BandwithAlthough bandwidth keeps growing, the amount of data grows fasterWhen transferring lots of data in a given period of time, network congestion may interfere3. Solution: Move time-critical data to separate networks. Prioritize calls4. The topology does not changeUnless a server goes down and is replaced. Or is moved to a different subnetOr clients wirelessly connect and disconnect. What will happen to the application when those hard coded / config-file values change?4. Solution: Don’t hard code IP addresses
  • Soa Tenet - 1. Services are autonomous.
  • Guaranteed delivery
  • Explaintransactionalmessage handlingShow MSMQ queues
  • In order to avoid spatial coupling, we have a mapping between message type & destinationIf we have subscribed to a message type, then we have a handler for itTherefore, registering that handler with the communications infrastructure is enough to express “subscribe”The infrastructure will send its own subscribe messageWhen the communications infrastructure receives a “subscribe” message, it saves the return address.
  • One service is authorisedtopublish eventsEvents: Stay away from DB thinking – no CRUDThink about business status changes
  • Bus architectural styleEvent sources and sinks communicate via channels in the busSource place events (messages) in channels, sinks are notified about message availabilityUse the Bus for SOA services, use Broker for integration of off the shelf software (PeopleSoft / SAP)

SOA Systems Design Presentation Transcript

  • 1. | 25-06-2012 | Alexander van Trijffel 18-06-2012 Your business technologists. Powering progress © Confidential Service Oriented Architecture Systems Design Alexander van Trijffel
  • 2. | 25-06-2012 | Alexander van Trijffel 2 Agenda ▶ The network ▶ Coupling ▶ Messaging ▶ Reliability ▶ Services ▶ Service decomposition
  • 3. | 25-06-2012 | Alexander van Trijffel Connectivity – The network matters ▶ Common assumptions made by developers and architects in distributed systems • The network is reliable • Latency isn’t a problem • Bandwidth isn’t a problem • The network is secure • The topology won’t change • The administrator will know what to do • Transport cost isn’t a problem • The network is homogeneous 3
  • 4. | 25-06-2012 | Alexander van Trijffel “The 8 fallacies of distributed computing” 1. The network is reliable 2. Latency isn’t a problem 3. Bandwidth isn’t a problem 4. The network is secure 5. The topology won’t change 6. The administrator will know what to do 7. Transport cost isn’t a problem 8. The network is homogeneous 4 Deutsch 94 Gosling 97
  • 5. | 25-06-2012 | Alexander van Trijffel Coupling ▶ What is coupling? – A measure of dependencies – If X depends on Y, there is coupling between them – 2 kinds of coupling: – Afferent (Ca) - Who depends on you – Efferent (Ce) - On who do you depend
  • 6. | 25-06-2012 | Alexander van Trijffel Loose coupling at the systems level ▶ Attempt to minimize afferent and efferent coupling ▶ 3 Different aspects of coupling for systems: – Platform – Temporal – Spatial
  • 7. | 25-06-2012 | Alexander van Trijffel Coupling Aspect: Platform ▶ Also known as “Interoperability” ▶ Using protocols only available on one platform – Remoting – Enterprise Services/COM+ – Datasets over Web Services ▶ One of the 4 Tenets of Service Orientation: – “Share contract and schema, not class or type”
  • 8. | 25-06-2012 | Alexander van Trijffel Coupling Aspect: Temporal Service A Synchronous Call Waiting Working Return Service B The processing time of Service B affects that of A
  • 9. | 25-06-2012 | Alexander van Trijffel Coupling aspect: Spatial Service A Service B
  • 10. | 25-06-2012 | Alexander van Trijffel Coupling aspect: Spatial Service A Service B
  • 11. | 25-06-2012 | Alexander van Trijffel Coupling aspect: Spatial Service A Service B Service B ? Can communication automatically continue?
  • 12. | 25-06-2012 | Alexander van Trijffel Coupling solutions
  • 13. | 25-06-2012 | Alexander van Trijffel Coupling Aspect #1: Platform ▶ XML on the wire. ▶ XSD (schema) describing XML structure ▶ Use standards based transfer protocol like http ▶ Standards based description of message flow – WSDL
  • 14. | 25-06-2012 | Alexander van Trijffel Coupling Aspect #2: Temporal - 1 Service A Service B Customer GetCustomerInfo(id) Calling thread is waiting for the result MakeCustomerPreferred(id) Save customer as preferred Bad. Resources are held while waiting.
  • 15. | 25-06-2012 | Alexander van Trijffel Coupling Aspect #2: Temporal - 2 Resources are held while waiting. Increased load on service B per consumer (impacted by polling interval) Service A Service B YieldCustomerInfo(id) MakeCustomerPreferred(id) Spawn polling thread Got data? Data ready Got data? Got data? Save customer as preferred Data ready but not passed to consumer
  • 16. | 25-06-2012 | Alexander van Trijffel Coupling Aspect #2: Temporal - final Good. By separating (in time) the inter-service communication and the request handling Service A Service B Publish updated customer infoStore data MakeCustomerPreferred(id) Save customer as preferred
  • 17. | 25-06-2012 | Alexander van Trijffel Coupling Aspect #3: Spatial ▶ Application level code should not need to know where cooperating services are on the network ▶ Delegate communications to “something else”, let’s call it an “agent” for now. – myAgent.Send(message); ▶ But if the application code doesn’t tell the agent which logical destination to send the message to, how would the agent know? ▶ If there was a direct mapping from message type to logical destination, then specifying the type of message being sent/published would be enough
  • 18. | 25-06-2012 | Alexander van Trijffel Message Type = Logical Destination ▶ AddCustomerMessage: – Sent by clients to one logical server – Multiple physical servers behind a load balancer if required ▶ OrderCancelledEventMessage: – Published by one logical server ▶ Strongly-typed messages simplify routing
  • 19. | 25-06-2012 | Alexander van Trijffel Messaging ▶ Asynchronous: One-way, fire & forget messages ▶ Why messaging? ▶ Reduces coupling – Use XML for platform coupling – Use asynchronous messaging for temporal coupling ▶ Reduces Afferent and Efferent coupling while increasing autonomy
  • 20. | 25-06-2012 | Alexander van Trijffel Performance – RPC vs Messaging ▶ With RPC, threads are allocated with load – With messaging, threads are independent – Difference based on blocking nature of communication ▶ Memory, DB locks, held longer with RPC Throughput Load RPC Messaging
  • 21. | 25-06-2012 | Alexander van Trijffel Reliability ▶ When servers crash ▶ When databases are down ▶ When deadlocks occur in the database
  • 22. | 25-06-2012 | Alexander van Trijffel When Servers Crash DBApp [HTTP] $$ Order Tx Call 1 of 3 Call 2 of 3 Critical Windows Patch Rollback Where’s the order!?
  • 23. | 25-06-2012 | Alexander van Trijffel When Deadlocks Happen TxApp [HTTP] $$ Order DB Call 1 of 3 Deadlock Exception Write to log A B Call 2 of 3 Where’s the order!?
  • 24. | 25-06-2012 | Alexander van Trijffel Securing client requests with Messaging TxQ$$ Order App Receive DB Call 1 of 3 Rollback Call 2 of 3 Rollback The order is back in the queue
  • 25. | 25-06-2012 | Alexander van Trijffel Calling Web Services A B C D WS DB [HTTP] Invoke $$ Order Deadlock Rollback Not Rolled back
  • 26. | 25-06-2012 | Alexander van Trijffel Messaging Gateway A B C D WS Msg DB $$ Order [HTTP] Invoke The message won’t be sent if there’s a failure
  • 27. | 25-06-2012 | Alexander van Trijffel Durable Messaging Server Client MSMQ MSMQ IncomingOutgoing Outgoing Incoming Store and Forward adds resilience
  • 28. | 25-06-2012 | Alexander van Trijffel Message types
  • 29. | 25-06-2012 | Alexander van Trijffel Standard message handling ▶ Problem is that service layers get too large ▶ Difficult for multiple developers to collaborate ▶ Difficult to reuse logging, authorization, etc Customer Service void ChangeAddress(Guid id, Address a); void MakePreferred(Guid id); void ChangeCredit(Guid id, Credit c);
  • 30. | 25-06-2012 | Alexander van Trijffel Exploit strongly-typed messages IMessage where T : IMessage IHandleMessages<T> void Handle(T message);
  • 31. | 25-06-2012 | Alexander van Trijffel Represent methods as messages IMessage ChangeAddress MakePreferred ChangeCredit
  • 32. | 25-06-2012 | Alexander van Trijffel Handling Logic Separated IHandleMessages<T> void Handle(T message); H1:IHandleMessages<ChangeAddress> H2:IHandleMessages<MakePreferred> H3: IHandleMessages<ChangeCredit>
  • 33. | 25-06-2012 | Alexander van Trijffel Multiple handlers per message H1:IHandleMessages<ChangeAddress> H4:IHandleMessages<ChangeAddressV2> Authorization: IHandleMessages<IMessage> ▶ Dispatch based on type polymorphism ▶ Allows for pipeline of handler invocation ▶ As side effect less merge change conflicts
  • 34. | 25-06-2012 | Alexander van Trijffel Demo ▶ Sending a and receiving a message using the bus
  • 35. | 25-06-2012 | Alexander van Trijffel Messaging patterns ▶ Return Address ▶ Correlated Request/Response ▶ Publish Subscribe
  • 36. | 25-06-2012 | Alexander van Trijffel Return Address Pattern – Send / Reply 2 Channels: one for requests, one for responses Return Address Target Service Return Address Some time in the future Initiating Service
  • 37. | 25-06-2012 | Alexander van Trijffel Correlated Request/Response Target Service Some time in the future Initiating Service Ticket (guid) Ticket (guid) In the header of the response message, there is a correlation id equal to the request message id
  • 38. | 25-06-2012 | Alexander van Trijffel Publish / Subscribe Service A Service B Publish updated customer infoStore data MakeCustomerPreferred(id) Save customer as preferred
  • 39. | 25-06-2012 | Alexander van Trijffel Publisher Subscriber Subscribe Subscriber Subscriber Subscriber Subscriber
  • 40. | 25-06-2012 | Alexander van Trijffel Publisher Subscriber Subscriber Subscriber Subscriber Subscriber MyEvent MyEvent MyEvent MyEvent MyEvent
  • 41. | 25-06-2012 | Alexander van Trijffel Demo ▶ Publishing an event
  • 42. | 25-06-2012 | Alexander van Trijffel What is a service? ▶ A service is the technical authority for a specific business capability. ▶ All data and business rules reside within the service.
  • 43. | 25-06-2012 | Alexander van Trijffel What a service is NOT ▶ A service that has only functionality is a function, not a service. – Like check if order is valid ▶ A service that has only data is a database, not a service. – Like [create, read, update, delete] entity
  • 44. | 25-06-2012 | Alexander van Trijffel Technical properties of a service ▶ A service may have multiple end points ▶ A service may communicate over multiple protocols and transports ▶ A service is responsible for its own availability and scalability
  • 45. | 25-06-2012 | Alexander van Trijffel Service deployments ▶ Many services can be deployed to the same box ▶ Many services can be deployed in the same app ▶ Many services can cooperate in a workflow ▶ Many services can be mashed up in the same page
  • 46. | 25-06-2012 | Alexander van Trijffel Service Examples Subscribe to Customer Status Updated Publish Customer Status Updated Save status locally Subscribe to Product Pricing Updated Publish Product Pricing Updated Save pricing locally Place Order Publish Order Accepted Sales MarketingCustomer care
  • 47. | 25-06-2012 | Alexander van Trijffel Which service owns this page?
  • 48. | 25-06-2012 | Alexander van Trijffel Which service owns this page? None
  • 49. | 25-06-2012 | Alexander van Trijffel Same page composition Server Product Catalog Pricing Inventory Cross Sell
  • 50. | 25-06-2012 | Alexander van Trijffel Amazon.com checkout workflow
  • 51. | 25-06-2012 | Alexander van Trijffel Which service owns this flow?
  • 52. | 25-06-2012 | Alexander van Trijffel Which service owns this flow? None
  • 53. | 25-06-2012 | Alexander van Trijffel Workflow composition Shipping Billing Sales Billing BillingShipping ShippingMarketing
  • 54. | 25-06-2012 | Alexander van Trijffel Autonomous Components ▶ The large-scale business capability that a service provides can be further broken down ▶ A service is composed of one or more Autonomous Components ▶ An AC takes responsibility for a specific set of message types in the service ▶ Autonomous Components are the unit of deployment in SOA ▶ An AC uses the bus to communicate with other ACs. Is independently deployable, has its own endpoint
  • 55. | 25-06-2012 | Alexander van Trijffel Flexibility in deployment ▶ Any number of autonomous components (ACs) can be deployed to a single machine ▶ Or even a single process ▶ Or have a single AC deployed on each machine
  • 56. | 25-06-2012 | Alexander van Trijffel Bus Topology App Bus.dll App Bus.dll App Bus.dll App Bus.dll App Bus.dll App Bus.dll App Bus.dll App Bus.dll
  • 57. | 25-06-2012 | Alexander van Trijffel Scalability ▶ Since each autonomous component maintains its state in the database of its service ▶ We can have a number of servers each running an instance of the same autonomous component
  • 58. | 25-06-2012 | Alexander van Trijffel Scaling out an AC Autonomous Component Distributor ACI ACI ACI Ready Autonomous Component Instance on each machine
  • 59. | 25-06-2012 | Alexander van Trijffel www.atos.net Atos, the Atos logo, Atos Consulting, Atos Worldline, Atos Sphere, Atos Cloud and Atos WorldGrid are registered trademarks of Atos SA. June 2011 © 2011 Atos. Confidential information owned by Atos, to be used by the recipient only. This document, or any part of it, may not be reproduced, copied, circulated and/or distributed nor quoted without prior written approval from Atos. Your business technologists. Powering progress © Confidential Your business technologists. Powering progress © Confidential www.atos.net Atos, the Atos logo, Atos Consulting, Atos Worldline, Atos Sphere, Atos Cloud and Atos Worldgrid are registered trademarks of Atos SA. July 2011 © 2011 Atos. Confidential information owned by Atos, to be used by the recipient only. This document, or any part of it, may not be reproduced, copied, circulated and/or distributed nor quoted without prior written approval from Atos. Thank You For more information, please contact : Alexander van Trijffel