[Mono-list] C# SOAP implementation - AXIS

[Jonathan Pryor]

Below...

On Wed, 2004-03-31 at 23:57, Mahen Perera wrote:
<snip/>
> As u have already mentioned, the existing ASP.net web services
> architecture is tightly integrated to .NET and cannot run without IIS.
> AXIS, on the other hand is an Open Souce effort and will run on the
> Apache Web server. What i am proposing is to have another SOAP
> implementation (in C#) as an add-on to MONO, which follows the AXIS
> architecture. 

As Ales Pour already mentioned, this is incorrect.  IIS is not needed. 
For example, mod_mono and xsp.exe are two separate ASP.NET hosting
environments developed by Mono.  (xsp.exe was the original test
container, useful for testing, and mod_mono is an Apache module for
hosting ASP.NET.)

> In developing AXIS C#, we hope to use the WSDL parser in
> System.Web.Services namespace and the XML Pull parser in System.Xml
> namespace (already implemented in MONO). Since we are following AXIS,
> we will have a server.wsdd file to configure the AXIS engine and
> follow similar architectural principles (such as having "handlers"
> to as a means of adding external components offline, in to the main
> AXIS message flow). Further to this, as I mentioned earlier, current
> AXIS users will find it easy to switch to the AXIS C#. 

Existing AXIS users may find this useful, but I doubt that existing
ASP.NET users would.  Just my $0.02...

> Hope this will answer your Q. 
> 
> Hoping for positive replies
> 
> Mahen
> 
> PS: I would like to know whether the support for creating and managing
> Application Domains

AppDomain support is...flaky.  You can create AppDomains, and run code
in them, but unloading them...tends to break things.  Zoltan added a
patch to ignore AppDomain.Unload() when the MONO_NO_UNLOAD environment
variable is set on March 24, so that existing code (NAnt) would continue
to function properly until the underlying AppDomain issues were
resolved.  I don't think this made it into 0.31, though.

So, until the bugs are fixed (which is until the next release, *at
least*), avoid AppDomain.Unload(). :-)

<snip/>

 - Jon