Alla verkar ju vilja ligga i framkant och använda WebServices idag, men:

NÄR! ska/bör man använda WebServices?

Det är den stora frågan ;)

cya,
/PatrikB

Svaret är enkelt. Där du behöver ge ut din data till andra system eller ta data från andra system än de innom ditt egna nät. :-)

Mvh Johan

Med andra ord så blir den enklar regeln:

WebServices bör inte användas inom sitt egna nät. Endast när man behöver dela/ta data från andra system utanför sitt egna nät.

cya,
/PatrikB

Typ. Sedan finns de de som har det innom sitt egna när oxå. Finnt ju undantag. Du kanske måste kommunicera med två olika servrar byhta data mellan dem då kan webservices vara bra. Men även vanlig remoting går utmärkt (som dessutom är snabbare.)

Mvh Johan

Är inte BizTalken bättre för det endamålet? Att "skyffla data" mellan olika interna servrar/applikationer?

Jo, men ändå ser man väldigt många företag som bygger WebServices internt (där Remoting säker skulle vara bättre) och det var därför som jag ställde min fråga.

cya,
/PatrikB

Allt handlar om krav och syften. Många är trendbögar och måste ständigt ha det tuffaste. De låter tekniken styra arkitekturen istället för tvärt om. Ett misstag många gör och ständigt verkar villja göra om.

BizTalken är bra då du vill tranformera data förändra den till nått annat format. Samt få hjälp med att öppna upp transportkanaler eller vad vi skall kalla det.
WebService är bra då du vill kommuncera med samma format med system utanför din server typ.
Remoting är bra då du vill kommunicera med andra .Net maskiner över nätverk i rasande fart.

Så länge du befinner dig på en och samma Maskin där du inte måste kommunicera med andra finns det ingen anledning att nyttja WebServices. Vill du komma åt data från en annan maskin i ditt nät och bara den maskinen har tillgång till en databas då kan du öppna upp en webservice där som ger dig datan eller köra remoting. Vill du ge andra system utanför ditt nät data är WebService bra då du kan kommunicera med andra platformar.

Det kan även vara så att du bygger två olika apps och vill prata mellan dem på ett snyggt sätt då kan du köra lite SOA (Service orienterad arkitektur)
Säg att du har två databaser och två olika applikationer. Du vill nu från Applikation A plocka data från applikation B. Du kan från A gå direkt in i databasen hos B om du vill. Men kan då råka ut för vissa problem. Säg att B måste byggas om, du ändrar databasen och måste då även ändra As anrop mot den. Om du istället väljer att kommunicera med WebServices mellan A och B kan du göra justeringar i Bs databas utan problem och sedan ev göra en justerign i den Webservice A har öppen för dig på så vis behöver du inte justera A något eftersom du ser till att Bs WebService som du nyttjade skickar rätt data.

Det finns lixom allit undantag. Ta och skissa ner vad du vill göra vad systemen har för krav så kommer du snart få svar på om du behöver Webservice internt eller ej. Många nyttjar dem som sagt för sakens skull för att det anses som en kul teknik helt i onödan.

mvh Johan

Kommentarer:

Jag skulle gott kunna tänka mig att använda webservices innanför brandväggen, det skulle underlätta för min applikation att bara ha ett gränssnitt som andra applikationer och klienter använder för att kommunicera med, istället för att ha ett gränssnitt internt och ett externt. Prestandan är jag inte heller speciellt rädd för eftersom fler och fler tenderar att ha höghastighetsnätverk innanför brandväggen och om jag istället fokuserar på att utveckla mina tjänster som "chunky" och inte "chatty" så är det inget problem.

Men BizTalk kan däremot hjälpa dig att antingen konsumera eller exponera webservices från andra applikationer och samtidigt grafiskt administrerar och exekvera dina affärsprocesser.

Kort sagt, det här är en vanlig fråga och jag tror att det inte finns något enkelt svar, det är lite beroende på krav och behov.

Mvh

Johan Lindfors
Microsoft