PHP and Web Services
- PHP and Web Services
- The Future of Web Services
- Using PHP to Create Web Services
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Web services are one of the most talked-about technologies of the day. They are set to change how data is exchanged on the Internet as the Internet itself evolves to deliver content not only to web browsers on PCs but also to PDAs and other devices. Further still, the evolution of "Internet-ready" software and hardware will see web services being used in applications such as MP3 players, personal stereos, and game consoles. PHP is a great language for developing web services, and this chapter shows you just what a web service is and how it is made up. Then we will look at how you can use PHP to develop web services.
What Makes Up a Web Service?
A web service is made up of four parts, as shown in Figure 9.1. The first part is the component that wants to act as a web service. It can be any part of an application: the executable, a COM component, a JavaBean, and so on. The web service component exposes public methods and functions that other applications can query. Your component could be one that you have created for this purpose, but normally you can expose any component that has public methods as a web service.
){kind=small}
Figure
9.1 The makeup of web services.
You must allow your components to be accessed by other applications as a web service. To do this, you must allow other applications to see what public functions and methods your components have. You don't allow applications to do this directly. To accomplish this, you create a file based on an XML-based metalanguage called Web Services Description Language (WSDL).
Next you must allow applications to query the WSDL file and exchange data with the web service.
For this purpose, you use another XML-based metalanguage called Simple Object Access Protocol (SOAP).
Using SOAP, you look up the web service component's public methods and functions using the WSDL file and then query those methods and functions. However, you don't always know where to find a web service's WSDL file. In that case, you can look at an XML-based database (also called a registry) of WSDL addresses. This database is called a Uniform Description, Discovery, and Integration (UDDI) registry.
The easiest way to remember the component parts of a web service is to think in terms of these three concepts:
Discovery: UDDI lets you discover web services.
Query: WSDL lets you query web services.
Transport: SOAP lets you transmit those queries back and forth from the web service.
Don't worry if some of these terms are new to you. They are covered in further detail later in this chapter. Now that we have identified all the component parts of a web service, let's look at each in detail.
SOAP (Simple Object Access Protocol)
In Chapter 5, "PHP and Sessions," SOAP was mentioned briefly when we looked at how WDDX developed. SOAP, like WDDX, is an XML-based language. Unlike WDDX, however, and like another XML-based language, XML-RPC, it is used for RPC (Remote Procedure Call) via XML. XML-RPC started life as an idea of Dave Winer of UserLand software. He discussed his ideas with Microsoft, and from his ideas, SOAP was born. (XML-RPC continues to develop as a protocol separate from SOAP.)
Other companies (such as IBM) joined Microsoft in developing SOAP. Soon after that, implementations of SOAP for languages such as Java (via IBM) and Visual C++ and Visual Basic (via Microsoft) were released.
Using SOAP
So how is SOAP used? SOAP is an XML-based language, so in effect, all SOAP implementations do is create XML files or strings that facilitate passing data and calling methods between (normally remote) applications. SOAP does not have to be strictly about web services; in other words, it does not require WSDL or UDDI to work and can be used in a standard RPC manner. SOAP is often described as passing objects between applications; this can be both misleading and confusing. All SOAP does is allow a public function or method to be queried via an XML interface. It does not pass physical objects in the same way that Java serialization does, for example.
When an application queries a public function or another application's methods, it passes some data to that function or method and might get results in return. A public function or method does not always do this, but it is good practice that such functions or methods at least return some handshake data (a simple code that allows the calling application to see that the public function or method has received the data it sent).
When dealing with remote applications, you might face data type problems. That is, different languages have different ways of representing data. You might have some success on this front. For example, Java and PHP have very similar data types, but when dealing with calling applications that might be made up of languages such Perl, Python, and C++, you will face a nightmare.
If you imagine that your remote application is developed in Java and your calling clients are made up of PHP and Visual Basic, you might face few problems with the PHP application calling the remote Java application. But you will face a lot of problems when you do the same with a Visual Basic application.
Luckily, SOAP deals with this by presenting a standard way of representing data. Imagine that your remote Java application function accepts a string. Using SOAP, you translate the calling application data into the SOAP equivalent and pass that to the remote Java application. The Java application then translates the SOAP string data into the Java equivalent.
This can work in reverse too so that if your Java application returns a result, it does so as SOAP data for your client applications to translate back into native data types. So, in effect, SOAP does not really let you pass objects between applications. Instead, it provides the means to interface between different objects in different languages.
I was once asked if SOAP, based on part of its definition (simple object), is for simple objects only. Its meaning is not to be confused with objects in the sense we use them in OOP languages such as C++. It does not need to know what an object does, how it exists, or how it works. In fact, the very use of the word object can be misleading. SOAP does not require objects to exist in a true OOP sense. They can be nothing more than public functions and methods and are not subject to OOP concepts such as encapsulation.
SOAP Transparency
Because SOAP is XML-based, it is nothing more than ASCII data that is being transmitted (and therefore is as simple as standard text). This is one of key benefits of SOAP. It uses simple character encoding (ASCII) as a file format. It can be transmitted on any protocol that supports the transmission of ASCII data. As it happens, most TCP/IP protocols do. This allows SOAP to be used across HTTP (the most common protocol to be used with SOAP), FTP, SMTP, and so on. This brings an added benefit in that such protocols don't require special ports and security measures such as firewalls. They run through commonly used ports. (This advantage is also enjoyed by other XML-based RPC methods, such as XML-RPC.)
This property is also apparent when you compare SOAP to other RPC methods. In PHP, you can also make use of DCOM (which is used with COM), CORBA (which uses the IIOP protocol), and Java (which natively supports the RMI protocol). Protocols that facilitate RPC are called wire protocols because they are low-level and require special ports. SOAP, however, has no such requirements.
SOAP's Makeup
What exactly is SOAP made of? A SOAP message is called a SOAP envelope. The following code exemplifies a SOAP envelope:
<?xml version="1.0" encoding="UTF-8" standalone="no" ?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
An envelope contains a body, which can be either a SOAP body call or a SOAP body response.
SOAP Body Call
When a call is made to a public function or method, this is done with a SOAP body call. Such a body call looks something like this:
<SOAP-ENV:Body> <SOAPSDK1:HelloFunc xmlns:SOAPSDK1="http://tempuri.org/message/"> <uname xmlns:SOAPSDK2="http://www.w3.org/2001/XMLSchema-instance"
Here the HelloFunc method is passed a string of data called "Andrew". Note that SOAP has added a mapping of what data we are passing to the public service or method:
type="SOAPSDK3:string"
A completed SOAP envelope calling a public service or method looks like the following:
<?xml version="1.0" encoding="UTF-8" standalone="no" ?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle=
SOAP Body Response
In response to a call to a public function or method, SOAP can respond to that call using the SOAP body response:
<SOAP-ENV:Body> <SOAPSDK1:HelloFuncResponse xmlns:SOAPSDK1="http://tempuri.org/message/"> <Result xmlns:SOAPSDK2="http://www.w3.org/2001/XMLSchema-instance"
The SOAP body result contains any data that the public function or method returns:
<Result xmlns:SOAPSDK2="http://www.w3.org/2001/XMLSchema-instance"
along with the original method call:
<uname xmlns:SOAPSDK4="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAPSDK5="http://www.w3.org/2001/XMLSchema" SOAPSDK4:type="SOAPSDK5:string">Andrew</uname>
Web Services Description Language (WSDL)
In the web services sense, although SOAP helps you exchange data between the public functions or methods of a web service, it can't help you explain which public functions or methods are available and what they do. Without this information, you can't use SOAP to exchange data, because you have no idea what is available to help you facilitate the exchange.
For this purpose, we have Web Services Description Language (WSDL). Like SOAP, WSDL is an XML-based file format for describing what public functions and methods are available in a web service. Other applications use the WSDL file to find this information and then use SOAP against those described public functions or methods.
WSDL File Makeup
<?xml version='1.0' encoding='UTF-8' ?> <!-- Generated 09/24/01 by Microsoft SOAP Toolkit WSDL File Generator,
As you can see, the WSDL file format is quite a complicated one. The three most important pieces are the port type, binding, and service name.
Port Type
The port type defines which public functions or methods are available. It uses the full name, which in this case is the HelloFunc method of the Examples class:
<portType name='ExamplesSoapPort'> <operation name='HelloFunc' parameterOrder='uname'> <input message='wsdlns:Examples.HelloFunc' /> <output message='wsdlns:Examples.HelloFuncResponse' /> </operation> </portType>
Binding
Binding describes how calls are made to each public method or function of a web service. In other words, it describes what encoding a client application should use when querying that public method or function.
<binding name='ExamplesSoapBinding' type='wsdlns:ExamplesSoapPort' > <stk:binding preferredEncoding='UTF-8'/> <soap:binding style='rpc'
This line describes what encoding will use of the binding:
<stk:binding preferredEncoding='UTF-8'/>
This must match the encoding for your XML file (the encoding specified in the XML header). Next you specify what the binding is (RPC) and its transport (HTTP):
<soap:binding style='rpc' transport='http://schemas.xmlsoap.org/soap/http' />
Next you specify what function you will call as Hello Func:
<operation name='HelloFunc' > <soap:operation soapAction='http://tempuri.org/action/Examples.HelloFunc' />
The WSDL file describes the encoding you use to query the web service and obtain a result:
<input> <soap:body use='encoded' namespace='http://tempuri.org/message/'
Although it's important to understand the structure of a WSDL file, you won't often need to write a WSDL file yourself. Most web service toolkits have tools for creating WSDL files for you.
Service Name
The service name defines where the WSDL gateway will be. A WSDL gateway is used to query the web service's component. A WSDL file passes the gateway information back to the client application. Such queries from the client application go to the gateway and on to the web service component and back.
<service name='PHP4WINSOAP' > <port name='ExamplesSoapPort' binding='wsdlns:ExamplesSoapBinding' > <soap:address location='http://localhost/phpbook/Chapter9
A gateway is language-independent. For instance, our example uses ASP, but the gateway can be developed in any language you like, as long as it supports XML. All it does is work in unison with the WSDL file to allow client applications to pass SOAP queries back and forth between the web service and the client application.
Uniform Description, Discovery, and Integration (UDDI)
Although you can now look up and query a web service's public methods and functions, finding a web service presents a problem. It can't be found using normal means such as a web search engine. If your company wants to make use of web services, it needs to make them generally available to all calling applications, not simply provide URLs on web pages for people to connect to.
Web services need a source of information all their own that an application can search and use to find WSDL files to query. UDDI was created for this purpose (see http://www.uddi.org). UDDI is another emerging standard for web services. It allows a company to register its company details, web page, and so on with a business group (for example, a car dealership could register with an automotive association). A person can then search the UDDI for companies within a business group or type via an application or directly via a web browser. More interestingly, UDDI allows companies to publish details of what web services are available (using brief descriptions and keywords) as well as the URLs of the WSDL files. An application can use this information to discover which web services a company has available.
Several public UDDI registries have been set up to allow companies to test and publish details of real-world web services. The Microsoft UDDI registry (http://uddi.microsoft.com), shown in Figure 9.2, serves such a purpose.
){kind=link}
Figure
9.2 Microsoft's UDDI web site.
Microsoft also provides a test UDDI registry at http://test.uddi.microsoft.com (see Figure 9.3). Other UDDI registries are available from IBM at http://www.ibm.com/developerworks/webservices/.
){kind=link}
Figure
9.3 Microsoft's UDDI web site for testing.