Integrering av företagsapplikationer

Enterprise Application Integration ( EAI ) är användningen av programvara och datorsystems arkitektoniska principer för att integrera en uppsättning företagsdatorapplikationer .

Översikt

Företagsapplikationsintegration är ett integrationsramverk som består av en samling tekniker och tjänster som bildar ett mellanprogram eller "mellanprogram" för att möjliggöra integration av system och applikationer över ett företag.

Många typer av affärsprogramvara som applikationer för försörjningskedjehantering , ERP- system, CRM -applikationer för att hantera kunder, affärsinformationsapplikationer , löne- och personalsystem kan vanligtvis inte kommunicera med varandra för att dela data eller affärsregler. Av denna anledning kallas sådana applikationer ibland för automationsöar eller informationssilos . Denna brist på kommunikation leder till ineffektivitet, där identiska data lagras på flera platser, eller enkla processer inte kan automatiseras. ^{[ citat behövs ]}

Företagsapplikationsintegration är processen att länka samman sådana applikationer inom en enda organisation för att förenkla och automatisera affärsprocesser i största möjliga utsträckning, samtidigt som man undviker att behöva göra genomgripande förändringar i befintliga applikationer eller datastrukturer. Applikationer kan länkas antingen i back-end via API: er eller (sällan) front-end ( GUI ). ^{[ citat behövs ]}

Med analysföretaget Gartners ord : "[EAI är] obegränsad delning av data och affärsprocesser mellan alla anslutna applikationer eller datakällor i företaget."

De olika systemen som behöver länkas samman kan finnas på olika operativsystem , använda olika databaslösningar eller datorspråk , eller olika datum- och tidsformat, eller kan vara äldre system som inte längre stöds av leverantören som ursprungligen skapade dem. I vissa fall kallas sådana system för " stovepipe-system " eftersom de består av komponenter som har klämts ihop på ett sätt som gör det mycket svårt att modifiera dem på något sätt. ^{[ citat behövs ]}

Förbättra anslutningsmöjligheter

Om integration tillämpas utan att följa en strukturerad EAI-metod växer punkt-till-punkt-kopplingar över en organisation. Beroenden läggs till på en improviserad basis, vilket resulterar i en komplex struktur som är svår att underhålla. Detta kallas vanligtvis spagetti, en anspelning på programmeringsmotsvarigheten till spagettikod .

Till exempel, antalet anslutningar som behövs för att ha helt maskade punkt-till-punkt-anslutningar, med $n$ punkter, ges av ${\tbinom {n}{2} }={\tfrac {n(n-1)}{2}}$ (se binomial koefficient ). För att tio applikationer ska vara helt integrerade punkt-till-punkt krävs alltså ${\displaystyle {\tfrac {10\times 9}{2}}=45} punkt-till-punkt-anslutningar, följande$ ett kvadratiskt tillväxtmönster .

Antalet kopplingar inom organisationer växer dock inte nödvändigtvis med kvadraten på antalet poäng. I allmänhet begränsas antalet anslutningar till någon punkt endast av antalet andra punkter i en organisation, men kan i princip vara betydligt mindre. EAI kan också öka kopplingen mellan systemen och därmed öka förvaltningskostnaderna och kostnaderna. ^{[ citat behövs ]}

EAI handlar inte bara om att dela data mellan applikationer utan fokuserar också på att dela både affärsdata och affärsprocesser. En middleware-analytiker som arbetar med EAI kommer ofta att titta på systemet med system . ^{[ citat behövs ]}

Syften

EAI kan användas för olika ändamål: ^{[ citat behövs ]}

Dataintegration : Säkerställer att information i flera system hålls konsekvent. Detta är också känt som Enterprise Information Integration (EII).
Leverantörsoberoende: Extraherar affärspolicyer eller regler från applikationer och implementerar dem i EAI-systemet, så att även om en av affärsapplikationerna ersätts med en annan leverantörs applikation, behöver affärsreglerna inte implementeras på nytt.
Gemensam fasad: Ett EAI-system kan front-end ett kluster av applikationer, ger ett enda konsekvent åtkomstgränssnitt till dessa applikationer och skyddar användare från att behöva lära sig att använda olika programvarupaket.

Mönster

Det här avsnittet beskriver vanliga designmönster för implementering av EAI, inklusive integration, åtkomst och livstidsmönster. Dessa är abstrakta mönster och kan implementeras på många olika sätt. Det finns många andra mönster som ofta används i branschen, allt från abstrakta designmönster på hög nivå till mycket specifika implementeringsmönster.

Integrationsmönster

EAI-system implementerar två mönster:

Medling (intrakommunikation): Här fungerar EAI-systemet som mellanhand eller förmedlare mellan flera applikationer. Närhelst en intressant händelse inträffar i en applikation (till exempel ny information skapas eller en ny transaktion slutförs) aviseras en integrationsmodul i EAI-systemet. Modulen sprider sedan ändringarna till andra relevanta applikationer.
Federation (inter-kommunikation): I det här fallet fungerar EAI-systemet som den övergripande fasaden över flera applikationer. Alla händelsesamtal från "omvärlden" till någon av applikationerna front-ends av EAI-systemet. EAI-systemet är konfigurerat att endast exponera relevant information och gränssnitt för de underliggande applikationerna för omvärlden, och utför alla interaktioner med de underliggande applikationerna på uppdrag av begäranden.

Båda mönstren används ofta samtidigt. Samma EAI-system skulle kunna hålla flera applikationer synkroniserade (medling), samtidigt som de betjänar förfrågningar från externa användare mot dessa applikationer (federation). ^{[ citat behövs ]}

Åtkomstmönster

EAI stöder både asynkrona (elda och glömma) och synkrona åtkomstmönster, det förra är typiskt i medlingsärendet och det senare i förbundsfallet. ^{[ citat behövs ]}

Livstidsmönster

En integrationsoperation kan vara kortlivad (t.ex. att hålla data synkroniserade mellan två applikationer kan slutföras inom en sekund) eller långlivad (t.ex. kan ett av stegen innebära att EAI-systemet interagerar med en mänsklig arbetsflödesansökan för godkännande av ett lån som tar timmar eller dagar att slutföra). ^{[ citat behövs ]}

Topologier

Det finns två huvudtopologier: nav och eker och buss . Var och en har sina egna fördelar och nackdelar. I nav-och-ek-modellen är EAI-systemet i centrum (navet), och interagerar med applikationerna via ekrarna. I bussmodellen är EAI-systemet bussen (eller implementeras som en resident modul i en redan befintlig meddelandebuss eller meddelandeorienterad mellanprogramvara ). ^{[ citat behövs ]}

De flesta stora företag använder zonerade nätverk för att skapa ett lager försvar mot nätverksorienterade hot. Till exempel har ett företag vanligtvis en kreditkortsbehandlingszon (PCI-kompatibel), en icke-PCI-zon, en datazon, en DMZ-zon för att proxyservera extern användaråtkomst och en IWZ-zon för att ge proxy intern användaråtkomst. Applikationer måste integreras över flera zoner. Nav- och ekermodellen skulle fungera bättre i det här fallet. ^{[ citat behövs ]}

Teknologier

Flera tekniker används för att implementera var och en av komponenterna i EAI-systemet: [ ^{citat behövs ]}

Buss/hubb: Detta implementeras vanligtvis genom att förbättra standardmellanprogramprodukter ( applikationsserver , meddelandebuss) eller implementeras som ett fristående program (dvs. använder inte någon mellanprogramvara), som fungerar som sin egen mellanvara.
Applikationsanslutning: Bussen/hubben ansluter till applikationer via en uppsättning adaptrar (även kallade kontakter ). Det här är program som vet hur man interagerar med en underliggande affärsapplikation. Adaptern utför envägskommunikation (enkelriktad), utför förfrågningar från hubben mot applikationen och meddelar hubben när en händelse av intresse inträffar i applikationen (en ny post har infogats, en transaktion slutförd, etc.). Adaptrar kan vara specifika för en applikation (t.ex. byggda mot applikationsleverantörens klientbibliotek) eller specifika för en klass av applikationer (t.ex. kan interagera med vilken applikation som helst genom ett standardkommunikationsprotokoll, såsom SOAP , SMTP eller Action Message Format ( AMF ) )). Adaptern kan finnas i samma processutrymme som bussen/hubben eller köras på en avlägsen plats och interagera med hubben/bussen genom industristandardprotokoll såsom meddelandeköer, webbtjänster eller till och med använda ett proprietärt protokoll. I Java-världen tillåter standarder som JCA adaptrar att skapas på ett leverantörsneutralt sätt.
Dataformat och transformation: För att undvika att varje adapter måste konvertera data till/från alla andra applikationers format, föreskriver EAI-system vanligtvis ett applikationsoberoende (eller vanligt) dataformat. EAI-systemet tillhandahåller vanligtvis en datatransformationstjänst också för att hjälpa till att konvertera mellan applikationsspecifika och vanliga format. Detta görs i två steg: adaptern konverterar information från applikationens format till bussens vanliga format. Sedan tillämpas semantiska transformationer på detta (konvertera postnummer till stadsnamn, dela upp/sammanfoga objekt från en applikation till objekt i de andra applikationerna, och så vidare).
Integrationsmoduler: Ett EAI-system kan delta i flera samtidiga integrationsoperationer vid varje given tidpunkt, där varje typ av integration bearbetas av en annan integrationsmodul. Integrationsmoduler prenumererar på händelser av specifika typer och processmeddelanden som de får när dessa händelser inträffar. Dessa moduler kan implementeras på olika sätt: på Java -baserade EAI-system kan dessa vara webbapplikationer eller EJB:er eller till och med POJO:er som överensstämmer med EAI-systemets specifikationer.
Stöd för transaktioner: När det används för processintegration, ger EAI-systemet också transaktionskonsistens över applikationer genom att exekvera alla integrationsoperationer över alla applikationer i en enda övergripande distribuerad transaktion (med tvåfas commit-protokoll eller kompenserande transaktioner ).

Kommunikationsarkitekturer

För närvarande finns det många variationer av tankar om vad som utgör den bästa infrastrukturen, komponentmodellen och standardstrukturen för Enterprise Application Integration. Det verkar råda enighet om att fyra komponenter är väsentliga för en modern arkitektur för företagsapplikationsintegration: [ ^{citat behövs ]}

En centraliserad mäklare som hanterar säkerhet, åtkomst och kommunikation. Detta kan åstadkommas genom integrationsservrar (som School Interoperability Framework (SIF) Zone Integration Servers) eller genom liknande programvara som Enterprise Service Bus- modellen (ESB) som fungerar som en tjänstehanterare.
En oberoende datamodell baserad på en standarddatastruktur, även känd som en kanonisk datamodell . Det verkar som att XML och användningen av XML-stilmallar har blivit de facto och i vissa fall de jure standarden för detta enhetliga affärsspråk.
En anslutnings- eller agentmodell där varje leverantör, applikation eller gränssnitt kan bygga en enda komponent som kan tala inbyggt till den applikationen och kommunicera med den centraliserade mäklaren.
En systemmodell som definierar API:erna, dataflödet och reglerna för engagemang för systemet så att komponenter kan byggas för att samverka med det på ett standardiserat sätt.

Även om andra tillvägagångssätt som att ansluta på databas- eller användargränssnittsnivå har utforskats, har de inte visat sig skala eller kunna justeras. Enskilda applikationer kan publicera meddelanden till den centraliserade mäklaren och prenumerera på att ta emot vissa meddelanden från den mäklaren. Varje applikation kräver bara en anslutning till mäklaren. Denna centrala kontrollmetod kan vara extremt skalbar och mycket utvecklingsbar . ^{[ citat behövs ]}

Enterprise Application Integration är relaterad till middleware-teknologier som meddelandeorienterad middleware ( MOM ) och datarepresentationstekniker som XML eller JSON . Andra EAI-tekniker innebär att webbtjänster används som en del av tjänsteorienterad arkitektur som ett sätt att integrera. Enterprise Application Integration tenderar att vara datacentrerad. Inom en snar framtid kommer det att omfatta innehållsintegration och affärsprocesser . ^{[ citat behövs ]}

Implementeringsfällor

År 2003 rapporterades att 70 % av alla EAI-projekt misslyckades. De flesta av dessa fel beror inte på själva programvaran eller tekniska problem, utan på hanteringsproblem. Integrationskonsortiets europeiska ordförande, Steve Craggs, har beskrivit de sju huvudsakliga fallgropar som företag som använder EAI-system utsätts för och förklarar lösningar på dessa problem.

Ständig förändring: Själva naturen hos EAI är dynamisk och kräver dynamiska projektledare för att hantera deras implementering.
Brist på EAI-experter : EAI kräver kunskap om många frågor och tekniska aspekter.
Konkurrerande standarder: Inom EAI-området är paradoxen att EAI-standarder i sig inte är universella.
EAI är ett verktygsparadigm: EAI är inte ett verktyg, utan snarare ett system och bör implementeras som sådant.
Att bygga gränssnitt är en konst: Konstruera lösningen är inte tillräcklig. Lösningar måste förhandlas fram med användaravdelningar för att nå en gemensam konsensus om det slutliga resultatet. Bristande konsensus om gränssnittsdesign leder till alltför stora ansträngningar att kartlägga mellan olika systems datakrav.
Förlust av detaljer: Information som verkade oviktig i ett tidigare skede kan bli avgörande senare.
Ansvarsskyldighet: Eftersom så många avdelningar har många motstridiga krav bör det finnas ett tydligt ansvar för systemets slutliga struktur.

Andra potentiella problem kan uppstå inom dessa områden: ^{[ citat behövs ]}

Brist på centraliserad samordning av EAI-arbetet.
Nya krav: EAI-implementeringar bör vara utbyggbara och modulära för att möjliggöra framtida förändringar.
Protektionism: Applikationerna vars data integreras tillhör ofta olika avdelningar som har tekniska, kulturella och politiska skäl att inte vilja dela sina uppgifter med andra avdelningar

Se även

Initiativ och organisationer