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 were accomplished. 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? 7