lördag, januari 14, 2006

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.

torsdag, januari 05, 2006

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.

tisdag, januari 03, 2006

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.