Clemens Vasters - Tuesday, September 07, 2004

Tuesday, September 07, 2004

A little while ago a new build of Indigo found its way onto my desk. On thing that’s interesting about this particular interim milestone (don’t hope for juicy details here on the blog) is that it doesn’t support WSDL. No. Calm down. It’s not what you think. It just happens that the WSDL support wasn’t included in this particular version; it’ll be there, no worries.

Such interim binary drops that the Microsoft product groups give out to very early adopters are really only meant for the bravest of the brave with too much time on their hands. Therefore, the documentation is not entirely in synch with the feature set – and that’s a stretch. (Hey, I am not complaining.) So until someone told me “yeah, there’s no WSDL or Metadata exchange worth talking about in this build” I tried to find how contract works in this build and of course I couldn’t find it. Well, not really true. It turns out that contract works just like with ASP.NET 1.0 or ASP.NET 1.1 Web Services. At runtime, WSDL usually doesn’t play any role, at all. Unless you use some funky dynamic binding logic, WSDL is just a design-time metadata container and that’s the basis for generating CLR metadata and code. Although there is an implementation aspect to it when you generate proxies or server skeletons, the most important job of WSDL.EXE is to perform a conversion of the WSDL rendering of the message contract into a format that the ASMX infrastructure can readily understand. That format happens to be classes with methods and attribute annotations. Here is a client and a server I just typed up with Notepad:

Contract.asmx

Client.cs

<% @WebService class="MyService" language="C#"%>

using System.Web.Services;
using System.Web.Services.Protocols;

[WebService(Namespace="http://tempuri.org")]
public class MyService
{
    [WebMethod]
    public string Hello( string Test )
    {
       return "Hello "+Test;
    }
}

using System;
using System.Web.Services;
using System.Web.Services.Protocols;

[WebServiceBinding(Namespace="http://tempuri.org")]
public class MyService : SoapHttpClientProtocol
{
    [SoapDocumentMethod]
    public string Hello( string Test )
    {
       return (string)Invoke("Hello", new object[]{Test})[0];
    }
}

public class MainApp
{
   static void Main()
   {
       MyService m = new MyService();
       m.Url = "http://localhost/contract.asmx";
       Console.WriteLine("Result: "+ m.Hello("Test"));
   }
}

Drop the contract.asmx into x:\inetpub\wwwroot, compile the client with “csc client.cs” and run it. No WSDL ever changed hands, no “Add Web Reference”, it just works. Ok, ok, it’s the year ‘04 now and there’s really no magic there anymore. Now here’s a tiny bit of refactoring:

Contract.asmx

Client.cs

<% @WebService class="MyService" language="C#"%>

using System.Web.Services;
using System.Web.Services.Protocols;

public interface IMyService
{
    string Hello( string Test );
}

[WebService(Namespace="http://tempuri.org")]
public class MyService : IMyService
{
    [WebMethod]
    public string Hello( string Test )
    {
       return "Hello "+Test;
    }
}

using System;
using System.Web.Services;
using System.Web.Services.Protocols;

public interface IMyService
{
    string Hello( string Test );
}

[WebServiceBinding(Namespace="http://tempuri.org")]
public class MyService : SoapHttpClientProtocol, IMyService
{
    [SoapDocumentMethod]
    public string Hello( string Test )
    {
       return (string)Invoke("Hello", new object[]{Test})[0];
    }
}

public class MainApp
{
   static void Main()
   {
       MyService m = new MyService();
       m.Url = "http://localhost:8080/contract.asmx";
       Console.WriteLine("Result: "+ m.Hello("Test"));
   }
}

Extracting the interface from server and proxy makes it very, very clear that we’re dealing with the very same message contract. Mind that we only have source-code level contract equivalence between client and server here. The compiled code on either side yields distinct IMyService types and that’s supposed to be that way. In the case I am illustrating here, the language C# serves as the metadata language (and the clipboard is the mechanism) for sharing contract between client and server (or endpoints).

There are two things I find (mildly) annoying about ASP.Net Web Services 1.x and they also become quite apparent in this example: #1 the server side and the client side have a different minimum set of required attributes and #2 ASP.NET’s ASMX support doesn’t look at inherited method-level attributes. The following does not even compile:

Contract.asmx

Client.cs

<% @WebService class="MyService" language="C#"%>

using System.Web.Services;
using System.Web.Services.Protocols;

[WebServiceBinding(Namespace="http://tempuri.org")]
[WebService(Namespace="http://tempuri.org")]
public interface IMyService
{
    [SoapDocumentMethod][WebService]
    string Hello( string Test );
}

public class MyService : IMyService
{
    public string Hello( string Test )
    {
       return "Hello "+Test;
    }
}

using System;
using System.Web.Services;
using System.Web.Services.Protocols;

[WebServiceBinding(Namespace="http://tempuri.org")]
[WebService(Namespace="http://tempuri.org")]
public interface IMyService
{
    [SoapDocumentMethod][WebService]
    string Hello( string Test );
}

public class MyService : SoapHttpClientProtocol, IMyService
{
    public string Hello( string Test )
    {
       return (string)Invoke("Hello", new object[]{Test})[0];
    }
}

public class MainApp
{
   static void Main()
   {
       MyService m = new MyService();
       m.Url = "http://localhost:8080/contract.asmx";
       Console.WriteLine("Result: "+ m.Hello("Test"));
   }
}

And, frankly, it’s probably not bad that it doesn’t compile, because the half of the attributes on the resulting interface declaration are useless on either side.

Indigo pulls both sides together into the notion of a service contract that’s good for either side (I am using a simple variant of the “publicly known” notation here)

[ServiceContract]
public interface IMyService
{
[ServiceMethod]
string Hello( string Test );
}

If you want to see it that way, this is Indigo’s IDL (Interface Definition Language). There’s an equivalence transformation from and to WSDL, if you want to share the contract with folks who program on other platforms or who use another programming language. There are just no angle brackets here and it’s much easier to read, too.

So if you see code that I wrote and you find (even today) seemingly unnecessary interface declarations that are implemented on a single web service class within a project and nowhere else and are also not referenced from anywhere – they might not be unnecessary as they seem. It’s simply IDL!

More confusingly, you might find those declarations replicated! in source code! in another service! Yes, because services are designed to be evolved independent of each other. So while the target service is already in V4, the consumer may still be on the level of V2. Moving up to the V4 interface version is a conscious choice by the developer of the service consumer – and at that point in time he/she imports the most recent contract. Whether that’s copy/paste of a C#/VB/C++ declaration or clicking “Update” on some menu in Visual Studio that turns WSDL into proxy code is not very important; it’s just a matter of tool preference.

Using explicit interface declarations with Web Services is strictly a “contract first” model. It’s just not using WSDL, that’s all.

Tuesday, September 07, 2004 4:09:18 AM (Pacific Daylight Time, UTC-07:00)

Comments [1] - Trackback
SOA

Oh, well....

I just saw this cry for help over on weblogs.asp.net and thought it'd make sense to answer with Elvis. ;-)

Tuesday, September 07, 2004 1:40:54 AM (Pacific Daylight Time, UTC-07:00)

Comments [0] - Trackback
Other Stuff

Thursday, September 02, 2004

Masked Edit Controls

I wonder when "the Americans" (sorry for making a horribly generalizing statement here) will understand that creating an edit control with a mask

(###)-###-####

is a thoroughly bad idea.

Thursday, September 02, 2004 2:36:43 PM (Pacific Daylight Time, UTC-07:00)

Comments [4] - Trackback
Other Stuff

Our place for all the Internet garbage

We set up a new blog here - primarily for our own amusement. Expect no seriousness there.

Thursday, September 02, 2004 8:35:26 AM (Pacific Daylight Time, UTC-07:00)

Comments [0] - Trackback
Other Stuff

Tuesday, August 31, 2004

A hack is a hack is a hack.

Doh! ;-)

Tuesday, August 31, 2004 12:00:38 PM (Pacific Daylight Time, UTC-07:00)

Comments [0] - Trackback

Monday, August 30, 2004

The Capital of Egypt

Ok, ok. I've said this over and over to Microsoft people over the past year and I can finally say it out loud. Ah, no, I won't. I'll just link.

Monday, August 30, 2004 2:55:28 PM (Pacific Daylight Time, UTC-07:00)

Comments [0] - Trackback
Longhorn

Clever conclusions. Not.

The Register is a really fine site. Usually. Except when Mr. All-bloggers-are-idiots has one of these "I don't get it, but I have a deadline, so I'll just make something up!" days. But I guess that's no real news.

Update: ... and corrects himself.

Monday, August 30, 2004 2:08:01 AM (Pacific Daylight Time, UTC-07:00)

Comments [0] - Trackback
Other Stuff

Blacklisting Northwest Airlines

I had the dubious pleasure to fly with Northwest to Seattle last week and for me, Northwest is now finally blacklisted. Not only do they still fly hopelessly outdated DC-10s (I am not qualified to make a judgement about the airframe, but I am qualified to make a judgement about the cabin), but I also really have a problem with the cabin crew attitude. There's nothing wrong with the cabin crew's average age being well above 50, but I do have a problem with them acting as if they're looking after a kindergarten. Point in case: "Madam, can I have a 7up please?" Answer: "Son, the galley is up there in front and you may want to stretch your legs anyways".

Monday, August 30, 2004 1:32:46 AM (Pacific Daylight Time, UTC-07:00)

Comments [3] - Trackback
Other Stuff

SECURITY ALERT: dasBlog. Download and install patch.

Security expert Dominick Baier made me aware of a security vulnerability in dasBlog at the beginning of last week. Dominick will post a concrete advisory later this week for reasons of completeness, but we want to give everyone a chance to patch their systems, because exploits are embarrassingly simple to write.

The problem affects all versions of dasBlog and allows a specially crafted cross-site scripting attack that would potentially and under certain circumstances allow an attacker to gain temporary access to the blog user’s credentials. The problem does not allow an attacker to gain any further control over the server or compromise system-level security.

The suggested workaround is to install the patch that can be found here (direct link). The patch archive contains four subdirectories (named 1.3, 1.4, 1.5, and 1.6) with replacement binaries for the newtelligence.DasBlog.Runtime.dll assembly for the respective version.

1. Back up your existing assembly from your blog’s /bin subdirectory,

2. Replace it with the new assembly for your version from the respective directory of the patch archive

3. Open and save “web.config” with notepad to restart the site

4. You are again safe.

The changes are minimal and should not have any adverse effects, but if you experience any odd behavior after applying the patch, please let me know.

Spread the word!

[The GotDotNet workspace source trees for 1.3-1.6 contain the modified sources for the respective versions. The “CurrentWork” tree is not yet patched.]

Monday, August 30, 2004 12:55:22 AM (Pacific Daylight Time, UTC-07:00)

Comments [2] - Trackback
dasBlog

Thursday, August 19, 2004

Picking the browser poison

I can't decide what I dislike more: IE6 randomly locking up or Firefox crashing on uncaught null pointer exceptions.

Thursday, August 19, 2004 4:02:52 AM (Pacific Daylight Time, UTC-07:00)

Comments [5] - Trackback
Other Stuff

Wednesday, August 18, 2004

"The PEACE service orientation tenets are not 4, they are 3+1" OR "Services vs.Web Services"

(1) Policy-negotiated behavior, (2) Explicitness of Boundaries, (3) Autonomy and (4) Contract/Schema Exchange are the proclaimed tenets of service orientation. As I am getting along with the design for the services infrastructure we're working on, I find that one of the four towers the others in importance and really doesn't really fit well with them: Autonomy.

P, E and CE say things about the edge of a service. P speaks about how a service negotiates its edge behavior, guarantees and expectations with others. E speaks about how talking to another service is and must be different from talking to anything within your own service. CE speaks about how it is possible to establish a common understanding about messages and data while allowing independent evolution of internals by not sharing programming-level type constructs.

P is about creating and using techniques for metadata exchange and metadata controlled dynamic configuration of service-edges, E is about creating and using techniques for shaping service-edge communication paths and tools in a way that services don't get into each others underwear, and CE is about techniques for defining, exchanging, and implementing the flow of data across service-edges so that services can deal with each other's "stuff".

P, E and CE are guiding tenets for "Web Services" and the stack that evolves around SOAP. These are about "edge stuff". Proper tooling around SOAP, WSDL, XML Schema, WS-Policy (think ASMX, WSE, Axis, or Indigo) makes or will make it relatively easy for any programmer to do "the right thing" about these tenets.

Autonomy, on the other hand, is rather independent from the edge of a service. It describes a fundamental approach to architecture. An "autonomous digital entity" is "alive", makes independent decisions, hides its internals, and is in full control of the data it owns. An autonomous digital entity is not fully dependent on stuff happening on its edge or on inbound commands or requests. Instead, an autonomous service may routinely wake up from a self-chosen cryostasis and check whether certain data items that it is taking care of are becoming due for some actions, or it may decide that it is time to switch on the lights and lower the windows blinds to fends off burglars while its owner is on vacation.

Autonomy is actually quite difficult to (teach and) achieve and much more a matter of discipline than a matter of tooling. If you have two "Web services" that sit on top of the very same data store and frequently touch what's supposed to be each others private (data) parts, each of them may very well fulfill the P, E, CE tenets, but they are not autonomous. If you try to scale out and host such a pair or group of Web services in separate locations and on top of separate stores, you end up with a very complicated Siamese-twins-separation surgery.

That gets me to very clearly separate the two stories: Web Services <> Services.

A service is an autonomous digital entity that may or may not accept commands, inquiries (and data) from the outside world. If it chooses to accept such input, it can choose to do so through one or more web service edges that fulfill the P,E,CE tenets and/or may choose to accept totally different forms of input. If it communicates with the outside world from within, it may or may choose to do so via web services. A service is a program.

A web service is an implementation of a set of edge definitions (policies and contracts and channels) that fronts a service and allows services to communicate with each other. Two services may choose to communicate using multiple web services, if they wish to do so. A web service is a communication tool.

With that, I'll cite myself from three paragraphs earlier: If you have two "Web services" that sit on top of the very same data store [...] they are not autonomous. If you try to scale out [...] you end up with a very complicated Siamese-twins-separation surgery." ... and correct myself: If you have two "Web services", they don't sit on the data store, they front a service. The service is the smallest deployable unit. The service provides the A, the web services bring P, E and CE to the table. A web service may, indeed, just be a message router, security gateway, translator or other intermediary that handles messages strictly on the wire-level and dispatches them to yet another web service fronting an actual service that does the work prescribed by the message.

All of this, of course, causes substantial confusion about the duplicate use of the word service. The above it terribly difficult to read. I would wish it was still possible to kill the (inapproprate) term "web service" and just call it "edge", or "XML Edge", or (for the marketing people) "SOAP Edge Technology", or maybe "Service Edge XML", although I don't think the resulting acronym would go over well in the U.S.

Wednesday, August 18, 2004 4:51:20 AM (Pacific Daylight Time, UTC-07:00)

Comments [3] - Trackback
SOA

Friday, August 06, 2004

Why I hate NBC Sports

This Slashdot story reminds me why I hate NBC Sports. I lived in New York in 1996 during the Olympic Games and I got to see soapy stories about which terrible obstacles athletes had overcome to end up winning whatever competition and ... NO SPORTS. And in 2000 I happened to be in the U.S. again during the Olympics and I got to see NO SPORTS. German ARD/ZDF will have literally hundreds of hours of live coverage from Athens from early in the morning into the night each day. Olympics is about sports and it's also about the guy who comes in on 36th place in Marathon, running a record for his country. NBC dilutes the experience. too bad, America doesn't get to see the Olympics.

Friday, August 06, 2004 2:22:48 PM (Pacific Daylight Time, UTC-07:00)

Comments [7] - Trackback
Other Stuff

The silence of summer

I don't blog much in summer. That's mostly because I am either enjoying some time off or I am busy figuring out "new stuff".

So here's a bit of a hint what currently keeps me busy. If you read this in an RSS aggregator, you better come to the website for this explanation to make sense.

This page here is composed from several elements. There are navigation elements on the left, including a calendar, a categories tree and an archive link list that are built based on index information of the content store. The rest of the page, header and footer elements aside, contains the articles, which are composed onto the page based on a set of rules and there's some content aggregation going on to produce, for instance, the comment counter. Each of these jobs takes a little time and they are worked on sequentially, while the data is acquired from the backend, the web-site (rendering) thread sits idle.

Likewise, imagine you have an intranet web portal that's customizable and gives the user all sorts of individual information like the items on his/her task list, the unread mails, today's weather at his/her location, a list of current projects and their status, etc. All of these are little visual components on the page that are individually requested and each data item takes some time (even if not much) to acquire. Likely more than here on this dasBlog site. And all the information comes from several, distributed services with the portal page providing the visual aggregation. Again, usually all these things are worked on sequentially. If you have a dozen of those elements on a page and it takes unusually long to get one of them, you'll still sit there and wait for the whole dozen. If the browser times out on you during the wait, you won't get anything, even if 11 out of 12 information items could be acquired.

One aspect of what I am working having all those 12 things done at the same time and allow the rendering thread to do a little bit of work whenever one of the items is ready and to allow the page to proceed whenever it loses its patience with one or more of those jobs. So all of the data acquisition work happens in parallel rather than in sequence and the results can be collected and processed in random order and as they are ready. What's really exciting about this from an SOA perspective is that I am killing request/response in the process. The model sits entirely on one-way messaging. No return values, not output parameters anywhere in sight.

In case you wondered why it is so silent around here ... that's why.

Friday, August 06, 2004 7:40:44 AM (Pacific Daylight Time, UTC-07:00)

Comments [9] - Trackback
SOA

Tuesday, July 27, 2004

The Nerd, The Suit, and The Fortune Teller is online

Arvindra blogged it first and I'll add the immediate link to the video stream (because the regular links don't work on my machine for some strange reason)

Tuesday, July 27, 2004 2:21:05 AM (Pacific Daylight Time, UTC-07:00)

Comments [2] - Trackback
TechEd Europe