Orkestrering

Organisasjoner som allerede har ansatt mellomvareprodukter for enterprise application integration (eai) for å automatisere forretningsprosesser eller integrere ulike eldre miljøer, vil sannsynligvis allerede være kjent med begrepet orkestrering. I disse systemene muliggjør et sentralt styrt sett med arbeidsflytlogikk interoperabilitet mellom to eller flere forskjellige applikasjoner. En felles implementering av orkestrering er hub-and-spoke-modellen som gjør det mulig for flere eksterne deltakere å samhandle med en sentral orkestreringsmotor.

et av drivkravene bak etableringen av disse løsningene var å imøtekomme sammenslåingen av store forretningsprosesser. Med orkestrering kan ulike prosesser kobles sammen uten å måtte videreutvikle løsningene som opprinnelig automatiserte prosessene individuelt. Orkestrering broer dette gapet ved å introdusere ny arbeidsflytlogikk. Videre kan bruken av orkestrering redusere kompleksiteten til løsningsmiljøer betydelig. Arbeidsflytlogikk abstraheres og vedlikeholdes lettere enn når den er innebygd i individuelle løsningskomponenter.

orkestrasjonens rolle utvides i serviceorienterte miljøer. Gjennom bruk av utvidelser som gjør det mulig å uttrykke forretningsprosesslogikk via tjenester, kan orkestrering representere og uttrykke forretningslogikk på et standardisert, tjenestebasert sted. Når man bygger serviceorienterte løsninger, gir dette en ekstremt attraktiv måte å bo på og kontrollere logikken som representerer prosessen som automatiseres.

Orkestrering utnytter ytterligere den iboende interoperabiliteten som tjenestedesign søker, ved å gi potensielle integrasjonsendepunkter i prosesser. Et sentralt aspekt for hvordan orkestrering er plassert i SOA er at orkestrasjoner selv eksisterer som tjenester. Derfor, bygge på orkestrering logikk standardiserer prosessen representasjon på tvers av en organisasjon, mens adressering målet om enterprise federation og fremme service-orientering.

Figur 6.32. En orkestrering styrer nesten alle aspekter av en kompleks aktivitet.

En primær industri spesifikasjon som standardiserer orkestrering Er Web services Business Process Execution Language (WS-BPEL). DENNE boken anerkjenner WS-BPEL som en viktig andre generasjons utvidelse og bruker derfor konsepter og terminologi som grunnlag for en rekke diskusjoner knyttet til forretningsprosessmodellering.

Merk

WS-BPEL ER DET siste navnet gitt til denne spesifikasjonen, som også er kjent SOM BPEL4WS og bare BPEL. For en oversikt over de viktigste delene AV ws-BPEL språk og en diskusjon om hvordan navneendringen kom, se Kapittel 16.

På Vanlig engelsk

Etter å ha vasket flere biler sammen, Bestemmer Chuck, Bob, Jim og jeg å starte vårt eget selskap. Vi formaliserer trinnene i vår bilvaskeprosess slik at vi kan håndtere ulike typer biler med forskjellige rengjøringskrav.

vår prosess påvirkes derfor av følgende nye krav:

• vi velger å leie ekstra hjelp i rushtiden. Dette introduserer opptil to ekstra medlemmer som blir med i teamet vårt.
• Fordi vi ikke har noen venturekapital for denne virksomheten, gjør vi en avtale med en lokal bensinstasjon. I bytte for å bruke en del av deres mye for vår bilvask drift, er vi enige om å hjelpe til med gass pumping plikter i rushtiden.

vår enkle bilvaskprosess har nå blitt betydelig mer komplisert. Prosessen er ikke lenger løst ved at den kan endres til enhver tid som følge av ulike forhold og hendelser.

• når våre ekstra arbeidere ankommer, endres oppgavetildelingen for hele teamet.
• når bensinstasjonspersonell trenger ekstra hjelp, er vi forpliktet til å sende en eller flere av våre bilvaskteammedlemmer for å hjelpe dem.

disse eksemplene gjelder forutsigbare forhold som oppstår på daglig basis. Vår drift er ytterligere påvirket av noen begrensninger:

• hvis vår kontantstrøm faller under et visst beløp, har vi ikke råd til deltidsarbeidere.
• hvis det regner, blir alt arbeid suspendert (fører også til redusert kontantstrøm).

disse begrensningene innfører forhold som er mindre vanlige, men som vi alltid må ta hensyn til. For å imøtekomme disse potensielle situasjonene, kommer vi opp med en plan som kartlegger vår utvidede prosess og gir alternative prosesser for å håndtere både vanlige og uvanlige forhold.

denne planen er i hovedsak en arbeidsflyt som forbinder individuelle trinn med prosesser og delprosesser partisjonert av beslutningspunkter. Denne forseggjorte arbeidsflyten inkorporerer vår opprinnelige prosess med bensinstasjonens prosess og den utvidede prosessen som følge av ankomsten av våre deltidsarbeidere. Denne arbeidsflyten er i hovedsak en orkestrering som styrer de enkelte prosesskrav og relaterte ressurser, deltakere, hendelser, forretningsregler og aktiviteter.

6.6.1. Forretningsprotokoller og prosessdefinisjon

arbeidsflytlogikken som består av en orkestrering, kan bestå av mange forretningsregler, betingelser og hendelser. Samlet sett etablerer disse delene av en orkestrering en forretningsprotokoll som definerer hvordan deltakerne kan samarbeide for å oppnå fullføring av en forretningsoppgave. Detaljene i arbeidsflytlogikken innkapslet og uttrykt av en orkestrering finnes i en prosessdefinisjon.

6.6.2. Prosesstjenester og partnertjenester

Identifisert og beskrevet i en prosessdefinisjon er de tillatte prosessdeltakerne. For det første er selve prosessen representert som en tjeneste, noe som resulterer i en prosesstjeneste(som skjer for å være en annen av våre servicemodeller, som vist i Figur 6.33).

Figur 6.33. En prosesstjeneste som koordinerer og eksponerer funksjonalitet fra tre partnertjenester.

Andre tjenester som er tillatt å samhandle med prosesstjenesten, identifiseres som partnertjenester eller partnerkoblinger. Avhengig av arbeidsflytlogikken kan prosesstjenesten påberopes av en ekstern partnertjeneste, eller den kan påberope seg andre partnertjenester (Figur 6.34).

Figur 6.34. Prosesstjenesten, etter først å ha blitt påkalt av en partnertjeneste, påkaller deretter en annen partnertjeneste.

6.6.3. Grunnleggende aktiviteter og strukturerte aktiviteter

WS-BPEL bryter ned arbeidsflytlogikk i en rekke forhåndsdefinerte primitive aktiviteter. Grunnleggende aktiviteter (motta, påberope, svare, kaste, vente) representerer grunnleggende arbeidsflythandlinger som kan settes sammen ved hjelp av logikken levert av strukturerte aktiviteter (sekvens, bryter, mens, flyt, plukk). Hvordan disse aktivitetene kan brukes til å uttrykke faktisk forretningsprosesslogikk, utforskes I Kapittel 16.

6.6.4. Sekvenser, flyter og koblinger

Grunnleggende og strukturerte aktiviteter kan organiseres slik at rekkefølgen de utfører, er forhåndsdefinert. En sekvens justerer grupper med relaterte aktiviteter i en liste som bestemmer en sekvensiell kjøringsrekkefølge. Sekvenser er spesielt nyttige når et stykke applikasjonslogikk er avhengig av utfallet av en annen.

Flyter inneholder også grupper av relaterte aktiviteter, men de innfører ulike utførelseskrav. Stykker av applikasjonslogikk kan utføres samtidig i en flyt, noe som betyr at det ikke nødvendigvis er et krav for ett sett med aktiviteter å vente før en annen er ferdig. Strømmen i seg selv avsluttes imidlertid ikke før alle innkapslede aktiviteter har fullført behandlingen. Dette sikrer en form for synkronisering mellom programlogikk bosatt i individuelle strømmer.

Koblinger brukes til å etablere formelle avhengigheter mellom aktiviteter som er en del av flyter. Før en aktivitet kan fullføres, må den sørge for at eventuelle krav som er etablert i utgående koblinger først er oppfylt. På samme måte, før noen koblet aktivitet kan begynne, krav som finnes i noen innkommende koblinger først må være oppfylt. Regler gitt av koblinger er også referert til som synkroniseringsavhengigheter.

6.6.5. Orkestreringer og aktiviteter

som vi definerte tidligere, er en aktivitet et generisk begrep som kan brukes på enhver logisk arbeidsenhet som utføres av en serviceorientert løsning. Omfanget av en enkelt orkestrering kan derfor klassifiseres som en kompleks og mest sannsynlig langvarig aktivitet.

6.6.6. Orkestrering og koordinering

Orkestrering, representert VED WS-BPEL, kan fullt ut utnytte ws-Coordination context management framework ved å inkorporere ws-BusinessActivity coordination type. Denne spesifikasjonen definerer koordineringsprotokoller designet for å støtte komplekse, langvarige aktiviteter.

6.6.7. Orchestration og SOA

Forretningsprosesslogikk er roten til automatiseringsløsninger. Orkestrering gir en automatiseringsmodell der prosesslogikk er sentralisert, men likevel utvidbar og komposerbar (Figur 6.35). Gjennom bruk av orkestreringer blir serviceorienterte løsningsmiljøer iboende utvidbare og adaptive. Orkestreringer selv etablerer vanligvis et felles integrasjonspunkt for andre applikasjoner, noe som gjør en implementert orkestrasjon til en viktig integrasjonsaktivitet.

Figur 6.35. Orkestrering knyttet til ANDRE DELER AV SOA.

disse egenskapene fører til økt organisatorisk smidighet fordi:

• arbeidsflytlogikken innkapslet av en orkestrering kan endres eller utvides på et sentralt sted.
• Plassering av en orkestrering sentralt kan betydelig lette sammenslåingen av forretningsprosesser ved å abstrahere limet som binder de tilsvarende automatiseringsløsningene sammen.
• ved å etablere potensielt storskala serviceorienterte integrasjonsarkitekturer, kan orkestrering på et grunnleggende nivå støtte utviklingen av et mangfoldig føderert foretak.

Orkestrering er en viktig ingrediens for å oppnå en føderasjon i en organisasjon som inneholder ulike applikasjoner basert på ulike databehandlingsplattformer. Fremskritt i mellomvare tillate orkestrering motorer selv å bli fullt integrert i serviceorienterte miljøer.

begrepet serviceorientert orkestrering utnytter fullt ut alle konseptene vi har diskutert så langt i dette kapitlet. For mange miljøer blir orkestrasjoner HJERTET AV SOA.

Case Study

serien av trinn vi pakket inn i en forretningsaktivitet i det forrige case study-eksemplet, viste hvordan TLS brukte ws-BusinessActivity-protokollen til å legge til kontekststyring og unntakshåndtering til en langvarig, kompleks aktivitet. Selv om omfanget av en forretningsaktivitet kan utgjøre en forretningsprosess, gir DEN IKKE TLS en standard måte å uttrykke den underliggende arbeidsflytlogikken på. FOR DET bruker TLS EN WS-BPEL orkestrering (Figur 6.36).

Figur 6.36. Den utvidede Innkjøpsordreprosessen for Tls administreres av en orkestrering og involverer mange potensielle partnerorganisasjoner.

orkestreringen etablerer omfattende prosesslogikk som omfatter forretningsaktiviteten og utvider den ytterligere for å styre flere samhandlingsscenarier med flere leverandørtjenester. Når en leverandør ikke kan oppfylle en ordre, sendes for eksempel den neste leverandøren på linje samme bestilling. Denne syklusen gjentas til en leverandør kan fullføre bestillingen i sin helhet (innenfor visse prisbegrensninger) eller til alle leverandører har blitt spurt. I sistnevnte situasjon vurderer systemet bare den beste avtalen på bordet ved å bruke en formel som tar hensyn til pris, prosentandel av ordre som skal fylles og restordrebetingelser.

orkestreringslogikken styrer alle aspekter av prosessen, inkludert involvering av flere leverandørpartnertjenester, samt forretningsaktiviteten som starter når EN PO behandles.

SAMMENDRAG AV VIKTIGE PUNKTER

• en orkestrering uttrykker en kropp av forretningsprosesslogikk som vanligvis eies av en enkelt organisasjon.
• en orkestrering etablerer en forretningsprotokoll som formelt definerer en forretningsprosessdefinisjon.
• arbeidsflytlogikken i en orkestrering er brutt ned i en rekke grunnleggende og strukturerte aktiviteter som kan organiseres i sekvenser og flyter.
• Orkestrering har blitt kalt «soas hjerte», da Det etablerer et middel til å sentralisere og kontrollere en stor inter-og intra-applikasjonslogikk gjennom en standardisert servicemodell.