bugfox blog

Sanjiva Weerawarana, one of the primary people responsible for the SOAP and WS-* specifications, defends them in an interview with InfoQ’s Stefan Tilkov:

InfoQ: Interview with Sanjiva Weerawarana: Debunking REST/WS-* Myths

Tilkov is a fairly hostile questioner, obviously arguing the REST viewpoint. Weerawarana provides calm and rational answers, though I don’t necessarily agree with them. Here are what I think his key points are, along with my responses.
(more…)

I know I’ve been dissing SOAP and WS-* quite a bit lately, but I can’t let this pass unnoticed.

If Richard Monson-Haefel of all people can’t easily use one of the leading toolkits to create a simple client for some of the most popular web services, how likely is it that the average programmer will be able to do a decent job? Keep in mind that the main selling point of these frameworks is that they are supposed to make it simple to use web services.

I think it’s time for the tool vendors to admit that this whole approach is a mistake. The idea of creating distributed applications by making RPC calls across the network, using code generators to hide all the details of network communications, has been around for over ten years. It sounds appealing at first, but we have had time to see how well it works in practice:

• Fragile, hard-to-maintain applications.
• That generally don’t scale well.
• And usually won’t interoperate with other vendor’s frameworks.

Tim Bray responds to Elliotte Rusty Harold’s negative comments in this post:

Hey Elliotte, I guess making friends and influencing people is for losers, right? The proof of the pudding, obviously, is in the eating, but the fact that this discussion is happening has to be a good thing.

Marc Hadley responds with some clarifications of what they are trying to do, and some sample code to show what they have in mind.

HTTP is the target of this API, we went back and forth a bit on the name and in the end decided to use RESTful in there to highlight that it will focus on RESTful use of HTTP. It doesn’t mean we plan to develop an abstract REST API with a binding to HTTP.

The sample doesn’t look to bad; at least it looks better than the existing APIs. However I see some issues that I hope will be addressed:

• The sample seems to assume that the message contents will be passed as strings. This would be fine for short messages but would probably be very inefficient for long messages.
• MIME attachements would also need to be supported.

ERH asks

why is this being proposed for Java Standard Edition at all? The proposal seems to depend on JAX-WS and the Java Servlet API, neither of which is included in the Java 6 Standard Edition. Will these packages have to be added to Java SE just to support this?

That’s a good point. Obviously there needs to be two packages:

1. A client-side API that belongs in Java SE
2. A server-side API that should be part of Jave EE or installable separately

Does that require two separate JSRs?

Elliotte Rusty Harolde wants everyone to submit comments on the proposed Java API for RESTful Web Services asking them to drop the whole idea:

…there are some companies (Sun being one of them) that can’t imagine regular, ordinary developers building systems without using some ultra-complex framework they’ve designed. The idea that people might just want to send plain old XML over plain old HTTP is inconceivable to them. There has to be some big framework for serializing objects and abstracting databases and faking method calls and guaranteeing message delivery and a dozen other things people either can already do perfectly well with HTTP and XML or don’t actually need to do at all.

…The problem is not HTTP or requiring developers to understand it. The problem is that Sun’s server-side HTTP API blows chunks…

I agree that this sounds misguided. If you provide SOAP-style wrappers around REST to hide the fact that you are dealing with HTTP, then is just isn’t REST anymore, and you will probably end up with all of the problems of SOAP and WS-*.

The Washington Post’s Rob Pegoraro describes a direct encounter with Vista’s DRM: Vista’s “Reduced Functionality”

The bottom line seems to be that Woody Leonhard is right (previous posts):

1. Microsoft can and will disable your computer without warning for no apparent reason.
2. If that happens you are SOL.

SEOmoz | Web Developers: 13 Command Line Tricks You Might Not Know

Via Cafe con Leche.

If you get an InvalidCastException when accessing a COM object from .NET, it generally means that there is a version mismatch between the .NET interop dll and the COM object.

1. Use Lutz Net Reflector to open the interop dll and disassemble the definition of the interface that you are trying to cast to. Note the interface ID (GUID).
2. Use OLE Viewer to open the COM dll as a type library. Examine the interface definition to make sure the GUID is the same.
3. If using DCOM/COM+, run Component Manager, open the component, open the interface list, right-click on the interface and select Properties. Once again the GUID should match.

If everything checks out, make sure that the COM interface is actually registered on your machine. Using an unregistered interface produces the same error message as using the wrong version. Note that if you are using DCOM remoting you do not need to have the component dll registered on the client machine, but you must register the dll that defines the interface that you are using. Just having the interop is not enough.

This is fairly obvious stuff once you figure it out, but it just took me several hours to track it down.

I’ve crossed my fingers and switched everything on the site to WordPress 2.1. If you see anything that is obviously broken, let me know via the contact form.

UPDATE: Two minor problems seen so far:

1. My old “Press It” bookmarks stopped working. Solved by creating new ones.
2. There seems to be a new formatting bug that inserts unnecessary and unterminated <p> tags in certain <div>s. This produces some ugliness that I worked around by tweaking the CSS.

UPDATE: Another problem: comments in templates don’t always seem to work. Note to self: delete it; don’t comment it out.

Few people have given more thought than Lawrence Lessig to the problems created by America’s ever-expanding copyright laws. Here he provides a detailed presentation on the problem of orphaned works (which you can’t use because somebody owns them but you can’t find out who.) He critiques the Copyright Office’s proposals and presents an alternative plan.