Patterns Anti Patterns of So A

8/2/2019 Patterns Anti Patterns of So A

1/53

Presented by:Mohamed R. Samy

Technical Architect, Geek


2/53

What is Architecture anyway?

The software architecture of a program orcomputing system is the structure orstructures of the system, which comprise

software components, the externally visibleproperties of those components, and therelationships between them. The term alsorefers to documentation of a system's

software architecture. Reference: Wikipedia

What is an architectural style?


3/53


4/53

What is an architectures goal? So what is SOA?

A style of architecture that emphasizes standardsbased integration.

Is it the best way? Is success guaranteed?


5/53

Standards based integration

Friction free interaction/Integration

Communication between system components


6/53

Should loose coupling be everywhere?

Implicit behaviour vs. Explicit behaviour

Services as an interface to businessprocesses.

(That is how we should think about a service

when we design it)


7/53

Boundaries are explicit

Services are autonomous

Services share contract and policy not class

Service compatibility is determined by policy


8/53


9/53

2 Tier (VB4-5-6) vs 3-Tier Com+ (Client in Egypt, Service in Mexico)

In the architecture you have to know where

the boundaries are. Practical Example:

Egypt/ Libyan Border vs. Cairo/ Alex

Their system vs Our system (A boundary)

Lessons learned: Authentication, Authorization

Communication overhead


10/53


11/53

Able to choose Self Governing

Self sufficient

Fax /Telephone between ministries When the computer is down, I can still get my

license (Send it later by the mail)


12/53


13/53

XML not objects, specially not platformspecific objects e.g. datasets

We need to agree on 2 things: The protocol

The policy

Just what is required for the service toperform its function (Just enough validation)


14/53

IT department Policy like language of the system (Arabic

Russian English)

Policy like http/XML/SSL ports

The requirements for the way theconversation is to be held

E.g. WS- standards (Message encryption,

which parts are encrypted, what algorithm wewill use to encrypt)


15/53

To understand the patterns we must take alook at the most common anti-patterns


16/53

Customer. ADD/Update/ Delete Why not?

Is updating the address just an update or is it abusiness process?


17/53

CustomersList.MoveNext Who holds the list?

Who controls the memory?


18/53

1.CustomerObject.Setflagfordelete2.CustomerObject. Delete

Objects should not be left in an inconsistentstate between message exchanges.

However, this is dangerous but not wrong.


19/53

The perfect interface for all services:

XmlDocument PerformOperation(XmlDocumentinput)

Why not? Implicit behavior versus explicitbehavior.

You need to know what you send specificallyand be generic about what you receive (Just

enough validation.)


20/53

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?


21/53

A flag called zeft, mido , soso A house of cards


22/53

What if the service schema changes? What happens to the connected systems?

Versioning contracts in .NET1.1 vs .NET2.0[OptionalField VersionAdded = 2]

Nickname

Why is that important?


23/53

The patterns


24/53

Patterns Document Processor

Idempotent Message

Reservation


25/53

An architectural approach to creating systemsbuilt from autonomous services Integration as a fore-thought rather than an after-

thought

A service is a program you interact with viamessage exchanges Services are built to last

Availability and stability are critical

A system is a set of deployed servicescooperating in a given task Systems are built to change

Adapt to new services after deployment


26/53

How do you create a simple to use, welldefined an interface?


27/53

Changing your drivers license, Giza Authorityfor Traffic


28/53

1. Start with a process

2. Compose a workflow

3. Start Defining your message contracts,before your objects and entities(try to beatomic- avoid chatty interface)

4.Define operations


29/53

5. Group your operations into services

Tips:

1. Do not use platform specific types e.g. datasets.

2. Decouple Internal vs. External objects

3. Use TDD so you know you are thinking about the serviceconsumer, now you know how it feels.


30/53

Context You are building a web service

Problem

How do you create a simple to use, well defined an interface?

Forces

Your interface should

Encourage document centric thinking

Define a clear semantic in the contract

Promote loose coupling through encapsulation of theimplementation

Be easy to consume from any platform (WS-I base profile)

Represent a business process as a complete unit of work


31/53

-Encourage document centric thinking by defining a schema (XSD) for request andresponse messages in your project

-Generate objects from your schema to simplify development

-Remember this is a boundary so dont leak internals

public FindCustomerByCountryResponse

FindCustomersByCountry(FindCustomerByCountryRequest request)

{

// Do something....

}


32/53


33/53


34/53


35/53

Benefits Consumers think about sending and receiving business

documents which are naturally more granular

The boundary of the system involves conversion from internalstructures to external documents

The implementation details of the system are encapsulated The service is more consumable from other platforms and can

evolve more easily

Liabilities

Performance will suffer with transfers of data from internal toexternal structures


36/53

Should I use the same schema for multipleservices or should each service have its ownschema?

Opinion: Give each service its own schema Sharing schema makes it difficult to evolve each

service independently and introduces unnecessarychurn for service consumers


37/53

How do I handle duplicate messages receivedat my service?


38/53

Context You are developing a web service for your SOA

You heard that messages should be idempotent

Problem

How do you insure that messages are idempotent?

Forces

You cannot expect anything more from the sender than whatthe contract defines for your service

You are working with a transactional database system withfrequent updates


39/53

Sender tags message with a request ID Your contract can specify that this is required

Your contract cannot insist that the ID is unique across time

The ID tags a unit of work which will be done only once

Receiver must check to see if the unit of work has alreadybeen done before doing it

Then what?


40/53

Option1: return a cached response

Option2: Process the message again.

Option3: Throw an exception


41/53

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 ofwork?


42/53

Great for reads, what about writes?

Should we withdraw $1000 from a checking account twice?


43/53

Did the sender get the original response?

How does he get the original response if you are sending himand exception?


44/53

UOW ID can be a part of the request schema Implies duplicate handling is part of the business process

UOW ID can be a custom SOAP header

Implies duplicate handling is part of the message processing

infrastructure Create a schema for the SOAP header

Having a URI for immediate sender can be helpful to detectreentrancy

Data changes should be traceable to a UOW ID

Your cached responses may need to reflect what the responsewas at the time when the request was received


45/53

Benefits Your service autonomy is increased by not having to rely on

consumer to do the right thing

You wont fool yourself into thinking that reliable messaging willsolve this problem

Liabilities

Your service will consume potentially large amounts of durablestorage caching responses

Your service will take a performance hit for cache management


46/53

How do you maintain data consistency acrossa long running process?


47/53

Context You are building a service oriented application

You have a complex business process that you want toexpose to your customers with a web service

Problem

How do you maintain data consistency across a long runningprocess?

Forces

You cannot share a distributed transaction The business process requires several messages to complete

The message exchange process could take anywhere fromseconds to hours


48/53

Reservepart:49389Qty: 200

Reservation ID:14432Expires: 2004-09-1502:43:53Z

Confirmreservation:14432PO #49839Reservation: 14432Receipt: 29389PO #49839


49/53

Know the concepts before you write the code

SOA is not web services

SOA is about standards based integration andfriction free interaction between systems

SOA is not a silver bullet


50/53

Web services WCF

Biztalk ESB


51/53

www.arcast.tv (Webcasts)

www.geekswithblogs.net/Mohamed (Cooltech blog)

www.msdn.com/Architecture

www.thevstsguy.com (under construction)

www.msdn.microsoft.com/practices (P&P)
http://www.arcast.tv/http://www.geekswithblogs.net/Mohamedhttp://www.msdn.com/Architecturehttp://www.thevstsguy.com/http://www.msdn.microsoft.com/practiceshttp://www.msdn.microsoft.com/practiceshttp://www.thevstsguy.com/http://www.msdn.com/Architecturehttp://www.geekswithblogs.net/Mohamedhttp://www.arcast.tv/


52/53

Email: [email protected] Facebook

@msamy
mailto:[email protected]:[email protected]


53/53

Patterns Anti Patterns of So A

Documents

Transcript of Patterns Anti Patterns of So A