Greetings,

I'm not too sure exactly how to phrase my question, so I'll give it the best shot I can: I'd like to know how is it possible to make a web service as a component to be hosted in another application.

That is, ship a DLL that with some configuration options, could enable consumers to add the web service to their application directly.

The best example I can give of this is the ASP.NET Application services (Roles, Authentication, Profile). Since they were made compatible with non-asp.net applications via the JSON/SOAP1.1 services to enable their usage in WPF, WinForm, Silverlight, or any JSON or SOAP compliant apps, you can make a blank web application, add some web.config settings, and BANG, they can be called as a web service.

Now, the only way so far I've found was to ship a DLL with a Type with the appropriate service and web method attributes, and someone can then make an asmx or svc (WCF) file, add the line to point to the type in my assembly (instead of to code behind), and it will work...

I'm wondering if its possible to have it work without that (like the ASP.NET Application services), or if the app services only work that way because of some framework specific enhancements ("hard coded") that I cannot replicate easily in my frameworks? Basically, so a consumer could add the DLL to a web app, edit the web.config somehow, and have their app expose the service without any other operations.

Any clue?

Thanks!

I have no idea how those application services work. What URL do you use to refer to those services?

That's the real question no matter what. There has to be a URL somewhere. That URL has to refer to some endpoint, using some protocol. Something has to be listening on that endpoint, using that protocol.

Only then does that something need to call your code, which you can certainly package. But you need to also package the something as well. Once you decide on the something, you may have determined the packaging.

If I were you, I'd use WCF, and then choose a subset of the available hosting options to support. See http://msdn.microsoft.com/en-us/library/bb332338.aspx for a thorough description of the options for hosting a WCF service.

I wouldn't even bother with ASMX. It's the past.

Yeah, if I don't figure it out, making a WCF component and simply having consumer add the code-behind-less SVC file seems like the best bet (thats actually how they suggest you use the application services in Silverlight from what I saw... take a codebehind-less SVC, point it to the application services' DLL, and use that as your end point instead of the normal JSON/SOAP one... better design time experience, and WCF > plain web services).

Ok, I just looked. Its making a request to http://mymachine/Authentication_JSON_AppService.axd/Login

I'm not too familiar on how to make these kind of fake URLs, but it almost look like its simply an httphandler thats behaving like a JSON web service, probably mapped in the base web.config or something, not sure. I'd be interested to know (same behavior as with the script ressources for example)

Interesting to note: For anything beyond ASP.NET AJAX, the documentation (on MSDN) itself state that you're supposed to make a blank SVC file to "map" the service in your application... So I figure making a WCF DLL and instructing consumers to do the same is fairly standard procedures...

Ok, I found it by decompiling System.Web.Extensions with reflector. The application service that you use with ASP.NET AJAX (the one that is "magical", so to speak, as you dont need to do anything beyond enabling a web.config entry) is an HttpHandler wrapper mapped to the *_AppService.axd fake path, and then it acts like a make shift web.service. So if you want an ACTUAL service, you need to map the type to an SVC type.

Good enough for me, i just wanted to be sure that was the "real" way of doing it :)