[Webservices] Interfaces specifiek maken of generiek houden?

[Verwijderd]

Even denken hoe ik t kort kan houden...

Op het ogenblik werk ik mee aan een groot automatiseringstraject. De bouwstenen van het systeem zijn webservices. Deze worden tevens gebruikt om de back-offices van verschillende partijen met het systeem te integreren.

Nu ben ik zelf geen programmeur, maar adviseur in dit project. Vandaar dat ik jullie wil "misbruiken"....

De kernvraag is als volgt:
Hoe zet je nu goede webservices op? Waar ik nu tegen aan loop is de keuze om heel generieke methods op te zetten (slecht voorbeeld: geefKlantgegevens()) of heel specifieke (vervolg slecht voorbeeld: geefNaam()) methods op te zetten.

Als je het heel generiek doet, dan heeft dit als gevolg dat er veel redundante gegevens over en weer gaan, wat uiteraard invloed heeft op de performance. (voorbeeld: je stuurt alle gegevens terwijl je alleen een nummer nodig hebt) Doe je het heel specifiek dan maak je het gebruik (aanroepen) en ontwikkelen heel complex.

Weten jullie of er hier richtlijnen voor zijn? Is er bijvoorbeeld een goede website waarop dergelijke zaken worden toegelicht en mijn inzicht kan worden verbreed?

Alvast heel erg bedankt voor jullie input!

[Alarmnummer]

Verwijderd schreef op 01 november 2004 @ 22:46:
Even denken hoe ik t kort kan houden...

Waar ik nu tegen aan loop is de keuze om heel generieke methods op te zetten (slecht voorbeeld: geefKlantgegevens()) of heel specifieke (vervolg slecht voorbeeld: geefNaam()) methods op te zetten.

Hele fijnmazige interfaces gaan enorme performance problemen opleveren. Daarom is het vrij gebruikelijk om een soort data verstuur object (Data Transfer Object) te maken die je naar de client stuurt (in het geval van webservices druk je een lading de data de lijn over). De overhead om 1 zo`n pakket te versturen is veel kleiner dan veel kleine calls.

Als je het heel generiek doet, dan heeft dit als gevolg dat er veel redundante gegevens over en weer gaan, wat uiteraard invloed heeft op de performance. (voorbeeld: je stuurt alle gegevens terwijl je alleen een nummer nodig hebt) Doe je het heel specifiek dan maak je het gebruik (aanroepen) en ontwikkelen heel complex.

Hele specifieke interfaces maken voor webservice is eigelijk een beetje in strijd met het doel van een webservice. Een webservice is vooral bedoelt om verschillende systemen aan elkaar te lijmen met vrij 'breed' in te zetten services. In principe moet je dus geen webservice maken vanuit de optiek van de client, maar vanuit de server. Hierdoor leg je je ook niet vast op de eisen van die client.

Nu ben ik zelf geen programmeur, maar adviseur in dit project.

Ach tja... in het land der blinden is eenoog koning.

[ Voor 4% gewijzigd door Alarmnummer op 01-11-2004 22:56 ]

[NMe]

Ik denk dat je het gouden midden moet zoeken tussen generieke en specifieke methods. Je zou kunnen denken aan een class Klant, die zowel die generieke functie bevat en een resource of resultset of iets dergelijks returnt, terwijl die class ook gewoon functies bevat om alles apart op te halen. Op die manier kun je per situatie bepalen wat het makkelijkst en efficiëntst werkt.

_{Ik vraag me overigens wel af hoe jij als niet-programmeur een goed advies moet geven over het ontwerp van een webservice...}

[alienfruit]

Het hangt vooral af van wat voor gegevens je wilt delen dmv. een web service, als kijkt na de lopende webservices projecten bij een MC is dit vaak gedeeltelijk specifiek en deels generiek. Waarmee ik bedoel dat "algemene" gegevens op een generieke manier wordt gedeeld (i.e. adresgegevens: getAddressById(), getAddressByName() etc.) maar soms ook specifiek voor andere informatie. Het hangt er vanaf. Maar goed dit zijn zo beetje mijn vuistregels

[curry684]

* curry684 roept subtiel iets over meta-data en het rondpompen van generieke structuren

Je kunt zelfs een metamodel maken rondom generieke querystructuren zodat je maar 1 call hebt die je voor de meest simpele single en de meest complexe bulk calls kunt inzetten

[Alarmnummer]

alienfruit schreef op 01 november 2004 @ 22:58:
Het hangt vooral af van wat voor gegevens je wilt delen dmv. een web service, als kijkt na de lopende webservices projecten bij een MC is dit vaak gedeeltelijk specifiek en deels generiek. Waarmee ik bedoel dat "algemene" gegevens op een generieke manier wordt gedeeld (i.e. adresgegevens: getAddressById(), getAddressByName() etc.) maar soms ook specifiek voor andere informatie. Het hangt er vanaf. Maar goed dit zijn zo beetje mijn vuistregels

Je moet enorm oppassen om data op deze manier op te halen. Als je veel data op gaat halen (zoals je vaak ziet in allerlei mooie webinterfaces) krijg je een enorme overhead. (Je moet iedere veld naar een call en dan naar xml vertalen.. de lijn over drukken.. terug naar serverside structuur... dan verwerken.. dan terug naar xml.. dat weer terug de lijn over.. en dat weer ombouwen naar clientside structuren. Iedere call heeft dus enorm veel overhead. Daarom kan je beter grotere stukken data in 1 keer overdrukken.

[djc]

Heb je het trouwens over een REST-style Web Service, of ben je meer van de SOAP en de hele WS-stack? (Als je nog niet weet wat het verschil is is het misschien wel nuttig om daar iets over uit te zoeken, dan weet je goed waar je aan begint.)

[Verwijderd]

NMe84 schreef op 01 november 2004 @ 22:55:
_{Ik vraag me overigens wel af hoe jij als niet-programmeur een goed advies moet geven over het ontwerp van een webservice...}

Don't worry...alles wat we willen is meer grip op de softwareleverancier en wat deze allemaal doet...

[Verwijderd]

Alarmnummer schreef op 01 november 2004 @ 23:03:
[...]
Daarom kan je beter grotere stukken data in 1 keer overdrukken.

Ja ok, maar wil je dat de server een kwartier staat na te denken?!

[whoami]

Verwijderd schreef op 02 november 2004 @ 11:45:
[...]


Ja ok, maar wil je dat de server een kwartier staat na te denken?!

Remote interfaces moeten coarse grained zijn, en niet fine grained. Dat wil dus zeggen dat je zo weinig mogelijk remote calls moet doen om je data te verkrijgen, omdat die overhead van een remote call zeer groot is. (Wat Alarmnummer dus al gezegd heeft).

Als je klantgegevens wil verkrijgen, dan ga je niet 2, 3, 4, ... aparte calls gaan doen om die gegevens te verkrijgen 'getNaam(), getBalacne(), ...), maar ga je één call doen die de hele data-chunk doorstuurt.

Misschien is het beter als je eens een en ander leest over remote interfaces/remote facades, etc...

Je server gaat echt geen kwartier staan 'nadenken' om een object oid te versturen.

_{Ik snap trouwens ook niet waarom ze iemand een project laten superviseren die van de materie helemaal geen kaas gegeten heeft.}

[steffex]

Ik zou een goede tussenweg zoeken...!

voor de gebruikers moet het snel en simpel zijn, maar qua programmatuur moet het ook uitgebreidt zijn zodat het compatible is met meerdere systemen..!

Jij als adviseur en de programmeurs in het team zullen hiervoor de koppen bij elkaar moeten steken, om tot een goede oplossing te komen.

[whoami]

Wat versta je dan onder een tussenweg ? Er is geen tussenweg.

[Alarmnummer]

stef-o.nl schreef op 02 november 2004 @ 12:07:
Ik zou een goede tussenweg zoeken...!

voor de gebruikers moet het snel en simpel zijn, maar qua programmatuur moet het ook uitgebreidt zijn zodat het compatible is met meerdere systemen..!

Wat hebben gebruikers te maken met de fijnmazigheid van remote interfaces?

Jij als adviseur en de programmeurs in het team zullen hiervoor de koppen bij elkaar moeten steken, om tot een goede oplossing te komen.

Misschien kan jij het team dan versterken. Met zo`n opmerking weet ik zeker dat je dan van de wal in de sloot terecht komt.

Je krijgt van mij de prijs voor de meest niets zeggende reply van het jaar.

[ Voor 16% gewijzigd door Alarmnummer op 02-11-2004 12:33 ]

[alienfruit]

Bij mijn weten doe ik dat dan ook hoor, als ik een adres van jou wil krijg ik zat NAW-gegevens om over de lijn te sturen. Overigens is het internet snel genoeg om wat meer bulk over de lijn sturen, maar natuurlijk kun je ook een andere manier van remoting gebruiken. Overigens kun je natuurlijk ook een eigen formaat gebruiken, zodat gebruik ik vaak RemObjects SDK voor zulke remoting oplossingen, dit stuurt in combinatie met Data Abstract zulke data zo efficient mogelijk over de lijn, door de compressie minstens 4-8 kleiner dan SOAP/WSDL.

[Verwijderd]

alienfruit schreef op 02 november 2004 @ 12:38:
Overigens kun je natuurlijk ook een eigen formaat gebruiken, zodat gebruik ik vaak RemObjects SDK voor zulke remoting oplossingen, dit stuurt in combinatie met Data Abstract zulke data zo efficient mogelijk over de lijn, door de compressie minstens 4-8 kleiner dan SOAP/WSDL.

Dat zal wel, maar in deze situatie gaat het om 1 systeem waar de back-offices van vele organisaties aan gekoppeld moeten worden. Als het dan over "eigen formaat" gaat, dan help je daarmee ook de interoperabiliteit om zeep...

En ook zijn er behoorlijk wat continue gebruikers... (100-en!!) Ik denk dat de beste oplossing is dat in overleg met de "gebruikende organisaties" welke specifieke methods veel nodig zijn en verder uit te gaan van generieke oplossingen.

[alienfruit]

Tuurlijk overleg met de gebruiker is altijd goed, voorkomt veel problemen later