A Web service is a self-describing component (large-scale piece of code) that can discover and communicate with other components using Web-based communications in a standardized way. A Web service consumer can invoke a Web service provider; a Web service provider can respond to a Web service consumer. An environment in which all applications are Web services providers and consumers is called a SOA (service oriented architecture).
Communicate between Web services using SOAP (Simple Object Access Protocol), which is built on the XML (eXtended Messaging Language) messaging protocol.
More specifically, in order to communicate with a Web service, an application will add Web service consumer code. This code first optionally "locates" the Web service in the directory or registry using UDDI, then sends a SOAP communication to invoke the Web service. The Web service receives the invocation via a Web service provider interface, and returns the results of the invocation to the calling application via the provider interface and SOAP.
Access to a Web service can be dynamic. In other words, at any time a calling application can do a scan of all applications on the Internet, identify yours are one it wants to invoke by scanning your UDDI directory, and then invoke the Web service by following the instructions in the directory. So, in many cases, application interfaces are no longer "hard-wired"; the security guru for an organization can no longer assume that only a small list of applications that have proven trustworthy in the past will invoke mainframe software.
Second, the organization can attach as much software as it likes to the Web service provider interface (and directory) -- security code, personalization code, business compliance code, and so on. A corporation that wishes can now require all Web services to offer the same Web service security code, and that security will apply semi-automatically to all applications in an SOA.
About the author:Kernochan is president of Infostructure Associates.
