[architectuur]service bus en business objects

[BasieP]

Heren (en dames natuurlijk),

Wij hebben binnen ons bedrijf een service bus die de mogelijkheid geeft om via een soap interface berichten te posten.

momenteel ziet dat er ongeveer zo uit:

XML:

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://esb.onsbedrijf.local/">
  <m:Postbericht>
    <m:data>&lt;messageStandaard version=&quot;1.1&quot;&gt;
&lt;itemlist&gt;
&lt;businessobject type=&quot;verzinietsleuks&quot;&gt;&lt;property&gt;value&lt;/property&gt;&lt;otherProperty&gt;value&lt;/otherProperty&gt;&lt;/businessobject&gt;&lt;businessobject type=&quot;verzinietsleuks&quot;&gt;&lt;property&gt;value&lt;/property&gt;&lt;otherProperty&gt;value&lt;/otherProperty&gt;&lt;/businessobject&gt;
&lt;/itemlist&gt;
&lt;/messageStandaard&gt;</m:data>
  </m:Postbericht>
</soap:Body>
</soap:Envelope>

Er zit dus xml in xml. (geescaped)

Mijn eerste gedachte was "huh wat gek.. dat is toch ranzig"
En ik heb mijn visie daarop voorgesteld aan de bouwer. Ik zei:

"Je wilt toch je domein model (de taal die je ESB spreekt) publiek maken door je webservices?"
en
"Clients kunnen veel makkelijker hun software bouwen als ze de xsd met het domein model niet via de mail krijgen, maar als de webservice die aanlevert"

Echter waren de bouwers het hier niet mee eens vanwege een aantal redenen, waarvan de grootste performance was.

Nu is de ESB binnen ons bedrijf momenteel verre van de bottleneck, dus ik wil persoonlijk best wat concessies doen wat betreft die performance, maar ik zat me vooral even af te vragen wat nou de best practices zijn.

Ik heb wat zitten googlen, maar ik kan hier weinig over vinden.
Ik vind wel wat voorbeelden waarbij het domein model wel in de xslt zit, maar dit gaat dan om kleine berichtjes.

In ons geval is een berichtje soms 5 mb (dat zijn wel de uitzonderingen), en het valideren van dit soort berichten nemen dan ook even wat resources in beslag. (hij schijnt onder water een dom-tree op te bouwen)

Wat zijn jullie ervaringen/meningen.

Moet je ESB je domein model exposen? en wat zijn de voors en de tegens?


linkjes die mij relevant leken:
http://docs.oracle.com/cd...7/modelingmessageflow.htm
http://www.ibm.com/develo...ces/library/ws-soapmqjms/

[ Voor 3% gewijzigd door BasieP op 28-10-2013 20:11 ]

[HMS]

Ik vind zelf SOAP een ramp, maar ik snap dat het binnen de meer 'enterprise' systeem een veelvoorkomend iets is (waarschijnlijk technical debt uit het webservices voor ALLES tijdperk).

Ook vind ik dat zodra je XML geëscaped in XML ziet zitten dat er al een belletje moet gaan rinkelen dat misschien 'you're doing it wrong' (satanistische constructies van een SOAP XML met een base64 encoded zip file met een XML erin zijn natuurlijk het mooiste voorbeeld).

[Feanathiel]

BasieP schreef op maandag 28 oktober 2013 @ 20:09:
...
"Je wilt toch je domein model (de taal die je ESB spreekt) publiek maken door je webservices?"
en
"Clients kunnen veel makkelijker hun software bouwen als ze de xsd met het domein model niet via de mail krijgen, maar als de webservice die aanlevert"

En een WSDL doet dit niet?

Anyway; wat wij doen is een model exposen waar de doelgroep wat mee kan. We houden dan rekening mee met eventuele groei en houden verschillende versies van webservices in het oog (waar nodig). Intern mappen we dit dan om naar een formaat waar wij wat mee kunnen en gaan hier vervolgens mee rekenen/verwerken.

[Hydra]

Dergelijke oplossingen hebben niks performance te maken. De reden dat dat zo gedaan is is gewoon tijdgebrek/luiheid. Is m.i. Compleet not-done.

[BasieP]

@Feanathiel:
niet als je er een bericht type="any" in zet waarin een lange ge-escape-te xml zit (zie startpost)

maar jullie vinden allemaal dat je je domainmodel zou moeten exposen, en door deze in de xsd/soap te zetten doe je dat.

De argumenten over performance die ik gehoord heb zijn dat ze nu de mogelijkheid hebben bericht validatie uit te zetten. (waarom ze dat in godsnaam willen weet ik niet)
Door dit uit te zetten hoeven ze dus geen kennis te hebben van de inhoud van het bericht en kijken ze alleen naar de meta-data om het bericht te routeren naar de afnemer(s).

het valideren kost tijd/resources omdat er een DOM tree opgebouwd moet worden voor de validatie. Dit klopt en ik kan me inderdaad voorstellen dat hier een performance penalty aan vast zit.

Ik kan alleen heel weinig documenten vinden op internet doe een best practice laten zien van hoe je soap berichten er uit zien in een ESB.

Mijn common sense zegt hetzelfde als dat van jullie, maar ik wil het graag kunnen onderbouwen.

Ik kan me voorstellen dat dit soort documenten wel bestaan, maar weet gewoonweg niet waar ik op moet zoeken.

Anyone?

[HMS]

Tja, wat wil je doen?

Volgens mij is het gewoon een Remote Procedure Call, dus je moet een target hebben (de functie die aangeroepen moet worden), de parameters, en waar de response heen moet.

Waarom moet hier een vet complexe XML van gemaakt moet worden, en niet gewoon iets simpels als JSON?

[BasieP]

HMS schreef op dinsdag 29 oktober 2013 @ 22:58:
Tja, wat wil je doen?

Volgens mij is het gewoon een Remote Procedure Call, dus je moet een target hebben (de functie die aangeroepen moet worden), de parameters, en waar de response heen moet.

Waarom moet hier een vet complexe XML van gemaakt moet worden, en niet gewoon iets simpels als JSON?

Dat hebben we nou eenmaal afgesproken.
Dit is geen hobby projectje maar de core van een groot bedrijf.

Er is door een groep mensen een domainmodel gemaakt en daar is een XSD van gemaakt. We hebben met elkaar afgesproken dat we die taal gaan praten.
In de eerste instantie gaan we dit doen dmv xml (omdat dat nou eenmaal makkelijk valideert, en soap xml is)
Wellicht dat we later wel json gaan bouwen

Dit gaan we doen middels een service bus (ding is inmiddels gebouwd) en nu ga ik er een applicatie aanhangen, en kom er achter dat de interface helemaal niet volgens ons domainmodel is. Dwz, de interface accepteert alles, maar wijst vervolgens berichten af die niet voldoen aan de xsd.
We zullen in de huidige situatie dus 'ergens' het xsd vandaan moeten halen, en zelf moeten gaan truken om daaraan te voldoen. Vervolgens daarvan xml uitspugen. Die escapen, en dan encapsuleren in een soap bericht.
Dat moet dan in de huidige situatie op de bus.

Echter heb ik de architectuur zo begrepen dat de bus WEL de xsd exposed, en daar hebben we nu deze discussie over.

Ik zag op de oracle site deze howto staan, waarbij ze ook gewoon data als elementen opnemen in het soapbericht.
https://java.net/download...ials_111140_and_later.pdf

Echter kan je dit ook opvatten als "that's one way to do it, maar er zijn er nog 5..."

[ Voor 3% gewijzigd door BasieP op 29-10-2013 23:16 ]

[DXaroth]

op zich xml als payload is geen ramp, met XSDs kan je dan 'simpel' validatie uitvoeren op ingaande/uitgaande berichten.
... maar het idee van encapsulated xml in een xml bericht.. dat lijkt me een beetje ver gaan.

Onze bus accepteerd gewoon xml data als deel van de payload, dus niet encapsulated, zo blijft het hele bericht leesbaar.. de belangrijke data (wat voor call, uuids etc) is direct beschikbaar (waardoor xsd-validatie snel uit te voeren valt), en je hoeft maar 1x de data te parsen (ipv parse, validate, extract, unescape, parse, validate, execute => parse, validate, execute )

[Bu588]

De reden die ik het vaakst tegenkom voor dit soort constructies is dat het proces flexibler wordt om aan te passen. Als je de structuur van de XML payload wilt wijzigen hoef je de ESB niet aan te passen maar alleen de zendende en/of ontvangende kant. Als de ESB de XML structuur volgt moet hij voor elke wijziging (extra attribuutje) worden aangepast, en ESB aanpassingen kosten over het algemeen veel tijd.

[DXaroth]

Bu588 schreef op donderdag 31 oktober 2013 @ 09:07:
De reden die ik het vaakst tegenkom voor dit soort constructies is dat het proces flexibler wordt om aan te passen. Als je de structuur van de XML payload wilt wijzigen hoef je de ESB niet aan te passen maar alleen de zendende en/of ontvangende kant. Als de ESB de XML structuur volgt moet hij voor elke wijziging (extra attribuutje) worden aangepast, en ESB aanpassingen kosten over het algemeen veel tijd.

Dan gebruiken mensen toch echt het verkeerde ESB pakket .. het compilen van onze ESB duurt nog geen minuut, en het opnieuw opstarten met de modules is ongeveer.. 30 seconden werk? ... gemiddeld is het systeem 10x langer bezig met alle test cases nalopen dan dat wij nodig hebben voor een deployment (graceful shutdowns etc)

Waar het mis gaat is dat de ontwikkelaars gelijk roepen dat het veel werk gaat zijn, maar dat valt volgens mij best mee..

[ Voor 6% gewijzigd door DXaroth op 31-10-2013 09:28 ]

[pedorus]

In het kader van wie stelt bewijst zou ik eens vragen waarom dubbel gecodeerde xml perse nodig is. Het is in ieder geval niet standaard, en performance geeft het ook niet. En hoe ga je zoiets in iets als SoapUI gebruiken?

[Bu588]

DXaroth schreef op donderdag 31 oktober 2013 @ 09:27:
[...]


Dan gebruiken mensen toch echt het verkeerde ESB pakket .. het compilen van onze ESB duurt nog geen minuut, en het opnieuw opstarten met de modules is ongeveer.. 30 seconden werk? ... gemiddeld is het systeem 10x langer bezig met alle test cases nalopen dan dat wij nodig hebben voor een deployment (graceful shutdowns etc)

Waar het mis gaat is dat de ontwikkelaars gelijk roepen dat het veel werk gaat zijn, maar dat valt volgens mij best mee..

Tja, technisch is het inderdaad niet zoveel werk maar binnen grote bedrijven duurt het hele ontwikkel/test/acceptatie traject vaak nogal lang en moet er nogal veel worden afgestemd tussen afdelingen, gebruikers en beheerders. Daarom besparen die zich vaak liever de moeite en gebruiken simpelweg XML payloads.

[Freeaqingme]

Als je je domeinmodel niet zou exposen, zou ik toch in ieder geval een CDATA-blok gebruiken, in plaats van je XML te escapen.