Greg Reinacker’s Weblog

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:

• .NET has dramatically better performance in every single test
• .NET requires significantly less code
• .NET requires a far smaller capital expense for equivalent performance

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.

I’ve gotten a bunch of e-mail recently, asking how to use the debugger when using my Basic or Digest authentication HTTP modules.  The problem is, if you disable Integrated Windows authentication on a virtual directory, the VS.NET debugger will be unable to start debugging within that vdir.

Prompted by a few questions, I thought I’d post about using my Basic and Digest authentication modules with .NET remoting. As you’re probably aware, .NET remoting does not include (out of the box) any built-in authentication mechanism. However, you can leverage IIS to authenticate requests if you wish; Ingo discusses using the IIS implementations of Basic and Integrated Windows authentication in his book. However, as he points out, Basic requires using SSL, and IWA will not work with most typical firewall configurations. Well, as I’ve said in the past, Digest is a good alternative to these two.

I will describe here the necessary code to use the Basic or Digest authentication modules with .NET remoting in IIS. Some code has been omitted for brevity, but all the important parts are here. :-)

Imaging a remote object implementation in RemoteServer.dll, containing the following:

namespace RemoteServer
{
public class Scoop : MarshalByRefObject
{
public Scoop()
{
}

public string GetTheScoop(string name)
{
return “Here’s the scoop, ”
+ Thread.CurrentPrincipal.Identity.Name + “!”;
}
}
}

To host this in IIS, your web.config file might look something like:

<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode=”SingleCall”
type=”RemoteServer.Scoop,RemoteServer”
objectUri=”Scoop.soap” />
</service>
</application>
</system.runtime.remoting>
</configuration>

If you want to use the Digest authentication module, all you need to do is add the required items to this file:

<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode=”SingleCall”
type=”RemoteServer.Scoop,RemoteServer”
objectUri=”Scoop.soap” />
</service>
</application>
</system.runtime.remoting>
<system.web>
<authentication mode=”None” />
<authorization>
<deny users=”?” />
</authorization>
<httpModules>
<add name=”DigestAuthenticationModule”
type=”Rassoc.Samples.DigestAuthenticationModule,DigestAuthMod” />
</httpModules>
</system.web>
<appSettings>
<add key=”Rassoc.Samples.DigestAuthenticationModule_Realm”
value=”RassocDigestSample” />
<add key=”Rassoc.Samples.DigestAuthenticationModule_UserFileVpath”
value=”~/users.xml” />
</appSettings>
</configuration>

And finally, modify the client code which accesses the service to provide credentials:

static void Main(string[] args)
{
ChannelServices.RegisterChannel(new HttpClientChannel());
RemotingConfiguration.RegisterWellKnownClientType(
typeof(RemoteServer.Scoop),
“http://localhost/ScoopRemoting/Scoop.soap“);

Scoop srv = new Scoop();

IDictionary props = ChannelServices.GetChannelSinkProperties(srv);
props["username"] = “test”;
props["password"] = “test”;

string s = srv.GetTheScoop(“Greg”);
Console.WriteLine(s);
}

In general, the complete ASP.NET HTTP pipeline is available for your use when hosting remote objects in IIS.

There was a lot of talk at the DevCon about writing your web service interface first in WSDL, and then implementing it in code.  This is in contrast to the method that the current tools tend to encourage; for example, with VS.NET, you can write your code, decorate the methods with [WebMethod], and automatically generate the WSDL.  I wholeheartedly agree with the first way – define your interface first, and implement second.  There are things you can do this way that the tools just won’t do for you.

In the old days of COM, we might design an interface method in IDL like the following:

HRESULT IsOldGeezer([in] int age, [out] VARIANT_BOOL* pIsGeezer);

All we can tell about the method is it takes an age as input, which must be an integer value, and returns an HRESULT and a boolean value.  Valuable information – but what are the valid values for age?  Hmm…we have no way to tell, without reading the documentation (if there even is any).

When you design your interface in WSDL, you define the parameters for your service and their types.  The types are usually defined with XML-Schema.  So the input age parameter might be defined as something like:

<s:simpleType name=”AgeType”>
 <s:restriction base=”s:int”>
  <s:minInclusive value=”1″ />
  <s:maxInclusive value=”120″ />
 </s:restriction>
</s:simpleType>

Which gives us a lot more information – namely, the age must be an integer between 1 and 120.  Wow, this is great stuff – lots of information for our clients.  We had to write the above schema by hand (the .NET WSDL-generation tools will not generate such a restriction in the schema), but it’s well worth it just for the additional information we give to the client.  [It's worth noting that most auto-generated client proxies will also ignore the schema restrictions, and just type the age as an int value.]

Now we’ve got a nice descriptive schema, and we implement the web service around it.  If you implement this service with .NET, you’re going to end up with a function signature that looks something like (a few attributes omitted for brevity):

[WebMethod]
bool IsOldGeezer(int age) {}

And yep, we could certainly get called with an invalid age of, say, 421.  This is because the ASP.NET plumbing, by default, does not validate the incoming message against the schema.

With .NET, a good way around this problem is to write a SoapExtension to validate against the schema.  I wrote such an extension, and I was going to post it with this note, when I noticed that Aaron Skonnard wrote such an extension for an MSDN Magazine article.  I hate it when people beat me to it!  At any rate, though, you can just add an attribute to the web method to force a validation of the incoming message against the schema.

This brings me to my main point of this post (took me long enough!).  I’ve said in the past to be extensible with your service interfaces, but to draw the line in the sand with your schema.  Use it to your advantage!  Use the great features of XML-Schema (like parameter value ranges, optional elements, substitution, etc.) which aren’t readily available when defining interfaces in other ways.  And as long as you have the CPU cycles to spare, validate the requests against the schema.

Comments?

I’m leaving in the morning for the Web Services DevCon.  If anyone who’s going wants to meet up out there, send me a note!

A dozen or so of us have been tossing around a lot of great ideas in the Groove Experiments shared space. One of our concerns, of course, is how to seemlessly share our findings publically with a wide public mechanism. Tonight, we decided to re-focus completly in a new direction, one direction. We felt that instead of continuing to be somewhat abstract that it would be better to take one of our ideas, discuss it, form requirements, and start writing code! We have decided to focus on a Groove to Weblog interface. We do realize that there have been two previous partial implementations that we will be looking at: Tim Knipp’s Blogger Tool and the Agora Groovelog. One of the members is looking into those two. We realize that this kind of dump from me here now is not optimal. Ideally we would like to have things available in real-time as they happen publically. Maybe this Tool or Solution will go a long way toward that. [reposted from Sam Gentile's Radio Weblog]

Similarly, Sabre Inc. (www.sabre.com) provides customers access to its Web services by supplying a module that runs on its partners’ Web sites. The XML Travel Toolkit module is designed to let partner companies build Web sites to allow their customers to book travel. For instance, a brick-and-mortar travel agent would build a Web site, and then, to allow its customers to make last-minute changes to an itinerary, the travel agent would connect its Web site to the Sabre system using the XML Travel Toolkit.

“The travel agent can extend loyalty for a customer who might otherwise sneak over to a travel dot-com,” said Cheryl Hutchinson, product manager the XML Travel Toolkit. The reason Sabre chose to distribute software, rather than run it all locally at Sabre, is that Sabre communicates with its module using its own lightweight, structured communications language, rather than XML, which requires more bandwidth.  [SD Times] via [.netWire]

Hmm.  So Sabre has services available, which require proprietary software on the client end, use a proprietary transport protocol, and a proprietary data format (the XML mentioned is only used between the client and the proprietary client library).  Does this have anything to do with web services?  Galileo has had a similar product available for several years, called XML Select.  This is nothing new!

However, Galileo also has “real” web services, using industry standard protocols and data formats (you know, SOAP and HTTP).  They even have huge customers (like AAA) using them.  Good stuff.

Disclaimer – I worked on both XML Select and the web services products at Galileo…so I’m prone to shamelessly plug them whenever possible.  However, if you want to keep track of who’s really doing it with web services, Google will tell you (for Sabre and Galileo).  The top hit for Sabre is about the XML Toolkit described above…

Microsoft Corp. and IBM, which, along with VeriSign Inc., published the original Web Services-Security specification, are now in two camps that have contrasting views over what should be done with the specification, also known as WS-Security.  [eWeek]

Microsoft and IBM disagreeing?  Ah, the world is coming back to normal.  Maybe the stock market will bounce back now, too.

Seriously, though, there is something missing from the WS-Security spec, as I see it.  When I want to access a web service secured via WS-Security, I have no way of knowing that it uses WS-Security, and even if I do, I don’t necessarily know what type of credentials I need to supply (username/password, certificate, etc.), and I don’t know if I am required to encrypt and/or sign the message.  Perhaps this information should be published as WSDL extensions.  The article referenced mentions IBM wants encryption-related WSDL extensions, but doesn’t go into any more details.