Aaron Skonnard says I am clearly wrong with my demand that one shouldn’t have to look at WSDL/XSD/Policy. Well, at this point in time the tooling makes it indeed difficult to ignore angle brackets. But that’s not a reason to give up. I also find the “it all has to start at the angle bracket” stance overly idealistic.

I can type up an XML Schema in notepad, I can even type up a WSDL in notepad. As much as one would like to have it different, both “skills” are not so common amongst the developer population. I would think that for the majority of ASP.NET Web Services in production today, their developers completely ignored the XSD/WSDL details. But even if that were different: The rubber hits the road when we talk about policy. Can you type up a complete and consistent set of policy assertions for integrity and confidentiality and authentication using Kerberos and vX509 tokens without looking at the spec or a cheat sheet? How about combining that with assertions for WS-AT and WS-RM? As long as we keep the story reduced to XSD and WSDL, dealing with angle brackets might something that someone could reasonably expect from a mortal programmer who has a life. One we take policy into the picture, we better start asking for tools that hide all those details. The interoperability problems of getting secure, reliable and transacted web service work together are far harder than just getting services to talk. That’s part of the contract story, too. Yet, I cannot imagine that anybody would seriously demand that we all sit down and explicitly write these endless sequences of policy assertions and then feed our tools with them. At least I don’t want to do that, but that may just be me getting too old for this stuff.

Bruce Williams illustrates how to turn my very simple “Hello World” Indigo sample into a queued service by changing the transport binding from HTTP to MSMQ (I think that’s radically cool). Now, the next step is to illustrate a Duplex conversation to get the response back to the caller. If Bruce or someone else isn’t going to beat me to it, I’ll show that once I get home from Warsaw tomorrow night. [Ah, by the way: Bruce! No need to “Mr.” me ]

Tim Ewald responds (along with a few others) to my previous post about WSDL and states: ”Remember that WSDL/XSD/Policy is the contract, period. Any other view of your contract is just an illusion.”

WSDL and XSD and Policy are interoperable metadata exchange formats. That’s just about it. The metadata that’s contained in artifacts compliant with these standards can be expressed in a multitude of different ways. I do care about “my tool” (whatever that is) to do the right thing mapping from and to these metadata standards whenever required and I do care about “my tool” guiding me to stay within the limits of what these metadata formats can express.

But WSDL/XSD/Policy isn’t the contract. If you do ASMX, you can create server and client without you or any of the tools ever looking at or generating WSDL. And it works. If you use Indigo, you can do the same and, in fact, for generating any XML-based metadata from within an Indigo service, it’s even required to explicitly add the respective service behavior at present. The required metadata to make services work comes in many shapes or forms and is, for a given tool, typically richer than what you will find in the related WSDL/XSD/Policy, because not all that metadata is related to the wire format itself.

If I need to tell someone who is not using my tool of choice how to talk to my service, I have my tool generate the respective metadata exchange documents and I want to be able to trust my tool that they’re “right”.

What I am stating here is simply my demand and expectation for the degree of “automatic interoperability” that I expect from the tools. I can read WSDL/XSD/Policy; out there, most people absolutely don’t seem to care about these details and I tend to agree with them that making this stuff work is someone else’s problem.

I don’t need to be able to read and write PDF to use PDF. I use PDF if I know that someone will open my document who is not using Microsoft Word. Still, that PDF doc isn’t the document. My Word source document is the document I edit and revise. The PDF is just one of several possible representations of its contents.

I wish I was at VSLive! in San Francisco to hang out with all of my friends. Instead (and that isn’t too bad, either), I am sitting in my hotel room at the Warsaw Marriott watching the sun rise over the Polish capital. Today and the next two days, my partner Achim Oellers and myself will be teaching a class on service orientation principles, explaining fundamental ideas, patterns, techniques and will go through a lot of concrete implementation guidance for today’s Microsoft MSMQ/WSE/ASMX/ES stack so that our customers can start writing services today. The fundamental principles about data contracts, message contracts and service contracts that we teach will carry forward to Indigo – along with a lot of the implementation techniques (and the resulting source code) that we will suggest. Of course, that has been a bit of a hidden agenda in past workshops, because I couldn’t openly speak about anything that happened to Indigo past PDC03, but now that the Indigo day at VSLive! is over, I can. That makes it even more fun.

XML is ugly and angle brackets are for plumbers. Unless you have a good reason to do so, you shouldn’t have to look at WSDL. Sharing this C# snippet here

[ServiceContract]
interface IHello
{
      [OperationContract]
      string SayHello(string name);
}
is a perfectly reasonable way to share contract between server and client, if you’ll be sticking to Indigo. A service can expose all the WS-MetadataExchange and XSD and WSDL you like so that other Web Service clients can bind to your service, but as long as you stay on the System.ServiceModel level and focus on writing a distributed systems solution instead of writing something that “does XML”, you won’t have to worry about all the goo that goes on in the basement. Staring at WSDL is about as interesting as looking at the output of “midl /Oicf”.

using System;
using System.ServiceModel;

namespace IndiHello
{
      [ServiceContract]
      public class Hello
      {
            [OperationContract]
            public string SayHello(string name)
            {
                  return "Hello " + name;
            }
      }

      class Program
      {
            static void Main(string[] args)
            {
                  ServiceHost<Hello> host = new ServiceHost<Hello>(new Uri("http://localhost/hello"));
                  host.AddEndpoint(typeof(Hello), new BasicProfileHttpBinding(), "ep");
                  host.Open();
                  Console.WriteLine("Press ENTER to quit");
                  Console.ReadLine();
                  host.Close();
            }
      }
}

I am told that I can talk, so I do   Here’s a simple Indigo server. If you looked at the PDC 2003 Indigo bits, you will notice that the programming model changed quite a bit. I think that in fact, every single element of the programming model changed since then. And all for the better. The programming model is so intuitive by now that I am (almost) tempted to say “Alright, understood, next technology, please”.

So up there you have a class with an implicit service contract. An explicit service contract would be a standalone interface (that’s the proper way to do it, but I wanted to keep the first sample simple) with a [ServiceContract] attribute. Here, [ServiceContract] sits right on the class. Note that the class doesn’t derive from any special base class. Each method that you want to expose as an endpoint operation is labeled with [OperationContract]. These and a set of other attributes (along with a bunch of options you could set, but which I am not doing for the moment) control how the class contract is exposed to the outside world via Indigo.

In the Main method, you have a ServiceHost, which hosts the service (the class is parameterized with the implementation type) and which is initialized with the base-adress at which the service shall be hosted. The base address here is “http://localhost/hello” and with that maps into the namespace of http.sys at port 80. The endpoint can exist alongside any IIS-hosted websites, even though this particular app is hosted in its own little console-based app.

Into this host, I map the service contract with a BasicProfileHttpBinding() to the endpoint address “ep”, which means that messages to that particular service that flow through HTTP using the WS-I Basic Profile 1.0 shall be directed to the “http://localhost/hello/ep” endpoint. Once I have a binding in place (that could also be done in config), I Open() the service and the service listens. Once I am done listening, I Close() the service.

Isn’t too hard.

There you go:

Happy Stewardesses who like my Alienware notebook (seems to work just as well as driving a Lamborghini)

And ... chatting with Hanselman and having (economy class ... so much for Lamborghini) food