Architecture – Zend Framework App #1

Intro
Facebook, MySpace, and yes everyone’s other cool community based application has a new neighbor, ‘Ficticious Application #1’. It has the cool features of adding your friends to a network of people, selecting your shows, and other neat little features as adding videos of your favorite show to your profile. But this isnt a plug piece for my current contract. No, its a short analysis of the architecture which supports ‘Ficticious Application #1’.

Of course I wont devulge any information that may cause my unexpected termination at NBC. 🙂

The Software Architecture
The current team manager has a strong desire to always use cutting edge technology so its no suprise that the application uses the Zend PHP Framework. The application fully implements the MVC pattern and uses a API to interface with core company specific calls on a central database. A small, not in full detail, diagram is shown below.

enlargeLooking at the above diagram, the system is largely composed of the MVC pattern (Zend Framework), a middle layer ‘NO NAME API’, REST & SOAP calls, and a database. Going into a bit more detail, The models in the MVC patten use wrappers to implement the necessary API calls under the ‘NO NAME API’. For example, to add a new user the application is built so that a User model has to use a wrapper. The User model calls the specific ‘NO NAME API’ and the ‘NO NAME API’ calls a spcific REST/SOAP call. This REST/SOAP call in turn will save the data to a database.

Pro
Let us break it down now. What are the benefits in creating a software application in this way?

1. Loosely Coupled Code Base. First let me define what the code base consist of, since i use this term frequently. The code base in this context is the code that retreives information from the database for a specific REST &/or SOAP call.

Back to loosely coupled. What it means is this, the code base can be shared with other applications that spring up. The code base is not specific to one application and hence the code base is much more valuable based on man-hours spent replicating code with similar functionality for new or existing applications.

2. Application specific code is left up to the application owner. Again, what does this mean? If the application, in this case ‘Ficticious Application #1’, wants to retreive user information but apply it differently than other applications wich use the same code base, ‘Ficticious Application #1’ can do this using the models.

Con
1. Depending on the users activities and the amount of traffic to the site the number of includes (require_once, load() etc) will become a bottle neck. Too many includes, in this case the controller calling up the model then the wrapper and then the API call might be too much. The Zend Framework already has already been proven to be slower than its non framework based code (‘Zend Framework – Simple Caching ‘ab’ Test.’).

2. Second, as each request comes in or out the latency on each call will depend on the network traffic due to the high coupling of REST & SOAP on the application. What this means is that each user’s action will be followed by either a few milli seconds of waiting to successfully complete the process or the process will never complete when faced with a very high traffic spike on the application. Here the bottle neck will be the network itself.

Conclusion
by Reviewing the structure of ‘Ficticious Application #1’ the overall word that comes to mind is, scalability. Scalability in terms of being able to add more functinality to the core base code and allowing the extending and embedding of code into new applications as deemed fit.

The structure presented here is not geared for perfomance since the REST and SOAP calls are a tremendous bottleneck along with the high number of include calls.

Armando Padilla