Types of web services

'BIG' web services
Big web services use XML messages that follow the Simple Object Access Protocol (SOAP) standard, an XML language defining a message architecture and message formats. Such systems often contain a machine-readable description of the operations offered by the service, written in the Web Services Description Language (WSDL), an XML language for defining interfaces syntactically.
A SOAP-based design must include the following elements:
- A formal contract must be established to describe the interface that the web service offers. WSDL can be used to describe the details of the contract, which may include messages, operations, bindings, and the location of the web service. You may also process SOAP messages in a JAX-WS service without publishing a WSDL.
- The architecture must address complex nonfunctional requirements. Many web service specifications address such requirements and establish a common vocabulary for them. Examples include transactions, security, addressing, trust, coordination, and so on.
- The architecture needs to handle asynchronous processing and invocation. In such cases, the infrastructure provided by standards, such as Web Services Reliable Messaging (WSRM), and APIs, such as JAX-WS, with their client-side asynchronous invocation support, can be leveraged out of the box.

RESTful web services
RESTful = Representational State Transfer web services. REST is well suited for basic, ad hoc integration scenarios. RESTful web services, often better integrated with HTTP than SOAP-based services are, do not require XML messages or WSDL service‚ÄďAPI definitions. RESTful web services are based on HTTP protocol and its methods mainly PUT, GET, POST, and DELETE.
A RESTful design may be appropriate when the following conditions are met:
- The web services are completely stateless. A good test is to consider whether the interaction can survive a restart of the server.
- A caching infrastructure can be leveraged for performance. If the data that the web service returns is not dynamically generated and can be cached, the caching infrastructure that web servers and other intermediaries inherently provide can be leveraged to improve performance. However, the developer must take care because such caches are limited to the HTTP GET method for most servers.
- The service producer and service consumer have a mutual understanding of the context and content being passed along. Because there is no formal way to describe the web services interface, both parties must agree out of band on the schemas that describe the data being exchanged and on ways to process it meaningfully. In the real world, most commercial applications that expose services as RESTful implementations also distribute so-called value-added toolkits that describe the interfaces to developers in popular programming languages.
- Bandwidth is particularly important and needs to be limited. REST is particularly useful for limited-profile devices, such as PDAs and mobile phones, for which the overhead of headers and additional layers of SOAP elements on the XML payload must be restricted.
- Web service delivery or aggregation into existing web sites can be enabled easily with a RESTful style. Developers can use such technologies as JAX-RS and Asynchronous JavaScript with XML (AJAX) and such toolkits as Direct Web Remoting (DWR) to consume the services in their web applications. Rather than starting from scratch, services can be exposed with XML and consumed by HTML pages without significantly refactoring the existing web site architecture. Existing developers will be more productive because they are adding to something they are already familiar with rather than having to start from scratch with new technology.

ASP.NET web service
These are .NET 'big' web services.
They will be generated as .asmx files.
ASP.NET will automatically create a WSDL and SOAP request.
It will also provide a HTTP POST entry.

WCF web service

ASP.NET Webservices

Coding a webservice

Referencing a webservice

Insert a reference to the webservice:
Rightclick on References, choose Add Web Reference
If Add Web Reference is not available, choose Add Service Reference, click on Advanced and click then on Add Web Reference.
This will also insert an item in your settings with a link to the web service.
You can give the webservice a name. This name is used to call the webservice.

Necessary References:

using (ServiceName.ServiceClient client = new ServiceClient())

Error 'Client found response type of '…'…

Check the password used in the webservice.

XML namespace

By default, the XML namespace in the service definition file, will contain the name of the development computer.
This can be dangerous when a different computer is used later, because this namespace is used in the wsdl file of the service.
If they don't match, you will get an error:
Server did not recognize the value of HTTP Header SOAPAction

So it is best to change the XML namespace to the same as the namespace of your project. Eg.:
[WebService(Namespace = "http://aaa.bbb.ccc")]
Don't forget to update the reference afterwards in your client project!

WCF services

Referencing a WCF service.

Insert a reference to the webservice:
Rightclick on References, choose Add Service Reference.
Enter the address to the service. Enter the namespace, this will be the name to call the service. You can choose the name shown underneath 'Services'. (So it is not the current namespace!)

Web.config client


      <binding name="WSHttpBinding_ISiteDealer" closeTimeout="00:01:00"
          openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
          bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
          maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text"
          textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false">
        <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
          maxBytesPerRead="4096" maxNameTableCharCount="16384" />
        <reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false" />
        <security mode="Message">
          <transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
          <message clientCredentialType="Windows" negotiateServiceCredential="true" algorithmSuite="Default" establishSecurityContext="true" />

      <behavior name="LrcClientBehavior">
        <WindowsClientCredential allowedImpersonationLevel="Impersonation" user="xxx" password="xxx" />

    <endpoint address="http://localhost:2714/SiteDealer.svc" binding="wsHttpBinding"
        bindingConfiguration="WSHttpBinding_ISiteDealer" contract="PDK.LS.SiteDealer.ISiteDealer"
        name="WSHttpBinding_ISiteDealer" behaviorConfiguration="LrcClientBehavior" >
        <dns value="localhost" />

Web.config server

    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
      <service name="DAF.PFE.Flow.Service.FlowEngine" 
        <endpoint binding="basicHttpBinding" 
        <behavior name="DAF.PFE.Flow.Service.PfeFlowEngineBehavior">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="true" />

In the code, the class of the service needs the attribute
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
The reason for this is the authorization to the database. Check that it is also present in the config file. (In <system.serviceModel>. See example.)

The verification methods of the site need to be Anonymous Access and Integrated Windows Verification.
In the ASP.NET, the application needs Local impersonation to an account that has access to the database.


Use the WCF Test Client to test the service.
Normally VS start this automatically if you have the .svc file as Start Page.
If not, open the Visual Studio Command Prompt and type 'wcftestclient'.

Maximum message size

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License