MoKhan.ca

Notes from the Distributed System Design by Udi Dahan Posted on September 27, 2010 @ 09:00 school

2010.09.27

shared database is one of the worst forms of coupling.

- e.g. one system writes to database, and another reads from it.
  • make coupling visible. no more shared database, it's to hard to figure out the coupling when you do that.

  • 1 danger is not being aware of the coupling by not seeing it.

Platform coupling

solutions: - use standards based transfer protocol like http, tcp, udp, smtp, snmp

Temporal coupling

Spatial coupling

summary

mitigate temporal and spatial coupling by hosting in the same process. [A[B]] or [B[A]]

to do: - add zip file to google docs. - look up 8 fallacies of distributed computing.

Messaging:

"represent methods as messages" - Authorization : IHandles --> runs against every message for authorization.

DAY 2 --- 2010.09.28

role playing... kinky? - previous assumptions are incorrect - cross functional teams

benefits - same infrastructure - slightly different architecture - increase performance

cost of messaging:

- learning curve

10:15 am - need "correlation id" to tell us which response belongs to which request. - eg this is response for request 123 - now you can have multiple responses for a single request.

browser -> send request to server

        -> poll server for response with correlation id
        <- return responses for corellation id

Publish/Subscribe

todo:: - topic hierarchies

1:08 pm

Broker

Service Orientation

4 tenets of service orientation

what is a service?

Service: technical authority for a specific business capability. Service: all data and business rules reside within the service.

what a service is not:

service examples

service deployments

Availability

The IT/Operations Service

todo:: * watch big bang theory * nerdtree vim plugin * tcommment vim plugin

DAY 3 = 2009.09.29

Review: (Hotel management system exercise) define the services + page composition really simplifies things. + avoid request/response between services. + avoid data duplication between service boundaries. + defining the services exercise helps identify the key business capabilities and fosters communication about the business. +

Services

break.

Service Decomposition

Business Components - BC

be aware of solutions masquerading as requirements - udi dahan

Services and transactions

"autonomous components" : AC

#

- responsible for one of more message types
- thing that performs a unit of work.
- is independently deployable, has it's own endpoint.
- common code that is needed to handle a specific message type not a single piece of code.
- running part of a service.

Layout

BC

- multiple AC's
- single DB

SOA building blocks summary

you see the AC's running. - autonomous components are the unit of deployment in SOA. - ac's takes responsibility for a specific set of messages types in the service. - ac uses the bus to communicate with other ac's - ac's can communicate using a message bus instead of a service bus. same technological bus, but used differently. - not all ac's require the same infrastructure, within a bc or across all ac's.

- eg. one ac my use an orm, another might write straight sql.

Service Structure

Queries in a collaborative multi user domain.

is this the right screen to be built for the purpose of collaboration?

Deployment and security

Role based security

Commands

model user intent - udi dahan we want to implement a fair system. if no one can see that a system is unfair, then it is fair enough.

HFT - high frequency trading.

CQRS

Validation

schema

ultimately, we are refactoring a bus into a plane while it's driving. - udi dahan

Day 4 -- 2009.09.30

Review: Order cancelled - don't process the refund until the products have been returned.

- the cancel order command has no reason to fail now.
    - you can now cancel an order at anytime, for the customer to receive the refund they must return the product.
- the ship order command has no reason to fail now.
    - we do not need to ship the order if it is cancelled, but even if they cancel the order after it has been shipped that's ok.

break

Long Running Processes

SAGA - handles long lived transaction

Testing

workflow foundation WWF - transaction management is manual do it yourself - hard to test - no timeout mechanism

biztalk - can't actually represent this kind of functionality in a drag and drop orchestration. - can be useful when doing something procedural and synchronous. - latency tends to be slower. - haven't modeled time. - biztalk rules engine (bre)

the hard part

summary

whenever you hear about workflows, orchestration etc then saga's are likely a candidate. if we see a saga handling 50 messages, that's usually a smell.

SCALING

SERVICE LAYER & DOMAIN MODEL

domain model - if you have complicated and ever changing business rules - if you have simple not-null checks and a couple of sums to calculate, a transaction script is a better bet. - independent of all concerns - poco - plain old c# objects - testing a connection between objects does not test any sort of behaviour - a unit is something that has a boundary. - you have been testing the innards of a unit - can be deployed multi tier - it's not about persistence, it's about behaviour.

service layer

concurrency models

DAY 5 - 2009.10.01

review

out of order events

Building a saga for shipping

public class ShippingSagaData : IContainSagaData
{
    public virtual Guid Id{get;set;}
    public virtual string Originator {get;set;}
    public virtual string OriginalMessageId {get;set;}

    public virtual bool Billed {get;set;}
    public virtual bool Accepted {get;set;}
    public virtual Guid OrderId {get;set;}
}

public class ShippingSaga : Saga<ShippingSagaData>,
    IAmStartedByMessage<OrderAccepted>
    IAmStartedByMessage<OrderBilled>
{
    public override void ConfigureHowToFindSaga()
    {
        ConfigureMapping<OrderAccepted>(s =>s.OrderId, m =>m.OrderId);
        ConfigureMapping<OrderBilled>(s =>s.OrderId, m =>m.OrderId);
    }

    public void Handle(OrderAccepted message)
    { 
        Data.OrderId = message.OrderId;
        Data.Accepted = true;

        if(Data.Billed)
            MarkAsComplete();
        else
            RequestTimeout(TimeSpan.FromDays(7), "bill");
    }

    public void Handle(OrderBilled message)
    { 
        Data.OrderId = message.OrderId;
        Data.Billed = true;
        if(Data.Accepted)
            MarkAsComplete();
    }
}

public class OrderAccepted : IMessage
{
    public Guid OrderId{get;set;}

}

the tests...

[TestFixture]
public class ShippingTests
{
    [Test]
    public void WhenBillingArrivesAfterAcceptedSagaShouldComplete()
    {
        Test.Initialize();
        Test.Saga<ShippingSaga>()
        .WhenReceievesMessageFrom("client")
        .When(s =>s.Handle(new OrderAccepted())
        .AssertSagaCompletionIs(false)
        .When(s =>s.Handle(new OrderBilled())
        .AssertSagaCompletionIs(true);
    }

    [Test]
    public void WhenBillingArrivesBeforeAcceptedSagaShouldComplete()
    {
        Test.Initialize();
        Test.Saga<ShippingSaga>()
        .WhenReceievesMessageFrom("client")
        .When(s =>s.Handle(new OrderBilled())
        .AssertSagaCompletionIs(false)
        .When(s =>s.Handle(new OrderAccepted())
        .AssertSagaCompletionIs(true);
    }

    [Test]
    public void SagaRequestsBillingTimeout()
    {
        Test.Initialize();
        Test.Saga<ShippingSaga>()
            .WhenReceievesMessageFrom("client")
            .ExpectSend<TimeoutMessage>(m => true)
            .When(s =>s.Handle(new OrderAccepted())
            .When(s =>s.Timeout(null))
            .AssertSagaCompletionIs(true)
        ;
    }
}

Web

smart clients

map display

comments powered by Disqus