orkestrering

organisationer som redan har använt enterprise application integration (EAI) middleware-produkter för att automatisera affärsprocesser eller för att integrera olika äldre miljöer kommer sannolikt redan att känna till begreppet orkestrering. I dessa system underlättar en centralt styrd uppsättning arbetsflödeslogik interoperabilitet mellan två eller flera olika applikationer. En vanlig implementering av orkestrering är nav-och-talade modellen som gör att flera externa deltagare kan samverka med en central orkestreringsmotor.

ett av drivkraven bakom skapandet av dessa lösningar var att tillgodose sammanslagningen av stora affärsprocesser. Med orkestrering kan olika processer kopplas samman utan att behöva utveckla de lösningar som ursprungligen automatiserade processerna individuellt. Orkestrering överbryggar detta gap genom att införa ny arbetsflödeslogik. Vidare kan användningen av orkestrering avsevärt minska komplexiteten i lösningsmiljöer. Arbetsflödeslogik är abstraherad och lättare underhållen än när den är inbäddad i enskilda lösningskomponenter.

orkestreringens Roll breddas i serviceinriktade miljöer. Genom att använda tillägg som gör det möjligt för affärsprocesslogik att uttryckas via tjänster kan orkestrering representera och uttrycka affärslogik på en standardiserad, tjänstebaserad plats. När man bygger serviceorienterade lösningar ger detta ett extremt attraktivt sätt att bo och styra logiken som representerar processen som automatiseras.

orkestrering utnyttjar ytterligare den inneboende interoperabilitet som eftersträvas av servicedesigner genom att tillhandahålla potentiella integrationslutpunkter i processer. En viktig aspekt på hur orkestrering är placerad inom SOA är det faktum att orkestreringar själva existerar som tjänster. Att bygga på orkestreringslogik standardiserar därför processrepresentation över en organisation, samtidigt som man tar itu med målet om företagsfederation och främjar serviceorientering.

figur 6.32. En orkestrering styr nästan varje aspekt av en komplex aktivitet.

en primär branschspecifikation som standardiserar orkestrering är Web services Business Process Execution Language (WS-BPEL). Denna bok erkänner WS-BPEL som en viktig andra generationens förlängning och använder därför sina begrepp och terminologi som grund för ett antal diskussioner om affärsprocessmodellering.

notera

WS-BPEL är det senaste namnet på denna specifikation, som också kallas BPEL4WS och bara BPEL. För en översikt över de primära delarna av ws-BPEL-språket och en diskussion om hur namnbytet kom till, se kapitel 16.

på vanlig engelska

efter att ha lyckats tvätta flera bilar tillsammans beslutar Chuck, Bob, Jim och jag att starta vårt eget företag. Vi formaliserar stegen i vår biltvättprocess så att vi kan hantera olika typer av bilar med olika rengöringskrav.

vår process påverkas därför av följande nya krav:

• vi bestämmer oss för att anställa extra hjälp under rusningstid. Detta introducerar upp till ytterligare två medlemmar som går med i vårt team.
• eftersom vi inte har något riskkapital för denna verksamhet, gör vi ett avtal med en lokal bensinstation. I utbyte mot att använda en del av deras parti för vår biltvätt, är vi överens om att hjälpa till med gaspumpningsuppgifterna under deras Högtider.

vår enkla biltvättprocess har nu blivit betydligt mer komplicerad. Processen är inte längre fastställd genom att den kan förändras när som helst till följd av olika förhållanden och händelser.

• när våra extraarbetare anländer ändras uppgiftsfördelningen för hela laget.
• när Bensinstation personal behöver extra hjälp, är vi skyldiga att skicka en eller flera av våra Biltvätt Gruppmedlemmar för att hjälpa dem.

dessa exempel avser förutsägbara förhållanden som uppstår dagligen. Vår verksamhet påverkas ytterligare av vissa begränsningar:

• om vårt kassaflöde faller under ett visst belopp kan vi inte ha råd med deltidsarbetare.
• om det regnar avbryts allt arbete (vilket också leder till minskat kassaflöde).

dessa begränsningar introducerar villkor som är mindre vanliga, men som vi alltid måste ta hänsyn till. För att tillgodose dessa potentiella situationer kommer vi fram till en plan som kartlägger vår utökade process och ger alternativa processer för att hantera både vanliga och ovanliga förhållanden.

denna plan är i huvudsak ett arbetsflöde som förenar enskilda steg med processer och delprocesser partitionerade av beslutspunkter. Detta utarbetade arbetsflöde innehåller vår ursprungliga process med bensinstationens process och den utökade processen till följd av ankomsten av våra deltidsarbetare. Detta arbetsflöde är i huvudsak en orkestrering som hanterar de enskilda processkraven och relaterade resurser, deltagare, händelser, affärsregler och aktiviteter.

6.6.1. Affärsprotokoll och processdefinition

arbetsflödeslogiken som består av en orkestrering kan bestå av många affärsregler, villkor och händelser. Sammantaget etablerar dessa delar av en orkestrering ett affärsprotokoll som definierar hur deltagare kan samverka för att uppnå slutförandet av en affärsuppgift. Detaljerna i arbetsflödeslogiken inkapslad och uttryckt av en orkestrering finns i en processdefinition.

6.6.2. Processtjänster och partnertjänster

identifierade och beskrivna i en processdefinition är de tillåtna processdeltagarna. För det första representeras själva processen som en tjänst, vilket resulterar i en processtjänst (som råkar vara en annan av våra servicemodeller, som visas i Figur 6.33).

figur 6.33. En processtjänst som samordnar och exponerar funktionalitet från tre partnertjänster.

andra tjänster som tillåts interagera med processtjänsten identifieras som partnertjänster eller partnerlänkar. Beroende på arbetsflödeslogiken kan processtjänsten anropas av en extern partnertjänst, eller så kan den anropa andra partnertjänster (figur 6.34).

Figur 6.34. Processtjänsten, efter att först ha åberopats av en partnertjänst, åberopar sedan en annan partnertjänst.

6.6.3. Grundläggande aktiviteter och strukturerade aktiviteter

WS-BPEL bryter ner arbetsflödeslogiken i en serie fördefinierade primitiva aktiviteter. Grundläggande aktiviteter (ta emot, anropa, svara, kasta, vänta) representerar grundläggande arbetsflödesåtgärder som kan monteras med hjälp av logiken som tillhandahålls av strukturerade aktiviteter (sekvens, switch, medan, flöde, plocka). Hur dessa aktiviteter kan användas för att uttrycka den faktiska affärsprocesslogiken undersöks i kapitel 16.

6.6.4. Sekvenser, flöden och länkar

grundläggande och strukturerade aktiviteter kan organiseras så att den ordning de utför är fördefinierad. En sekvens justerar grupper av relaterade aktiviteter till en lista som bestämmer en sekventiell exekveringsordning. Sekvenser är särskilt användbara när en applikationslogik är beroende av resultatet av en annan.

flöden innehåller också grupper av relaterade aktiviteter, men de inför olika exekveringskrav. Delar av applikationslogik kan köras samtidigt inom ett flöde, vilket innebär att det inte nödvändigtvis är ett krav för en uppsättning aktiviteter att vänta innan en annan slutar. Flödet i sig slutar dock inte förrän alla inkapslade aktiviteter har slutfört bearbetningen. Detta säkerställer en form av synkronisering mellan applikationslogik som finns i enskilda flöden.

länkar används för att upprätta formella beroenden mellan aktiviteter som ingår i flöden. Innan en aktivitet helt kan slutföras måste den se till att alla krav som fastställs i utgående länkar först uppfylls. På samma sätt, innan någon länkad aktivitet kan börja, måste kraven i alla inkommande länkar först uppfyllas. Regler som tillhandahålls av länkar kallas också synkroniseringsberoenden.

6.6.5. Orkestrationer och aktiviteter

som vi definierade tidigare är en aktivitet en generisk term som kan tillämpas på alla logiska arbetsenheter som kompletteras av en serviceorienterad lösning. Omfattningen av en enda orkestrering kan därför klassificeras som en komplex och sannolikt långvarig aktivitet.

6.6.6. Orkestrering och samordning

orkestrering, som representeras av WS-BPEL, kan fullt ut utnyttja ws-Coordination context management framework genom att införliva ws-BusinessActivity coordination type. Denna specifikation definierar samordningsprotokoll som är utformade för att stödja komplexa, långvariga aktiviteter.

6.6.7. Orkestrering och SOA

affärsprocesslogik är roten till automatiseringslösningar. Orkestrering ger en automatiseringsmodell där processlogiken är centraliserad men ändå utbyggbar och komposterbar (figur 6.35). Genom användning av orkestreringar blir serviceorienterade lösningsmiljöer i sig utbyggbara och anpassningsbara. Orkestreringar själva skapar vanligtvis en gemensam integrationspunkt för andra applikationer, vilket gör en implementerad orkestrering till en viktig integrationsaktivering.

figur 6.35. Orkestrering som rör andra delar av SOA.

dessa egenskaper leder till ökad organisatorisk smidighet eftersom:

• arbetsflödeslogiken inkapslad av en orkestrering kan ändras eller utökas på en central plats.
• att placera en orkestrering centralt kan avsevärt underlätta sammanslagningen av affärsprocesser genom att abstrahera limet som binder samman motsvarande automationslösningar.
• genom att etablera potentiellt storskaliga serviceorienterade integrationsarkitekturer kan orkestrering på en grundläggande nivå stödja utvecklingen av ett mångsidigt federerat företag.

orkestrering är en viktig ingrediens för att uppnå ett federationstillstånd inom en organisation som innehåller olika applikationer baserade på olika datorplattformar. Framsteg inom middleware gör det möjligt för orkestreringsmotorer att bli helt integrerade i serviceorienterade miljöer.

begreppet serviceorienterad orkestrering utnyttjar fullt ut alla de begrepp som vi hittills har diskuterat i detta kapitel. För många miljöer blir orkestrationer hjärtat av SOA.

fallstudie

serien av steg som vi lindade in i en affärsverksamhet i det tidigare fallstudiexemplet visade hur TLS använde ws-BusinessActivity-protokollet för att lägga till kontexthantering och undantagshantering till en långvarig, komplex aktivitet. Även om omfattningen av en affärsverksamhet kan utgöra en affärsprocess, ger den inte TLS ett standardmedel för att uttrycka den underliggande arbetsflödeslogiken. För det använder TLS en ws-BPEL-orkestrering (figur 6.36).

figur 6.36. Den utökade processen för inlämning av TLS-inköpsorder hanteras av en orkestrering och involverar många potentiella partnerorganisationer.

orkestreringen etablerar omfattande processlogik som omfattar affärsverksamheten och utökar den ytterligare för att styra ytterligare interaktionsscenarier med flera leverantörstjänster. Till exempel, när en leverantör inte kan uppfylla en order, skickas nästa leverantör i rad samma inköpsorder. Denna cykel upprepas tills antingen en leverantör kan slutföra beställningen i sin helhet (inom vissa prisbegränsningar) eller tills alla leverantörer har frågats. I den senare situationen bedömer systemet helt enkelt det bästa erbjudandet på bordet genom att använda en formel som tar hänsyn till priset, procentandelen för att fyllas och restordervillkor.

orkestreringslogiken hanterar alla aspekter av processen, inklusive involvering av flera leverantörspartners tjänster, liksom den affärsaktivitet som sparkar in när en PO behandlas.

sammanfattning av viktiga punkter

• en orkestrering uttrycker en kropp av affärsprocesslogik som vanligtvis ägs av en enda organisation.
• en orkestrering etablerar ett affärsprotokoll som formellt definierar en affärsprocessdefinition.
• arbetsflödeslogiken inom en orkestrering är uppdelad i en serie grundläggande och strukturerade aktiviteter som kan organiseras i sekvenser och flöden.
• orkestrering har kallats ”hjärtat av SOA”, eftersom det etablerar ett sätt att centralisera och kontrollera en hel del Inter-och intra-applikationslogik genom en standardiserad servicemodell.