SAP NetWeaver

Efter att ha lyssnat på Dag Königs podcast med Lars Lindberg från SAP inser man vilket fotfäste SOA och öppna standarder har fått. Med NetWeaver tar SAP steget från bilden av det monolitisk ERP-systemet till en rörlig sammansatt arkitektur. Tidigare versioner av SAPs affärssystem har visserligen varit moduluppbyggt, men med NetWeaver har man skapat en plattform för exekvering, underhåll, managering, monitoring av affärsprocesser som öppnar sig med 10 tusentals tjänster.

Vad man också kan snappa upp från intervjun är SAPs vision att NetWeaver ska bli en plattform för att bygga nya komposita processer för olika verksamheters behov. Det innebär att de konkurerar mer och mer med teknikleverantörer som IBM, Oracle och BEA. Partners eller kunder ska kunna förändra och skapa nya processer ovanpå NetWeaver som bygger på öppna standarder som BPEL, SAML och WS-*.

SAP har kommit så långt inom SOA området eftersom visionen med just SOA härstammar från deras egen bakgård. Man kan säga att det är på grund av SAP som behovet på rörlig arkitektur har uppkommit ;).

Vilken roll SAP spelar gentemot BEA, Oracle, MS och IBM kommer snart att visa sig.

Ska man kunna ett eller flera språk i framtiden?

C# 1.0 släpptes som RTM i februari 2002 och innehöll ett språk lika utvecklat som flera generationer Java. Alldeles nyligen släpptes C# 2.0 som innehåller bland annat generics, anonymous methods och iterators. Om ett tag kommer C# 3.0 med lambda-uttryck, extension methods, anonyma typer och query expressions. Spännande kan man tycka, men varför utvecklas ett språk så mycket på en plattform som är byggd för att kunna köra program utvecklade i vilket språk som helst (bara det finns en kompilator)?

Glömde nämna C# 4.0!

Nu var det inte C# jag tänkte på utan programspråk i allmänhet och BPEL i synnerhet. Java förstår jag om man utvecklat med tiden eftersom varken Java-utvecklare eller Java-miljöer kunde något annat eller hade förmågan att kommunicera utanför Java-domänen.

BPEL 1.0 har fått mycket stryk för att inte kunna stå upp mot de krav som finns på flödesorienterad utveckling. Läs exempelvis David Chappells punkter:

• BPEL kan inte aktivera lokala objekt.
• BPEL kan bara kommunicera genom Web Services.
• BPEL kan inte kommunicera direkt med relationsdatabaser.
• BPEL kan inte kommunicera med människor.
• BPEL kan inte distribueras som en assembly

Precis som Chappell säger så var det inte meningen att BPEL skulle kunna något annat heller. Han menar ändå att BPEL inte har någon plats eftersom det saknar så pass mycket verklighetsförankring till den värld den ska styra flödet över. Så vad inte Chappell skriver, men som framgår tydligt är att XOML (Windows Workflow Definition) har det BPEL saknar.

• XOML kan aktivera lokala objekt
• XOML kan kommunicera med andra XOML
• XOML kan distribueras som .NET assemblies
• XOML kan anropa .NET kod och kan därför göra "allt" inkl anropa en databas
• XOML kan kommunicera med människor eftersom det kommer som en del i Office 12 :-)

Samtidigt som C# byggs ut för att kunna ersätta alla andra programspråk (dynamiska, logiska, funktionella etc) så släpps snart BPEL 2.0 med stöd för vissa av de "brister" som Chappell pekar på. Varför ska ett språk som konstruerats för ett visst syfte behöva uppfylla en massa annat som inte har med visionen för språket att göra? Varför kan man inte använda BPEL till det det är till för och istället uppfinna andra språk som uppfyller andra ändamål?

Hur som helst så får vi med Web Services samma fördelar som med .NET, dvs att kunna välja programspråk fritt efter behov. .NET är en stabil plattform för att bygga applikationer och tjänster på, men den är inte ett krav för att bygga sammanhängande arkitekturer i framtiden. Säger man Web Services idag så tänker man på interop mellan olika tekniska plattformar. Det är sant, men i framtiden kan WS vara det som knyter samman olika domänspecifika språk (se även). Kan man inte skapa nytta med .NET som plattform så får vi ändå hoppas att Web Services uppfyller det.

Wolfram Meyer pratar SOA

http://www.microsoft.com/sverige/msdn/msdntv/?category=SOA

Insikter om SOA under 2006

1. Verksamhets- och tjänsteperspektiv
En SOA har inget med teknik att göra, Web Services möjliggör bara (då de inte försvårar). Visionen med en SOA är att IT-stödet ska mappa 1-1 mot tjänster i verksamheten för ökad rörlighet i din Enterprise Architecture (EA).

2. SOA = Tjänster + Processer + Aktiviteter
En SOA består av tre pelare 1) tjänster som omfattar 2) processer som består av 3) aktiviteter. Produkter som implementerar stöd för SOA-paradigmen kallas Enterprise Service Bus.

3. Applikationen vs meta-applikationen
Det onda i en EA är applikationerna. EAI knyter samman applikationer och vittnar bara på ett sjukdomstillstånd. SOA knyter samman tjänster som supporteras i form av meta-applikationer.

4. Bygg inte ut integrationsramverket till en SOA
En SOA ska ersätta, inte bara det gamla integrationsramverket utan även alla monolitiska applikationer i din EA.

5. Skapa din SOA utifrån möjligheterna med BAM
Det finns många sätt att modellera en SOA. Att göra det utifrån ett aktivitetsperspektiv bygger på att den resulterande arkitekturen ska synliggöra ärenden som flödar via aktiviteterna i verksamhetsprocesserna. Business Activity Monitoring (BAM) är den enskilt största vinsten för en SOA som inte har med IT att göra.

6. Designa alla nya applikationer för SOA
Varje ny applikation som ska byggas i din EA ska byggas för SOA, dvs baserat på tjänstenätverket.

SOA-kartläggning

För ett tag sedan skrev Tamina Vahidy en artikel om resultatet av en undersökning som gick ut på att kartlägga vilka komponenter som användes mest för att uppnå en SOA.

• 71% Web Services
• 61% Portalramverk
• 46% Applikationsserver
• 43% Integrationsramverk
• 36% Säkerhetsramverk
• 18% Analysramverk
• 18% Datacentralisering
• 14% ESB
• 14% BPM

Tamina konstaterar "- That's an excellent illustration not just of how companies are building SOA, but of SOA's complexity". Hon säger att SOA är inte en applikation, utan en paradigm. SOA är allt ovan, från portalramverk till datacentralisering. Det är det som gör det komplext!

Sedan kan man ju konstatera att prioriteringarna (av siffrorna ovan att dömma) är något förskjutna mot EAI och inte de delar som implementerar det unika med en SOA, nämligen BPM och ESB. Det är bara att konstatera att vi kommer få se negativa erfarenheter av SOA så länge man inte uppnår målen med SOA. Ronan Bradly beskyller produktleverantörerna för att paketera sina gamla EAI-produkter som ESB:er, vilket jag skriver under på.

SOA och DSL

Det har alltid funnits ett stort gap mellan problembeskrivaren och problemlösaren när det kommer till programutveckling. Det gapet har med tiden försökts att överbryggas på alla tänkbara sätt. Problem beskrivs av personer som har kunskaper inom problemdomänen, medan lösningen skapas av personer som har kunskap i verktygen som används för att konstruera lösningen.

En väg att minska gapet och som fått alldeles för stort genomslag är CASE-verktygen, som exempelvis Rational. I ett CASE-verktyg enas problembeskrivaren och problemlösaren i ett gemensamt språk och metodik som ex. UML/RUP. Det finns generellt sätt mängder av problem med den här typen av modeller, men i synnerhet ett som har förpassat UML & Co till 90-talet. UML kan nämligen inte exekveras!

Att UML inte kan exekveras har man försökt att åtgärda med hjälp av kodgenerering. Det blev aldrig, av förståliga skäl, någon hit eftersom den genererade koden inte fick några fans bland utvecklarna som hela tiden låg steget före med ny teknik. UML är även ett problem med tanke på underhåll eftersom man blev tvungen att underhålla både kodbasen och modellen. UML nådde heller inte fram till roten av problemet, att minska gapet, utan skapade istället två nya raviner. Det första mellan problembeskrivaren och modellen, men även mellan modellen och problemlösaren. Den fylldes med nya roller som titulerade sig analytiker, kravhanterare och andra former av "fördyrande mellanhänder".

DSL (Domain Specific Languages) är ett annat sätt att minska gapet. Det går ut på att skapa språk som kan exekveras samtidigt som det närmar sig problembeskrivaren genom att "prata" samma språk som honom. Det viktiga med DSL är just att det, precis som UML, ska ge möjligheten att modellera inom problemdomänen samtidigt som det ger ett resultat som kan exekveras.

Ett enda språk kan inte lösa alla problem. Därför måste det finnas en mängd språk som på olika nivåer skapar lösningen. Vissa språk är nära problembeskrivaren och andra är närmare tekniken. Det är lite som idén med .NET (även om MS väljer att ersätta alla andra programspråk med C#) där flera språk enas runt en exekveringsmodell, tillskillnad från Java där alla kodare enas runt ett språk som ska passa alla problem.

En SOA är ett nätverk av komponenter av DSL:er som samspelar med det gemensamma i Web Services. Web Services ger även möjligheten att konstruera arkitekturer av komponenter utvecklade för olika exekveringsplattformar, vilket betyder att man kan uppnå fördelarna med .NET utan att för den delen vara fullt beroende av en exkeveringsmodell.

Skikten av språk som används, nära problembeskrivarens domäner ned till tekniken skiljer sig mellan en traditionel arkitektur och en SOA. I en klassisk skiktad arkitektur så finns en hierarki där ju närmare problemet man kommer desto mer finns behovet av DSL:er. Att knyta samman alla språken i ett gemensamt meta-språk kommer säkert ge de stora leverantörerna något nytt att bråka om framöver (se SCA och SDM).

Oavsett vem som bygger det ultimata meta-meta-meta-...-språket så är en SOA ett klockrent exempel på hur olika DSL:er samspelar i en arkitektur. Där finns det nämligen ingen hierarki som avgör vem som orkestrerar vem. En SOA är ett nätverk och inte en skiktad arkitektur.

WS-Management

WS-Management (eller MS-Management) har publicerats här.

Läs mer om WS-Management här.

Enligt denna källa kommer WCF i.o.m. R2 supporteras av WS-Management.

Tjänsteorientering IV - Första steget

Att uppnå en SOA är ingen enkel omställning. Att gå från en applikationsorienterad IT-miljö till en tjänsteorienterad kräver stora förändringar inom IT.

Applikationer har karaktäriserats som en paketering av tjänster, där just paketering har ingivit en positiv trygghetskänsla. Trygghet både för den som använder applikationen, men även för den som erbjuder tjänsterna. Det negativa med applikationen är att den är som en svart låda som säger "jag erbjuder allt eller inget" i form av tjänster.

Applikationer saknar förmågan att kunna kopplas ihop med omvärlden om man inte gör det på applikationens villkor. Dels mellan lager som gränssnitt, logik och data, men även tjänstevis. En SOA måste kunna erbjuda samma trygghet som en applikationen ger, men även uppfylla de delar som anses vara negativa med applikationer. Ett tjänstenätverk måste kunna gruppera tjänster i vita lådor, eller meta-applikationer. En meta-applikation är en paketering av tjänster i en SOA som ska garantera samma trygghet man fick med en vanlig applikation.

Meta-applikationen har en rörlighet som en traditionell applikation saknar. Den består av ett tjänstenätverk som en del av ett större nätverk. Gränserna för meta-applikationen manageras av verktyg som kan upprätthålla dess förväntade tjänstenivå.




Här måste SOA börja, d v s att applikationerna förändras. Att bygga en SOA är ett jobb som arbetar sig bottom-up. Sitter man på en applikationmiljö som behöver integreras m h a en broker-lösning eller ett middleware så kan man definitivt göra det som en start. Men en SOA handlar om att få bort applikationerna och byta ut dom mot meta-applikationer i ett tjänstenätverk.

Så trycket måste ligga på applikationsutvecklarna om SOA ska bli en realitet. Tillsvidare får IT nöja sig med applikationsintegration, vilket tyvärr ändå verkar vara det enda så gått fram till IT som en definition av SOA.

Måsteläsning

http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/ws-soa-whitepaper.pdf

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: