Patterns&Antipatternsof SOA

Patterns and anti-patterns of SOAPresented by:Mohamed R. SamyTechnical Architect, MVP

What is Architecture anyway?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: WikipediaWhat is an architectural style? Introduction

What is an architectures’ goal?So what is SOA? A style of architecture that emphasizes standards based integration.Is it the best way? Is success guaranteed?Introduction contd.

Standards based integrationFriction free interaction/IntegrationCommunication between system componentsThe Goal of SOA

Should loose coupling be everywhere? Implicit behaviour vs. Explicit behaviourServices as an interface to business processes.(That is how we should think about a service when we design it)The Hype

Boundaries are explicitServices are autonomousServices share contract and policy not classService compatibility is determined by policyThe four Tenets of SOA

2 Tier (VB4-5-6) vs 3-TierCom+ (Client in Egypt, Service in Mexico)In the architecture you have to know where the boundaries are.Practical Example:Egypt/ Libyan Border vs. Cairo/ AlexTheir system vs Our system (A boundary)Lessons learned:Authentication, AuthorizationCommunication overheadTENET I :Boundaries are Explicit

Able to chooseSelf GoverningSelf sufficientFax /Telephone between ministriesWhen the computer is down, I can still get my license (Send it later by the mail)TENET II: Services are Autonomous

Services Share Schema and Contract not Class

XML not objects, specially not platform specific objects e.g. datasetsWe need to agree on 2 things:The protocolThe policyJust what is required for the service to perform it’s function (Just enough validation)TENET III:Services Share Contract and Policy not Class

IT departmentPolicy like language of the system (Arabic – Russian – English)Policy like http/XML/SSL portsThe requirements for the way the conversation is to be heldE.g. WS- standards (Message encryption, which parts are encrypted, what algorithm we will use to encrypt) TENET IV: Service Compatibility is determined by Policy

To understand the patterns we must take a look at the most common anti-patternsPatterns/Antipatterns of SOA

Customer. ADD/Update/ DeleteWhy not? Is updating the address just an update or is it a business process?CRUDY interface

CustomersList.MoveNextWho holds the list?Who controls the memory?Enumeration

1.CustomerObject.Setflagfordelete2.CustomerObject. DeleteObjects should not be left in an inconsistent state between message exchanges.However, this is dangerous but not wrong.Chatty Interface

The perfect interface for all services:XmlDocument PerformOperation(XmlDocument input)Why not? Implicit behavior versus explicit behavior.You need to know what you send specifically and be generic about what you receive (Just enough validation.)Loosey Goosey

To avoid this anti pattern ask 3 questions:1.What does the service do? 2. What data does it need to do it?3. What data does the service return?Loosey Goosey contd.

A flag called “zeft”, “mido” , “soso”A house of cardsWhy implicit behavior is bad

What if the service schema changes? What happens to the connected systems?Versioning contracts in .NET1.1 vs .NET2.0[OptionalField VersionAdded = 2]NicknameWhy is that important?Just Enough Validation

The patternsPatterns and Anti Patterns- Part2

PatternsDocument ProcessorIdempotent MessageReservationSome important SOA patterns

An architectural approach to creating systems built from autonomous servicesIntegration as a fore-thought rather than an after-thoughtA service is a program you interact with via message exchangesServices are built to lastAvailability and stability are criticalA system is a set of deployed services cooperating in a given taskSystems are built to changeAdapt to new services after deploymentSOA

How do you create a simple to use, well defined an interface?Pattern1: Document Processor

Changing your drivers license, Giza Authority for TrafficReal world examples

1. Start with a process2. Compose a workflow3. Start Defining your message contracts, before your objects and entities(try to be atomic- avoid chatty interface)4.Define operationsWhere to start

5. Group your operations into servicesTips: 1. Do not use platform specific types e.g. datasets.2. Decouple Internal vs. External objects3. Use TDD so you know you are thinking about the service consumer, now you know how it feels.Where to start contd.

ContextYou are building a web serviceProblemHow do you create a simple to use, well defined an interface?ForcesYour interface should Encourage document centric thinkingDefine a clear semantic in the contractPromote loose coupling through encapsulation of the implementationBe easy to consume from any platform (WS-I base profile)Represent a business process as a complete unit of workPattern1: Document Processor

Solution: Document Processorpublic FindCustomerByCountryResponse FindCustomersByCountry( FindCustomerByCountryRequest request){ // Do something....}-Encourage document centric thinking by defining a schema (XSD) for request and response messages in your project-Generate objects from your schema to simplify development-Remember this is a boundary so don’t leak internals

Do not leak internal abstractions

Generate Data transfer objects

BenefitsConsumers think about sending and receiving business documents which are naturally more granularThe boundary of the system involves conversion from internal structures to external documentsThe implementation details of the system are encapsulatedThe service is more consumable from other platforms and can evolve more easilyLiabilitiesPerformance will suffer with transfers of data from internal to external structuresResulting context

Should I use the same schema for multiple services or should each service have its own schema?Opinion: Give each service its own schemaSharing schema makes it difficult to evolve each service independently and introduces unnecessary churn for service consumersDesign Question

How do I handle duplicate messages received at my service?Pattern2: Idempotent Message

ContextYou are developing a web service for your SOAYou heard that messages should be idempotentProblemHow do you insure that messages are idempotent?ForcesYou cannot expect anything more from the sender than what the contract defines for your serviceYou are working with a transactional database system with frequent updatesIndempotent messages

Sender tags message with a request IDYour contract can specify that this is requiredYour contract cannot insist that the ID is unique across timeThe ID tags a unit of work which will be done only onceReceiver must check to see if the unit of work has already been done before doing itThen what?Solution

Option1: return a cached responseOption2: Process the message again.Option3: Throw an exceptionSolution Options

You will have to cache responses for some period of time – how long?What if the current value is different than the cached value?What if the response was an error?What if the sender sends duplicate IDs for different units of work?Option1: Return a cached response

Great for reads, what about writes?Should we withdraw $1000 from a checking account twice?Option2: Process the message again

Did the sender get the original response?How does he get the original response if you are sending him and exception?Option 3: Throw and exception

UOW ID can be a part of the request schemaImplies duplicate handling is part of the business processUOW ID can be a custom SOAP headerImplies duplicate handling is part of the message processing infrastructureCreate a schema for the SOAP headerHaving a URI for immediate sender can be helpful to detect reentrancyData changes should be traceable to a UOW IDYour cached responses may need to reflect what the response was at the time when the request was receivedSolutions

BenefitsYour service autonomy is increased by not having to rely on consumer to do the right thingYou won’t fool yourself into thinking that reliable messaging will solve this problemLiabilitiesYour service will consume potentially large amounts of durable storage caching responsesYour service will take a performance hit for cache managementPattern3: Indempotent message

How do you maintain data consistency across a long running process?Pattern3: Reservation Pattern

ContextYou are building a service oriented applicationYou have a complex business process that you want to expose to your customers with a web serviceProblemHow do you maintain data consistency across a long running process?ForcesYou cannot share a distributed transactionThe business process requires several messages to completeThe message exchange process could take anywhere from seconds to hoursReservation pattern

Reservation pattern illustratedReserve part: 49389Qty: 200Reservation ID: 14432Expires: 2004-09-15 02:43:53ZConfirm reservation: 14432 PO #49839Reservation: 14432Receipt: 29389PO #49839

Know the concepts before you write the codeSOA is not web servicesSOA is about standards based integration and friction free interaction between systemsSOA is not a silver bulletSummary

Web servicesWCFBiztalk ESBSOA Technologies

www.arcast.tv (Webcasts)www.geekswithblogs.net/Mohamed (Cool tech blog)www.msdn.com/Architecturewww.thevstsguy.com (under construction)www.msdn.microsoft.com/practices (P&P)References:

Email: m_raafat_samy@hotmail.comFacebook@msamyContacts

Patterns&Antipatternsof SOA

Recommended

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Patterns&Antipatternsof SOA (20)

More from Mohamed Samy (11)

Recently uploaded (20)

Patterns&Antipatternsof SOA

Editor's Notes