Enterprise Application Integration (EAI) kopplar samman applikationer och får dem att samverka på en högre (Enterprise) nivå. En EAI-lösning karraktäriseras av flödesbeskrivningar, transformationer och adaptrar som ska se till att rätt information kommer till rätt applikation. EAI implementeras i en Integration Broker. EAI ser exempelvis till att integrera order- och faktureringssystemet. Då kopplas en adapter till ordersystemet för att hämta ut orderinformationen, transformerar den till faktureringsunderlag och sedan genom ytterligare en adapter styra informationen till fakturasystemet. Den största fördelen med EAI är att det ger möjlighet att följa en order mellan de olika applikationerna, s k Business Activity Monitoring (BAM). En annan fördel är den åstadkomna abstraktionsnivån mellan processerna i verksamheten och applikationerna. Det ger ett löst kopplat processnätverk som möjliggör utbytbarhet och flexibilitet.
Enterprise Information Integration (EII) bygger på att man har en virtuell databas som inte innehåller någon information utan vet bara var den ska leta om någon frågar. Tillskillnad från EAI så löser EII en identitetskris, d v s problemet med informationens hemvist och korrekthet. Finns rätt kundinformation i applikation A eller B? Inkorrekt information kan vara kostsamt och katastrofalt i värsta fall. Därför är den här typen av system väldigt viktiga att implementera om man har en decentraliserad informationslagring. System som stödjer EII kallas för Information Brokers. De implementerar ett Meta Repository med information om var informationen finns, dess format, typ m m. En Broker hanterar även pub/sub vilket gör att applikationer kan prenumerera på informationsändringar när de inträffar i någon annan applikation.
Extract, Transform och Load (ETL) förutsätter däremot en riktig databas som innehåller information. Det är ett Data Warehouse som lagrar, indexerar och aggregerar information för analys. Ett Data Warehouse används inte som en uniform databas där alla applikationer läser och skriver, utan enbart för analys.
Business To Business (B2B) är som EAI fast mellan Enterprises.
Alla integrationsmetoderna ovan är skapta för att lösa olika problem som uppstår i en heterogen applikationsmiljö. EAI abstraherar applikationerna från processerna i en verksamhet vilket ger en överblick och inblick i flödet. EII säkerställer att informationen i en verksamhet är korrekt. ETL möjliggör analys och sökningar i stora datamängder som inte skulle vara möjligt annars.
Arkitektur
Så hur kommer SOA in i bilden? SOA är inte en integrationsmetod som de andra tre, utan en arkitektur för att undvika att hamna i ett integrationsscenario och alla problem som uppstår i samband med det. Det finns ett antal andra arkitekturer som provats med olika framgång.
Först och främst är väl den som SAP implementerar, Enterprise Resource Planning (ERP). D v s en homogen miljö där applikationerna som levereras kommer från en och samma leverantör och är byggda för att fungera tillsammans. Nackdelen med det är att man blir fullständigt leverantörsberoende samt att man förmodligen ändå någon gång kommer att hamna i ett integrationsbehov.
Nästa arkitektur som kan nämnas är datacentralisering där alla applikationer använder samma datakälla och skulle därmed dela informationsmodell. Lika osannolikt som det låter.
En populär arkitektur på 90-talet var är centralisering av transaktionerna i ett Enterprise Object Framework som stöds av olika EJB implementationer. Det bygger på att alla transaktioner hanteras av ett och samma ramverk. Använder man inte ramverket så fungerar inte modellen.
Till förra århundradet hör även portalerna. Webbplatserna som skulle ersätta allt GUI och prata direkt med APIer exponerade från applikationerna. Inte heller ett troligt scenario som skapade svåra underhållsproblem.
Portaler, EOF och datacentralisering lyfte inte utan skapade istället nya integrationsproblem som låste in IT-avdelningar i svårhanterade hemmabyggda arkitekturer.
Tjänsteorienterad arkitektur
SOA är en arkitektur som "lärt sig" av misstaget med portaler, EOF och datacentralisering. SOA tar EAI ett steg längre ned i arkitekturen och upplöser applikationsgränserna som ersätts med tjänster. Det som först och främst skiljer en SOA från EAI är att en riktig SOA bygger på standardiserade tjänster och inte adaptrar och applikationer. Fördelarna med EAI och BAM finns inbyggda överallt i en SOA. EAI är som en ofullständig SOA.
När det kommer till EII så har en SOA inbyggd hantering av lokalisering av information (data services). EII är en naturlig del av en SOA med möjligheter att slå upp var informationen finns åtkomlig. Det gäller inte bara information och data i en SOA. På samma sätt blir processer åtkomliga på ett intelligent sätt.
ETL och SOA har inte lika mycket med varandra att göra, men eftersom informationensåtkomsten är standardiserad så kan Data Warehouse enkelt fyllas med information.
B2B är bara en förlängning av SOA från Enterprise nivå till cross-Enterprise.
Alternativa arkitekturer
Det finns även en halvmesyr som kan anses vara den mest verklighetsförankrade arkitekturen. Nämligen en heterogen applikationsmiljö med EAI, EII, ETL och B2B som bygger helt och hållet på WS-Endpoints á la WS-*. Vi kan kalla det Enterprise Web Service Enabled Application Integration (EWSEAI). Tyvärr fortfarande med applikationer i grunden (vilket en SOA inte har (den har tjänster (tjänster i bemärkelsen Business Service (inte Web Services (som föranleder det globala missförståndet om SOA))))).
Det finns även en arkitektur som kallas Bus Architecture och bygger på en Enterprise Service Bus (ESB). Den fungerar som den ovan fast med en annorlunda decentraliserad topologi. En ESB och Integration Broker är i praktiken implementerade på samma sätt men ritas oftast ut i olika diagram på två olika sätt.
Inga kommentarer:
Skicka en kommentar