Standards are discussed in this book elsewhere, but it bears discussing here too. Here is how standards-based development works:

Realistically, regardless of certification, only when a large number of companies implement a standard does it actually become a genuine standard. Many so-called "Web" browsers over the years supported "standard" protocols like VRML and such that never made it.

It's true, folks. The Internet superhighway is littered with the broken documents of dead standards.

The WS-* (usually pronounced WS-star, referring to the wildcard * character that references all standards that begin with WS) standards fit right in here. These are Web service standards that apply to protocols like SOAP. They are written by a standards organization, reviewed, certified, and have been used.

What is better is that the additional standards include a lot of really neat functionality that makes SOAP a very rich development experience. Usually, distributed communication standards leave transactions, security, and other such functionality up to the developer.

SOAP isn't like that. It is supposed to have all that stuff baked in.

The WS-* standards include all this useful functionality:

In general, these are fantastic additions. They define a set of functionality that all Web service development software providers — Microsoft, IBM, Sun, open source initiatives, whomever — can implement. If you need transactions, they are there. Security? Baked in.

The problem is that these standards were used differently by every company that implemented them.

No, I am not kidding. The problem with standards this detailed in scope is that in order to be useful they must either leave a lot to the imagination or define everything. OASIS erred on the side of being too loose, and the implementations are a mess.

If you are working inside the Microsoft stack — meaning, you are communicating with other .NET projects — you are golden. Within the Microsoft platform, everything is defined the same.

However, if you are communicating outside the .NET Framework — say with IBM or Sun — you should expect problems if you are using WS-* defined functionality.

The take-home is that SOAP includes a lot of standard functionality that isn't found anywhere else. Sure, some distributed message contracts have a lot of features found in SOAP, and SOAP might not be completely implemented the same everywhere, but there isn't anything else that even tries to provide this functionality in a standardized way.

From this perspective, SOAP is a fantastic platform. Need transactions, especially secure transactions? SOAP has them. Need large binary attachments? SOAP has that. Have BPEL requirements? There's a SOAP for that.

All this eating at the trough of standardized features has made SOAP, well, a little large-boned. Let me give you an example. The XML required just to set the context for transactions (the service equivalent of a cookie) is:

<wscoor:CoordinationContext
             xmlns:wsa="http://www.w3.org/2005/08/addressing"
             xmlns:wscoor="http://docs.oasis-open.org/
                               ws-tx/wscoor/2006/06"
             xmlns:myApp="http://www.example.com/myApp"
             S11:mustUnderstand="true">
             <wscoor:Identifier>
                  http://Fabrikam123.com/SS/1234
             </wscoor:Identifier>
             <wscoor:Expires>3000</wscoor:Expires>
             <wscoor:CoordinationType>
                http://docs.oasis-open.org/ws-tx/wsat/2006/06
             </wscoor:CoordinationType>
             <wscoor:RegistrationService>
                 <wsa:Address>
                  http://Business456.com/
                             mycoordinationservice/
    registration
                  </wsa:Address>
                  <wsa:ReferenceParameters>
                     <myApp:BetaMark> ... </myApp:BetaMark>

<myApp:EBDCode> ... </myApp:EBDCode>
            </wsa:ReferenceParameters>
        </wscoor:RegistrationService>
        <myApp:IsolationLevel>
              RepeatableRead
        </myApp:IsolationLevel>
    </wscoor:CoordinationContext>

In the Java world, 10MB SOAP messages are not uncommon — although that includes the payload — and that works out to what, 200,000 lines? In one HTTP call? That's probably a bit much.

SOAP dramatically increases your overhead in communication. If you don't need the security, federation, and transaction capabilities of SOAP, consider ReST — covered in Chapter 4. If you are communicating in a homogenous Microsoft environment, consider binary encoding.

On the other hand, if you are communicating in moderately heterogeneous environments and do in fact need an encrypted, federated transaction using a common enterprise data model, by all means look at SOAP.

ASMX Web services are ASP.NET projects. As such, they seem a lot like ASP. NET Web applications — because they are ASP.NET Web applications. You can actually put an ASMX file in a regular ASP.NET application, and a Web file in a Web service application like we do in the following step list. The template is just there to help you get started.

This process generates a project that has all the right references for a Web service project in ASMX and gives you a sample file to start with.

Analyzing the file setup

Note that although a Service1.asmx file (and the usual code-behind file) is created, the markup file has only one line in it:

<%@ WebService Language="C#" CodeBehind="Service1.asmx.cs"
    Class="ANewService.Service1" %>

This is by design. Nothing goes in the markup file. All the magic is in the code-behind.

Figure 2-1. Make a new Web service.

1 using System;
2 using System.Collections.Generic;
3 using System.Linq;
4 using System.Web;
5 using System.Web.Services; 6
6
7 namespace ANewService
8 {
9     /// <summary>
10    /// Summary description for Service1
11    /// </summary>
12    [WebService(Namespace = "http://tempuri.org/")]
13    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
14    [System.ComponentModel.ToolboxItem(false)]
15    // To allow this Web Service to be called from script, using ASP.NET AJAX,
   uncomment the following line.
16   // [System.Web.Script.Services.ScriptService]
17   public class Service1 : System.Web.Services.WebService
18   {
19
20      [WebMethod]
21        public string HelloWorld()
22        {
23            return "Hello World";
24        }
25    }
26 }

Running the service

Press F5 and run the service. If all goes well, you should see something like Figure 2-2. This is the default visualization for a service — remember that you didn't make a user interface; IIS did this for you, to make it easier to test. External users can't see this.

Clicking the Service Description gives you the WDSL for the whole service. This is what a non-.NET application needs to build its proxy. Note that all it does is append a ?WSDL to the end of the URL.

Clicking the Hello World link gives you a test screen and implementation guidance for the method. You will have one of these links for every one of the methods in the class marked with WebMethod.

Figure 2-2. Running the default service.

First you need to get set up. Here's what you need to do to start using the Web template:

Figure 2-3. Adding the Sharp tables to the model.

That's how you set up an ASMX Web service project. You have a data source, an entity model (you could use your organization's domain model, or hand-rolled procedures and ADO.NET, or whatever), and a starting point for the service.

The deciding factor is reuse. If you will later need to roll exactly this logic into a standalone application (anything that won't use the services), then make a separate BL. For simplicity, we will do the former.

So what about all that other stuff that goes into SOAP? Security, transactions, and like that? It's all baked in, but it's well beyond the scope of this book.

For instance, check out the SoapHeader attribute. It allows you to specify even the most complex security attributes on your Web methods. There's more, too. Check out MSDN.

Deploying an XML Web Service is just like deploying a Web application. They are effectively the same thing.

One benefit of ASMX over WCF is the simple configuration. In fact, if you check out the configuration file for the application you built here, you'll see that the only configuration information revolves around the Entity Model. Adding an ASMX service to a Web project is easy.

Figure 2-4. Results of our service.

Figure 2-5. Can't run test scripts in production!

Consuming an ASMX service works just like consuming any other service, from any provider. To see what I mean, follow these steps.

Visual Studio does a ton of work for you here. There is no magic — Visual Studio reads the WSDL of the service referenced and builds a proxy just as though it were a service written in C++ or Java.

Figure 2-6. Adding a service reference.

As such, the objects returned to you will be more along the lines of a service than what you would expect in C#, especially as delivered by ASMX. The code in the console application to consume your now-proxied service looks like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            SharpReference.RegistrationSoapClient serviceReference = new
    SharpReference.RegistrationSoapClient();
            SharpReference.Conference[] conferences = serviceReference.
    conferencesAtLocation(3);
            Console.WriteLine("There will be {0} conferences at location number
    3.", conferences.Length)
            Console.ReadKey();
        }
    }
}

Notice that the conferencesAtLocation method now returns an array rather than a List<Conference>. The consuming language doesn't have to have generics, but it does have to have arrays (if it conforms to WS-I). That's the only assumption we can make. (See Figure 2-7.)

Right-click on the console application and press F5. The console application should start, and it should find the two rows in the array just as it would in the list.

Figure 2-7. Running the consumed service.