Before COM, Web Services, and XML
From the authors personal experiences, one of our earliest tasks was to
provide some remedial-level interoperability that involved the Microsoft
Winsock control. At that time, Winsock was all the rage in Internet com-
munication. The ActiveX control allowed you to connect and bind to a
server via TCP/IP. The server was often another application created using
the Winsock control, but that provided logic and processing by supplying
the IP address and port of the host.
The host was most likely another application that you created to com-
municate specifically with the client, as most client/server code at the time
used a parser that was built exclusively to handle the data that the client
would send across the Internet.
After initiating the conversation with the server, the client control had to
contain logic to handle callbacks from the server. Also, the server was
responsible for handling the requests of the connected clients, forcing the
server to queue the requests when more than one thread accessed the same
function to prohibit unanticipated collisions, ultimately resulting in an
unnecessary application failure.
Once the server parsed the request of the client, usually sent as a comma-
delimited or fixed-length string, it could do just about anything it wanted
with it, including validations, database inputs and selects, and even
returning information to the user in a string format.
Provided you didnt do anything thickheaded on the server, like run the
contents of the input parameters through the command line, everything
was good. Additionally, the server environment could be controlled. If a
client request did not contain the correct header information and structure,
then the request could be terminated and the clients connection could
even be closed if needed. This was how our earlier attempts to accomplish
transaction-based programming using a form of remote procedure calls
One of the earlier hurdles when writing code to communicate with
remote servers was the firewall. This is ironic because it is still a major
problem for some Internet applications and software today. The firewalls
on the client might prohibit the call from ever making it to the outside
world if the port required by the server was blocked by the clients firewall,
never even making it as far as the server.
This same scenario could be true for a server application. A client/server
handshake might never take place if the Winsock server sat behind a fire-
wall. To challenge this issue usually meant using port 80. After all, most
What Are Web Services?