[SOAP] Business logic in een SOAP server

[Wortelpudding]

Ik ben bezig met een project waarmee ik mbv business objects een database moet vullen en queryen. Deze business object bevatten alle business logic/rules van de database.
Ik wil graag dat de interface naar deze business objects generiek is en makkelijk te gebruiken voor derden, dus ik zat aan SOAP/WSDL te denken.

Zijn er mensen die al eens business objects met behulp van SOAP/WSDL geimplementeerd hebben? En zo ja, hoe heb je dat dan gedaan?

Ook ben ik geinteresseerd in andere open en generieke interfaces (dus los van de database, ik wil het liefste GEEN stored procedures hoeven gebruiken)...

[LordLarry]

Ja, goed. Ik ben begonnen met de interfaces op te stellen en toen te implementeren.

SOAP, COM, DCOM, COM+, Corba, J2EE, .Net Remoting, RMI om er maar een paar te noemen. Maar dat heeft niets te maken met het wel of niet gebruiken van stored procedures.

Wat is je echte vraag?

[mbravenboer]

Het lijkt mij dat je het beste kan proberen om je applicatie zoveel mogelijk op te zetten zonder je specifiek aan een interface voor remoting te binden. De remoting code zou dus imho gescheiden moeten zijn van de 'echte' code.

[Wortelpudding]

mbravenboer schreef op 20 February 2003 @ 17:10:
De remoting code zou dus imho gescheiden moeten zijn van de 'echte' code.

Je bedoelt dus dat je de business logic ook nog weer scheidt van de functionaliteit om de business logic remote beschikbaar te maken?

LordLarry schreef op 20 February 2003 @ 16:53:
Wat is je echte vraag?

lol, nou, algemeen gesteld: Wat is de beste (of gewoon een goede) manier om business logic remote beschikbaar te stellen?

Een manier is door gebruik te maken van stored procedures in je database, maar dan loop je al heel snel het gevaar dat je die business logic op zo'n manier implementeert dat het vrijwel onmogelijk wordt om nog een beetje soepel naar een ander RDBMS over te stappen (bijv van MSSQL naar Oracle).

Het liefst zou ik m'n database volledig met behulp van business objects toegankelijk maken, die door meerdere applicaties eenduidig te raadplegen zijn. Deze business objects implementeren dan dus niet alleen de validatie van ingevoerde data, maar ook het daadwerkelijk doorvoeren van de data in de database en ook het zoeken naar gegevens in de database. Je zou het eigenlijk kunnen zien als een OO schil om een relationele database.
De volgende stap is om deze business objects niet alleen maar op de lokale server, maar ook vanaf een andere server/workstation te kunnen raadplegen. Dus mijn eerste vraag zou eigenlijk m'n 2e vraag moeten zijn, want de 1e vraag is eigenlijk:
Wat is een goede manier om dit soort business objects te maken, en wel op zo'n manier dat ze vanuit verschillende applicaties toegankelijk zijn? Of is er misschien een betere manier dan het gebruik van business objects?
Hierover zou ik graag eens in dit topic met mijn mede-devtweakers over willen brainstormen

[Alarmnummer]

Als je van boeken houdt, dan raad ik je deze aan:
Patterns of Enterprise Application Architecture van Martin Fowler.

En als je naar kant en klare oplossingen wilt kijken, dan adviseer ik je EJB (als je met java wilt werken dus ). Hierbij hoef je zelf alleen nog de business logic te schrijven en netwerk/database etc wordt allemaal voor je gedaan.

En verder moet je proberen om je business logic niet te besmetten met de middelware die je gebruikt. Hierdoor kan je makkelijk een ander systeem erachter zetten, maar het grootste voordeel is denk ik wel dat je je maar met 1 aspect van het systeem tegelijk bezig houdt.

[ Voor 63% gewijzigd door Alarmnummer op 22-02-2003 12:12 ]

[mbravenboer]

MrHuge: Je bedoelt dus dat je de business logic ook nog weer scheidt van de functionaliteit om de business logic remote beschikbaar te maken?

Exact .

[Verwijderd]

Ik vind dat SOAP traag is
Lekker nuteloze bijdrage

[Just_a_Gamer]

Verwijderd schreef op 22 February 2003 @ 22:04:
Ik vind dat SOAP traag is
Lekker nuteloze bijdrage

graag een onderbouwing

Ik heb met mijn stage veel met soap/ webservices gewerkt. Het is vrij snel afhankelijk van wat je wilt gaan doen.

[Verwijderd]

Traag omdat je zo'n vreselijke XML overhead hebt
Ik gebruik zelf

http://www.remobjects.com...9-4502-8C90-36396EFB0FB5}

[ Voor 8% gewijzigd door Verwijderd op 23-02-2003 01:26 ]

[mbravenboer]

reyer: Traag omdat je zo'n vreselijke XML overhead hebt

Daarom zou je het ook alleen in systemen moeten toepassen waar de inzet van XML belangrijk of vrijwel noodzakelijk is. Dit geldt in het algemeen in voor XML web-services systemen, of ze nu op SOAP, XML-RPC, RDF of plain-data gebaseerd zijn.

SOAP wordt naar mijn idee teveel gepositioneerd (en dus ook ingezet) als een systeem voor gedistribueerde object systemen, waarbij je ook nog van alle voordelen van XML geniet. In de praktijk blijkt dat veel van de voordelen volledig wegvallen als je je niet heel serieus bezig houdt met het formaat waarin de data wordt uitgewisseld. Zelf een hello world achtig gedistribueerd object systeem wordt al snel vrijwel onbereikbaar voor clients die niet van dat zelfde gedistribueerde object systeem gebruik maken.

In die situaties kan je beter kiezen voor andere methode en opzet van transport, wat niet direct hoeft te betekenen dat je een heel ander gedistribueerd object systeem moet gaan gebruiken.

[mbravenboer]

Dit is wel een aardige, die gisteren op Cafe con Leche stond:

SOAP is using XML because of the lingering hype wave from XML, not because XML itself is particularly well-suited to the tasks that SOAP performs. I'd say SOAP used HTTP early on for similar reasons, and I hope that just as SOAP appears to be leaving HTTP behind as it becomes clearer that SOAP and HTTP have little to do with each other, that SOAP may yet leave XML behind.

(Simon St.Laurent on the xml-dev mailing list, Thu, 04 Jul 2002)

Dit gaat wel wat ver, maar hij heeft wel een punt. Volgens mij gaat het met name over de manier waarop SOAP toegepast wordt (misbruikt imho) dan echt over SOAP zelf.

XML-RPC is ook zo'n probleem geval. Het is bij sommigen wat populairder om het allemaal een stuk duidelijker, eenvoudiger en logischer is, maar in principe is het een merkwaardig gebruik van XML.

Je wisselt bij XML-RPC in feite Abstract Syntax Trees (AST) van methode aanroepen en resultaten uit. In een bepaald opzicht past dat goed bij XML omdat het bij XML in feite ook draait om abstracte syntax, maar je gebruikt maar een heel klein deel van XML: het wordt alleen maar toegepast om het veel beperkte data model van XML-RPC (arrays, structs, ints, strings en dergelijke) te representeren.

Dit betekent dus in feite dat beide systemen die altijd genoemd worden als web-services standaarden nogal een merkwaardige aanpak hebben als je kijkt naar wat XML eigenlijk kan betekenen voor uitwisseling van data tussen software componenten op verschillende locaties.

MusicBrainz!, wat samen met Google waarschijnlijk het genoemde voorbeeld van publieke web services zal worden, gebruikt wellicht daarom weer RDF.

Documentatie en voorbeelden:
http://www.musicbrainz.org/MM/
http://www.musicbrainz.org/MM/mm_examples.html

Zie trouwens ook dit topic van mij op Webgoeroe.net: xml-rpc: leuke demo services?

[Wortelpudding]

SOAP is iig een goed protocol voor open services. Zeker als je het combineert met WSDL dan heb je een zeer open interface die je beschikbaar kunt stellen aan 3rd parties. Dit is de manier waarop we SOAP gebruiken, en eigenlijk ook de meest logische manier. Je hoeft van SOAP alleen niet te verwachten dat het een high-performance protocol is (vanwege die XML overhead dus). Het lijkt mij dan ook eigenlijk dat SOAP voor business objects voor een database op zich een mooi principe is (vanwege de toegankelijkheid, een SOAP client heb je mbv MS SOAP Toolkit echt binnen 1 minuut gebouwd), maar de uitwerking is imo misschien toch te traag.

Volgende vraag dus :
Zijn er betere (meer doorontwikkelde) protocollen/api's voor het remote beschikbaar stellen van objecten (business objects) die net zo'n toegankelijke interface hebben als SOAP? Het zou dus ook mooi zijn als een API goed samen kan met VB en collections. Ik vind collections nl ideaal voor het beschikbaar stellen van een recordset (of zijn daar ook nog andere suggesties voor ).

Ik heb al verschillende termen voorbij zien komen:

COM/DCOM/COM+:
Dit is een mooie techniek, omdat het heel erg goed met Visual Basic samen werkt. Volgens mij is Visual Basic een goede omgeving om business objects in te ontwikkelen.
Het nadeel van (D)COM(+) is, dat je te maken hebt met usercontexts. Bij het gebruiken van COM objecten moet je er altijd rekening mee houden dat een COM object zich in een een bepaalde gebruikerscontext bevindt met zijn specifieke rechten. Als je wilt dat een COM object alleen maar onder 1 bepaalde usercontext draait, dan is dat altijd geklooi.

CORBA:
Dit vindt ik eigenlijk een prachtig principe, maar (correct me if i'm wrong) niet zo heel erg ingeburgerd. De snelheid van ontwikkelen (voor zover ik er meer ge-expirimenteerd heb) is niet zo heel erg hoog als bij (D)COM(+) icm VB en/of SOAP.

Alle Java-based technieken:
Java is leuk, maar ik associeer Java nou niet direct met high-performance en scalability.

Verwijderd schreef op 23 February 2003 @ 01:26:
Ik gebruik zelf
http://www.remobjects.com...9-4502-8C90-36396EFB0FB5}

Dit ziet er inderdaad veelbelovend uit! Zou je eens iets meer kunnen vertellen over je ervaringen met RemObjects?
Het is me bij RemObjects niet echt duidelijk of je het ook gemakkelijk met andere programmeeromgevingen dan Delphi kunt gebruiken, heb jij daar ervaring mee, reyer?

[ Voor 4% gewijzigd door Wortelpudding op 24-02-2003 09:35 ]

[LordLarry]

Wortelpudding schreef op 24 February 2003 @ 09:20:
COM/DCOM/COM+:
Dit is een mooie techniek, omdat het heel erg goed met Visual Basic samen werkt. Volgens mij is Visual Basic een goede omgeving om business objects in te ontwikkelen.
Het nadeel van (D)COM(+) is, dat je te maken hebt met usercontexts. Bij het gebruiken van COM objecten moet je er altijd rekening mee houden dat een COM object zich in een een bepaalde gebruikerscontext bevindt met zijn specifieke rechten. Als je wilt dat een COM object alleen maar onder 1 bepaalde usercontext draait, dan is dat altijd geklooi.

Bij COM is dit natuurlijk altijd degene die hem start, maar bij DCOM en COM+ kan de applicatie beheerder en/of programmeur zelf aangeven onder welke security context het moet draaien. Ik denk niet dat dit een probleem gaat zijn. Dit in tegenstelling tot SOAP waar de standaard helemaal niets met security doet. Dit is allemaal aan de programmeur om dit te implementeren.

CORBA:
Dit vindt ik eigenlijk een prachtig principe, maar (correct me if i'm wrong) niet zo heel erg ingeburgerd. De snelheid van ontwikkelen (voor zover ik er meer ge-expirimenteerd heb) is niet zo heel erg hoog als bij (D)COM(+) icm VB en/of SOAP.

Corba is weldegelijk (bijna) even snel als COM en/of SOAP, maar het is vooral de onbekendheid die Corba tegenwerkt. Bovendien is het niet standaard bij de MS talen en is dus vrij onbekend. Bij IDE's/talen zoals Delphi, BCB en JBuilder is Corba wel standaard meegeleverd en daarmee ook een stuk toegankelijker. Corba lijkt erg sterk op COM in zijn implementatie, maar het grootste verschil is wel dat Corba beschikbaar is op vele platformen in tegenstelling tot COM.

.Net remoting vind ik nog niet terug in je lijstje. Het werkt alleen tussen .Net software, maar aangezien dat heel breed is lijkt me dit niet echt een probleem. Ook .Net remoting is zeer simpel en snel te bouwen. Net als SOAP kan het als tekst over http verstuurd worden, maar ook als binair over tcp/ip sockets wat de snelheid dan weer tengoede komt.

Ook J2EE zie ik niet terug, terwijl deze erg toegespitst is op dit gebied. Let wel dat dit niet een simpele RMI is, maar echte middel-ware architectuur vergelijkbaar met COM+ en Corba.

Soap mist te veel (standaard) mogelijkheden, IMHO, om echt vergelijkbaar te zijn met COM+, Corba en J2EE middle-ware. Voor 'simpele' remoting is het wel bruikbaar en zit dan in de buurt van de overige hier opgenoemde methoden.

[Verwijderd]

Wortelpudding schreef op 24 February 2003 @ 09:20:
SOAP is iig een goed protocol voor open services. Zeker als je het combineert met WSDL dan heb je een zeer open interface die je beschikbaar kunt stellen aan 3rd parties. Dit is de manier waarop we SOAP gebruiken, en eigenlijk ook de meest logische manier. Je hoeft van SOAP alleen niet te verwachten dat het een high-performance protocol is (vanwege die XML overhead dus). Het lijkt mij dan ook eigenlijk dat SOAP voor business objects voor een database op zich een mooi principe is (vanwege de toegankelijkheid, een SOAP client heb je mbv MS SOAP Toolkit echt binnen 1 minuut gebouwd), maar de uitwerking is imo misschien toch te traag.

...

Zijn er betere (meer doorontwikkelde) protocollen/api's voor het remote beschikbaar stellen van objecten (business objects) die net zo'n toegankelijke interface hebben als SOAP? Het zou dus ook mooi zijn als een API goed samen kan met VB en collections. Ik vind collections nl ideaal voor het beschikbaar stellen van een recordset (of zijn daar ook nog andere suggesties voor ).

...

Er is naar mijn mening nog een punt om naar te kijken -- security. Is er een degelijke methode om SOAP berichten te beveiligen?
Via TCP is natuurlijk een secure (SSL/SSH) verbinding een optie, maar hoe zit het dan op een "normaal" LAN dat bijvoorbeeld via IPX/SPX loopt. (SOAP kan ook over dit protocol heen gezonden worden)

Hoewel ik nog geen ervaring met 3-tier ongevingen heb (behalve dan de theorie van de HTS), lijkt het mij een goede optie om gebruik te maken van VPN i.c.m. DCOM/RPC. Binaire dataoverdracht verviervoudigt de transfersnelheid t.o.v. ASCII (of UNICODE) SOAP, en met VPN is security niet meer een hekel punt.

Visual Basic i.c.m. DCOM levert goede mogelijkheden voor het serializen van complexe datatypen, zelfs arrays van die typen. Dit is in SOAP nogal een crime (understatement).

Hopelijk leveren de antwoorden op dit bericht mij wat meer overzicht in de mogelijkheden!

Gr.

Korque

[LordLarry]

Verwijderd schreef op 24 February 2003 @ 11:02:
Visual Basic i.c.m. DCOM levert goede mogelijkheden voor het serializen van complexe datatypen, zelfs arrays van die typen. Dit is in SOAP nogal een crime (understatement).

Het Soap protocol zelf heeft er absolut geen problemen mee IMHO. Misschien wel de implementaties ervan aan de server en/of client kant.

[Wortelpudding]

Verwijderd schreef op 24 February 2003 @ 11:02:
...
Hoewel ik nog geen ervaring met 3-tier ongevingen heb (behalve dan de theorie van de HTS), lijkt het mij een goede optie om gebruik te maken van VPN i.c.m. DCOM/RPC. Binaire dataoverdracht verviervoudigt de transfersnelheid t.o.v. ASCII (of UNICODE) SOAP, en met VPN is security niet meer een hekel punt.
...

VPN is meer bedoeld om een client op het internet op een secure manier toegang te verschaffen tot je interne netwerk. Als je secure wilt communiceren over TCP/IP dan kun je beter gebruik maken van SSL.

LordLarry schreef op 24 February 2003 @ 10:58:Bij COM is dit natuurlijk altijd degene die hem start, maar bij DCOM en COM+ kan de applicatie beheerder en/of programmeur zelf aangeven onder welke security context het moet draaien. Ik denk niet dat dit een probleem gaat zijn.

Het grote nadeel van dat security gedoe met (D)COM(+) is dat de applicatiebeheerder het dus allemaal moet configureren op systeemniveau. Dit vindt ik echt een groot nadeel, vooral omdat wij de configuratie van onze applicaties allemaal via web-based interfaces doen vanwege het feit dat de servers waar onze software op draait altijd in lawaaiige server ruimtes staan. Je hebt daar natuurlijk VNC enzo voor, maar wij willen zoveel mogelijk de configuratie van onze systemen via 1 interface doen.

Als ik dit lees over J2EE, dan krijg ik sterk de indruk dat het alleen maar gericht is op web-based clients of standalone java applicaties. Ik ben meer op zoek naar een techniek die vanuit elke programmeertaal/ontwikkelomgeving te gebruiken is.

Als ik om me heen naar .NET ervaringen vraag, dan is de algemene indruk dat .NET niet waarmaakt wat het belooft. Vooral de performance speelt hierbij een grote rol. .NET heeft het grote voordeel dat het erg RAD is, je hebt echt in een vloek en een zucht een webservice gebouwd.

Als je met Corba snel en eenvoudig business objects kunt bouwen zou dat op zich best een goede optie zijn. Ik ben alleen benieuwd of je met Corba ook in staat bent om recordsets op de een of andere manier terug te geven.

Citaat uit de MS SOAP Toolkit 3 handleiding:
The Simple Object Access Protocol (SOAP) standard does not define security, leaving it for the transport layer to handle. The transport layer for the Microsoft® SOAP Toolkit 3.0 is HTTP. SOAP applications using HTTP are web applications like any other ASP or ISAPI application running on Microsoft Internet Information Services (IIS). Therefore, the mechanisms used in web applications for authentication, authorization, and encryption also apply to SOAP applications. If you are familiar with web security in general, then you already know about implementing security in SOAP applications.
Het is dus wel degelijk mogelijk om met SOAP op een secure manier te communiceren, maar zoals gezegd is SOAP eigenlijk niet echt een optie als je business objects wilt 'remoten'.

[Wortelpudding]

LordLarry schreef op 24 February 2003 @ 11:25:
Het Soap protocol zelf heeft er absolut geen problemen mee IMHO. Misschien wel de implementaties ervan aan de server en/of client kant.

Helemaal mee eens, maar het probleem van SOAP ligt nou juist ook bij de implementaties. Iedereen die wel eens gekeken heeft naar compatibiliteitsmatrixen tussen de verschillende SOAP implementaties kan daarover meepraten.
Je kunt je met de huidige SOAP implementaties maar beter beperken tot het bouwen van simpele services die je voor 3rd parties beschikbaar wilt stellen, maar zodra je wilt gaan werken met complexe datatypes en arrays dan wordt het een ander verhaal. Dit heeft dus niet zozeer met het SOAP protocol op zich te maken, maar met de toolkits.

[LordLarry]

Het grote nadeel van dat security gedoe met (D)COM(+) is dat de applicatiebeheerder het dus allemaal moet configureren op systeemniveau. Dit vindt ik echt een groot nadeel, vooral omdat wij de configuratie van onze applicaties allemaal via web-based interfaces doen vanwege het feit dat de servers waar onze software op draait altijd in lawaaiige server ruimtes staan. Je hebt daar natuurlijk VNC enzo voor, maar wij willen zoveel mogelijk de configuratie van onze systemen via 1 interface doen.

Nee, je kan de secutiry ook intern regelen als je dat wilt en ook via een API de security in laten stellen door andere partijen. Bovendien is COM+ heel goed in te stellen van afstand. Gewoon via Computer Management.

Als je met Corba snel en eenvoudig business objects kunt bouwen zou dat op zich best een goede optie zijn. Ik ben alleen benieuwd of je met Corba ook in staat bent om recordsets op de een of andere manier terug te geven.

Dit is geen specifieke vraag voor Corba, maar geldt voor alle genoemde methoden. Dat is aan de ontwikkelaar om daar voor te zorgen en er zijn mogelijkheden genoeg.

[i]Citaat uit de MS SOAP Toolkit 3 handleiding:
Het is dus wel degelijk mogelijk om met SOAP op een secure manier te communiceren, maar zoals gezegd is SOAP eigenlijk niet echt een optie als je business objects wilt 'remoten'.

Mogelijkheden genoeg, maar helaas geen standaarden en dus geen garantie dat iemand anders er wat mee zou kunnen. Je zal specifieke CGI en/of ISAPI interfaces moeten aanspreken om de callerid te achterhalen, omdat dit geen taak is van SOAP. Bovendien staat SOAP boven het transport protocol en hoeft het dus niet altijd via HTTP te gaan.

[Wortelpudding]

LordLarry schreef op 25 February 2003 @ 09:32:
Nee, je kan de secutiry ook intern regelen als je dat wilt en ook via een API de security in laten stellen door andere partijen.

Ik heb hier al eens mee geprobeerd te werken, maar dat was zo'n gedoe, dat ik daar uiteindelijk weer vanaf gestapt ben, en overgestapt op 'good old' RPC .

[Wortelpudding]

Nog suggesties?
Ik zou graag willen weten of er meer mensen met RemObjects werken en wat de voor- en nadelen zijn.