[alg] Hoe Webservices op te zetten

[Verwijderd]

We hebben verzekeringsmaatschappij A en B die allebei brandverzekeringen aanbieden maar die zelfstandig opereren. De maatschappijen slaan dus verschillende gegevens op en hebben een andere interface.

Nu wil ik een pakket maken dat verzekeringen kan aanmaken bij maatschappij A en B via Webservices (voor tussenpersoon X, door softwarehuis W). De systemen van A en B zijn opengesteld middels Webservices

Uiteraard wil X ook klantgegevens en gegevens over polissen opslaan in zijn lokale database (voor marketing doeleinden)

Het systeem van softwarehuis W dient zo gebouwd te zijn dat nieuwe maatschappijen makkelijk 'ingeplugd' kunnen worden.

Hoe pak ik het volgende aan:
- Waar vindt verificatie en validatie van de credentials plaats? (bij maatschappij A, B of softwarehuis W) Wat is wijs?

- Hoe sla ik de gegevens van de brandverzekeringen lokaal op? A en B slaan immers andere gegevens op! Aparte tabellen voor elke maatschappij of is er een slimmere manier?

Alle reacties zijn welkom

[Verwijderd]

Waarom niet gebruik maken van 1 tabel met dubbele columns.. ?

[Verwijderd]

Wat bedoel je precies met dubbele kolommen? Ik heb toch verschillende velden per maatschappij? Kun je het concreet maken?

[bartvb]

Als jij gemakkelijk nieuwe maatschappijen makkelijk in wil kunnen 'pluggen' dan lijkt het me HEEL verstandig om te kijken of je de gegevens toch op de een of andere manier kan standaardiseren. Neem aan dat de gegevens toch voor een erg groot deel overeenkomen? Een brandverzekering is een brandverzekering lijkt me

Kan je wat concreter zijn over de verschillen in de gegevens.

BTW wat betreft verificatie/validatie, verificatie hangt nogal af van wat er gebruikelijk is in die sector en waar de verantwoordelijkheden liggen. Voor het systeem zelf maakt dit nogal weinig uit. Validatie gebeurd natuurlijk in eerste instantie tijdens het invoeren maar verder ook bij het in de DB plaatsen. Maar ook daar ligt het nogal aan de situatie/verantwoordelijkheden/eisen..

[Basszje]

Interessant probleem

Ik zou eventueel gaan overwegen om XML te gaan gebruiken, want dat ik juist voor dit soort standaardiserings werk gemaakt.

Verder moet je dus de data van de verschillende databases dus standaardiseren. Dit zal wel met concessies van beide partijen gaan.

En dan idd de verificatie etc en waar de data wordt opgeslagen. Daar kan je ook meerdere opzetten voor bedenken.
Bijvoorbeeld via een centraal punt of gewoon decentraal.
Maar dan moet je er wel voor zorgen dat de users die import rechten hebben bij beide punten gelijk zijn, anders krijg je problemen.

[Verwijderd]

Als je die maatschappijen A en B zover kan krijgen dat ze een WebInterface implementeren die jij specificeert heb je in je eigen applicatie geen problemen.
Alleen A en B zover krijgen is lastig..

[Verwijderd]

Inderdaad. Maar als ik A en B niet zover krijg dat ze die Webinterfaces specificeren vlgens mijn specificaties....hoe kan ik het dan oplossen?

A en B hebben immers reeds een backend systeem....

[Verwijderd]

Op maandag 04 maart 2002 13:08 schreef Basszje het volgende:
Ik zou eventueel gaan overwegen om XML te gaan gebruiken, want dat ik juist voor dit soort standaardiserings werk gemaakt.

Ik ga SOAP gebruiken als communicatieprotocol in combinatie met HTTP als transportprotocol. Maar SOAP lost dit probleem toch niet op?

[Basszje]

Op maandag 04 maart 2002 13:31 schreef gerritsenea het volgende:
Inderdaad. Maar als ik A en B niet zover krijg dat ze die Webinterfaces specificeren vlgens mijn specificaties....hoe kan ik het dan oplossen?

A en B hebben immers reeds een backend systeem....

Het lijkt me dat de meeste data over die verzekeringen hetzelfde of bijna hetzelfde is

Dan kan jij met jou systeem gewoon die data die ze beide gemeen hebben pakken, allebei dezelfde naam geven ( voor zover dat niet al het geval is ) en deze tussen beiden uitwisselen.

Andere data wordt dan meer een probleem en zal je met ze moeten overleggen.

[Basszje]

Op maandag 04 maart 2002 13:33 schreef gerritsenea het volgende:

[..]

Ik ga SOAP gebruiken als communicatieprotocol in combinatie met HTTP als transportprotocol. Maar SOAP lost dit probleem toch niet op?

Zou ik nog ff kijken naar de verschillende technieken.
(als ik het goed begrijp ) is Http idd voor transport, SOAP ook voor communicatie tussen de systemen ( op een hoger niveau dus ) en XML voor de data.

Ze gaan dus allemaal mooi samen. Hier is bijv. .NET strategie van MS helemaal op gebaseerd.
Misschien moet je daar eens naar kijken ( ken de details niet ) .

[Verwijderd]

Op maandag 04 maart 2002 12:23 schreef bartvb het volgende:
Neem aan dat de gegevens toch voor een erg groot deel overeenkomen? Een brandverzekering is een brandverzekering lijkt me

Voor een groot gedeelte komen ze overeen, maar de vraag is of het ook op te lossen in zonder standaardisatie van de gegevens. Er kan immers in de toekomst een maatschappij C komen die niet mee wil werken aan de standaardisatie en waar ik toch verzekeringen wil afsluiten...

Kan je wat concreter zijn over de verschillen in de gegevens.

Maatschappij B legt de volgende gegevens vast voor een brandverzekering: soortwoning (permanent of vakantiewoning), aantal woon- slaap en hobbykamers, soort woning (flat/appartement of anders), bouwaard van de buitenmuren (steen/beton, hout, houtskelet), soort dakbedekking (harde dakbedekking, riet met brandwerende beplating), herbouwwaarde woning, postcode woning, huisnummer woning, polisnummer, datum ingang, verloopdatum

Maatschappij A legt de volgende gegevens vast voor een brandverzekering: soortwoning (eensgezinswoning, flat/etagewoning, studentenflat, woonboerderij), aantal woon- slaap en hobbykamers, bouwaarde van de buitenmuren (steen/beton, hout, kunstof, staal), soort dakbedekking (pannen/mastiek, riet, aluminium, hout, kunstof, steen/beton, staal), herbouwwaarde, postcode woning, polisnummer, datumingang, verloopdatum

Zo dit waren de concrete gegevens

[Verwijderd]

Dit klinkt ook wel als iets dat je met BizTalk op zou willen lossen. Dat is gemaakt om datastromen van verschillende bronnen te converteren en samen te voegen.

[bartvb]

Eeeh, ik wil niet flauw doen ofzo maar IMO komen die gegevens voor meer dan 90% overeen

[Verwijderd]

prima, hoe los je dan die overige 10% op?

[BlackBurn]

Op dinsdag 05 maart 2002 19:23 schreef gerritsenea het volgende:
prima, hoe los je dan die overige 10% op?

Dan toch extra kolommen overwegen?

Maar noem eens wat van die 10%, ik zie eerlijk gezegd niks zo wat problemen geeft

edit:
Ik had niet goed gekeken

[Verwijderd]

Op dinsdag 05 maart 2002 19:33 schreef BlackBurn het volgende:

Maar noem eens wat van die 10%, ik zie eerlijk gezegd niks zo wat problemen geeft

Maatschappij B wil doorkrijgen of de dakbedekking van metaal is, terwijl maatschappij A alleen de keuzes 'harde dakbedekking en riet met brandwerende beplating' heeft. Wat verstuur je dus naar maatschappij A als de persoon in je scherm heeft aangegeven dat het 'riet' is. Maak je dat in je programma een vertaalslag van riet naar harde beplating? En hoe programmeer je die vertaalslag, middels vertaaltabellen in je database???