CBE™

:)

Coordination Patterns

För inte länge sedan tog jag del av CCR och fick då en förhoppning om att även utvecklare ska börja tänka processorienterat mha av detta ramverk. Fundamentet för processorienterad utveckling handlar nämligen om koordinering av asynkron meddelandehantering. Med det menas att kunna kontrollera inkommand och utgående kommunikation till och från processen.

CCR är ett ramverk till C# 2.0 och kan jämföras med bland annat CSP för Java, men även med BPEL. CCR är en bredare produkt som tillsammans med C# kan användas i många fler sammanhang än orkestrering av web service, som är BPELs huvudsakliga uppgift.

Men låt oss ändå jämföra hur BPEL och CCR utmanar 2 vanliga koordineringsmönster. För fler mönster som relaterar till workflows och meddelandehantering se här och där.

Racing Incoming Messages Pattern

En instans ämnar ta emot fler än ett inkommande meddelande, men är bara intresserad av det första. Exemplet nedan visar hur man enbart tar emot det först inkommande budet på en auktion.

BPEL:

<pick>
 <onMessage operation="receiveBet" partnerLink="partner1" 
     portType="port1" variable="bet1">
  <!-- Handler code belongs here -->
 </onMessage>
 <onMessage operation="receiveBet" partnerLink="partner2" 
     portType="port2" variable="bet2">
  <!-- Handler code belongs here -->
 </onMessage>
</pick>

CCR:

Arbiter.Activate(taskQueue,
 Arbiter.Choice(
  Arbiter.Receive(true, port1, receiveBet1),
  Arbiter.Receive(true, port2, receiveBet2)
 )
);

Synchronization Pattern

I ett parallellt flöde behöver man synkronisera två eller flera sekvenser. Exemplet nedan visar hur man låter båda budgivarna få en chans att bjuda i auktionen.

BPEL:

<flow>
 <links>
  <link name="bet1" />
  <link name="bet2" />
 </links>
 <receive name="receiveBet1" operation="receiveBet" 
     partnerLink="partner1" portType="port1" variable="bet1">
  <source linkName="bet1"/>
 </receive>
 <receive name="receiveBet2" operation="receiveBet" 
     partnerLink="partner2" portType="port2" variable="bet2">
  <source linkName="bet2"/>
 </receive>
 <anyBPELActivity>
  <target linkName="bet1"/>
  <target linkName="bet2"/>
 </anyBPELActivity>
</flow>

CCR:

Arbiter.Activate(taskQueue,
 Arbiter.JoinedReceive(true, bet1, bet2, anyHandler)
);

Vilket språk föredrar du?

Choreography vs Orchestration och fotboll

Ibland stöter man på orden Choreography och Orchestration när man pratar om processer. Koreografi handlar om att koordinera rörelser (dans), medan dirigera (orchestration) handlar om att skapa musik från toner med hjälp av flera instrument. Medan dans inte är en lika exakt konst, så är musik desto mer komplex i sin sammansättning. Dans ger utrymme för kreativitet, medan musik som dirigeras styrs av dirigenten. En dansare kan avvika från koreografin utan att skapa oreda, tillskillnad från orkestermedlem som om han avviker blir mer påtagligt.

Jämför med fotboll, som är en koreografi där spelarna ofta använder sin kreativitet för att föra bollen till mål. Om fotboll skulle dirigeras skulle det bli ganska förutsägbart, vilket säkert också skulle gynna motståndaren.

En affärsprocess o andra sidan kan antingen definieras genom koreografi eller dirigering, beroende på kulturen i affären. En affär som toppstyrs har ofta en företagskultur där man med respekt för komplexiteten dirigerar hur processerna skapar "musiken". En kultur där man istället låter ansvaret för processerna ligga hos de ingående delarna, utnyttjar kreativitet bättre.

Det är lätt att se att den kultur vi är vana vid i sverige, är den som förespråkar kreativitet och koreografi framför dirigering. Dirigering ser vi ofta utomlands ibland företagskulturer där. Varför det är på det viset kan du läsa om här.

Företagskulturen i sverige smittar även av sig på utvecklaren. Han vill ha frihet att kunna jobba på ett kreativt sätt. Han vill inte dirigeras och jobbar helst inte med verktyg och språk där den designmodellen premieras. I sverige är det exempelvis ingen som intresserar sig för BPEL (som en branchkollega mycket vänligt upplyste mig om). Kanske kan Culture-Driven Design som jag försökte införa som begrepp bli något att ta hänsyn till som arkitekt?

Gick det bra för Volvo att lämna löpandebandet och jobba mer med arbetslag som skulle främja kreativiteten?

BPM vs SOA

Jag läste en blog från Ismael Ghalimi där han positionerade BPM och SOA som två sidor av samma mynt.

"BPM is SOA’s killer application, while SOA is BPM’s enabling infrastructure."

(nu handlade egentligen den bloggen om middle-out eller top-down, men än då)

Asynkron koordinering med CCR

I XOML eller BPEL så är asynkron koordinering av kommunikation första klassens medlemmar.

CCR (Concurrency and Coordination Runtime) ger C#-utvecklare samma möjlighet till detsamma.

SOA 2.0

Web 2.0, Office 2.0 och nu SOA 2.0 visar att man kan sätta versionsnummer även på arkitekturer.

Åsikterna går i sär och är du en av dom som inte gillar det så skriv då på ett anti-SOA 2.0 petition.