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.

Comments

[Lars Olofsson]

Jag ser tjänsterna i SOA som en nivå högre i abstraktion än OOD, och att man ska vara lite försiktig med att *direkt* överföra OOD-koncept på dem. På samma sätt som OOD är en nivå högre i abstraktion än strukturerad utveckling. De är tre separata abstraktionsnivåer, och tre olika tänkesätt, som likt ryska dockor kapslar in varandra. Givetvis finns det många likheter, men det gäller att hålla tungan rätt i mun.

[Jonas]

Btw, jag gillar typsnittet på den här texten. Jag dammade av en bok igår, skriven av Al Major som handlar om IDL och COM. Läser man den förstår man tydligt varför distribuerade system har nått vägs ände. System som skapar beroenden som DCOM, RMI och sena versioner av CORBA är inte hållbart sägs det. Men är det därför vi har fått drillat SOA-metaforer i snart 2 år? Är det inte messaging i allmänhet och WS i synnerhet som är lösningen på tekniska bereoenden. Måste vi ha en service modell bara därför? Är inte serviceorientering något som bygger på att separerar logik och data (applikationer) från varandra? Dvs all logik ska inte implementeras i en stor applikation som delar data, utan som fler stycken services som byter data med varandra.

[ogpu sbdlj]

oefh qnwrguemp dstx rxtc tfvi shjzcugwv mxugkelb