Dag König

Microsofts initiativ Software Factories får en egen webbplats

Flera av er har säkert hört talas om "Software Factories", alltså ett sätt, inkluderande olika metoder, för att bättre strukturera sin utveckling av mjukvara. Lämpar sig bäst när man skall utveckla flera liknande mjukvaror. Boken är intressant, men tyvärr har jag inte läst igenom den fullständigt än. Det som jag har fastnat för och som jag funderar mycket på är de "domain specific languages", DSL, som Microsoft just nu håller på att fila på.

Nu har, för att hålla grytan kokande, en gemensam webbplats för Software Factories skapats. Det kan vara intressant att slänga ett getöga på den. Vi är bara i början på Software Factories. Om Microsoft verkligen lägger resurser bakom satsningen så kommer det säkert att bli många aktiviteter omkring detta i framtiden.

Jag själv sitter i en situation där jag inte tycker att jag har funnit ett modelleringsspråk som hjälper mig att beskriva en tjänstebaserad arkitektur. Jag duttar runt med olika varianter, men fastnar aldrig riktigt för något. Se gärna mitt inlägg om Microsoft Application Designer för ett exempel. Vi får se vart det slutar…

Tjänstebaserad arkitektur för en hel organisation

Det är rätt lätt att förstå hur man skall bygga en tjänst, både dess kontrakt, med hjälp av Xsd, och dess insida, alltså implementeringen av denna. Men det blir direkt mycket svårare när man har fler tjänster som skall samverka inom en organisation. Frågor som bland annat brukar infinna sig är:

1. Hur stor skall tjänsten vara. Hur mycket skall den innehålla och ha ansvaret för?
2. Finns det olika typer av tjänster och hur hänger de i sådana fall ihop?
3. Hur återanvänder man tjänster?
4. Osv..

Sammanfattningsvis kan man säga att det är först nu som den svåra biten kommer när det gäller att implementera SOA i en organisation. Vissa skulle till och med säga att det först är när vi gör detta som vi verkligen har en tjänstebaserad arkitektur.

Boken Enterprise SOA – Service-Oriented Architecture Best Practices har ett mycket intressant förslag på hur man delar upp tjänster i olika tjänstetyper, där de olika typerna har olika karaktäristiska. Dessa typer är en bra hjälp när man börjar skissa upp en  tjänstebaserad arkitektur i en organisation.

Först vill jag kortfattat beskriva detta förslag som en matris och sedan diskutera en implementation utifrån detta. Köp gärna boken om ni vill ha en djupare presentation av matrisen.

Tjänstetyperna

(Klicka på bilden för att se en större variant.)

Det finns fyra typer av tjänster. Dessa är:

• Basic Service
• Intermediary Service
• Process-Centric Service
• Public Enterprise Service

Basic Service är den grundläggande typen av tjänst. Det är faktiskt den enda typen av tjänster som måste finnas i SOA för att vara en sådan arkitektur. Dessa tjänster är de grundläggande byggstenarna i arkitekturen. De är de lättaste att återanvända. De brukar ofta vara ett verksamhetsobjekt såsom Order, Produkt eller något liknande.

Intermediary Service är en tjänstetyp som på ett eller annat sätt förmedlar information eller funktionalitet. Det kan vara gateways mellan olika implementeringstekniker, adapters emot äldre system som organisationen redan har. Facade är en servicetyp som som aggregerar underliggande tjänster med ett gemensamt gränssnitt. (Det finns en annan arkitekturbild av SOA som Microsoft ofta förmdelar, där det finns tre nivåer, Process service -> Activity service -> Entity service. Vår facadetyp är ungefär samma sak som en activity service i det diagrammet.)

Process-Centric Service är den mest avancerade tjänstetypen. Den typen har ansvar för processer och just därför är denna typ den enda tjänsten som kan hålla state. Detta för att bland annat klara av "longrunning transactions".

Public Enterprise Service är en tjänstetyp som exponerer tjänster till andra utanför organisationen.

Exemplet

Det här exemplet utgår ifrån en påhittad Internetbokhandel med namnet Lexia. De har flera distributörer av sina produkter, i dagsläget tre, och de använder sig också av ett externt fraktbolag för att leverera produkter till kunderna. Lexia har tre gränssnitt emot kunder, anställda och partners: En webbapplikation som är själva internetbokhandeln, en windowsapplikation som används av anställda och en webbtjänst som partners använder sig av för att kommunicierar med företaget. Lexia har också ett gammalt CRM-system som skall integreras i den nya lösningen.

(Klicka på bilden för en större variant)

Innan jag beskriver de olika tjänstetyperna vill jag uppmärksamma er på att jag har lagt till två lager till: Legacy Layer och External Layer. Jag tycker också att det är bra att se sådana beroenden i diagrammet.

Basic Services
Lexias Basic Services är CustomerService, ShoppingCart, OrderService och ProductService. Alla dessa tre är datacentrerade tjänster. Deras största ansvar är att lagra informationen.

Intermediary Services
CustomerMergerService är en Functional-Adding Service emot det gamla CRM-Systemet. Den har till uppgift att dels vara en gränsnitt mellan det gamla systemet och företagets nya arkitektur. En annan viktigt uppgift som den också har är att den utökar funktionaliteten hos CRM-Systemet. Det är nämligen så att viss funktionalitet och information som behövs för att hantera kunderna i webbapplikationen saknas i det gamla systemet. Av det skälet har en ny CustomerService skapats och CustomerMergerService kopplar ihop dessa båda med ett gemensamt gränssnitt. I framtiden kommer det gamla CRM-systemet avvecklas och ersättas fullt ut av CustomerService.

De tre tjänsterna BiblioAdapterService, BrontusAdapterService och CDtoGOAdapterService interna representationer för de externa tjänsterna som dessa tre distributörer har. Det är dessa tjänster som har till ansvar att synkronisera och hantera produktkatalogerna ifrån respektive distributör. Dessa tjänster tar också hand om beställningar emot distributörerna. Man skulle kunna bygga in dem i ProductService, men för att göra det enklare att föra in nya distributörer så byggs de upp som egna tjänster istället.

OrderHandlingService är en Facade Service som sammanfogar de Basic Services som behövs för att hantera en order. Till exempel finns den en metod i den här tjänsten som heter MakeOrder. Den anropar ett flertal andra tjänster CreditCardService, ShoppingCartService, OrderService och ProductService för att kunna utföra den aktiviteten.

Process-Centric Services
Lexia har en processervice för att hantera ordrar. Den här tjänsten håller state genom att ha en databas där all information om en order sparas. (Den här servicen kan också implementeras som en BizTalk-process.)

Public Enterprise Services
LexiaExternalService ger partner möjlighet att kommunicera med Lexia på det här sättet. Exempelvis så är det via den här tjänsten som som distributörer meddelar att det finns nya produktkataloger att hämta.

Sammanfattning
Detta är en mycket kortfattad beskrivning av den här arkitekturen. Jag kommer i framtida inlägg diskutera problem och lösningar som inträffar när man skall implementera denna. Det finns nämligen mycket att diskutera och fundera över.

Ett tiotal av mina kollegor på Know IT skall åka bort ett par dagar i slutet av maj för att implementera hela den här arkitekturen. Vi kommer att implementera den i olika versioner av Visual Studio, vissa delar i Java, och vissa delar i Mono. Det skall bli mycket spännande. Jag hoppas kunna återkomma med nya erfarenhter utifrån det projektet.

Vi gjorde en liknande workshop förra året, där vi också lärde oss mycket, speciellt om att jobba med "Contract First". Jag har skrivit om det i tidigare inlägg. Kolla under kategorin Rumba.

Mer information om Office 12

Cnet har en ny artikel om Office 12. Dt är en intervju med Jeff Raikes som är Micosoft Group Vice President. Det finns några intressanta "snippets" som jag vill dela med mig.

The company is also talking about some broad areas that it sees as ripe for improvement, including enhanced collaboration.

Jag tror just att möjligheten att kommunicera och på olika sätt samarbeta med varandra kommer att vara en av huvuddelarna i den här versionen av Office. Jag tycker fortfarande att exempelvis Outlook är ett program som kan utvecklas mycket.

Jag hörde en intressant podcast för en tid sedan där de beskriv möjligheterna att använda outlook bättre genom att skriva applikationer som kördes inuti outlook och som hakade på processer som exempelvis kom ifrån mailsystemet. Outlook blir tydligare en koppling emot de de processer som ett företag har och kan användas för att göra de manuella stegen som behöver utföras i en sådan process. Låter lite luddigt, men låt mig få ge ett exempel på vad jag menar:
Säg att vi har en orderprocess som består flera steg, några automatiska och några manuella. När ett manuellt steg krävs, något som skall utföras av en människa, skickas det steget via outlook till personen. Han får, det inte som ett mail, utan han får upp en applikation som hjälper honom att uföra steget och också rapportera tillbaka till processen. Det kan exempelvis vara killen på lagret som skall plocka ihop ordern. När han har gjort det rapporterar han tillbaka till processen och den fortsätter med nästa steg.

Jag är verkligen sugen på att göra en sådan applikation och få ihop system som via meddelanden och olika användargränssnitt, på ett enkelt sätt kan utföra processer i ett företag.

Some things, like e-mail, have improved, but nonetheless raised new challenges. Raikes noted studies that show that the average worker gets about 10 times as much e-mail now as in 1997. That's projected to increase another fivefold in the next four years, Raikes said.

Inte speciellt svårt att förstå, eller hur? Men om vi tänker efter, så ser egentligen alla mailprogram likadana ut nu som 1997. Visst det har kommit lite sökfunktioner i olika former och filter av olika slag, men inte mer.

Meanwhile, in PowerPoint, Microsoft said it is working to automate more of the graphics features from within the presentation program so workers can create documents that look good without much design effort. The company is also planning to expand its use of XML as a means of sharing data with other programs.

Powerpoint, en favorit, har alltid hamnat lite på efterkälken när det gäller ny funktionalitet, i alla fall i själva kärnan av programmet, alltså det som använts i 95% av fallen. (Jag menar att det utvecklas PowerPoint Producer och liknande system, men hur många av oss använder verkligen dessa? Tyvärr tycker jag, de är spännande grejor.) Jag tycker att Microsoft verkligen skall sätta några riktiga "tänkare" som kan titta över programmet. Det skulle behöva transformeras till en ny nivå, ifrån att vara ett presentationshjälpmedel till något mer och kanske annat. En teori kan vara att precis som IE och sin renderingsmotor Trident, så har Powerpoints renderingsmotor blivir för gammal och komplex för att utveckla vidare. De behöver kanske en ny. Här är det kanske som bland annat flashkillern "Sparkle", som är så mystisk, kan användas?
 
In addition to sharing only the broad strokes of what features will be added to the Office suite itself, Microsoft is also not ready to discuss any new companion products that will be coming with the Office 12 wave of software. In the last go-round, Microsoft added its InfoPath electronic forms program as well as OneNote, a note-taking application.

Både OneNote och InfoPath är intressanta produkter. Och det skall med spänning bli intressant och se vad som kommer att hända med dem i framtiden. Jag hoppas verkligen att de kommer att utvecklas till nästa version av Office. Själv använder jag OneNote relativt ofta och InfoPath har vi kunder som kör med. (Det här inlägget är skrivet med hjälp av OneNote.)

Ett älsklingsämne för mig är författarverktyg, speciellt i kombination med xml. Office, och speciellt Word, är på väg i helt rätt rikning. I kombination med Visual Studio Tools for Office har man ett kraftigt hjälpmedel för att skapa avancerade författarverktyg. Men det finns fortfarande en bit att gå. Jag ser med spänning på vad de kommer att göra där.

Dvorak prisar Sverige

John C. Dvorak är en riktig höjdareditor på tidning PC Magazine. I den senaste numret av tidningen, vilket jag prenumererar på genom www.zinio.com, berättar han att han har varit i Sverige och blivit mycket imponerad av oss. Som lokalpatriot kan jag inte låta bli att vidarbefodra detta till er.

Det känns lite som 1999 när Stockholm blev utropat till världens IT-huvudstad. (Ja, i alla fall lite.)

A visit to Sweden Dept.: At the behest of the Invest in Sweden Agency, I was invited to the high-tech centers of Stockholm and Gothenburg to chat with the dozens of
emerging technology companies. There was no particular agenda. I was impressed with what I saw:
Although its population is a mere 9 million people, Sweden nonetheless has two world-class car companies (Volvo and Saab) and two massive truckmanufacturing companies (Volvo Trucks and Scania) and is one of the few countries that make a state-of-the-art jet fighter and other aircraft (Saab). It’s also home to major players in telecommunications infrastructure (Ericsson) and cellphone technology (Sony Ericsson).

Compare this with the state of Georgia (Lockheed Martin and peanut farming), which has a similar population, or Texas (Dell, Motorola, Texas Instruments, and beef ribs), with 23 million people. I think the biggest difference is that they eat better in Georgia and Texas. The best meal I had in Sweden was in the dining room at Ericsson’s corporate headquarters.

A few trends jumped out at me. Scandinavia isdeeply into various open-source projects and has produced lots of freeware. For example, the superb MySQL database manager comes from Sweden. Another trend is that these folks are so into mobilephone optimization that they are essentially too far ahead of the adoption curve. This means they are constantly creating products that are great ideas but have no infrastructure to support them.

The hottest thing from Sweden, which has become something of a worldwide phenomenon, is the VoIP system Skype. Skype has had over 100 million downloads. Everyone in Sweden uses it, and often during demos I would see a Skype message appear on the screen. Skype is the latest and most modern implementation of computer-to-computer VoIP telephony and has just recently added a POTS gateway channel, so you can use the system to call real phone numbers around the world for about a cent a minute. You simply
open a SkypeOut account and prepay for a number of minutes like a long-distance calling card, and you can start making calls.

You may as well join this network too, since it has already gone far past critical mass. Go to www.skype.com to add yourself to the download total. This product comes from the people who developed Kazaa, only it has no spyware!

Att alla i Sverige använder Skype var något nytt för mig. Jag har det inte. Usch vad jag skäms.

NorDev - Dag 1

Idag var det faktiskt första gången som jag fick försvara domändriven utveckling och Domain Modell (förlåt att jag använder ett patternnamn. Mer om det senare.) En talare gjorde nämligen en dålig poäng på den typen av mappning och sade att det aldrig skall används. Jag tyckte inte att han var lite väl föraktfull emot denna typ av att hantera information. Och jag, TDO-snubben, fick stå upp för detta.
Jag pratade med honom lite efteråt. Och det jag kom fram till var att han inte gillade att använda den här tekniken för att integrera mellan heterogena system. Och det kan jag förstå. Jag skulle heller inte rekommendera det i sådana situationer. Men jag kan tänka mig att använda Domain Modell inuti en applikation, eller tjänst (som jag hellre vill kalla det.)
 
En annan sak som framfördes på förmiddagen var att pattern helt plötsligt har blivit en slagpåse. Det blev konstiga motsatsförhållanden.
 
Pattern i motsats till Kommunikation
Pattern i motsats till Pragmatisk
 
Jag hoppas att jag missförstod det hela. Det var en rätt stor skillnad emot gårdagens Architectual Day, där man använda patterns som ett sätt att återanvända kunskap och erfarenheter.
En annan åsikt som framfördes var att patterns beskriver lösningar på en låg nivå och kan därför inte kunna användas när man som arkitekt ser på en lösning på en högre nivå. Men min förståelse är verkligen att det finns patterns på många olika nivåer. (Jag vet dock inte om det finns patterns för vissa specifika applikationstyper, såsom finansapplikation eller dylikt. Jag tror det nämligen var på den nivån som talaren tyckte att det saknade patterns.)

Överlag var presentationerna mycket bra. Jag ser fram emot morgondagen.

 

Se till att debugging är avstängd i Web.Config vid produktionssättning

Det finns tyvärr en missuppfattning att om man stänger av debuggingen i ASP.NET genom att sätt kompileringenläget i Visual Studio till Release. Men det räcker inte. Man måste också manuellt ändra i filen web.config för att debuggingen skall vara avstängd helt och hållet.

Det är följande element som man själv måste ändra:
<compilation defaultLanguage="c#" debug="true" />

Det är nämligen så att detta element talar om vilken kompileringen som skall användas av själva sidan, alltså det som sker när man anropar sidan den första gången i en webbläsare. Och det är faktiskt en stor skillnad om man har satt elementet till true eller false.

Här finns en artikel som beskriver detta ytterligare. Jag vill bara återge två av de viktigaste upplysningarna i den artikeln.

debug=false
Now, pay close attention to this: when an ASP.NET file is requested for the first time the framework conducts a batch compilation on that directory. It compiles files in that directory only into a DLL.

debug=true
Batch compilation doesn't take place! To the contrary, every page is compiled into its own assembly! This is a very important point. More so, every page comes with a bunch of other files: debug symbol file, compiler command line file, compiler output file, etc. I'll reiterate: every page will have to be compiled individually into a separate assembly. 

PDA Historia

Jag börjar bli så gammal att jag ofta blir nostalgisk. Det kanske är ett säkert tecken på att medelåldern håller på att inträda. Jag vet faktiskt inte inte riktig när den inträffar, men jag känner på mig att det närmar sig. Om jag tänker efter borde medelåldern inträffa i mitten på på den förväntade medellivslängden på en man i Sverige.

Vad säger NE?
Medellivslängden är den genomsnittliga livslängden för nyfödda, beräknad enligt livslängdstabellen. Den är nästan alltid något större för kvinnor än för män. Medellivslängden har ökat kraftigt under den tid för vilken det finns tillförlitlig statistik. Under andra hälften av 1700-talet var medellivslängden i Sverige 33,7 år för män och 36,6 år för kvinnor. Vid början av 2000-talet är medellivslängden i Sverige bland de högsta i världen, ca 78 år för män och över 82 år för kvinnor. Många andra länder i Västeuropa har också hög medellivslängd. Världens högsta medellivslängd har Japan. Under senare år har medellivslängden stigit kraftigt också i många utvecklingsländer; t.ex. har den i Indien nått 63 år, en nivå som Sverige nådde ca 1930. (www.ne.se)

Det innebär att medelåldern är 78 / 2 = 39 år. Oops. Det blir jag om tre månader.

Här är en sådan nostalgitripp igen. Nu gäller det handdatorer och avancerade miniräknare. Några har man haft och flera har man önskat sig när de var heta. Min första var någon version av kalkylator med en adressbok. (Jag undrar om jag fortfarande har kvar den någonstans? Om så är fallet har väl batteriet vid det här laget löpt amok och droppat ut batterisyra i hela apparaten.)

The history of PDAs

Microsoft Architectual Day och Boktävling

[Tävlingen är avslutad, vinnarna har utsetts.]

En dag full av värdefull information, speciellt om hur man integrerar system mellan varandra. Jag tycker speciellt att första presentationen var mycket bra. (Jag vill inte vara partisk heller. Vi på Know IT hade en av de andra tre. Jag kunde tyvärr inte vara kvar och lyssna på den sista. Så Daniel, jag kritiserar inte dig.) Det var faktiskt en genomgång av den bok som jag tycker är den bästa jag har läst den här månaden, Enterprise Integration Patterns av Gregor Hohpe med flera.

Hela dagen handlade i princip om mönster. Jag tycker att det är bra att mönster håller på att bli “mainstream” inom .NET-världen. Men jag tror inte, som en av talarna sade, att alla vet vad ett mönster av typen singleton är.

Som grädden på moset eller sockret på pannkakan fick alla deltagare faktiskt den här boken helt gratis. Vilket är helt fantastiskt. Det är ingen billig bok. Jag vet, jag köpte den för två månader sedan. Så istället för att strunta i att ta någon bok, så tog jag min och bad om en extra för att göra en liten tävling där priset är en av dessa böcker. Mer om tävlingen i slutet på det här inlägget.

Ett av poängerna som jag, redan innan dagen, tänker mycket på är vilken teknologi som man skall använda för att kommunicera mellan tjänsterna. I dagsläget är det tyvärr så att man direkt tänker web service när man funderar på kommunikation mellan tjänster i en SOA-lösning. Det är viktigt att man inte låser sig vid den teknologin, speciellt en meddelandeteknologi är något som man gärna också skall använda i en sådan här arkitektur.

Tävlingsfrågan
Tävlingen går ut på att beskriva en fullständig SOA-lösning både i dokumentation och i kod. Nej, jag skojar. Min enkla fråga är: Vad heter namnspacet i Compact Framework 2, som gör det möjligt att implementera köhanterare på dessa enheter? Maila svaret tillsammans med ditt namn och din adress till [email protected]. De två först rätta svaren belönas med varsin bok.

Vad är det för skillnad på en "consultant" och en "contractor"

Det har hänt någon gång att jag har jobbat i ett internationellt team, där vissa har varit “consultants” och vissa “contractors”. Jag har tänkt på “contractor” mer som inhyrd personal, medan en “consultant” är en expert av något slag.

Idag läste jag en artikel, där det fanns en beskrivning av båda. Jag tycker att den är bra och vill dela med mig av den:

Dictionary definitions focus around two words: expert and advice. These two key words are important for understanding what a consultant is. First, a consultant should be an expert. Second, a consultant should provide advice.

One of the common mistakes is to hire contractors when an expert is called for. Contractors are people who agree to perform a job for a price usually for a shorter period of time. In other words, they are supplemental staff. They have no prerequisite knowledge and are expected to complete work.

Many contractors (and contracting companies) call themselves consultants (and consulting companies). But remember: Consultants are experts; contractors are labor.

When you hire a consultant be clear that you are hiring expertise, of which the primary goal is to provide advice. The advice may be in the form of an evaluation and recommendation. It may also be direct training of employees with recommendations. This is, in fact, the way most of my consulting engagements go. I'm there to educate IT management, technical staff, or both, on what they are doing well and what they can do better " or at least how to best utilize the technology they have.

Jag jobbar nog i ärlighetens namn ibland både som “consultant” och “contractor”. Det blir lite av båda. Ibland är det så att man börjar som “consultant” till 100% och sedan när man har gjort allt “tänk”, beskrivit arkitekturen och andra grejor, så går man över till att bli mer av en “contractor”, med inslag av en “consultant”.

Jag tror, precis som artikeln beskriver, att det är viktigt att veta om det är en “consultant” eller en “contractor” som man vill hyra in. Och när man hyr in en “consultant” är det viktigt att ha en tydlig specifikation på vad denne skall göra. (Kanske är rätt naturligt, eller hur?)

Hur hårt skall man typa en XSD-typ?

Xsd har stora möjligheter att specificera hur en typ skall se ut. Man kan ange allt ifrån hur långt ett värde kan vara till mycket avancerade regular expressions. En viktig fråga är hur mycket tid man skall lägga ned på att specificera sina typer, speciellt som dessa specifikationer inte följer med när man genererar kod av dem i .NET?

Bakgrund
Man börjar med att specificera sin typer med hjälp av xsd när man väljer att använda sig av tekniken contract first för att beskriva sin tjänster. Här är ett mycket enkelt exempel på en sådan specifikation.

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema id="PersonType" targetNamespace="http://tempuri.org/PersonType.xsd" 
        elementFormDefault="qualified"
        xmlns="http://tempuri.org/PersonType.xsd" 
        xmlns:mstns="http://tempuri.org/PersonType.xsd"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">
    
    <xs:element name="Person" type="PersonType"></xs:element>
    <xs:complexType name="PersonType">
        <xs:sequence>
            <xs:element name="FirstName" type="PersonNameType" maxOccurs="1" />
            <xs:element name="LastName" type="PersonNameType" maxOccurs="1" />
            <xs:element name="PersonIdNumber" type="xs:string" />
        </xs:sequence>
    </xs:complexType>
    <xs:simpleType name="PersonNameType">
        <xs:restriction base="xs:string">
            <xs:maxLength value="40" />
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="PersonIdNumberType">
        <xs:restriction base="xs:string">
            <xs:pattern value="[12][09][0-9]{2}[0-1][1-9][0-9]{4}" />
        </xs:restriction>
    </xs:simpleType>
</xs:schema>

Här har jag definierat en typ med namnet PersonType. Den har tre element: FirstName, LastName och PersonIdNumber. De två första elementen är av typen PersonNameType och det sista elementet av typen PersonIdNumberType. Båda dessa typer är definierade med olika regler. PersonNameType får endast vara upp till 40 tecken lång och PersonIdNumberType måste ha ett personnummer som är formaterat på ett speciellt sätt, exempelvis: 198409128909. (Observera att det inte går att skapa definitioner i xsd av den sorten att man kan räkna ut att kontrollsiffran på personnumret är rätt.)

När man genererar kod ifrån denna xsd-fil, antingen med Wsdl.Exe eller Xsd.Exe så kommer följande programkod att skapas.

[System.Xml.Serialization.XmlTypeAttribute
   (Namespace="http://tempuri.org/PersonType.xsd")]
[System.Xml.Serialization.XmlRootAttribute("Person", 
    Namespace="http://tempuri.org/PersonType.xsd", IsNullable=false)]
public class PersonType {
    
    /// <remarks/>
    public string FirstName;
    
    /// <remarks/>
    public string LastName;
    
    /// <remarks/>
    public string PersonIdNumber;
}

Alla mina definitioner på hur elementen skall vara har försvunnit. Det är alltså så att de inte följer med på något automatiskt sätt.

Hur mycket skall man då definiera typer och varför?
Det finns flera åsikter här och till viss del beror det på vad man skall bygga för system och använda typerna till. Men mina åsikter, som kan ändras om andra förutsättningar finns, är följande:

• Definiera så långt som det är nödvändigt. Det innebär att jag minimalt tycker att man skall ange längder på strängar och också ange vilken typ av tal som ett element skall innehålla. Det blir ungefär samma nivå som när man definierar fält i en tabell i en databas.
• Bygg upp generella definitioner, som använts ofta, och återanvänd dem.
• Använd <xs:pattern> för att använda regular expressions för att beskriva avancerade definitioner.
• Även om inte dessa definitioner kommer med vid kodgenereringen, så är de bra att använda vid dokumenteringen av kontraktet. Tänk på att helt andra system, på andra plattformar kan använda kontrakten och att dessa system kanske har kodgenererare som klarar av definitionerna.

Vad kan man göra åt att definitionerna inte följer med?
Det finns möjlighet att själv skapa valideringsrutiner som använder sig av de definitioner som finns lagrade i xsd-filerna. Ett mycket bra exempel på detta finns i följande artikel.
Jag har funderat på om man kunde bygga ut attributen som används för att specificera information i koden. Man skulle kunna skapa nya attribut som beskriver definitionerna och sedan använda sig av dem för att validera.