Tjänsteorientering III - Vägen dit

Vägen till en SOA tar sig olika beroende på var man befinner sig. Många kan relatera till bilden nedan med ett antal applikationer sammankopplade till varandra efter behov och med webbar som gör anropar direkt mot applikationerna. Det här är en vanlig arkitektur och kallas i integrationskretsar för "spagetti" eftersom allt hänger samman genom peer-to-peer.



Andra har byggt ett Middleware á la 90-tal, baserat på ett integrationsramverk utvecklat på J2EE eller Windows DNA. Kostnaderna har här mest att göra med underhållsproblem och integrationskostnader när det ska ske tillägg eller förändringar i ramverket.



Möjligen har man investerat stora pengar i ett integrationsnav eller en "Integration Broker". I så fall har man skapat bra förutsättningar för att integrera applikationer. En integrationsplattform är en öppen lättskött miljö för att integrera applikationer.



Men för att nå en SOA så måste siktet vara inställt på att skapa ett komplett tjänstenätverk istället för applikationer. En SOA bygger på standarder och kan enbart fungera i en värld där man som konsument och producent av tjänster kan lita på sin motpart.



SOA handlar alltså om tjänster som i sin tur handlar om tillit. Tillit handlar om Service Level Agreements, standarder, kontrakt, policies och säkerhet. För att kunna bygga upp ett tjänstenätverk måste man bygga tillit på just dessa komponenter. OASIS och W3C definierar just dessa komponenter som ska garantera tillit i ett tjänstenäteverk. Produktleverentörer inom SOA måste förhålla sig till standarder för att nätverket ska fungera.

Tjänsteorientering II - En utopi

I Tjänsteorientering I illustrerades hur mycket bättre en SOA mappar mot en verksamhet jämfört med en applikationsmiljö. Anledningen till att man vill skapa en avbild av verksamheten gentemot arkitekturen beror på att man kan ta samma beslut för en arkitektur som man gör för en organisation. Det kan gälla omorganisation, förändringar, nedskärningar, utflyttning (out sourcing) , m m.

Applikationer paketerar tjänster, processer och aktiviteter i en svart låda där man är tvingad till att använda allt eller inget. Applikation löser ofta problem som hör hemma i en viss del av en verksamhet, men de tar ingen hänsyn till att det finns andra applikationer som lagrar samma information eller använder samma tjänster. Det är en stor dubblering av både data och funktion i en applikationsmiljö.

I en SOA existerar inga applikationsbarriärer. I ett tjänstenätverk finns det visserligen dubbletter av data och funktion, men det är under ordnade former. Dessa former är vad man inom SOA kallar för Service Management. Det kallas även Service Governance och är även det hämtat från affärsvärlden och har med styrning av en verksamhet att göra.

SOA är en utopi av en värld där IT-stödet består av tjänster som mappar mot tjänster i verksamheten vilket ska göra den lika kontrollerad som en organisation.

Tjänsteorientering I - En avbild

Det här är första av fem bloginlägg om tjänstorienteringens uppgång och fall.

En affärsverksamhet består av personal och tjänster som är representerade i en organisation.

Fig 1. En förenklad bild av en affärsverksamhet

Så här kan en verksamhet struktureras lite förenklat. Det stöd en organsiation normalt sätt får i en applikationsorienterad IT-miljö ser ut som nedan.

Fig 2. En förenklad bild av en generell IT-miljö

Som man ser döljer applikationens gränser en stor del av det verksamheten byggs upp av. D v s om verksamheten ska omstruktureras finns det inget genomslag i applikationen.

En bättre representation av verksamheten skulle man kunna få i en SOA som i bilden nedan.

Fig 3. En förenklad bild av en SOA

En SOA är en direkt avbild av en verksamhet.

• Varje behov av tjänst finns representerad i arkitekturen, varken mer eller mindre.
• Varje arbetsprocess finns representerad i arkitekturen, varken mer eller mindre.
• Varje aktivitet finns representerad i arkitekturen, varken mer eller mindre.

SOA inte bara framgång

Efter att ha läst resultatet från en undersökning om SOA-införanden så dyker frågorna upp. Varför misslyckas ett av sju projekt? Varför förutsåg man inte att ett införande av SOA skulle ta sådan tid? Vad hade man för bild av SOA och vilka problem försökte man lösa? Vilken metodik hade man vid införandet och vilka var förväntningarna? Vilken teknik användes och hur organiserade man sig? Var hittade man kompetensen och vilka var inblandade? Vad är kriteriet för misslyckande?

SOA & outsourcing

Outsourcing motiveras ofta med lägre kostnader, bättre kvalité, snabbare time-to-market, högre flexibilitet och rörlighet. Samma fördelar gäller även för en SOA, så vad har de med varandra att göra?

Läs det här dokumentet av Martin Eldracher som beskriver SOA och outsourcing.

Se även ett dokument från ZapThink i samma ämne.

Byta tjänsteleverantör borde vara lika enkelt som att gå till Konsum istället för ICA.

90-talets integrationsplattformar

På slutet av 90-talet var det två teknologier som dominerade det mesta, Enterprise Java Beans och COM. Det finns inte många företag som inte byggde sina integrationsplattformar på EJB eller COM. Tanken var som alltid med integrationsplattformar att skapa ett centraliserat integrationsramverk som applikationer, webbportaler och B2B kunde gå igenom för att kommunicera med bakomliggande system.

COM och EJB har många fördelar, men som ramverk för integration är de inte perfekta. Jag vill peka på fyra av problemen med dessa ramverk:

1. För det första så är det problem med interoperabiliteten. Både COM och EJB kräver sin motsvarighet för att kunna integreras, dvs har du EJB som ramverk, kräver det java på klienten och samma sak med COM.
2. Ramverken är skrivna i VB/C++ resp Java som kan anses vara lågnivåspråk i ett integrationssammanhang. Det gör ramverken svåra och dyra att underhålla.
3. Ramverken är "svarta lådor" som döljer vad som händer inom dom. Transparansen är obefintlig vilket är ett problem vid integrationssammanhang då extra god överblick är av vikt.
4. Java och COM har två olika protokoll som de använder för att kommunicera mellan klienterna och ramverket. Det protokollet var inte konstruerat för integration, utan snarare för klient/server-applikationer.

Web Services är ju svaret på problemet med interoperabiltet och kommunikationsprotokoll (nummer 1 & 4). Däremot så kvarstår problemen med implementationen. Många företag idag ser SOA som att exponera Web Services på sina existerande ramverk för att göra dem mer åtkomliga och samtidigt inte behöva ta en investering för att ersätta det gamla ramverket. Så kan man göra, men det ger ingen vinst när det kommer till integrationskostnader.

Kostnaderna med integration har att göra med punkt 2 och 3 ovan, d v s implementationen av tjänsterna. För att undvika det så ska integrationsramverket implementeras i en mer transparant och lättrörlig arkitektur. Enterprise Service Bus (ESB) eller Integration Brokers (IB) är skapta för att just ge dom fördelarna utöver interop och kommunikation som tillsammans skapar en flexibel integrationsplattform.

Falluckan med ett integrationsramverk baserat på EJB eller COM som ska migreras till en SOA är hur man ser på tjänsterna. Det är viktigt att man inte mappar det gamla ramverkets design direkt till ett tjänstenätvärk utan bygger det på den nya teknikens möjligheter och begränsningar.

Steg 1:
Steg 2:
Steg 3:

Vad är SOA utan distribuerade händelser?

I COM+ finns något som kallas för Loosely Coupled Events eller distribuerade händelser. Ett COM-objekt kan registrera sig för att prenumerera på händelser från ett annat COM-objekt utan att det andra är medveten om det första. Ur ett integrationsperspektiv så är distribuerade händelser en viktig ingridiens som förenklar mycket för både integratören och applikationsutvecklaren. Tekniken för det är implementerat inne i COM+ och är inte en del av varken prenumeranten eller servern. På liknande sätt har man specificerat det för Web Services genom WS-Eventing.

WS-Eventing beskriver hur man kan skapa prenumerationer på händelser över Web Services. Klienten skickar över en förfrågan av en prenumeration till en tjänst. Den förfrågan innehåller vilken händelse som är av intresse samt vart händelsen ska skickas när den inträffar. Allt som implementerar distribueringen av händelsen är inbyggt i WS-plattformen.

När behöver man distribuerade händelser? Händelser inträffar ju lite när som helst mellan och inom applikationer. En distribuerad händelse är bara aktuell då tjänsten eller applikationen som skapar den inte vet vem eller vilka som är intresserad av den. I första hand då något tillstånd har förändrats som man vill notifiera omvärlden om. En distribuerad händelse är dock inte intressant då en tjänst tagit emot en förfrågan från en klient som vill har ett svar, nu direkt eller senare. I det fallet känner tjänsten till klienten och svaret skickas enbart till den. Däremot kan tjänsten, som en sideffekt av det, skapa en distribuerad händelse för att notifiera övriga klienter om en tillståndförändring.

Distribuerade händelser är en naturlig del av en SOA. Den del av SOA vi känner väl är där orkestreringen av tjänster beskriver flödet och kommunikationen inom tjänstenätverket. Men det finns även en del som måste vara händelsestyrd och inte helt förutsatt. En SOA behöver WS-Eventing och innan plattformarna stödjer det så kan SOA anses vara en stel och statisk arkitektur.

Hur passar SOA in bland EAI, EII och ETL?

Integration
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.