Windows Communication Foundation (WCF) kommer att vara den mest utbyggbara implementationen av en Web Service stack som sätt ljuset när den till slut släpps med .NET Framework 3.0. Med WCF är det möjligt att förändra hela sekvensen som ett meddelande går igenom, från början av en endpoint ned till implementationen.
Men bara för att det är möjligt så betyder det inte att man ska använda sig av den möjligheten. Har det varit något du intresserat dig av tidigare när du exempelvis programmerade COM-objekt? Det var inte ofta man behövde implementera custom marshalling för att på så vis kunna styra över serialisering, encoding, routing, säkerhet i DCOM. Lita på mej, det är inte något som bör intressera dig (som tjänsteutvecklare) nu heller, även om det är lika enkelt som att andas luft (jämfört med DCOM).
Vad som däremot är intressant när man har ett antal tjänster är att skapa en SOA som bygger på att man kan administrera sina tjänster på en högre nivå och då kommer fördelarna med WCF in i bilden. I en SOA är det viktigt att kunna skapa nya versioner (förändra address, binding, etc) av tjänster. Man vill även kunna skapa virtuella kontrakt som passar en grupp av konsumenter. Routing, för att kunna distribuera anropen baserat på policies eller andra villkor. Transformering, att kunna modifiera meddelandet på vägen genom WS-stacken. Det är mängder av olika anledningar (och jag ska återkomma till fler framöver) till att kunna hantera sina tjänster och det är det som är anledningen till att WCF är så flexibelt.
Motsatsen till en SOA är att ha lite tjänster här och lite tjänster där, vilket tillslut blir ohanterligt. Det betyder heller inte att man ska bygga administrativa verktyg genom möjligheterna med flexibiliteten i bl a WCF. Det finns sådana produkter och det är dessa man ska använda sig av. Amberpoint är en leverantör av administrativa produkter för en SOA som även kan skapa hooks till andra implementationer än WCF. På så sätt får man en central dashboard av funktioner för att administrera sina tjänster oavsett plattform. Tillskillnad från Amberpoint så finns det produkter (BizTalk, Enterprise Service Bus) som kräver att alla tjänster ska implementeras i verktyget för att kunna administrera dom, vilket inte är troligt att man önskar i en heterogen värld.
Så tipset är att bygga tjänster som är hanterbara och där kontrollen ligger i verktyg som administrerar dina tjänster och inte i genom hemmasnickrade hooks till WCF.
2 kommentarer:
"Tillskillnad från Amberpoint så finns det produkter (BizTalk, Enterprise Service Bus) som kräver att alla tjänster ska implementeras i verktyget för att kunna administrera dom, vilket inte är troligt att man önskar i en heterogen värld."
Nja.
För det första är ju inte Enterprise Service Bus en produkt, utan ett (hyfsat luddigt) begrepp som myntats av Sonic. Det kan enklast sägas var ett antal egenskaper hos en meddelande-orienterad middleware (MOM - Message-Oriented Middleware) - som avgör om denna ska kategoriseras som en "ESB". Bland dessa brukar följande nämnas:
funktionalitet för att agera som meddelandebroker, smart routing baserad på innehåll i meddelanden,
stöd för WS, metadata för endpoints.
Vissa leverantörer hakar även på meddelande-transformation, validering och loggning.
Kan BizTalk vara en ESB?
Absolut - kolla in den här: http://geekswithblogs.net/bloesgen/archive/2006/01/20/66509.aspx
Det krävs inte heller att man "administrerar" sina tjänster i BizTalk för att kunna dra nytta av plattformens processhantering, business rule engine, BAM mm. Man kan mycket väl tänka sig BizTalk som en central del i sin SOA, men med tjänsterna helt autonoma. De måste naturligtvis kunna anropa BizTalk för att leverera meddelanden, men eftersom man naturligt arbetar med en Contract-first approach i BizTalk kan du få en verkligt lös koppling, där orchesteringarna endast är intresserade av att meddelanden av en viss typ levereras till BizTalk MessageBox, men inte behöver bekymra sig hur dessa kom dit.
mvh Robert Folkesson
Hej Robert!
Vad jag försöker peka på är den del av BizTalk, eller vilken ESB (läs WS:fierat EAI-verktyg) som helst, där man hanterar service management. I en ESB är service management en central del men det bygger på ett centraliserat synsätt på implementationen av en service bus. Men WCF kan renodlade service management produkter bygga centrala management i distribuerade miljöer kontra BizTalk och ESBer där man får centralt management i en centraliserad implementation. Samma nackdelar som med EJB där man låser in sig mot en enda leverantör för sin SOA. Inte den framtid jag tror på för SOA.
Skicka en kommentar