Global activation model bij .NET webservices

[Verwijderd]

Beste mensen,

Borland Delphi geeft bij het maken van een SOAP server de mogelijkheid het zgn activation model te kiezen: global of per request. Global komt erop neer dat de class van de webservice eenmalig gemaakt wordt en dat verschillende requests dus bij één en dezelfde class uitkomen. Per request is dat, zoals de naam zegt, bij elke request een nieuwe instantie van de class gemaakt wordt.

Nu ben ik al enige tijd bezig met het ontwikkelen van een webservice in ASP.NET. Ik heb helaas nog niet de mogelijkheid gevonden om het activation model te veranderen (standaard is per request). Is het uberhaupt mogelijk? Wellicht niet omdat de garbage collector je class op zou ruimen (de GC weet immers niet of er nog requests komen)? In dat geval graag een bevestiging...

[MTWZZ]

Het kan wel maar dan moet je er eerst even eea lezen over Remoting en activation.
Zie bijvoorbeeld hier. Verder zijn dingen als Lifetime, Leases en Singletons handige zoektermen.

Google weet er ook een hoop over evenals MSDN natuurlijk.

Suc6

[Verwijderd]

Naast de link die MTWZZ gaf, staat hier een heel aardig hands-on praktijkvoorbeeld wat me aardig op de goede weg heeft geholpen: Sending a DataSet across the Wire using .NET Remoting.
't Hoeven natuurlijk geen datasets te zijn, maar wat je anders als [WebMethod] zou aanbieden kan via remoting ook goed.
Maar ik ben er zelf ook nog mee aan 't experimenteren, en loop wel tegen wat probleempjes aan. De WSDL van een remoting server over SOAP wijkt bv. af van die van een ASP.NET webservice, niet dramatisch, maar genoeg dat klanten die tegen die server aan moeten babbelen zenuwachtig kunnen worden. Request en Response heten opeens Input en Output, dat soort dingen.

[whoami]

Hmm, in .NET remoting heb je idd de mogelijkheid om een remoted object als 'Singleton' of 'Singlecall' te configureren (bij jou heet dat dus blijkbaar 'Global' en 'Per Request'). Dit kan je oa doen in de configuratie file waar je je remoted objecten definieert (als je mbhv een config file werkt).

Echter, ik dacht niet dat dit mogelijk was bij WebServices ?

[Verwijderd]

whoami schreef op maandag 28 augustus 2006 @ 20:41:
Echter, ik dacht niet dat dit mogelijk was bij WebServices ?

Bij WebServices is 't prima mogelijk, maar bij ASP.NET WebServices heb ik die mogelijkheid ook nog niet gevonden...
Bij .NET remoting over HTTP gebruik je uiteindelijk gewoon SOAP, met een duidelijke WSDL, en dan heb je in feite ook over een WebService. Alleen wijkt 't op punten nogal af van de standaard definitie van WebServices (vooral naming conventions). Je hebt niet perse een .NET remoting-aware client nodig om met een remoting server te kletsen, met de WSDL kan dat ook gewoon op de "ouderwetse" manier. Alleen is 't wel een stuk meer werk.

Maar wanneer je voordeel hebt bij de mogelijkheden van een Singleton benadering (vooral het niet bij iedere instance op hoeven halen van een uitgebreide objectstructuur) is 't de moeite van het bekijken waard.
Al vermoed ik wel dat ik in mijn geval uit zal komen op een remoting server waar een gewone WebService mee zal praten, maar dan binary over TCP. Al hoop ik nog steeds dat die extra laag niet nodig zal zijn.

(Was 't in m'n Delphi/Win32 services ook niet, want daar was de WebService meteen ook de HTTP server, en die kon van alles aan data cachen en persisten.)

[Verwijderd]

Bedankt voor jullie reacties. Om mogelijke verwarring te voorkomen: ik ben deze webservice aan het ontwikkelen in Visual Studio 2005, dus met .NET 2.0 (en dus niet in Delphi). Ik noemde dus Borland's termen (global / per request) aangezien ik de .NET termen niet wist

Als ik het goed begrijp komt het neer op een applicatie die voortdurend draait (want dat is een Remoting server toch?) en dus ook als zodanig geinstalleerd moet worden. Met de nodige voor- en nadelen uiteraard... Voordeel is volledige controle over de applicatie (een console applicatie kan ook een .NET Remoting server zijn), een nadeel is de deployment (een shared hosting provider zit niet te wachten op je setups).

Bij .NET Remoting kun je inderdaad (naast de binary formatter) de SOAP formatter kiezen. Ik neem aan dat deze wel een strikt WSDL formaat geeft (of wordt er geen WSDL gegenereerd en moet je dit zelf doen)? Dat er intern aan de server zijde aangepaste naming conventions zijn is geen punt, wel als deze doorgevoerd worden in de WSDL. Het is namelijk de bedoeling dat een Win32 applicatie (geschreven in Delphi 2006) probleemloos gaat communiceren met de .NET Remoting server.

Dan even over veiligheid. Ik begrijp dat een ASP.NET webservice niet als singleton kan fungeren. Neemt dit meteen het gebruik van SSL certificaten weg? Met andere woorden: is .NET Remoting met een SOAP formatter over HTTP of over TCP? Ik heb de volgende informatie gevonden welke mij niet veel verder helpt:

Security
.NET remoting plumbing does not provide out of the box support for securing cross-process invocations. However a .NET remoting object hosted in IIS, can leverage all the same security features provided by IIS. If you are using the TCP channel or the HTTP channel hosted in a container other than IIS, you have to implement authentication, authorization and privacy mechanisms yourself.

Since ASP.NET Web services are hosted, by default, in IIS, they benefit from all the security features of IIS such as support for secure communication over the wire using SSL, authentication and authorization services.

[whoami]

Verwijderd schreef op dinsdag 29 augustus 2006 @ 00:14:

Als ik het goed begrijp komt het neer op een applicatie die voortdurend draait (want dat is een Remoting server toch?) en dus ook als zodanig geinstalleerd moet worden. Met de nodige voor- en nadelen uiteraard... Voordeel is volledige controle over de applicatie (een console applicatie kan ook een .NET Remoting server zijn), een nadeel is de deployment (een shared hosting provider zit niet te wachten op je setups).

Je kan een .NET remoted object ook in IIS hosten; dan hoef je geen custom applicatie te ontwikkelen die dat object voor jou host.
Gewoon een virtual directory maken, een bin subdirectory in die VD plaatsen, je assembly in de bin plaatsen, de virtual directory als 'application' configureren in IIS, en een web.config file in de virtual directory plaatsen waarin je je remoting stuff configureert.

Dan even over veiligheid. Ik begrijp dat een ASP.NET webservice niet als singleton kan fungeren. Neemt dit meteen het gebruik van SSL certificaten weg? Met andere woorden: is .NET Remoting met een SOAP formatter over HTTP of over TCP? Ik heb de volgende informatie gevonden welke mij niet veel verder helpt:

De formatter staat los van de channel die je gebruikt. Je kan maw perfect een binary formatter gebruiken over een HTTP channel. (Wat ik atm ook doe).

[MTWZZ]

Verwijderd schreef op dinsdag 29 augustus 2006 @ 00:14:Als ik het goed begrijp komt het neer op een applicatie die voortdurend draait (want dat is een Remoting server toch?) en dus ook als zodanig geinstalleerd moet worden. Met de nodige voor- en nadelen uiteraard... Voordeel is volledige controle over de applicatie (een console applicatie kan ook een .NET Remoting server zijn), een nadeel is de deployment (een shared hosting provider zit niet te wachten op je setups).

Remoting componenten kun je als het goed is ook direct in IIS hosten: click (MSDN) en click (O'Reilly)

[whoami]

MTWZZ schreef op dinsdag 29 augustus 2006 @ 09:12:
[...]

Remoting componenten kun je als het goed is ook direct in IIS hosten: click (MSDN) en click (O'Reilly)

whoami schreef op dinsdag 29 augustus 2006 @ 09:05:
[...]
Je kan een .NET remoted object ook in IIS hosten; dan hoef je geen custom applicatie te ontwikkelen die dat object voor jou host.

[MTWZZ]

whoami schreef op dinsdag 29 augustus 2006 @ 10:31:[...]

Doh

[Verwijderd]

whoami schreef op dinsdag 29 augustus 2006 @ 09:05:
[...]
Je kan een .NET remoted object ook in IIS hosten; dan hoef je geen custom applicatie te ontwikkelen die dat object voor jou host.

Gaat dat ook goed wanneer 't een Singleton remoted object is? Ik zal 't morgen 's proberen, maar mijn gevoel zegt me dat dat een beetje indruist tegen de manier waarop IIS met .NET assemblies omgaat.

[whoami]

Waarom zou het niet goed gaan als het een Singleton remoted object is ?
@work heb ik een aantal remoted objects die gehost worden door IIS (een stuk of 14 denk ik), en ééntje daarvan is een Singleton, de rest zijn allemaal single-call.

[ Voor 53% gewijzigd door whoami op 29-08-2006 22:23 ]