If anyone is interested, the Valvoline Runoffs are being televised on the Speed Channel. The Spec Racer Ford race (that’s mine) will be this Sunday morning, 11/24, at 12pm eastern / 9am pacific. I was in car #7, white and blue. Should be fun to watch!
Is WSDL too hard? Cont’d.
A couple of comments from Simon and Clemens:
Is WSDL too hard?. In response to Greg Reinacker’s comments I didn’t say WSDL is hard, I said its cumbersome and unproductive. Come on, its just angle brackets how hard can it be ?? [Simon Fell]
Simon – I didn’t actually mean to say that you were one of the “oh-so-many people” I talked about…your post just happened to remind me about them. :-)
Hard or not hard — can we agree on “It’s just not enough” ? :) My main problem with WSDL is that it tries to do 2 things (message contract and transport mapping), while it should do 3 things (message contract, service contract and transport mapping), hnowever at the same time, one thing (WSDL) shouldn’t do all these 3 things altogether but leave them two 3 separate things: A message contract definition language (defines soap:Body content), a service contract definition language (soap:Header) and a “web services binding language” that maps messages combined with services to transports. [Clemens Vasters: Enterprise Development & Alien Abductions]
Clemens hits the nail on the head here. What he describes as a “service contract” is exactly what’s missing from WSDL, in my opinion. One example is a service that supports WS-Security; I should be able to look at the WSDL contract, and learn that WS-Security is required, and perhaps what form of credentials (certificate, username/password, etc.) are required, and perhaps even additional information such as an authentication domain, so I know which credentials to send. Right now, there’s no standard way that I’m aware of to communicate this information.
A while back, Jon Udell and Mark Baker were discussing addressibility and interface uniformity. Mark said:
getSunwStockQuoteRealtime()
getIbmStockQuoteDelayed()The problem with these is obviously that they’re not readily reusable.
They do one thing and one thing only. So we typically generalize them
by parameterization; permitting a single method to be used for multiple
quotes, by moving identifying information away from the method name
and into the parameters. An obvious next iteration would be;getStockQuote( “SUNW”, “realtime” );
getStockQuote( “IBM”, “delayed” );However, generalization doesn’t have to stop there. We could do this;
getQuote( “Stock”, “SUNW”, “realtime” );
Which would permit other types of quotes to be retrieved, such as
insurance quotes, quotes for auto repairs, etc..Eventually however, generalization has to end. I suggest that this
is as far as one can go with it;
I would argue that the progression from getStockQuote to getQuote is where the usefulness of this model breaks down. Suppose a getQuote function, which could be used a couple of ways:
getQuote(“Stock”, “SUNW”, “realtime”);
getQuote(“Insurance”, “Allstate”, “realtime”);
If you design such an interface, you’re making the assumption that a stock quote and an insurance quote have some amount of information in common. In essense, you’re designing an inheritance hierarchy, that says you have “quotes” and they can be either “stock” or “insurance” (or others). But how do I work with the quote once I get it? For stock quotes, I might be interested in the current price and the day’s opening price. For insurance, I might be interested in the premium and the deductibles. Since you can’t generalize any “quote” into a single interface, you need to treat each kind of quote differently. And if this is the case, did you really buy anything from being able to retrieve them all with a single mechanism?
It seems to me you just move the specifics down a level. You can retrieve anything the same way, but you can’t process it without knowing more specifically what it is. And while it’s nice to have an interface that is essentially type-less (which seems like what Mark describes), it’s not as nice if the returned types can’t be coerced into something you can use.
Modeling without WSDL. Mark Ericson has some thoughts on Interface design with WSDL, I agree with him, WSDL is far to cumbersome to work with by hand, the only way to be remotely productive is to use some sort of tool, personally I like Omniopera, YMMV. [Simon Fell]
I’ve heard oh-so-many people talk about how difficult WSDL is to use, and how it’s too hard to create by hand. Well, I don’t buy it. Yes, it’s not exactly intuitive. But for 95% of the WSDL one might need to create, you could create a boilerplate template and just fill it in. When doing this, most of the work will be generating your schemas, which there are plenty of tools for (although I usually write schemas by hand). It’s cryptic, it’s strange, and you might not understand it all at first…but it’s not all that hard.
I’d like to extend a welcome to my good friend Sean Varley, who has just started a weblog. Sean’s company does electronics and embedded systems engineering and consulting.
It’s interesting to read and talk about work on the fringes of what we do. I talk to Sean a lot about software development issues, and the problems faced in embedded systems are very different than the problems we face in other kinds of software development. Fun stuff. And sooner or later, I just know I’m going to talk him into building something that will run the .NET compact framework.
Anyway, welcome Sean!
Just in case you weren’t aware…Don Box is scheduled to give a webcast this afternoon, discussing the above web service protocols. Details and free registration are here.
Scott Short has an article on importing external schemas into your WSDL in the latest MSDN magazine. The text isn’t online yet, but you can download the code, which is the important part. The idea is that you can add attributes onto parameters and return values from your method. The attribute identifies a schema to associate with the parameter. I don’t think it provides validation, but that would be easy enough to add via a SoapExtension. The framework uses the semi-documented System.Web.Services.Description.SoapExtensionReflector class to modify the default WSDL generated by the .NET framework, so your WSDL contains the complete contract for the method, but internally, you’re dealing with the data as XML. [Gordon Weakliem’s Radio Weblog]
This is super-cool. With this code, you can create a method taking a XmlNode parameter, but have it strongly typed in your WSDL:
[WebMethod]
public int Test(
[XmlImportedElement(“urn:test”, “test.xsd”, ElementName=”Stuff”)]
XmlNode stuff)
{}
So on the server side, we can process the parameter as XML; and yet the contract is fully described (including schema) in the auto-generated WSDL. Tim Ewald talked about this kind of thing at the DevCon – great stuff.
Nice job, Scott!
Wow, my post on the pet shop application has generated quite a few comments. I wanted to clear up a couple of things, and make a couple of comments.
1. I personally believe you can write performant, scalable systems with either Java/J2EE or .NET. It’s all a matter of good design. And I certainly didn’t mean to sound like election coverage!
2. Most “.NET people” I know also believe that you can certainly write good, scalable systems with Java/J2EE. In contrast, many “Java people” don’t believe that .NET is even worth considering. And it doesn’t seem to be based on technology – it seems to be fear of Microsoft. Here’s a great example. Yikes. Can’t we all just get along? (this is a part of why I’ve spent so much time working with web services.)
Ok, off my soapbox. Larry O’Brien, author of Thinking in C#, made some interesting and well thought-out comments on the benchmark tests. He discusses how the development and operational costs are a significant piece of the pie which wasn’t covered in the benchmark; he goes on to state that since the pet shop application was not built by “average” developers, the benchmark results not useful. He then continues:
In the past year, I have compared C# and Java performance on hundreds of small, focused programs. Every indication that I have seen is that, currently, the two platforms are quite comparable in run-time performance of strictly comparable code. In my experience, one of the two platforms displays a small performance advantage in the majority of programs, a performance advantage which I absolutely, positively believe to be irrelevant to the issue of business performance in an enterprise-level application.
Here we come, I believe, to the flaw in his point. He said he has tested on small, focused programs, and found similar performance between C# and Java. I will concede that for repetitive, CPU-intensive calculations, there is probably little measurable difference. However, it is in the platform where things really differ, running real-life applications. .NET enterprise applications typically execute in the context of COM+ applications, which are typically used to provide (among other things) automatic transaction and JIT activation support. Java enterprise applications execute within a EJB container such as Websphere or Weblogic, which provides the automatic transaction and activation support. The real performance difference, I believe, comes from the efficiency of these application servers when running with EJB’s, and the length and latency of the code path executed per request.
And it is most likely that difference, I believe, which is causing the performance disparity. I read many articles, and talk to many people, where the Java experts say something along the lines of “well you shouldn’t be using EJB’s – they don’t perform well.” This leads me to a couple of questions: a) does that mean I have to give up automatic transaction support? Object pooling? JIT activation? b) what about the “average” developers who read the docs from the big app server vendors, saying EJB’s are the way to go? Will they never end up with a performant system?
I’m obviously not a Java expert…so if there’s a big flaw in what I’m saying, please point it out. I’m not trying to spread FUD – just trying to have a discussion. :-)
I don’t just mean GUI design – I mean the down-and-dirty work with Windows user interface controls. I had almost forgotten.
95% of my work today is server-side code, and most of that directly related to web services. But for the last day or so, I’ve been working on a managed GUI component for a client. Basically, it’s a ListView control, but with multi-line rows which simulate a variable row height (which is unfortunately unsupported in owner-drawn listview controls). Each multi-line row gets a single checkbox. Custom row separators (because the normal ListView gridlines didn’t look good with the multi-line rows). And all of the detailed work to make sure the mouse and keyboard will both work as desired in all situations.
Working with Windows controls, it seems like it’s so much trial and error…intercept this message, aha, maybe if I just swallow it things will work, uh oh, better pass that one along… Remember Spy++? I haven’t used that in years…but dusted it off again today. It’s a black art. The documentation just doesn’t cut it for detailed control work – there are too many details which aren’t covered. Like where is is documented that you’re allowed to change the CDIS_FOCUS state for an item to tweak the rendering during a NM_CUSTOMDRAW, but not the CDIS_SELECTED state? And the brute force method (you know, a blank screen and a WM_PAINT message) is pretty brutal for an interactive control, unless you’ve got lots of time!
All in all, it was a nice break from my “normal” work…and a good memory of what I used to do every day. :-)
Someone just posted a link to this benchmarking research done by Middleware Company on the WinTech Offtopic list. Considering Middleware Co. specializes in Java technology training, you’d be skeptical of some skewing in favor of Java, but all the benchmarks clearly show the .NET implementation blowing the doors off the Java implementation. Not only that, but in less lines of code! [Drew’s Blog]
I finally had a chance to review this research from the Middleware Company. At a previous job, I had to defend .NET against Java/J2EE, as the company was trying to make a decision as to its technical direction, and they had a desire to standardize on a single platform. To save you the suspense, I lost this battle, although not for lack of trying. I subsequently left the company (yes, I’m a bit biased, I suppose, but I wanted to go somewhere where I could leverage my expertise). Anyway, the Java people at this company looked at the older petshop benchmarks, and weren’t impressed – there were too many variables to account for the performance differences.
In this new benchmark, things are probably as close (design-wise) as they’re ever going to get. And we see:
The Middleware Company is a Java training/consulting company – so they themselves are certainly biased. And in their own words:
The TMC team spent 4 months performing this benchmark. They worked 100 hours per week on this and worked every weekend, skipping holidays. Trust me, they were trying very hard to make J2EE win. But in the end, J2EE did not come out on top.
TMC had a lot of heartache seeing the results of this benchmark. We internally debated about whether we should post this or not. In the end, we decided to go forward and publish this report.
’nuff said.