Dag König

Generics och Webbtjänster

Ett annat svar på en fråga som jag har fått.

Jag har själv funderat lite kring SOA på sistone och har funderat på en domain-modell som används inom objekt orienterad arkitektur; generetics; som ska ge stöd för t.ex. primitiva datatyper.

Du funderar kring en service ska returnera null eller annat vid SearchUser, men vad händer om du inför ett generetic-web-service. Jag har själv inte kunnat finna användning för denna modell inom SOA, för mig så ter det sig som att det skulle bli för högt beroende av en generetic-service mellan i princip alla andra services.

Här kommer jag säkert att komma i blåsväder, men jag anser att man skall vara lite försiktig att oreflekterat överföra objektorienterade koncept på SOA. Vid första anblicken kan man tycka att SOA egentligen bara är objekt som innehåller ett antal metoder. Men det finns skillnader som är viktiga att ha i åtanke när man designar system utifrån SOA.

A Common problem of object-oriented programming is that the level of abstraction och granularity that is exposed to the clients of a component is too fine to enable efficient reuse, let alone distribution. Therefore object-orientation – while being great for large, usually relativity isolated and monolithic applications – proven to be a dead-end from the point of view of distributed computing. (Enterprise SOA – Service-Oriented Architecture Best Practices, 0–13–146575–9)

Personligen tycker jag att man med fördel använda objektorienterad programmering när man skriver en tjänst. Men jag vill påpeka att det är inte alls något krav. Man kan använda Cobol eller något annat språk lika bra.

Så tillbaka till din fråga. Jag tycker att generics snarare är ett koncept som hjälper oss att skapa en tjänst och skall inte användas vid gränssnittet, alltså som definition av kontraktet. Jag tror inte heller att det faktiskt går att beskriva generics med xsd, vilket är språket för att definiera kontraktet.

Det man eventuellt skulle kunna göra är att bygga in generics på det sättet att man först returnerar en array med information och sedan ett element som beskriver vad det är för typ av information. Det finns säkert lösningar till det.

Men jag lutar nog åt principen att man skall definiera kontrakten hårt. Det vill säga, att de endast går att använda på ett förutbestämt och begränsat antal sätt.

Mer om "Vad är ett fel?"

Jag fick en intressant kommentar på mitt inlägg “Vad är ett fel?” ifrån Morgan som jag gärna vill dela vidare.

Dag skrev: "Ett problem som lätt kan uppstå vid sådana här fel, alltså att S2 genererar ett exception som S1 tar emot, är att S1 vet inte hur mycket av metoden i S2 som kördes" Jag tycker att S1 bara ska behöva veta av S2 om det gick bra eller inte, om S1 måste fundera på hur mycket av sitt anrop som S2 körde så har man skapat ett beroende som inte är önskvärt i SOA (dvs att en service skall vara oberoende av andra services). Det måste vara S2's problem om den körde 30% eller 92% av S1's anrop, det kan inte bli S1's problem. S1 får avgöra om den ska försöka igen eller meddela sin anropare att den inte kan utföra sitt jobb OCH rulla tillbaka allt sitt arbete för det anropet, tex med kompenserande transaktioner/meddelande till andra services.

Jag håller med Morgan och vill tacka för inlägget. S1 skall endast veta om S2 gick bra eller ej. Det kan till och med vara skadligt ur ett säkerhetsperspektiv att S1 får veta för mycket om S2. (Precis det som jag skrev i den tidigare artikeln.)

Jag tror att jag uttryckte mig lite otydligt. Det jag ville säga var just att vi inte kan veta vart i S2 något kraschar. Det mesta kända är om det var före eller efter databassparningen, om man nu har någon sådan. Har man då inte gjort S2 idempotent så har S1 svårt att hantera detta. 

Men tyvärr måste vi ändå vara beredda på att det kan komma ett exception farande ifrån S2. Felet kan exempelvis uppstå i själva infrastrukturen på tjänsten. Det kan vara att S2 inte är startad, det kan vara att S1 inte har kontakt med nätverket eller dylikt.

Så Morgan, efter att funderat på ditt inlägg, så tror jag att vi faktiskt tänker likadant. Det här med kompenserade transaktioner är ett ämne som jag tycker är mycket viktigt. Det har jag tänkt ta upp snart i min blogg. Om tid finnes i överflöd… 

Ingen Visual Studio 2005 den 11 april?

För ett par veckor sedan var jag på en Microsoftkonferens här i Stockholm. Där sade de att nästa beta av Visual Studio 2005 skulle släppas den 11 april. Men det verkar fortfarande inte ha kommit någon. Jag kollade precis på MSDN. Jag kanske hörde fel eller så har något hänt.

Vad är ett fel?

Detta kanske, vid första anblicken, är en konstig fråga att ställa. Ett fel är väl alltid ett fel? Jag önskar att det vore så enkelt, men tyvärr blir det mer komplext när man tittar närmare på det. Jag har gjort detta utifrån ett SOA-perspektiv, alltså hur olika tjänster samverkar med varandra.

Tänk dig att vi har två tjänster, S1 och S2. S1 anropar S2 med metoden SearchCustomer. Den metoder returnerar inga eller flera kundobjekt utifrån en angiven söksträng.

Enkelt eller hur? Vad kan gå fel här och vad är definierat som ett fel? Är det ett fel om inga kunder hittas? Nej, det låter inte troligt. Det är snarare ett ganska normalt utfall. Man kan kalla det ett alternativflöde i förhållandet till huvudflödet, vilket är att man hittar en eller flera kunder. Men om man anger ett illegalt tecken i sin söksträng? Är detta ett fel? Kan vi normalt förvänta oss att detta kan ske eller skall vi överhuvudtaget inte ha några illegala tecken? Eller skall ett fel genereras om vi anger en tom söksträng? (Detta var bara några enkla exempel.)

Hur returnerar S2 de olika, ovan beskrivna, händelserna? Om S2 inte hittar några kunder, skall då ett helt tomt returmeddelande ifrån tjänsten skickas? Hur skiljer man på alternativflödens returmeddelanden och ett fels meddelande?

Jag tänker så här
Jag skapar en mall för alla returmeddelanden, vilket alltid innehåller någon form av returinformation. Det kan vara en enkel kod eller någon mer avancerad struktur. Den fyller jag alltid på med information innan jag skickar tillbaka meddelandet till det som anropade tjänsten. Det gör att jag i ovanstående exempel, skulle skicka tillbaka en returkod som talade om att inga kunder kunde hittas med den angivna söksträngen.

Om det är ett fel, alltså något som genererar en exception i den anropade tjänsten, alltså S2 i vårt exempel, kommer detta exception att skickas till S1 såsom SoapException, om vi inte hanterar det innan dess. Det blir alltså alltid ett SoapException, men man kan inuti detta exception avläsa vilket som var den ursprungliga exceptionklassen. (Observera att det är mycket viktigt att se till att ett fel aldrig returnerar information som kan utgöra en säkerhetsrisk. Var väldigt försiktig med att returnera något som exponerar insidan på en tjänst.)

Ett problem som lätt kan uppstå vid sådana här fel, alltså att S2 genererar ett exception som S1 tar emot, är att S1 vet inte hur mycket av metoden i S2 som kördes. Nu är det inget större problem i vårt exempel eftersom metoden endast söker i befintlig data, men tänk om metoden istället hade uppdaterat data. S1 kan inte alltid veta om datat som den skickade till S2 verkligen har blivit bearbetat. Vad skall S1 göra då? Det mest naturliga är att S1 ber S2 att köra metoden igen med samma data. Men tänk då om S2 redan hade behandlat detta data. Vad händer då när samma data skickas igen? För att lösa det här problemet brukar man skapa metoder där det inte gör någonting att man kör samma metod med samma data flera gånger. Det brukar kallas att man gör metoderna "Idempotent". (Hur man gör detta är en artikel i sig själv.)

 

Versionshantering av meddelanden i en webbtjänst

Versionshantering, det vill säga, vad händer när ett publikt gränssnitt ändras i en tjänst, är en fråga som jag har stött på ett flertal gånger. I det här inlägget tänkte jag diskutera och visa på vissa aspekter av denna hantering.

INLEDNING
Egenligen skall det inte, i de bästa av världar, ändras ett publikt gränssnitt. Det skall vara låst när det väl är publiserat och kunder (speciellt om de är utanför vår kontroll) har börjat använda dem. Men hur lätt är detta att uppnå?

För att diskutera vad som händer när man ändå gör förändringar i ett gränssnitt, så har jag skapat ett litet exempel. Det är en webbtjänst som innehåller en metod, AddNewCustomer, vilken har en parameter in och en parameter ut. (Alltså enligt den dokumentcentrerade principen när man bygger webbtjänster.) Både metoden och parametrarna, eller meddelandena, är beskrivna med hjälp av Wsdl och Xsd. Första versionen av meddelandena ser ut på följande sätt:

<xs:element name="AddNewCustomerRequest">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="Name" type="xs:string" />
    </xs:sequence>
  </xs:complexType>
</xs:element>
<xs:element name="AddNewCustomerResponse">
  <xs:complexType>
    <xs:sequence>
       <xs:element name="ReturnCode" type="xs:int" />
    </xs:sequence>
  </xs:complexType>
</xs:element>

Meddelandena är väldigt enkla. Inmeddelandet består endast av ett element, Name, och utmeddelandet består också av en parameter, ReturnCode.
Följande .net-kod använts för att ifrån en klient anropa webbtjänstens metod:

VersioningService.AddNewCustomerRequest _request = new
   VersioningTestClient.VersioningService.AddNewCustomerRequest()
   
_request.Name = "Kalle Anka";
   
VersioningService.Customer _service = new
   VersioningTestClient.VersioningService.Customer();

VersioningService.AddNewCustomerResponse _response;
   
_response = _service.AddNewCustomer(_request);

TESTER
1. Vad händer om vi lägger till ett element i inmeddelandet?
När vi har gjort detta så händer igenting på klienten. Den slutar alltså inte att fungera. Även om vi skulle uppdatera klientens wsdl-information för webbtjänsten, så händer ingenting. Grunden för detta är att det som skickas över är beskrivet som xml, vilket innebär att det inte är några problem att lägga till nya element till meddelandet. Vi kommer att få problem om vi ändrar namn på ett element, alltså i mitt fall Name till Namn, eller om vi tar bort element ifrån meddelandet.
Denna slutsats känns vid första anblicken rätt bra ut och i många fall räcker detta. Men det finns ändå vissa bitar som inte känns lika bra. Det blir inte lika strukturerat och kontrakten blir lite "informella". Om inmeddelandet ändras, så vet inte klienten längre vilka delar som är obligatoriska respektive valfria. Klienten blir mer osäker också på vilken version av webbtjänsten som den använder.

2. Sätt att motverka detta
För att lösa detta så kan jag se tre olika sätt:
a) Använd ändå mer generella meddelanden in och ut. Ett sätt är att skicka ren xml fram och tillbaka och sedan tolka det själv.
b) Skapa ny metod istället för att ändra parametrar i en metod. Exempelvis kan man skapa en ytterligare metod som heter AddNewCustomer11(), för version 1.1. c) Använd möjligheter i xsd som beskriver inparametern på ett sätt som gör det möjligt att ha flera versioner i samma definition. Detta kan se ut på följande sätt: 
<xs:element name="AddNewCustomerRequest">
  <xs:complexType>
    <xs:sequence>
      <xs:choice>
        <xs:element name="Version10">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="Name" type="xs:string" />
            </xs:sequence>
           </xs:complexType>
         </xs:element>
         <xs:element name="Version11">
           <xs:complexType>
             <xs:sequence>
               <xs:element name="Name" type="xs:string" />
               <xs:element name="Address" type="xs:string" />
             </xs:sequence>
           </xs:complexType>
         </xs:element>
       </xs:choice>
     </xs:sequence>
  </xs:complexType>
</xs:element>

Som vi ser här så beskrivs i samma meddelande att man antingen skall skicka in en parameter med namnet Name eller två parametrar med namnen Name och Address. Denna möjlighet kan beskrivas med xsd element choice. Det blir lite mer avancerad kod på klientsidan för att hantera ett sådant här meddelande.

Vilket skulle jag välja?
En svår fråga och som så mycket annat spelar många fler faktorer in än de som vi har beskrivit ovan. Det bästa vore naturligtvis att kontrakten hölls heliga, det vill säga att de inte ändrades. Jag känner tveksam till att skicka xml-dokument fram och tillbaka.

Jag håller frågan öppen just nu. (Var det detta som du ville höra?)

Punktmarkera punktlistan i Powerpoint

De absolut flesta bilderna i en powerpointpresentation är av typen punktlista, alltså en bild enbart fylld med text, fördelad som ett antal punkter. Jag tror att detta också är den mest missbrukade funktionen i powerpoint. Det är den funktionen som har gett powerpoint ett dåligt rykte. Varför? Jo, det är väldigt enkelt att skapa sådana bilder och tyvärr skapas de oftast som ett talarmanus, med mycket text. En sådan här bild är tyvärr inte ovanligt att se.

Här är några tips på vad man skall tänka när man skapar punktlistor.

1. Rubriken skall inte innehålla några radbrytningar.

2. Varje punkt skall bestå av två till fem ord och de skall inte heller innehålla några radbrytningar.

3. Försök att inte ha fler än fyra till sex punkter på en sida. Måste man ha fler, så använd animeringar för att ta fram dem, en i taget.

4. Försök att göra punkterna symmetriska. Med det menar jag att varje rad skall vara ungefär lika långa.

 

Denna punktlista är bättre. Observera att vissa hävdar att man också skall försöka att undvika underpunkter om det går. Andra anser att man inte skall ha någon symbol framför underpunkterna och har man det, skall det inte vara ett minustecken. Ett sådant tecken skapar en negativ association.

Andra viktiga tips

Det är viktigt med grammatiken när man skapar punkterna. Det skall inte vara olika tempus, aktiv/passiv ordföljd och andra saker som försvårar för publiken att läsa och förstå punkterna. Titta först på följande bild:

Jämför med denna bild:

Vill du fördjupa dig mer i det här ämnet, så rekommenderar jag boken Presentation to Win.

Att få Powerpoint att jobba för dig istället för emot dig

Powerpoint, det älskade och hatade programmet, kan användas på många olika sätt. Tyvärr finns det fler dåliga powerpointpresentationer än bra sådana. Det behövs faktiskt inte så mycket för att ppt-presentationen skall motverka det egentliga syftet, att hjälpa dig att framföra ett budskap. Vad menar jag med det? Här kommer några tankar som jag har:

Presentatören är viktigare än presentationen

Detta låter kanske självklart när vi säger det, men är det verkligen så? Många presentatörer verkar lita på att en god powerpointpresentation skall göra att själva presentationen blir bra. De tror att själva powerpointfilen är presentationen och att de själva är någon form av bifigur till den. En sådan presentation är dömd att misslyckas. Det är du som gör presentationen, som presentatör. Powerpoint är bara ett hjälpmedel för att du bättre skall kunna framföra dina åsikter. Din presentation skall klara sig utan en powerpointpresentation, men ej utan dig som presentatör.

Vad händer när en ny slide i en powerpointpresentation visas?

Har ni någonsin tittat på er publik när ni visar en ny slide? Om det är mycket text, i from av punkter, eller avancerad grafik eller dylikt, så kommer ögonen på publiken att rulla fram och tillbaka för att få in allt. Under den tiden är det inte många som lyssnar. Därför kan vi inte då, som presentatörer, prata. Det skulle bara störa publiken i sitt inläsande av slidens information. Detta måste vi vara medvetna om. Det är bland annat av den anledningen som vi inte skall ha slides med mycket text eller avancerad grafik. Måste vi ha det, så behöver vi anpassa vårt prat, så att publiken kan hänga med. Om vi inte gör detta så kommer powerpointpresentation oftast att vinna över dig och det du vill säga.

En powerpointpresentation är ämnad för publiken inte för dig

Det finns många av oss som gör powerpointpresentationer som blir talarmanus. Den staplar upp punkter som vi som presentatörer inte får glömma. Det blir mer en hjälp för oss än för publiken. Vissa ppt-presentationer har så bra talarmanus att det är bättre att publiken läser det, än lyssnar på talaren. Ditt manus måste du hantera på något annat sätt. Presentationen skall vara till för att sammanfatta och förmedla ditt budskap.