Building XML Web Services with PHP NuSOAP - What are Web Services? (Page 2 of 5 )
All future software applications will be Web applications, which will run over the Internet as services for clients. Future applications will not contain large masses of compiled executable code (EXE, DLL, OCX, etc.). Applications will be broken down into a number of smaller individual services that are easier to create and easier to maintain. Individual services will be developed and maintained by smaller groups of people. It is time to wake up and get rid of our traditional skills. Find out how to create future Internet applications with the tools that are available today.
So, what are Web Services? If you ask this question to five IT gurus, you may get six different correct definitions, however, a Web service is any piece of software that makes itself available over the Internet and uses a standardized XML messaging system.
XML lies in the core of Web services, which was designed to describe data. The main functions of XML are inter-application communication, data integration and external application communication with outside partners. By standardizing on XML, different applications can more easily talk to one another, and this makes software a whole lot more interesting. If you want to know about XML, read this XML tutorial, or if you want a more intuitive feel for Web Services, try out the IBM Web Service Browser, available on the IBM Alphaworks site. The browser provides a series of Web Services demonstrations. Find more resources here.
Benefit of Web Services
Web Services let applications share data and—more powerfully—invoke capabilities from other applications without regard to how those applications were built, what operating system or platform they run on, and what devices are used to access them. While XML Web Services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task. Read here to learn more about benefits of different Web Services.
Evaluation of Web Services
Web Services didn't just exist suddenly. They aren't a new revolution; rather they have to be seen as an evolution based on existing Internet protocols. They are the logical next step. Since 1994, Distributed Objects have been developed by several organizations under various names. NeXT called them Portable Distributed Objects, Microsoft called them Component Object Model (COM), IBM called them System Object Model (SOM), and Apple called them OpenDoc. These companies (with the exception of Microsoft) formed the Object Management Group (OMG) and converged upon a standard called Common Object Request Broker Architecture (CORBA). The concept was to develop an architecture that lets applications plug in to an "application bus" and call a service. Based on object-oriented units, it called on specialized software components. Today, interoperable objects are being called Web Services. You can read a good introductory article here.
Web Services Protocol Stack
The Web Services protocol stack consists of three key XML-based technologies: SOAP (Simple Object Access Protocol), WSDL (Web Service Description Language), and UDDI (Universal Description, Discovery and Integration).
UDDI: This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via the UDDI. The UDDI specification can help to solve making it possible to discover the right services from the millions currently online. Learn more about UDDI here.
WSDL: This layer is responsible for describing the public interface to a specific Web service, which is an XML-based language that describes the various functions that a Web service is capable of. Currently, service description is handled via the WSDL. You do not need to learn all the nitty-gritty details because there are tools that generate WSDL for you. You can get one here.
SOAP: This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this includes XML-RPC and SOAP. For example, the client program bundles up two values (see Figure 1) to be added into a SOAP message, which is sent to the Web service by sending it as the body of an HTTP POST request. The server unpacks the SOAP request that the application can understand and executes Add operation. Next, the server packages up that result of summation as response into another SOAP message, which it sends back to the client program in response to its HTTP request. The client program unpacks the SOAP message to obtain the results of the summation. So, SOAP=XML + HTTP.
You can experiment with Web Services using PHP by writing only a few lines of code, without having to set up a special environment. PHP is already broadly deployed for data-centric web applications. Your PHP-driven web sites may have component that may be reused by exposing their methods using SOAP or XML RPC and this conversion process is trivial using the tools available today. For the sake of simplicity we will narrow down our discussion about SOAP. In the following example, we will use NuSOAP, which is a component-based Web Services toolkit that allows user to send and receive SOAP message over HTTP. NuSOAP is distributed by NuSphere Corporation. It is open source and licensed under the GNU LGPL.