Introduction


With the Internet taking a center stage in today's communication world, it's a natural progression for applications to allow Internet communication between themselves. Dynamically generated HTML content works fine in Web browsers, but it presents a nightmare for anyone trying to utilize that data with other programs. Consider a simple case such as obtaining a stock quote. While you can view this easily in a web browser, an application would require a complicated HTML parser to extract the quote. Services solve this problem with a consistent and easy method for accessing information. While middleware platforms such as RMI, Jini, CORBA, DCOM provide great implementation vehicles for services, none of them is a clear winner. They share the same drawbacks such as:

  • Both, Client and Server, need to be implemented using the same technological environment:
    • COM Server --> COM Client
    • EJB Server -->EJB Client
  • Both, Client and Server, need to understand:
    • Services Deployment
    • Implementation Language
    • Security
Moreover, the Client and Server both need to run on similar operating system platforms. A Unix client and a Windows server cannot communicate effectively because of problems associated with marshalling. This technology stack dependency poses implementation hurdles making a seemingly simple task difficult to achieve.

SOAP was conceived as the ultimate solution to interoperability.

Next --> So What Is SOAP??