Scribd Logo
Upload

Welcome to Scribd!

  • 14 views

    Negotiating Aggregator

    Uploaded by

    Greg Young

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Negotiating Aggregator

    Uploaded by

    Greg Young
    14 views2 pages

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    14 views2 pages

    Negotiating Aggregator

    Uploaded by

    Greg Young

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    You are on page 1of 2

    Negotiating Event Aggregator

    An Event Aggregator has already been discussed. A Negotiating Event Aggrega-


    tor is a quite similar pattern, but it is one that has a very key difference. Instead
    of just including the data inside the aggregated event, it will negotiate what
    form that data should be in.
    The same pattern it uses has been seen prior in this text. Instead of including
    the data in the aggregated event it will instead include a URI where the data in
    the event can be obtained. This providing of a URI allows the consumer to use
    content type negotiation in order to specify how it wants to receive the body of
    the event.
    While most people associate this to some consumers using say XML and others
    JSON, this is not in fact the primary use of this pattern. The primary use is to
    handle . . . versioning.
    Instead of sending something like the following.
    Events [
    "FoodCooked" {
    "id" : "24728347",
    "table": 2,
    "dishes": [12,17],
    "state" : 3,
    placed : true,
    cooked : true,
    priced : false,
    paid : false
    }
    ]
    A Negotiating Event Aggregator would send over the events with URI in order
    to negotiate how the caller wants to see them.
    Events [
    "FoodCooked" {
    "id" ="24728347",
    uri : "http://mydomain.com/aggregator/24728347"
    }
    ]
    The receiver will then follow this URI using content type negotiation to say how
    they want to get that event.
    curl -H "Accept-Charset: utf-8" -H "Content-Type: application/json" http://mydomain.com/aggr
    This can also even include the version of the event by setting such in the Content-
    Type. Doing this will allow the server to convert what is being asked for to the
    version that the client prefers.

    1
    This can be invaluable when dealing with many subscribers who might have
    quite different update cycles. It is simply saying that the old versions are still
    supported, so everyone does not need to upgrade at the same time. It is not
    unheard of to even have hundreds of subscribers. Having any change to the
    aggregator require changes to every single client will not turn out well, instead
    you deprecate versions over time.
    When using a Negotiating Aggregator one thing to consider quite explicitly is
    “how long are we going to support this?”. What are the release cycles of other
    things that integrate with you? You want to get the transformations out as soon
    as is “reasonable”. Try to be quite explicit with others about how long you will
    support them.
    In terms of removing old versions I have found that using an attribute /annotation
    on them does a good job of this. You can then have something in your continuous
    integration looking for it.
    [Expires("01-01-2024")]
    class FoodCookedv2_converter {

    }
    Fun note about C# as passing the string looks a bit odd, you need
    to use a string here not a DateTime as you might expect as the time
    of writing you cannot pass the a DateTime into an attribute. Instead
    it will paarse the string in the attribute itself.
    You can even be nicer and go one step further looking at the content type
    and returning a “happy little reminder” to the client that the version they are
    currently using will expire soon or even better “on this date”. If nothing else
    they won’t be able to say that you did not warn them that this might happen
    when it actually does. Do note: this will happen when dealing with many clients,
    it is not a matter of if, it is when . . .

    You might also like