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.

Patterns&Antipatternsof SOA


Published on

This is a talk I gave on patterns and antipatterns of SOA, based on my understandings and practices and inspired by Ron Jacobs famous webcast by the same name.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Patterns&Antipatternsof SOA

  1. 1. Patterns and anti-patterns of SOA<br />Presented by:<br />Mohamed R. Samy<br />Technical Architect, MVP<br />
  2. 2. What is Architecture anyway?<br />The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them. The term also refers to documentation of a system's software architecture. Reference: Wikipedia<br />What is an architectural style? <br />Introduction<br />
  3. 3. Architectural Styles<br />
  4. 4. What is an architectures’ goal?<br />So what is SOA? <br />A style of architecture that emphasizes standards based integration.<br />Is it the best way? Is success guaranteed?<br />Introduction contd.<br />
  5. 5. Standards based integration<br />Friction free interaction/Integration<br />Communication between system components<br />The Goal of SOA<br />
  6. 6. Should loose coupling be everywhere? <br />Implicit behaviour vs. Explicit behaviour<br />Services as an interface to business processes.<br />(That is how we should think about a service when we design it)<br />The Hype<br />
  7. 7. Boundaries are explicit<br />Services are autonomous<br />Services share contract and policy not class<br />Service compatibility is determined by policy<br />The four Tenets of SOA<br />
  8. 8. Borders are Explicit<br />
  9. 9. 2 Tier (VB4-5-6) vs 3-Tier<br />Com+ (Client in Egypt, Service in Mexico)<br />In the architecture you have to know where the boundaries are.<br />Practical Example:<br />Egypt/ Libyan Border vs. Cairo/ Alex<br />Their system vs Our system (A boundary)<br />Lessons learned:<br />Authentication, Authorization<br />Communication overhead<br />TENET I :Boundaries are Explicit<br />
  10. 10. Services are Autonomous<br />
  11. 11. Able to choose<br />Self Governing<br />Self sufficient<br />Fax /Telephone between ministries<br />When the computer is down, I can still get my license (Send it later by the mail)<br />TENET II: Services are Autonomous<br />
  12. 12. Services Share Schema and Contract not Class<br />
  13. 13. XML not objects, specially not platform specific objects e.g. datasets<br />We need to agree on 2 things:<br />The protocol<br />The policy<br />Just what is required for the service to perform it’s function (Just enough validation)<br />TENET III:Services Share Contract and Policy not Class<br />
  14. 14. IT department<br />Policy like language of the system (Arabic – Russian – English)<br />Policy like http/XML/SSL ports<br />The requirements for the way the conversation is to be held<br />E.g. WS- standards (Message encryption, which parts are encrypted, what algorithm we will use to encrypt) <br />TENET IV: Service Compatibility is determined by Policy<br />
  15. 15. To understand the patterns we must take a look at the most common anti-patterns<br />Patterns/Antipatterns of SOA<br />
  16. 16. Customer. ADD/Update/ Delete<br />Why not? <br />Is updating the address just an update or is it a business process?<br />CRUDY interface<br />
  17. 17. CustomersList.MoveNext<br />Who holds the list?<br />Who controls the memory?<br />Enumeration<br />
  18. 18. 1.CustomerObject.Setflagfordelete<br />2.CustomerObject. Delete<br />Objects should not be left in an inconsistent state between message exchanges.<br />However, this is dangerous but not wrong.<br />Chatty Interface<br />
  19. 19. The perfect interface for all services:<br />XmlDocument PerformOperation(XmlDocument input)<br />Why not? Implicit behavior versus explicit behavior.<br />You need to know what you send specifically and be generic about what you receive (Just enough validation.)<br />Loosey Goosey<br />
  20. 20. To avoid this anti pattern ask 3 questions:<br />1.What does the service do? <br />2. What data does it need to do it?<br />3. What data does the service return?<br />Loosey Goosey contd.<br />
  21. 21. A flag called “zeft”, “mido” , “soso”<br />A house of cards<br />Why implicit behavior is bad<br />
  22. 22. What if the service schema changes? <br />What happens to the connected systems?<br />Versioning contracts in .NET1.1 vs .NET2.0<br />[OptionalField VersionAdded = 2]<br />Nickname<br />Why is that important?<br />Just Enough Validation<br />
  23. 23. The patterns<br />Patterns and Anti Patterns- Part2<br />
  24. 24. Patterns<br />Document Processor<br />Idempotent Message<br />Reservation<br />Some important SOA patterns<br />
  25. 25. An architectural approach to creating systems built from autonomous services<br />Integration as a fore-thought rather than an after-thought<br />A service is a program you interact with via message exchanges<br />Services are built to last<br />Availability and stability are critical<br />A system is a set of deployed services cooperating in a given task<br />Systems are built to change<br />Adapt to new services after deployment<br />SOA<br />
  26. 26. How do you create a simple to use, well defined an interface?<br />Pattern1: Document Processor<br />
  27. 27. Changing your drivers license, Giza Authority for Traffic<br />Real world examples<br />
  28. 28. 1. Start with a process<br />2. Compose a workflow<br />3. Start Defining your message contracts, before your objects and entities(try to be atomic- avoid chatty interface)<br />4.Define operations<br />Where to start<br />
  29. 29. 5. Group your operations into services<br />Tips: <br />1. Do not use platform specific types e.g. datasets.<br />2. Decouple Internal vs. External objects<br />3. Use TDD so you know you are thinking about the service consumer, now you know how it feels.<br />Where to start contd.<br />
  30. 30. Context<br />You are building a web service<br />Problem<br />How do you create a simple to use, well defined an interface?<br />Forces<br />Your interface should <br />Encourage document centric thinking<br />Define a clear semantic in the contract<br />Promote loose coupling through encapsulation of the implementation<br />Be easy to consume from any platform (WS-I base profile)<br />Represent a business process as a complete unit of work<br />Pattern1: Document Processor <br />
  31. 31. Solution: Document Processor<br />public FindCustomerByCountryResponse FindCustomersByCountry( FindCustomerByCountryRequest request)<br />{<br /> // Do something....<br />}<br />-Encourage document centric thinking by defining a schema (XSD) for request and response messages in your project<br />-Generate objects from your schema to simplify development<br />-Remember this is a boundary so don’t leak internals<br />
  32. 32. Do not leak internal abstractions<br />
  33. 33. Generate Data transfer objects<br />
  34. 34. Transition at the boundary<br />
  35. 35. Benefits<br />Consumers think about sending and receiving business documents which are naturally more granular<br />The boundary of the system involves conversion from internal structures to external documents<br />The implementation details of the system are encapsulated<br />The service is more consumable from other platforms and can evolve more easily<br />Liabilities<br />Performance will suffer with transfers of data from internal to external structures<br />Resulting context<br />
  36. 36. Should I use the same schema for multiple services or should each service have its own schema?<br />Opinion: Give each service its own schema<br />Sharing schema makes it difficult to evolve each service independently and introduces unnecessary churn for service consumers<br />Design Question<br />
  37. 37. How do I handle duplicate messages received at my service?<br />Pattern2: Idempotent Message<br />
  38. 38. Context<br />You are developing a web service for your SOA<br />You heard that messages should be idempotent<br />Problem<br />How do you insure that messages are idempotent?<br />Forces<br />You cannot expect anything more from the sender than what the contract defines for your service<br />You are working with a transactional database system with frequent updates<br />Indempotent messages<br />
  39. 39. Sender tags message with a request ID<br />Your contract can specify that this is required<br />Your contract cannot insist that the ID is unique across time<br />The ID tags a unit of work which will be done only once<br />Receiver must check to see if the unit of work has already been done before doing it<br />Then what?<br />Solution<br />
  40. 40. Option1: return a cached response<br />Option2: Process the message again.<br />Option3: Throw an exception<br />Solution Options<br />
  41. 41. You will have to cache responses for some period of time – how long?<br />What if the current value is different than the cached value?<br />What if the response was an error?<br />What if the sender sends duplicate IDs for different units of work?<br />Option1: Return a cached response<br />
  42. 42. Great for reads, what about writes?<br />Should we withdraw $1000 from a checking account twice?<br />Option2: Process the message again<br />
  43. 43. Did the sender get the original response?<br />How does he get the original response if you are sending him and exception?<br />Option 3: Throw and exception<br />
  44. 44. UOW ID can be a part of the request schema<br />Implies duplicate handling is part of the business process<br />UOW ID can be a custom SOAP header<br />Implies duplicate handling is part of the message processing infrastructure<br />Create a schema for the SOAP header<br />Having a URI for immediate sender can be helpful to detect reentrancy<br />Data changes should be traceable to a UOW ID<br />Your cached responses may need to reflect what the response was at the time when the request was received<br />Solutions<br />
  45. 45. Benefits<br />Your service autonomy is increased by not having to rely on consumer to do the right thing<br />You won’t fool yourself into thinking that reliable messaging will solve this problem<br />Liabilities<br />Your service will consume potentially large amounts of durable storage caching responses<br />Your service will take a performance hit for cache management<br />Pattern3: Indempotent message<br />
  46. 46. How do you maintain data consistency across a long running process?<br />Pattern3: Reservation Pattern<br />
  47. 47. Context<br />You are building a service oriented application<br />You have a complex business process that you want to expose to your customers with a web service<br />Problem<br />How do you maintain data consistency across a long running process?<br />Forces<br />You cannot share a distributed transaction<br />The business process requires several messages to complete<br />The message exchange process could take anywhere from seconds to hours<br />Reservation pattern<br />
  48. 48. Reservation pattern illustrated<br />Reserve part: 49389<br />Qty: 200<br />Reservation ID: 14432<br />Expires: 2004-09-15 02:43:53Z<br />Confirm reservation: 14432 PO #49839<br />Reservation: 14432<br />Receipt: 29389<br />PO #49839<br />
  49. 49. Know the concepts before you write the code<br />SOA is not web services<br />SOA is about standards based integration and friction free interaction between systems<br />SOA is not a silver bullet<br />Summary<br />
  50. 50. Web services<br />WCF<br />Biztalk ESB<br />SOA Technologies<br />
  51. 51. (Webcasts)<br /> (Cool tech blog)<br /><br /> (under construction)<br /> (P&P)<br />References:<br />
  52. 52. Email:<br />Facebook<br />@msamy<br />Contacts<br />
  53. 53. Questions?<br />