Skip to main content

WebServices

Webservices are exposed methods which can be accessed through a uri e.g.your code is contained in a .asmx file.
The .asmx file contains webmethods (ordinary methods with the [WebMethod] attribute). You place your .asmx file inside your webserver somewhere and these can be consumed directly by browsing to the uri or by consuming the webservice by adding it as a reference to your application and then accessing that reference. Webservices can also be created with Codebehind meaning the code itself is in another file, this results in the .asmx file just containing a Directive to the class name containing the webmethod, to use this webservice the codebehind dll must be placed within the websites bin directory.

The WebService works by the Client and Server sending SOAP XML (SOAP is just the root element, it's something that Internet Explorer knows how to parse) up and down over HTTP. Both sides need to know how to create this SOAP XML, on the Client side this is done by a Proxy class which Serializes/De-Serializes the SOAP XML into objects.

Proxy Class

Client side class, usually called Reference.cs, which Serializes/De-Serializes the SOAP XML into objects. This lives on the Client side (in .NET) e.g. if the client is an .NET Console application then in order to gain access to the methods available on a website the application will need a Proxy class (this is created for you by VS.NET when you add a Web Reference which points to the Webservice on the website i.e. http:..........).
If you want to use Webservices from a Client such as an ASPX form then you again need to add the Web Reference but a Proxy class is not generated, instead because your making calls on the same web application you can call into the WebService class directly like a normal class.
If your calling a WebService from on Web app to another then it's the same as a Console app, you'' have to use a Proxy class, again this is generated for you in the calling website by VS.NET when you add the Web Reference.

Hiding the asmx

I have not actually found a way to get rid of the .asmx file completely. You can hide the webservice endpoints functionality in an assembly and create a handler for it as described below but to implement the webservice you will always need a .asmx file somewhere. Even the Proxy Class uses the .asmx file. In order to implement a remote call to a method inside your own code I think the only solution is .NET Remoting.


An Extensive Examination of WebServices (4guysfromrolla thorough).
Creating a .NET Web Service (15seconds goood)
ASP.NET Web Services Techniques (Very thorough explanation of how WebServices work)
Writing a raw Web Service using HttpHandler
Labels:

Comments

Post a Comment

Popular posts from this blog

dotNET - Debugging

Debugging with .NET MSIL assemblies Visual Studio and debugging the CLR are different, I'll talk about both. MSIL Assemblies Assemblies compiled with .NET tools such as the CLR compiler are compiled into a file which contains MSIL (Microsoft Intermediate Language). At runtime the contents of the assembly are loaded into the CLR and ran as machine code. When you compile an assembly in debug a PDB file is generated alongside the DLL or EXE you've just created. The link between these 2 files is that the PDB contains the line numbers of the methods and classes as well as the file names of the original source code that created the assembly. When you launch the debugger in Visual Studio the assembly is loaded into the Debugger (similar to the CLR) along with the PDB file. The debugger now uses your PDB file contents to match the running code found in the assembly to locations in source files (hopefully in your present project). CLR CLR Inside Out (msdn magazine) .NET Framework Tools:...
7 comments
Read more

Installer CustomAction, Debugging the CustomAction, InstallState

Custom Action The Custom Action is added to the Setup Project, select the Project node and hit the Custom Action button. This allows you add an Action to a particular phase in the Installation. But first you must create the Custom Action. To Add a Custom Action you must first have a Custom Action created, this is usually in the form of a Installer Class, this should be created in a seperate project, the Installer Class is actually one of the File Templates in the C# Projects. So it's File->New Project and select Visual C# Projects. Then add a Class Library, this will prompt you for the Class Library Types , select "Installer Class". Walkthrough - Creating Custom Action (msdn). Also here's a more comprehensive document on Setup/Installer implementations, it delves into the Registry etc Getting Started with Setup Projects (SimpleTalk). Visual Studio Setup Projects and Custom Actions (Simple Talk). Create your Installer Class and then add it as a Custom Action to the ...
3 comments
Read more

dotNET - Use app.config ApplicationSettings and UserSettings

When using Settings in an Assembly or .exe you can use the Settings Designer to generate a config file using Settings. The Settings Designer provides a wrapper class which allows you to provide defaults and access the config data using Properties. But what if you're not working inside that Assembly or .exe? this presents a problem. If your loading the Assembly externally and want to access that Assembly's .config file you'll probably wish to use something in the System.Configuration namespace... unfortunately it's not of much use if you've created the .config file from the Settings Designer in Visual Studio!! This is because the Designer creates Sections and ApplicationSettings and UserSettings, the System.Configuration namespace does not provide a method to access these (it has a method to access AppSettings which are a different thing. Below I've written a workaround which locates the app.config and accesses the ApplicationSettings and UserSettings using XML i...
8 comments
Read more