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:

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.

Att införa SOA

Är ni i startgroparna för att dra igång en SOA-satsning? Funderar ni på i vilken ände ni ska börja för att bygga en SOA? Kanske undrar ni om man ska börja med att kartlägga processerna i verksamheten, eller en inventering av nuvarande applikationsmiljö, eller kanske hitta produkter som kan förverkliga en SOA? Är sådant fallet, så är ni helt rätt ute. Alla tre aktiviterna krävs för att planera ett införande av en SOA. Men innan ni börjar införa en SOA så är det viktigt att ni är klara över vilka fördelarna är och vad ni ska tjäna på en SOA.

Fördelarna
En SOA kan sammanfattas i att skapa en IT-miljö som ligger i linje med en föränderlig omvärld eller en verksamhet. En SOA ska kunna svara direkt mot alla förändringar i den verksamhet som den implementerar. Den ska även kunna signalera tillbaka nödvändiga förändringar till verksamhetens processer.

1. Processerna
SOA handlar om att lära känna sina processer. Kännedomen om processerna är grundläggande inom SOA. Utifrån processerna byggs tjänstenätverket upp. Alla behov av tjänster utgår ifrån processerna. Underordnade tjänster till processerna är först och främst andra processer, men även datatjänster, interaktiva tjänster (som kräver mänsklig dialog) samt en grupp av beräkningstjänster. Kartläggningen innefattar processerna och dess beroenden till data och interaktivitet.

2. Applikationsmiljön
Nästa steg är att inventera den nuvarande applikationsmiljön för att veta var man står. Troligtvis finner man ett antal applikationer. Applikationer är silos som äger information och ansvarar för dess korrekthet så länge man går via applikationens gränssnitt. Applikationer abstraherar och döljer ingående processer, data och dialog med användarna. I en SOA existerar däremot inte applikationsbegreppet. I en SOA är istället processerna, datat och beräkningarna fria tjänster som är möjliga att återanvända för att bygga upp tjänstenätverket med.

3. Produkterna
Förr i tiden då man skapade datacentriska arkitekturer nyttjades teknologi och metodik som exempelvis Domain Driven Design, objektorientering och EJB. SOA kräver också sina produkter för att underlätta designen. I det här fallet ska det underlätta för processdriven design. Det finns olika åsikter om vem som har den bästa plattformen för SOA. Några kommer att satsa på en leverantör av hela plattformen (en superplattform), andra kommer välja det bästa av det mesta (best of breed). Det viktiga är att i en SOA ha kolla på var alla produkter kommer in i bilden och hur de hänger samman. Plattformen består bland annat av stöd för kommunikation, interaktivitet, processer, integration, säkerhet, datahantering och övervakning.

4. Införandet
När processerna är kartlagda, applikationsmiljön inventerad och man är konfortabel med en plattform så kan man planerar sitt införande av SOA. En fullständig SOA är inte ett troligt resultat av införandet. Man kommer alltid ha ett antal applikationer kvar från den gamla miljön som måste integreras. Så även om en SOA bygger på att alla applikationer ska ersättas med ett tjänstenätverk så bör man istället jobba uppifrån och ned. Börja med de övergripande processerna och integrera in applikationerna i tjänstenätverket. SOA handlar inte om att bygga om och kasta ut. Det handlar om att ha en strategi för att skapa en arkitektur som är lika föränderlig som din verksamhet kräver.

Go SOA!

Är SOA en nollvision?

Världsorganisationer strävar efter global fred, mänskliga rättigheter och rättvisa. Ett samhälle strävar efter att ingen medborgare ska gå arbetslös, vara sjuk eller stå som bostadslös. Mindre organisationer strävar efter att ingen ska dö i trafiken, av rökning eller alkohol. Att sträva efter något är att ha en nollvision som mål.

I vissa fall är andra mål än en nollvision oacceptabla, eller snarare omöjliga för att driva på arbetet med att nå målet. Nollvisioner sätts då målet aldrig kan realiseras pågrund av att målgruppen och motståndet är för stort. Nollvisionen är ouppnålig men ska driva på det bästa möjliga alternativet.

Motståndet inom målgruppen i nollvisionen består oftast av:

1) ovilja - "vissa vill inte sluta röka"
2) illvilja - "motstånd i eget intresse (ex. Swedish Match)"
3) konkurens - "oenighet om hur visionen ska uppnås"
4) inkompetens - "felaktiga tillvägagångssätt att uppnå visionen (ex. FIMPA NU!)"
5) begreppsförvirring - "tvetydighet runt definitioner"

Ju större grupp som innefattas av en nollvision och ju större motstånd det finns inom gruppen, desto svårare är det att uppnå målet. Världsfred är t ex svårare att uppnå än att alla Stockholmare ska sluta röka.

Jag skulle vilja påstå att SOA är en nollvision, dvs något man kan sträva efter men aldrig kommer uppnå pga dess komplexitet.

Man kan inte säga att man har en SOA förän man uppnått visionen av den gamla klyschan, att ha en fullständigt normaliserad modell. SOA-modellen består av ett tjänstenätverk där ingen tjänst förekommer mer än en gång och under varje tjänst utnyttjas tjänstenätverket om och om igen. Tjänstenätverket sprider sig ut från lokala resurser till globala och universella. När nätverket är komplett och normaliserat så har man uppnått SOA.

Det räcker med att en enda person inte slutat röka så har man inte nått målet med hela gruppen. Samma sak med SOA; det räcker med att en tjänst inte nyttjar tjänstenätverket, så har inte SOA uppnåtts. Antag att man genom ett lager exponerar ut tjänster för access till ett legacy-system. Det systemet använder inte tjänstenätverket och arkitekturen är därmed inte SOA.

Så vad betyder det här för de som ska satsa på SOA? Jo, att SOA bara är något man kan sträva efter och inte något man kan uppnå. Det gör inget om en tjänst inte utnyttjar tjänstenätverket, men man ska veta att det inte är en SOA man då åstadkommit. Men fortsätt att sträva efter en SOA! Det finns mycket att vinna bara genom att vara på väg mot målet.

Superplattformen

Enligt Anne Thomas Manes på Burton Group kommer satsningarna på tjänsteorienterade arkitekturer dela upp marknaden mellan leverantörer av superplattformar, medan resten gör sig icke besvär.

Hon menar att de få (IBM, MS, Oracle och BEA) som kan stoltsera leverantör av superplattformen kommer att slå undan fötterna på mellanskiktet (Sybase, Iona, mfl) och låsa upp kunderna mot respektive leverantör för lång framtid.

Superplattformen är "sammanhållande" (cohesive) och måste bl a innehålla teknik och produkter för:

• Portal Management
• Process Management
• Integration Management
• Database Management
• Operation Management
• Registry Management
• Security Management
• Service Distribution Management

Jag vet inte hur väl det rimmar med att SOA ska vara en löst kopplad arkitektur av tjänster baserade på standardiserad teknik. Men det finns ju en verklighet att ta hänsyn till.

Implementera datatjänster med SQL Server 2005

I SQL Server 2005 kan du enkelt skapa en HTTP endpoint till dina lagrade procedurer. Varför inte ha tjänsterna så nära datat som möjligt? Nu finns ju även CLR och .NET Framework till förfogande även i SQL Server.

Anta att du ska implementera en tjänst som returnerar kundinformation. Då måste du först ha en lagrad procedur.

CREATE PROC dbo.spGetCustomerInfo
  @CustomerId varchar(10)
AS
  SELECT Name, Address, Phone
  FROM tblCustomer
  WHERE CustomerId = @CustomerId

Sedan skapar man bara en HTTP endpoint enligt:

CREATE ENDPOINT GetCustomerInfo
  STATE = STARTED
AS HTTP
(
  PATH = '/CRM',
  AUTHENTICATION = (INTEGRATED),
  PORTS = (CLEAR),
  SITE = 'localhost'
)
FOR SOAP
(
  WEBMETHOD 'GetCustomerInfo'
    (NAME='CRM.dbo.spGetCustomerInfo),
  BATCHES = DISABLED,
  WSDL = DEFAULT,
  DATABASE = 'CRM',
  NAMESPACE = 'urn:local/crm'
)
GO

WSDL-filen hittar man under http://localhost/crm?wsdl som innehåller schema information som mappar till SQL:ens interna typer.

Workflow-motorns stöd

Antag exemplet i föregående blog. Det som karrakteriserar dessa flöden var att:

• de spänner över tiden, ibland månader innan en lead resulterar i en leverans
• anropar eller blir anropade från underliggande tjänster
• består av tillståndsfulla instanser med egen information (exempelvis ett Lead)
• kopplar samman delprocesser och mappar direkt till affärsflödet i verksamheten

Att implementera flödet utan hjälp från en workflow-motor är tidskrävande och svårt. En workflow-motor supporterar all den funktionalitet som implementationen av flöden kräver.

• Flödesmodellering
• Assynkrona anrop till/från tjänster
• Tillståndshantering
  

Flödesmodellering
För att enkelt kunna jobba med processmodellen erbjuds gränssnitt där man enkelt kan skapa flöden, koppla samman dem med andra tjänster och även möjligheten att ändra beteendet i drift.

Assynkrona anrop till/från tjänster
För att stödja verksamhetens processer måste en workflow-motor kunna ta emot meddelande både vid start av en process, men även som händelser inne i en process. Ex. då en betalning i fakureringsprocessen kommer från en betalningstjänst.

Tillståndshantering
En workflow-motor måste kunna hantera tillstånd över tiden. En process ska kunna släckas ned för en tid och plockas upp då en händelse inträffar. Flödet bevaras med tiden och kan aktiveras av andra tjänster.

Stödet i en workflow-motor är bara en del av det som stöds i en ESB. Där ingår bland annat även support för:

• Distributionshantering
• Aktivitetsmonitorering
• Transformeringar
• Schemavalidering
• Säkerhet
• Skalbarhet

Exempel på processorienterad utveckling

Ett företag som säljer varor skulle kunna ha följande affärsprocess definierad för sin verksamhet.

En sådan process börjar med ett prospekt på en potentiell försäljning och slutar med en leverans. Processen är nedbruten i 4 andra processer; försäljning-, order-, fakturering- och leveransprocess. Anledningen till att man vill bryta ned processen i mindre delar är att skapa en flexibilitet i lösningen. Om verksamheten väljer att exempelvis byta ut en del mot en annan process så ska de andra inte drabbas av det.

Faktureringsprocessen är en delprocess i sammanhanget och definieras enligt flödesdiagrammet nedan. Varje process har ett gränssnitt, som i en SOA även kallas för en tjänst. Processen är alltså en tjänst och kan exponeras som t ex en web service. Indata till ett flöde är tjänstens anropsparametrar. För faktureringsprocessen blir det faktureringsunderlaget som är parameter. Faktureringsunderlaget kommer från orderprocessen.

I faktureringprocessen används bland annat en utskickstjänst. Den implementeras enligt flödet nedan. Innan en faktura skickas iväg så ska kundinformationen kompleteras. Därför anropas en tjänst som hämtar kundinformationen. Den tjänsten är en datatjänst, tillskillnad från en processtjänst som de två ovan är.

Flödet från försäljning ned till leverans och fakturering hanterar information och data som relaterar till entiteter i processen. Viss information hör till respektive instans av en process, medan annan information är global för alla instanser. Kundinformation kan förändras utanför processerna och ska därför inte ingå i processinformationen. Samma sak gäller varor, som också kan förändras med tiden. Därför så hämtar utskickstjänsten kundinformationen från en datatjänst (som exempelvis kan exponeras från ett CRM).

Det finns information som hör till en instans av en process. Fakturainformation är ett exempel på det. I den ingår kund- och produktinformation enbart som en relation (foreign keys), medan pris och fakturarader är exempel på information som verkligen hör till processinstansen. Nedan är kopplingen mellan processen och den information som hör till respektive instans:

Försäljningsprocess -> Lead
Orderprocess -> Order
Faktureringsprocess -> Faktura
Leveransprocess -> Leverans

Implementera datatjänster med LINQ

Project LINQ har fått enormt mycket uppmärksamhet efter PDC05. Med LINQ tar Microsoft ett steg närmare object-relational mapping och lämnar DataSet och tabeller som projektion på en relationsdatabas. Med LINQ kan man på lika smidigt sätt implementera en data service som du kunnat med DataSet, fast nu även med typinformation i kontraktet.

Har du skickat ett DataSet från en web service någon gång så kanske du lagt märke till att bara klienter som kan skapa just ett DataSet kan anropa din tjänst. Så här ser nämligen WSDL kontraktet ut:

<s:element name="GetMeetingRequestDSResponse">
  <s:complexType>
    <s:sequence>
      <s:element 
minOccurs="0" maxOccurs="1" name="GetMeetingRequestDSResult">
        <s:complexType>
          <s:sequence>
            <s:element ref="s:schema" />
            <s:any />
          </s:sequence>
        </s:complexType>
      </s:element>
    </s:sequence>
  </s:complexType>
</s:element>

 
[WebMethod]
public DataSet GetMeetingRequestDS()
{
 return new DataSet();
}

Typinformationen kommer i runtime och kan enbart konsumeras av ett DataSet. Det gäller även typade DataSet, vilket självfallet inte borde vara fallet eftersom typinformationen är känd i o m att det finns ett schema definierat.

DataSet är det idag enklaste och mest effektiva sättet att med Visual Studio och .NET Framework (Out Of the Box) skapa en datastruktur med innehåll från en relationsdatabas. Tyvärr så är det inte lämpligt att använda i en tjänstebaserad arkitektur, eftersom man inte bygger tjänster för att de ska konsumeras av en viss typ av plattform. Man vill ju ha ett teknikoberoende vilket man bara får om typerna som ska skickas över nätet kan definieras enligt WSDL.

En objektstruktur i .NET kan serialieras till en datastruktur som är kompatibel med WSDL. LINQ ger samma stöd som du får från DataSet för att populera en datastruktur fast för en godtycklig objektstruktur.

WWF och BizTalk

Windows Workflow Foundation har äntligen sett ljuset och kommer att ge .NET-utvecklaren nya möjligheter att jobba processorienterat. Fördelarna med WWF är att den inte kräver varken SQL Server för persistens eller BizTalk Server, utan ingår som en del av .NET Framework. WWF är en BizTalk light och kommer enligt MS passa för att utveckla processorienterat på applikationsnivå.

I en SOA-värld så flyter applikationsmodellen ihop och blir inte lika tydlig som den varit. Tidigare har man kunnat definiera en applikation som en isolerad mängd moduler som enbart fungerar tillsammans i en helhet. I en SOA raderas applikationsbegreppet ut och ersätts av tjänster som kan byggas samman mha processer/workflows. Den konstruktionen har från flera håll i branschen definierats som en Enterprise Service Bus.

Så om applikationer inte är en del av en SOA, varför säger man då att WWF är anpassat för applikationsnivån. Förmodligen så kommer vi från olika håll se exempel på samma kritik mot MS för WWF och BizTalk som IBM fått för sin WebSphere ESB.

Varför workflows?

Ingen säger det (och det) bättre eller så väl-timat som David Chappell.

Workflow workflow workflow

Den här web casten är en sammanfattning av vad Don Box och Dharma Shukla kommer att prata om på PDC. Missar du PDC men vill ändå vara uppdaterad i höst så är det här den Web Cast du inte får missa. Nu är process-centric development en nära verklighet för alla .NET-utvecklare.

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032280583&EventCategory=4&culture=en-US&CountryCode=US

Fler web casts i samma ämne hos Paul Andrew ...

Sammanfattning av BPEL

Den här artikeln rekommenderas från The Server Side .COM.

BPEL Learning Guide

Jag hittad en bra BPEL-guide som kan rekommenderas.

SOA och Data

SOA består av ett antal olika typer av tjänster. Själv ser jag tre stycken som är tydligare än andra, processer, data och interaktiva. Processer är tjänster som kopplar samman de övriga typerna och låter dom samspela (orchestrate). Datatjänster ger åtkomst till informationen som bearbetas i applikationen. Interaktiva tjänster är de som kräver männsklig dialog. För att dra en parallell till produktvärlden så är BizTalk Server ansvarig för processerna, SQL Server för datatjänsterna och Sharepoint/Exchange/InfoPath för interaktiva tjänster.

Processerna i sig hanterar också data. Men det datat är enbart information som är kopplat till processen och resten är nycklar till data som görs åtkomligt via daatjänsterna. En orderprocess skulle därför hantera orderinformationen, men ha nycklar till exempelvis kundinformationen som ligger åtkomlig genom datatjänster. BizTalk och andra produkter som kan agera processmotor kan hantera informationen som är knuten till processen genom stödet för persistens och long running transactions.

En SOA applikation som består av de tre delarna har sina egna tjänster för att fungera som exempelvis ett Customer Relational Management (CRM). Eftersom SOA kan skala till ett Enterprise så kan applikationen styra om sin dataåtkomst till att lagra datat centralt eller i en annan applikations dataservices. I en Enterprise SOA skulle det kunna finnas en Unified Data Model (UDM) som hanterar all dataåtkomst från alla applikationer. En UDM är även intressant i samband med Business Intelligence (BI) för att kunna skapa analyser av den totala informationsmängden. Tillsammans med information i processerna och Business Activity Monitoring (BAM) kan effektiva Key Performance Inidicators (KPI) ge aktuell och tidskritisk information som är viktig för verksamheten.



Samspelet mellan SOA och Business Intelligence kommer genom BAM och UDM skapa helt nya sätt att dra nytta av en flexibel arkitektur.

Människa datorinteraktion i en SOA

Även i en SOA kommer den människliga dialogen vara närvarande och kanske mer än någonsin. Människor kommer vara naturliga delar av de processer som ingår i applikationerna. Det kan antingen vara en användare som ska sätta igång en process, eller bara som en deltagare i ett steg i en process.

Vi är vana vid att skriva klientapplikationer i antingen Web-miljö eller som feta eller smarta klienter. Men det som delas mellan alla dessa är att de är mycket smartare än de borde vara. Ofta kodar man in flödeslogiken i klientapplikationer och inte bara de delar som interagerar med användaren. Det kan vara ett antal ASPX-sidor som anropar varandra med valideringsregler och ett flöde för att t ex mata in en kundorder eller uppdatera en kundpost. I en SOA så kommer vissa tjänster att exponeras till människor. En arkitektur där man flyttat logiken till processer kommer kräva ett nytt sätt att se på GUI.

Web Services for Remote Portlets (WSRP) är en OASIS standard som kommer att få stort genomslag bland GUI-utvecklare. WSRP definierar hur man ska bygga gränssnitt ovan på tjänster som ska interagera med användare. I en vanlig applikation är det interaktiva och flödeslogiken starkt ihopkopplat medan i en SOA är det löst kopplat. Antag en process för inköpsorderhantering. En anställd vill köpa något och hans chef ska attestera. Processen är flödeslogiken och är representerad av en tjänst, medan attesteringen hanteras av en annan tjänst.

Just nu byggs det portalservrar som är WSRP kompatibla för att kunna bygga upp snygga paketeringar av tjänster som kräver dialog med användaren. Microsoft har t ex Sharepoint Portal Server och InfoPath för att möta behoven i portalsammanhang. InfoPath kan även användas tillsammans med Exchange för att nå användarna då det kanske är mer bråttom i dialogen med användaren.

Vishet

Web Service Distributed Management (WSDM som uttalas 'wisdom') är en OASIS standard som kommer att få en stor betydelse i en SOA. Det mesta som har med tjänster i affärssammanhang att göra är på något sätt kontrakterat med ett avtal. Avtalet reglerar leverantörens och klientens skyldigheter och rättigheter. I IT-världen kallas det för Service Level Agreement (SLA) där leverantören deklarerar sina skyldigheter att kunna leverera tjänsten.

I en SOA kommer behovet att bli stort av den här typen av avtal eftersom systemen går från monolitiska komplexa applikationer där leverantören kan garantera en SLA för allt som händer inom applikationen till en arkitektur av sammankopplade mindre tjänster där många leverantörer ansvarar för sina tjänster. I en SOA måste en tjänst som inte kan hålla sin SLA, på grund av att en annan tjänsteleverantör inte levererar, styra om sin process mot en annan leverantör istället.

WSDM handlar om att administrera tjänster för att möte ett SLA. Ett exempel kan vara en leverantör av datorer som underkontrakterar leverantörer av komponenter. Datorleverantören har ett avtal med sin kund om kunna leverera produkten inom 10 dagar. Om då komponentleverantören inte hinner leverera måste en annan leverantör användas istället. Annars hinner man inte leverera inom 10 dagar.

HelloBPEL

Många har säkert sett The Evolution of a Programmer och tyckte det var komiskt hur mycket kod man kan skriva för att få ut "Hello World" på skärmen. Här är Hello BPEL.

En SOA bygger på meddelanden, tjänster och processer och det gäller även om man ska implementera något så simpelt som Hello World. För att köra det här exemplet krävs en ESB (ex. CapeClear, ActiveBPEL).

Meddelandet
Vi börjar med att definiera meddelandetyperna i XML Schema även om man normalt sett börjar med processen och därefter meddelandena.

Hello.xsd


<?xml version="1.0" encoding="utf-8" ?>
<xsd:schema targetNamespace="http://swenug.com/bpel-demo/Hello.xsd"
  xmlns="http://swenug.com/bpel-demo/Hello.xsd"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">

I schemat skapar man typerna som ska ingå i ett meddelande.

  <xsd:complexType name="HelloRequestType">
    <xsd:sequence>
        <xsd:element name="Name" type="xsd:string" />
    </xsd:sequence>
  </xsd:complexType>

I det här fallet så definierar vi en typ för anropet och ett för svaret.

  <xsd:complexType name="HelloResponseType">
    <xsd:sequence>
      <xsd:element name="Greeting" type="xsd:string" />
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>

Tjänsten
Tjänsten som deklareras i WSDL innehåller en import av meddelandetyperna, meddelandena själva, port, operation, address och bindning som tillsammans skapar tjänstekontraktet.

HelloService.wsdl

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
  targetNamespace="http://swenug.com/bpel-demo/HelloService.wsdl"
  xmlns:tns="http://swenug.com/bpel-demo/HelloService.wsdl"
  xmlns:htd="http://swenug.com/bpel-demo/schema"
  xmlns:imp="http://swenug.com/bpel-demo/Hello.xsd"
  xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">

Ett WSDL-kontrakt börjar alltid med en typdeklaration. 
Här importeras typerna från schemat.

  <wsdl:types>
    <xsd:schema
      targetNamespace="http://swenug.com/bpel-demo/schema"
      xmlns:imp="http://swenug.com/bpel-demo/Hello.xsd"
      xmlns:htd="http://swenug.com/bpel-demo/schema"
      xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema">

      <xsd:element name="HelloRequest" type="imp:HelloRequestType"/>
      <xsd:element name="HelloResponse" type="imp:HelloResponseType"/>
    <xsd:import
      namespace="http://swenug.com/bpel-demo/Hello.xsd"
      schemaLocation="http://swenug.com/bpel-demo/v.0.2.1/Hello.xsd"/>
    </xsd:schema>
  </wsdl:types>

Sedan deklareras själva meddelandena som ska användas i operationerna.
Typerna ovan är delar (parts) av ett meddelande.

  <wsdl:message name="HelloRequestMessage">
    <wsdl:part element="htd:HelloRequest" name="Salut"/>
  </wsdl:message>
  <wsdl:message name="HelloResponseMessage">
    <wsdl:part element="htd:HelloResponse" name="Greeting"/>
  </wsdl:message>

I WSDL är PortType som ett Interface är i C# eller Java. 
Operation kan liknas vid en metod.

  <wsdl:portType name="HelloPortType">
    <wsdl:operation name="sayHello">
      <wsdl:input message="tns:HelloRequestMessage"/>
      <wsdl:output message="tns:HelloResponseMessage"/>
    </wsdl:operation>
  </wsdl:portType>

Bindningen anger till den fysiska delen av kontraktet, 
på vilket sätt som meddelandena ska paketeras när de passerar porten.

  <wsdl:binding name="HelloBinding" type="tns:HelloPortType">
    <soap:binding style="document" 
transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="sayHello">
    <soap:operation soapAction="urn:Hello#sayHello">
      <wsdl:input>
        <soap:body parts="Salut" use="literal"/>
      </wsdl:input>
      <wsdl:output>
        <soap:body parts="Greeting" use="literal"/>
      </wsdl:output>
    </wsdl:operation>
  </wsdl:binding>

Den här delen av kontraktet binder porttypen/interfacet till en fysisk port.

  <wsdl:service name="HelloService">
    <wsdl:port binding="tns:HelloBinding" name="HelloPort">
      <soap:address location="http://servername/Hello"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>

Processen
Det är processen som ska göra jobbet, d v s implementera tjänsten. Innan vi skapar arbetsflödet i BPEL så måste vi ha en länk till kontraktet. Den skapas i en ny WSDL-fil.

HelloPartnerLinks.wsdl

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
  targetNamespace="http://swenug.com/bpel-demo/HelloPartnerLinks.wsdl"
  xmlns:tns="http://swenug.com/bpel-demo/HelloPartnerLinks.wsdl"
  xmlns:ns="http://swenug.com/bpel-demo/HelloService.wsdl"
  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">

  <wsdl:import namespace="http://swenug.com/bpel-demo/HelloService.wsdl"
    location="http://swenug.com/bpel-demo/v.0.2.1/HelloService.wsdl"/>

Här knyter vi ihop BPEL med kontraktet.

  <plnk:partnerLinkType name="HelloLink">
    <plnk:role name="ServiceProvider">
      <plnk:portType name="tns:HelloPortType"/>
    </plnk:role>
  </plnk:partnerLinkType>

</wsdl:definitions>

Nu är det dags för själv processen att beskrivas i BPEL.

HelloBPEL.bpel

<?xml version="1.0"?>
<bpws:process name="Hello"
  targetNamespace="http://swenug.com/bpel-demo/HelloBPEL.bpel"
  xmlns:tns="http://swenug.com/bpel-demo/HelloBPEL.bpel"
  xmlns:plt="http://swenug.com/bpel-demo/HelloPartnerLinks.wsdl"
  xmlns:hs="http://swenug.com/bpel-demo/HelloService.wsdl"
  xmlns:htd="http://swenug.com/bpel-demo/schema"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/">

Importera information om länken till kontraktet.

  <bpws:import 
location="http://swenug.com/bpel-demo/v.0.2.1/HelloPartnerLinks.wsdl"
    namespace="http://swenug.com/bpel-demo/HelloPartnerLinks.wsdl"
    importType="http://schemas.xmlsoap.org/wsdl/">
  </bpws:import>

Nu är det dags att sätta namn på länken till tjänstekontraktet 
 så det kan användas för åtkomst senare.

  <bpws:partnerLinks>
    <bpws:partnerLink myRole="ServiceProvider" name="HelloClient"
      partnerLinkType="plt:HelloLink">
    </bpws:partnerLink>
  </bpws:partnerLinks>

Processen behöver definiera variabler. De här två i scopet av hela processen.

  <bpws:variables>
    <bpws:variable messageType="hs:HelloRequestMessage"
      name="HelloRequestMessage" />
    <bpws:variable messageType="hs:HelloResponseMessage"
      name="HelloResponseMessage" />
  </bpws:variables>

Nu till själva flödet.

  <bpws:sequence>

Receive är starten på processen som även deklarerar 
att en ny instans av arbetsflödet ska skapas. 
Varje anrop in som inte görs till en existerande instans, 
skapar istället en ny.

      <bpws:receive partnerLink="HelloClient" portType="hs:HelloPortType"
        operation="sayHello" variable="HelloRequestMessage" createInstance="yes">
      </bpws:receive>

Det här är själva logiken bakom tilldelningen av svarsmeddelande. 
Här används ett uttryck som hämtar upp namnet ur meddelandet och 
bygger upp ett svar.

      <bpws:assign>
        <bpws:copy>
          <bpws:from expression="concat('Hello ',
bpws:getVariableData('HelloRequestMessage', 
'Salut', '/htd:HelloRequest') )"></bpws:from>
          <bpws:to variable="HelloResponseMessage" part="Greeting"/>
        </bpws:copy>
      </bpws:assign>

Det sista som behöver göras är att returnera svaret.

      <bpws:reply partnerLink="Hello" portType="hs:HelloPortType"
        operation="sayHello" variable="HelloResponseMessage">
      </bpws:reply>
  </bpws:sequence>
</bpws:process>

Vägen till tjänstebaserad arkitektur

En artikel om lite historik i samband med SOA.

Ensam är stark

Microsoft står på sig här och här om definitionen av en ESB. Nu verkar dock Redmond vara nära att bestämma sig för att en ESB kanske ändå är en produkt. Man säger iofs att BizTalk + WCF är en supermängd till ESB och att det bättre matchar kundernas krav. Det är ju sant, om man pratar integrationslösningar. Men roligt tycker jag det är med alla ESB:er som följer nya OASIS och W3C standarder till punkt och pricka för att driva SOA framåt utan att fastna för mycket i vad behoven är just idag. Men MS verkar idag och kommer säkert ha en produkt som matchar en ESB någon dag efter morgondagen.

SOA: Inte bara för Powerpoint-konsulter

Ofta får man höra att SOA är en arkitektur som passar för som man säger programming in the large. Det skrämmer en vanlig kodare som än själv ;) SOA är en arkitektur som skalar från det man normalt implementerar i en klass upp till orchestration på en hög nivå. SOA kryper in under skinnet och sträcker sig långt ned i det som vi idag kallar applikationer. SOA är en applikationsarkitektur lika väl som en enterprise arkitektur.

Så till alla programmerare: SOA är inte värt vatten om det inte börjar med att implementeras på applikationsnivå. SOA är inte bara för Powerpoint-konsulter.

O.b.s. Ser du en web sida som beskriver BPEL eller SOA som en teknik för att integrera applikationer med en service façade så anmäl den här ;)

SOA: Var går gränsen?

När SOA ska definieras hamnar man ofta i en diskussion som handlar om ytterligheter. Vart tycker du att SOA hamnar mellan de här två ytterligheterna?

1. En komplex enhet som innehåller all funktionalitet och data.
2. All funktionalitet och data representeras i oändligt många små okomplexa tjänster.

Jag vågar nästan säga att alla nog anser att det borde ligga någonstans i mitten. Men vad är det som bestämmer hur många tjänster som ska byggas i en SOA och vad ska tjänsterna göra?

Processer! Det är processerna som bestämmer. Finns det processer som kräver funktion och data, så ska det finnas som en tjänst. Finns det processer som kräver andra processer så ska de finnas som tjänst. Finns det flera processer som kräver samma funktion och data så ska det finnas tjänster. Det är processerna som avgör hur många och vilka tjänster som krävs.

Service Oriented Architecture skapas med Process-driven design (top-down el. outside-in).