In this session we will take a look at several different methods for building tiered applications. Some of the tiering methodologies include Soap, XML-RPC, RESTful and multiple language architectures. The purpose of this talk will not be to determine which methodology is best, but instead will try to provide an unbiased view of the pros and cons of each.

1. Tiery Eyed - Approaches to tiered development in PHP
Kevin Schroeder
Copyright © 2007, Zend Technologies Inc.

2. Could also be called
“Solving simple problems with complex
solutions”
|

3. Introduction
• About me
Kevin Schroeder
Consultant for Zend Technologies
Have worked with a bunch of languages
Have worked with a bunch of hardware
Have worked in a bunch of scenarios
Enough about me
|

4. … Almost
• From Canada
• Live in Dallas
• Flew in to San Hose, Eh?
|

5. Introduction
• What is a tiered architecture?
Has multiple distinct parts, typically
• Presentation
• Business/Application Logic
• Data
Often used to provide access to a single layer of logic to
multiple informational endpoints
|

6. Typical Architecture
|

7. Why would you want to use a tiered architecture?
• Less sharing
Reduced replication and/or clustering
• Scale vertically for your data, horizontally for your UI
• Sharing increases complexity
• Less likelihood of invalid or out-of-date data
• Less duplication
SELECT * FROM users WHERE user_key = 1 is only called
in fewer places
Easier code rollout
• More options for interaction
• Separated developer tasks
|

8. Why would you want to use a tiered architecture?
• It forces you to think about the consequences of
your work
No more hacking together a simple script
…hopefully
• It forces you to separate presentation and data
layers
• Migrate your application to PHP slowly
|

9. When is a tiered architecture rational?
• When your development team has highly
segmented skill sets
Why force good business logic developers write bad HTML
code?
Why force graphical people to write business logic? Can
they?
Separate your development efforts so people can specialize
• When different parts of your application have
different scalability needs
Frontend might scale better horizontally
Backend might scale better vertically
Why force both to scale the same?
|

10. When is a tiered architecture rational (con’t)?
• When you want to expose your business logic to
multiple different presentation layers
• When you have different programming languages
being used in different tiers
For example, JEE on the back end, PHP on the front
|

11. Why are we doing this?
• Is an N-tiered application a better architecture than
a more traditional web-based app?
Probably not – depends on your needs
• Then why go through this all?
To give you some ideas as to
• What to watch out for
• What the tradeoffs are
• What the performance overhead is
|

12. Where are we focusing?
|

13. What will we look at
• 4 different options
Soap
XML-RPC
REST-like
Integration with Java backends (PHP preso tier)
• Could also use COM
• Could also use Zend Platform 5250 Bridge, if on IBM i
|

14. How was testing done?
• Front end is a Zend Framework microblogging
application
Only 2 classes
• Account
• Message
• Backend is an HTTP server, or the Java Bridge in
front of a simple MySQL database
Let’s look at some code!!!
|

15. Option 1 – Soap
• Benefits
Easy object handling
Most cross-platform compatible out of all the solutions
• Works well in heterogeneous environments
Provides highly structured data transfer
The PHP extension is freaking fast for all that it does
• Drawbacks
Most complex out of all the solutions in terms of setup
Let’s look at the Soap handling code
|

16. Option 2 – XML-RPC
• Benefits
Pretty lightweight in terms of protocol
Low barrier to entry
• Drawbacks
Limited vendor support
… Except Zend Framework ☺
Difficult to use with objects/classes
|

17. Option 2 – XML-RPC
• Used SimpleXML
• Why did I not use Zend Framework?
Performance
Framework’s XML-RPC framework is great for systems that are
loosely coupled
This application was tightly coupled
• I had control over the front end
• I had control over the backend
• Therefore
• Introspection was overkill
• I could “bend” the standards a little
• Why did I not use PHP XML-RPC extension?
It’s still considered experimental
Let’s look at some code
|

18. Option 3 – REST or REST-like
• Introduction
RESTful web services typically use XML, bound to a particular URL to
retrieve data
This implementation passed serialized objects instead of XML
• We had already looked at an XML-like implementation
• Benefits
Because it can use GET it is possible to use front and backend caching
together
Can utilize HTTP header codes
Closest to a native PHP RMI
Gives more control to networking options like persistence if you use
pfsockopen()
• Drawbacks
No real standards
Size limitations on size of GET request
Let’s look at some code
|

19. Option 4 – Java Bridge
• Benefits
Makes it fairly easy to integrate with 3rd party software that is
based on Java
Robust caching options available
Easy integration into enterprise environments
Lighter communication than HTTP
|

20. Option 4 – Java Bridge
• Drawbacks
Need to know the ins and outs of more than one language
Need to buy twice the server to due to memory requirements
Not a shared-nothing environment… but that’s another story
• Things I learned
__magic methods and variable variables are LOVELY when
you are using the proxy design pattern
Java likes to suck up every free resource on your system…
• Like you didn’t know that (Had to double the RAM on the VM)
|

21. Performance Tests
• Done using a custom PHP script to set up
repeatable scenarios
• Tests were done connecting to the front end
domain so that data translation time was included
• No caching was used
The only one that could have used caching was REST-ish
|

22. Performance Tests
• Tests included
Get entries
Post Message
Get Subscribers
Add Subscriber
Remove Subscriber
• 1000 requests for read operations
• 100 for write operations
Except for Java. Had difficulty with long-running requests
|

23. Get Entries
0.25
0.2
0.15 Java
Restish
Soap
0.1 XML-RPC
0.05
0
1 14 27 40 53 66 79 92 105 118 131 144 157 170 183 196 209 222 235 248
|

24. Get Entries (10 request average)
0.16
0.14
0.12
0.1
Java (10 req. avg)
Restish (10 req. avg)
0.08
Soap (10 req. avg)
XML-RPC (10 req. avg)
0.06
0.04
0.02
0
1 16 31 46 61 76 91 106 121 136 151 166 181 196 211 226 241
|

25. Post Message
0.14
0.12
0.1
XML-RPC
0.08
Soap
REST-ish
0.06
Java
0.04
0.02
0
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
|

26. Post Message (10 request average)
0.09
0.08
0.07
0.06
XML-RPC (10 sec. avg.)
0.05
Soap (10 sec. avg.)
REST-ish (10 sec. avg.)
0.04
Java (10 sec. avg.)
0.03
0.02
0.01
0
1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97
|

27. Results
• “I thought Java would be slower”
or
“I thought PHP would be faster than Java”
Java performance was partially due to the architecture of the
Zend Platform Java Bridge
• It uses a very efficient binary protocol instead of using HTTP as a
transport mechanism
It was also partially because this was not a typically
architected Java structure.
• Have you ever run a Java app with only 2 classes?
It was also partially because Java is faster than most people
give it credit for
Slowness in Java is usually due to architectural decisions
|

28. How about debugging?
• Simply add the following query string to the URL that the front end connects
to
• For example, looking at the Soap WSDL
<service name=quot;tbbServicequot;>
<port name=quot;Soap_BrokerPortquot; binding=quot;typens:Soap_BrokerBindingquot;>
<soap:address location=quot;http://tbb/soap.phpquot;/>
</port>
</service>
To
<service name=quot;tbbServicequot;>
<port name=quot;Soap_BrokerPortquot; binding=quot;typens:Soap_BrokerBindingquot;>
<soap:address
location=quot;http://tbb/soap.php?use_remote=1&amp;debug_port=10137&amp;start_debug=1&a
mp;debug_start_session=1&amp;debug_session_id=1201&amp;send_sess_end=1&amp;debu
g_host=192.168.175.1&amp;debug_stop=1quot;/>
</port>
</service>
• Notice the URL-encoded &amp;
• You can use this string for any of the backend communication methods
|

29. … and profiling?
• Simply add the following query string to the URL that the front end connects
to
• For example, looking at the Soap WSDL
<service name=quot;tbbServicequot;>
<port name=quot;Soap_BrokerPortquot; binding=quot;typens:Soap_BrokerBindingquot;>
<soap:address location=quot;http://tbb/soap.phpquot;/>
</port>
</service>
To
<service name=quot;tbbServicequot;>
<port name=quot;Soap_BrokerPortquot; binding=quot;typens:Soap_BrokerBindingquot;>
<soap:address
location=quot;http://tbb/soap.php?no_remote=1&amp;debug_port=10137&amp;start_profile=1&amp;debug_start_session=1&
amp;debug_session_id=1201&amp;send_sess_end=1&amp;debug_host=192.168.175.1&amp;profile_stop=1quot;/>
</port>
</service>
Notice the URL-encoded &amp;
You can use this string for any of the backend communication methods
|

30. Alternatively…
$sc = new SoapClient('http://tbb/tbb.wsdl');
$sc->__setCookie('use_remote', '1');
$sc->__setCookie('debug_port', '10137');
$sc->__setCookie('start_debug', '1');
$sc->__setCookie('debug_start_session', '1');
$sc->__setCookie('debug_session_id', '1201');
$sc->__setCookie('send_sess_end', '1');
$sc->__setCookie('debug_host', '192.168.175.1');
$sc->__setCookie('debug_stop', '1');
|

31. Using a tiered architecture for migration
As noted in the (boring :-) ) keynote this morning
Enterprises are moving from existing environments to PHP
Why?
• Many applications are more complex than they need to be
• Many applications are simply interfaces to data
• Many applications do not really need to be strongly-typed
• PHP flexes to fit the solution. You are not flexing the solution to
fit PHP
• Rapid Application Development without losing control (!!)
|

32. Questions?
• Do you have any
Questions?
Thoughts?
Experiences?
|

33. Zend is looking for quality PHP experts in
North America Global Services!!
|

34. Contact Me
Kevin Schroeder
kevin@zend.com
|