June 16, 2006

Day 2 Session 2: Patterns of SOA

[I switched to this session from the 'introduction to Spring 2 because Gregor gave such an engaging keynote]

SOA is a shift in the way that we think about assembing systems – thinking about coupling, asynchrony, conversations and document exchange. It's really about reducing the degree of control one system exerts on another.

– Exists at a level of abstraction above the code; your compiler can't tell you if you're violating SOA principles

– Looks conceptually simple, but the devil is in the details; object–>document mapping is as hard as ORM; declarative programming and document transformation is hard to maintain; event–based programming; and business process modelling is hard when you try to do a complete design (long–running–processes & conpensating transactions (since 2PC isn't really applicable)

– Graphical tools tend to be a thin veneer over a complex / unfamiliar programming paradigm
– Understanding technology – process is something like {syntax=>constructs(e.g. in java classes, objects, interfaces etc)=>principles(SoC, open–closed principle)=>patterns}
– patterns are expressed in the constructs of the language, to support the principles of the language
SOA patterns are different to OO patterns because the constructs &vocabulary of SOA are not those of OO

– request–reply pattern – starts out very simple, but gets a bit more complex fairly quickly (return–address and correlation–id required to locate endpoints and re–produce state if you have more than 1 producer / consumer) It's possible to use a pattern like this in reverse; i.e. if you don't have a correlation ID, then you can't have multiple provider; if you don't have a return address you can't have multiple consumers. When you introdroduce retries, it gets more complex again as you move into heuristics about how long to keep trying.

– dynamic discovery – broadcast request for service, providers respond, requestor chooses 'best' provider from response, requestor starts using provider. DHCP is a good example of this.

– Subscribe–notify – subscriber expresses an interest in receiving notifications, provider starts sending messages; subscriber does not reply, after some event the provider stops sending messages and notifies subscriber that it is done.

– sub–patterns for the end refresh e.g. automatic expiration (e.g. DHCP lease&renew), renewal request (e.g. magazine model). Generally try to avoid allowing the subscriber to control when the subscription ends because it doesn't cope with the subscriber going away

Orchestration: a facade co–ordinating the calling of multiple services (which may in turn orchestrate their own conversations)
Orchestration patterns: switches: XOR, OR, ;merges: synchronized, multiple, discriminator;
(not all orchestration environments support all orchestration patterns)

Patterns and standards interact; standards tell you how to express a pattern in code; patterns act as the requirements for the standard. There's a feedback cycle between patterns and standards; but it happens very slowly when you're dealing with cross–organisational standards.

- No comments Not publicly viewable

Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

Most recent entries


Search this blog

on twitter...


    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXX