[XML] - Push of Pull uitwisselen van data?

[gvanh]

Als onderdeel van een content management oplossing ben ik nu aan het kijken naar wat de handigste manier is voor uitwisseling van content. Daarbij staan mij nu twee paden voor ogen, te weten een Pull-systeem en een Push-systeem. Nu twijfel ik wat in dit geval handig is. Twijfel wordt veroorzaakt doordat naast tekstuele content ook multimediale content aangeboden moet worden (lees: afbeeldingen en video-bestanden). De voor- en nadelen zoals ik ze nu zie:

Pull
- Bij opvragen van een URL wordt een XML bestand samengesteld.
- Systeem van contentafnemer gaat periodiek naar http://<url>?klantid=xxxx&password=yyyy.
- Vervolgens wordt op basis van de gegeven identificatie een XML document samengesteld.
- In het XML document staan verwijzingen (uri's) opgenomen voor multimediale content, zoals afbeeldingen en video's.
- Bij verwerken van de XML door de content-afnemer, moet deze eenmalig de multimediale content downloaden en verwerken op zijn eigen server.

Voordelen:
- Klant kan zelf zijn interval kiezen voor het ophalen van data
- Systeem is eenvoudig opnieuw te gebruiken voor vergelijkbare vormen van (realtime) content-levering

Nadelen:
- Multimediale content moet nog eens los worden opgehaald
- Aangezien (geautomatiseerde) authenticatie via de URL gebeurt, worden username + pass plaintext over het internet verstuurd. (dat is - neem ik aan - zelfs zo, wanneer de verbinding via SSL versleuteld wordt ... aangezien de URL nog steeds plaintext wordt verstuurd vóórdat de versleuteling begint???)

Push
- XML-bestanden + bijbehorende multimediale bestanden worden periodiek op een FTP server van de contentafnemer geplaatst.

Voordelen::
- Alle content kan tegelijktijd worden geleverd.
- Content wordt nooit verschillende malen door dezelfde content-afnemer opgevraagd (bij video-bestanden wellicht een besparing van band-breedte).

Nadelen::
- Het systeem moet per afnemer nauwkeurig bijhouden welke bestanden al verstuurd zijn en welke niet.
- Er zijn meer werkzaamheden op het punt van foutafhandeling (wat moet er gebeuren wanneer de FTP server van de afnemer niet beschikbaar is ... wat als onvoldoende permissie is om bestanden te plaatsen, etc. etc.)

Er zijn ongetwijfeld nog meer overwegingen te noemen.

Mijn vraag is nu: heeft iemand argumenten die een keuze voor één van de twee opties makkelijker maakt? Zijn er nog andere opties naast de push/pull varianten die ik nu genoemd heb en die wellicht beter geschikt zijn voor leveren van XML en multimediale content?

Alvast dank voor de hulp bij het nadenken.

[Erkens]

gvanh schreef op maandag 19 maart 2007 @ 09:37:
- Aangezien (geautomatiseerde) authenticatie via de URL gebeurt, worden username + pass plaintext over het internet verstuurd. (dat is - neem ik aan - zelfs zo, wanneer de verbinding via SSL versleuteld wordt ... aangezien de URL nog steeds plaintext wordt verstuurd vóórdat de versleuteling begint???)

Als je gewoon HTTP authenticatie gebruikt worden de username en password iig wel met SSL versleuteld. Wat sowieso aan te raden is ipv een paar GET parameters

Ow, en ik zie het los ophalen van eventuele "multimediale content" eerder als een voordeel dan een nadeel in geval van pull.

Verder denk ik dat je gewoon bij je (potentiele) klanten moet vragen wat ze zelf het liefste zien.

[gvanh]

Verder denk ik dat je gewoon bij je (potentiele) klanten moet vragen wat ze zelf het liefste zien.

Idee is juist om dat niet te doen, maar om een methode op te stellen die op een dusdanige manier de huidige stand van de techniek en de standaarden volgt, dat díe werkwijze "gedicteerd" kan worden aan alle afnemers. Dat voorkomt dat je voor iedere afnemer een eigen implementatie aan het schrijven bent met de specifieke voorkeuren van die klant.

Overigens ben ik nu voor het eerst echt naar SOAP aan het kijken. Wellicht dat dat een goede gegadigde is om te dienen als "optie 3". Volgens mij kwam ik net tegen dat je middels SOAP ook binary bestanden kunt sturen ... maar dat ben ik nu aan het opzoeken.

[ Voor 21% gewijzigd door gvanh op 19-03-2007 10:20 ]

[dingstje]

gvanh schreef op maandag 19 maart 2007 @ 10:19:
[...]


Idee is juist om dat niet te doen, maar om een methode op te stellen die op een dusdanige manier de huidige stand van de techniek en de standaarden volgt, dat díe werkwijze "gedicteerd" kan worden aan alle afnemers. Dat voorkomt dat je voor iedere afnemer een eigen implementatie aan het schrijven bent met de specifieke voorkeuren van die klant.

Doe navraag wat de meest gevraagde methode is en dring die op...

Overigens ben ik nu voor het eerst echt naar SOAP aan het kijken. Wellicht dat dat een goede gegadigde is om te dienen als "optie 3". Volgens mij kwam ik net tegen dat je middels SOAP ook binary bestanden kunt sturen ... maar dat ben ik nu aan het opzoeken.

SOAP is slechts een techniek die de pull-methode gebruikt.

Ik zou overigens gaan voor een combinatie: de info zelf pushen, de mediacontent laten pullen wanneer dat nodig is.

[Confusion]

dingstje schreef op dinsdag 20 maart 2007 @ 00:52:
SOAP is slechts een techniek die de pull-methode gebruikt.

SOAP is een protocol dat poogt cross-platform webservices mogelijk te maken. Je kan er precies hetzelfde mee als met alle andere XML.

[Verwijderd]

Erkens schreef op maandag 19 maart 2007 @ 09:57:
Als je gewoon HTTP authenticatie gebruikt worden de username en password iig wel met SSL versleuteld. Wat sowieso aan te raden is ipv een paar GET parameters

Is dat zou? Naar mijn weten zijn er twee soorten HTTP-authenticatie: Basic en Digest. Bij Basic Authentication gaan de inloggegevens in leesbare vorm over de lijn. Bij Digest Authentication wordt met behulp van een salt een hash gemaakt van in elk geval het wachtwoord.

HTTPS maakt wel gebruik van SSL.

[Erkens]

Verwijderd schreef op woensdag 21 maart 2007 @ 12:34:
Is dat zou? Naar mijn weten zijn er twee soorten HTTP-authenticatie: Basic en Digest. Bij Basic Authentication gaan de inloggegevens in leesbare vorm over de lijn. Bij Digest Authentication wordt met behulp van een salt een hash gemaakt van in elk geval het wachtwoord.

HTTPS maakt wel gebruik van SSL.

En doordat je SSL gebruikt zijn de headers gewoon netjes encrypted