- Introduction
- Surface Comparisons
- The Service
- The Twist
- The End (or Is It?)
Surface Comparisons
We're going to build a genuine Web service in a moment, but first let's take a look at the differences between a hand-rolled TCP/IP client/server app and a Web service, and clear up a few common misconceptions.
First of all, a client/server application is much like any other application you might custom build. It's more or less an island (or pair of connected islands, rather). It's probably going to be more secure or easier to secure than a Web service, because the whole point of WSDL is to standardize publishing and accessing of services.
Second, and as a result, your hand-rolled application isn't interoperable. That is, your new service won't work with any client(s) other than the one(s) you write to fit your highly customized service. With the appropriate know-how and proper hooks, of course, you can add access for new clients. On the flip side, by creating a Web service you would gain the standardization of WSDL, in which any client could hook up to your Web service with no serious effort on your part.
These two points should be fairly self-evident. What's less obvious is that one application probably won't be much faster than the other. WSDL will be slower than a native client/server application written with a more direct connection (but not as much slower as you might think), which in turn would be slower than a native monolithic application. (And a monolithic DOS application would be fastest of all!)
Another somewhat obfuscated fact is that "Web service" does not mean "Web browser." It also doesn't mean "Java" or "C#" or ".NET." In true Internet fashion, WSDL is an open standard that any program can use.
This is where we're going to begin our technical exploration: by building a server using Java, .NET, and a native-code compiler. This will give us a basic apples-to-apples comparison and ultimately provide a basis for comparing Java and .NET.