Jag pratade om en kommande CTP kring BPEL i en post tidigare och nu är den här.
Detta är ett tillägg till .NET 3.0's workflowstöd och går att ladda hem här.
2007-03-19
Prenumerera på:
Kommentarer till inlägget (Atom)
skip to main |
skip to sidebar
En blogg på svenska om Windows Workflow Foundation
Om mig
- Daniel
- Arbetar som konsult på Connecta AB daniel.karlsson(a)connecta.se Vi letar efter nya kollegor, se connecta.se för mer information eller kontakta mig direkt.
Taggar
- .NET 4.0 (25)
- AppFabric (5)
- Azure (5)
- BizTalk (4)
- BPEL (8)
- Dublin (8)
- FormServices (2)
- IDE (2)
- Imaging (1)
- MOSS (18)
- OASIS (4)
- Orcas (13)
- OSLO (6)
- Pageflow (3)
- Patterns (5)
- PDC 2008 (7)
- Rules (4)
- SDK (35)
- Sharepoint (24)
- Silverlight (1)
- SPAspTaskForm (4)
- SPC09 (1)
- SQL (2)
- TechDays2009 (1)
- Visio (3)
- WCF (10)
- XAML (7)
Länkar
Övrigt
Kommentera gärna nyheterna och våga ställa frågor direkt till mig.
6 kommentarer:
Synd bara att det bygger på BPEL 1.1 och inte WS-BPEL 2.0 som resten av industrin redan har lanserat stöd för i sina produkter.
Jag har inte läst din blog tidigare så jag vet inte vad du anser om det, men tror du BPEL kommer bli viktigt för WF-utvecklare?
Jag tror att BPEL är viktigt för beslutsfattare/managementkonsulter och övriga vilka är de som ställer krav vid systemutveckling.
Detta leder pga detta till krav på att utvecklarna kan tillhandahålla lösningar där det enkelt går att realisera befintliga processer som finns beskrivna i BPEL. Gissar att detta är en selling-point när man jämför med befintliga WF-system där BPEL stöds sedan länge.
Om utvecklaren själv får välja gissar jag att det inte blir BPEL som gäller ;)
Som jag skrev i mitt förra inlägg så kommer OASIS 2.0 standarden för BPEL att vara den som gäller för den slutgiltiga releasen.
Vad skulle du säga avgör varför utvecklaren inte väljer BPEL för implementation av processer/workflows?
BPEL ger inte samma rika programmeringsmöjligheter som WF. Själv är jag galet imponerad av alla möjligheter med dependencypropertys, custom actions osv som vi har tillgång till.
Sedan är det även en fråga om hur man skall kontrollera flödet när man har sk. human workflow, dvs med uppgifter som skall utföras av människor.
Men skillnaden mellan programmeringsmöjligheterna i BPEL och WF beror väl mer på hur man kapslar in sin kod. Med BPEL som jag förstår kapslar man in all custom kod (med vissa undantag av XPath-uttryck) i web services som sedan orchestreras med BPEL. På så vis blir det en tydligare skillnad mellan vad som är aktiviteter och vad som är processflöde. I WF kan man skriva kod som en del av exekveringen och då får man "vanliga" beroenden mellan .NET assemblies. Den stora skillnaden blir ju då att BPEL är mer disiplinär med avseende på att använda sig av web services, medan man i WF tar till det vid behov. Så egentligen handlar det mer om var man lägger sin kod än programmeringsmöjligheterna.
Disiplinen som BPEL stödjer kan ju även vara av viss fördel när det kommer till aspekter av SOA. Om alla aktiviteter implementeras som services drar du en direkt fördel av att redan från början ha en SOA och inte behöva riva upp beroenden till .NET assemblies där det saknas SOA stöd.
När det kommer till human-centric workflows så finns det väl stöd i vissa språk-extensions (BPEL4People). Sedan är det väl så att exekveringsspråket BPEL kan abstraheras av exempelvis BPMN där det finns tydligare stöd för human workflow.
Du har många bra poänger men mkt hänger på hur stort stöd vi får i den slutgiltiga versionen vid slutet av året.
BPEL 2.0 / SOA blir otroligt intressant, skall försöka göra någon PoC tillsammans med MOSS för att se om det kan leda till något.
Själv har jag inte hunnit leka med denna release ännu och det måste fixas snarast =]
Skicka en kommentar