Comparing connection technologies
The Web service approach to your Survey application afforded you a great deal of flexibility and, in different ways, the PHP Java Bridge provides similar flexibility. Let's take a closer look at these differences and similarities before you delve deeper into the development process.
You converted the original application so that it could be accessed as a Web service in the fourth part of the series (see Resources). The Web service model has a number of advantages, not least of which is the accessibility. By exposing the classes through a Web service interface, you can guarantee interoperability, since nearly all languages support some form of Web service support—whether that is XML-RPC or Simple Object Access Protocol (SOAP).
As you saw in fourth installment of this series, exposing your applications as a Web service is hardly a trivial exercise. To do it right requires development and deployment of your code through a Web Services Description Language (WSDL) file; and then you have to separately define the interfaces to each function, while also ensuring that the encoding and encapsulation of supplied values and return values is in a format that is interoperable with the standards you want to use.
All of that work requires a significant amount of time to develop and, longer term, to keep in check as you develop and add new functionality and extensions to your core classes. It is probably not an overstatement to expect to add 25 to 50 percent of your development time for the original classes to make those same classes accessible through a Web service interface.
Furthermore, as you'll see in more detail later, the Web services option also implies a significant performance overhead that shouldn't be ignored if you expect to deploy your application in a large-scale operation.
In the fifth installment of this series, you looked in detail at the PHP Java Bridge (see Resources), but the key element of the PHP Java Bridge allows you to access Java classes directly from within PHP, just as if you were accessing a local PHP class.
Although the Web service and PHP Java Bridge interfaces are very different in a fundamental way, in reality, they both communicate over XML to exchange the information about the original methods and classes and how they should be accessed. Unlike the Web service solution, the process is automatic.
As you saw in the fifth installment (see Resources) and as outlined here in Listing 1, once you have imported the PHP element and created the connection to the remote Java host, using and creating Java classes and objects is straightforward.
Listing 1. Simple PHP Java Bridge example
<? require_once("http://sulaco.mcslp.pri:8080/JavaBridge/java/Java.inc"); $System = new Java("java.lang.System"); print_r($System->getProperties()); ?>
You'll examine the exact methods and solutions required later in this tutorial.
The Web service and PHP Java solutions share a number of distinct differences and similarities that provide advantages and disadvantages on both sides of the development and deployment aspects of your application.
For example, both the Web service and PHP Java Bridge solutions enable you to use PHP for your front end and a Java environment for your back-end portions of the application. For the Web service solution, you must develop the original classes, the Web service classes, and the PHP interface. With the PHP Java Bridge, you need only to develop the original Java classes and the PHP front end—the PHP Java Bridge handles all of the interoperability issues for you.
A more significant difference between the Web service and PHP Java Bridge solution is the steps required to achieve the solution. The Web service solution requires additional development time to expose the services through the desired Web service interface and make them available. Using the Web service from within PHP is also comparatively non-trivial, as you must develop a solution that interfaces to the Web service interface that you have developed.
With the PHP Java Bridge, you can access the existing Java classes directly without having to explicitly develop an interface on the Java side or an access interface on the PHP side.
In order to convert your original request into something that is completely platform-neutral, one of the key problems with Web services is that the request must be converted into XML. The resulting XML packet includes the request, source or destination information, and any data or information contained in that request (for example, arguments to a method or function) and that makes the payload of the XML component quite large.
Generating valid XML in this way is quite time consuming, but decoding that information can be even more time consuming, as XML parsing is not as simple and straightforward a process as you might expect. The result is a comparatively high load on the client that sends the request to the server, then receives it, and finally processes the request. The same process happens in reverse (response encoded in XML, sent to client, client parses XML, and extracts response) when the response is sent back to the client.
You can see this in more detail in Figure 1.
Figure 1. The Web service interface in action
The open format and encoding in XML is what makes Web services so compatible and accessible; however, it also places a significant load on both the client and server to have to create and parse XML just to exchange the information.
If you want to use Web services as your solution for exposing your Java application using PHP as the front end, keep in mind that the load on your Web server will be considerable, as you basically have to encode and decode the XML twice on the same machine.
By using the PHP Java Bridge, information is still encoded and even encoded in XML, but it is a much stricter and more easily encoded and decoded format than either SOAP or XML-RPC.
There are some important differences between the development of Java-based Web applications and PHP applications. It is worth considering these differences and how that can affect the development of your survey solution.
Java technology is a heavily object-based and class-based compiled language. As you've already seen with the Java language, you must edit the source code and then compile the source code into the final classes before you can use them.
PHP is an interpreted language, which means that you need only edit the source code and then access the PHP page to execute the program. This makes development of your application very quick, since you need to do very little to actually enable your application.
By default, PHP is not an object-oriented language, but it does support the notion of object orientation and you access properties and execute methods on an instance of a class. Within the Java environment, you access a method by separating the class instance and the method with a period:
With PHP, you would use this line:
With the PHP Java Bridge, most PHP types are automatically converted into the corresponding Java types (and vice versa). There are some minor differences due to the differences in available types. For example, PHP has no concept of the Boolean data type used by the Java language. To exchange a Boolean data type between PHP and Java language, you have to create a new Boolean type with an integer for the value and then use that, as shown in Listing 2.
Listing 2. Creating a new Boolean type with an integer for the value
$boolean = new Java("java.lang.Boolean",1); print $question->htmlquestion($boolean);
Similarly with arrays, PHP does not natively support a bare array type (all arrays in PHP are maps), but you can simulate a Java array by using the PHP array() type to create a normal index-referenced array:
You'll see some examples of these in action when you start to develop the final PHP interface later in this tutorial.