The Broker and the Model-View-Controller architectural patterns: Illustration with examples

Orban Pierre-Yves March 11, 2013

1
1.1

Broker architectural pattern

Brief reminder

The Broker Pattern is an architectural pattern mainly bound to distributed system in which clients communicate with remote servers. The principle is relatively simple. I will explain it very (very) briey. On the one hand, we have servers which proposes services. These servers know the brokers location and they register themselves to it to become available for the clients. A client access services through a network. Because he doesnt know the services servers location (and he knows the Brokers location), he uses the broker to communicate with the servers by sending requests and receiving answers. Sometimes, we can use client-side and server-side proxies to manage the communication over the network and to add some transparency.

1.2

Conditions of use

This pattern is particularly interesting when several conditions are met. Firstly, from a clients point of view, the client has to access remote components (servers) and he doesnt know the servers location. Secondly, from a servers point of view, the server provide services, available to multiple clients through a network and the servers location may change over time. Thirdly and nally, from a systems point of view, new components (servers) could be added dynamically to the system and these components can be totally dierent: on dierent machine, using dierent protocols and programming languages, etc.

1.3

Remote Procedure Call

The broker architecture has been widely used for systems proposing a Remote Procedure Call mechanism. The most famous architecture using the broker pattern is maybe the CORBA (Common Object Request Broker Architecture). Several other implementations, like Java RMI or SOAP use the broker pattern.

1.4
1.4.1

Illustration: a global knowledge

Scenario

We all know the current search engines: the user enter a term and the engine returns a list of web pages talking about the entered key words. But, now, imagine a new kind of search engine proposing direct services to the users. For example, a user could use the national registry service to know the number of people of a city or he also could use the UCL mathematical department calculator service to compute some something. Even better, imagine now that the system could analyse what the user entered and automatically choose the right service to ask. This imaginary global knowledge engine is a little bit like the Wolfram Alpha engine1 . But, I think Wolfram Alpha works mainly with its own database rather than asking other services. 1.4.2 Client side

From a client side of view, it is relatively simple. The client knows the (xed) IP address of several brokers and he will connect to one of these. For use simplicity, lets say the user will connect to the broker using its browser and a website. When the user is on the website, the connection is established with the broker. Now, the user has three main possibilities: Get a list of all services To know what are the available services, the user can simply ask the broker what are services are recorded. So, the user enter a special command or click a button, a message is sent to the broker, for example /getservices, and the broker returns the services list. We can also imagine some parameters and conditions to restrict the returned list, like the services location or the services category. Ask something to a service When a user want to use a service directly, he has just to enter the services name followed by the desired command. A rst command could be to ask the available commands and their description. For example, if the user wants to know the population of Louvain-la1

http://www.wolframalpha.com

Neuve using the national registry service, he could enter something like that: nationalRegistry.getPopulation "Louvain-la-Neuve". Ask something blindly This solution is even better but this requires a great analysis algorithm on the broker side. The user could enter what he wants and the corresponding services will be automatically contacted. For example, if the user enter Louvain-la-Neuve, the broker could decide to ask the the national registry service (to get the population) but also the national geography service to get the GPS coordinates, the altitude, etc. 1.4.3 Broker

The broker has three main roles: Client communication Firstly, the broker has to manage the incoming connection from the client. So, it has to keep a list with all the connected clients. Moreover, he also has to forward the incoming command to the specied service. Server communication Secondly, the broker has obviously to manage the service connections (registration and communication). When a server (oering a service responding to the system standards) wants to be available for the users, it has to register itself to the broker. So, when the broker receives a new incoming connection (on the port dedicated to the services listening), it veries if the server responds to the systems standards (like the available methods, the communication protocol, the possibility to use an encrypted connection, etc.) If it is ok, the service is registered in the list and becomes available for the users through internet. Data analysis This last point is more for a better user experience than for a good system architecture. The broker could analyse what the user entered and, according to this and the available services, choose automatically a corresponding service and send to it the right command. But this feature is more in the data analysis domain and this is not the point of this paper (which is, remember, an illustration of the Broker pattern).

1.4.4

Server side

Any server connected to the Internet can provide a service. But, the service must comply with some rules. Firstly, it has to respond to several general commands (for instance, /category). Secondly, the returned answer has to be in an XML format. When the server want to add its service to the available services, it has to register itself to the broker. Once it is done, the server switch in a listening mode, waiting for requests coming from the broker. When a request is received, if the command is managed by the service, the service computes and returns the answer. If not, the service returns an error message. Server proxy If the service wants to be independent and, maybe, available for several brokers, it could use one or multiple proxies. Each proxy will manage the connection to one broker system. Moreover, a server can use a this proxy as a cache system to deliver common answers faster.

1.5

Advantages

There are multiple advantages of a such system. Reliability A such system allows a broker to record several servers oering the same service. So, if a server fails, the broker will simply remove it from its list and ask another server oering the same service than the failed server. Moreover, we also can imagine this system with several brokers. Thus, the user could choose the broker to which connect. For example, he could decide to use the closest broker. But, a system with several brokers implies a synchronization mechanism between brokers in order that all brokers oer the same services and, when a server (un)registers itself to one broker, it is also registered to all the other brokers. Scaleability The main advantage of this system is maybe the scaleability. In a imaginary world where there would be no fraud, spam and scam, we could let any programmer to develop its own service and record it to the global broker. With such service registering system, the global system can add and remove external services very easily.

Interoperability Using a general format like the XML to marshal and unmarshall messages and an interface like the Socket interface to send and receive messages, the services could be developed in any programming language and run in any operating system.

1.6

Disadvantages

Eciency A such system is obviously slower than a system using a unique database to return answers. There is a lot of exchanged messages and several intermediates. Moreover, if the client ask several dierent services at the same time, he has to wait for the response of each service and some could be very slow, especially if the system is open to everyone (and, for example, if some guys host their service on their own personal server at home). Fault tolerance On the one hand, this distributed system can also be less tolerant to fault than a centralized system. Using the network and the Internet to access services increases the risk of having a connection problem. If a service fails, the broker has to detect it and remove the service quickly otherwise a user could try to use this failed service. But, on the other hand, a such distributed system can also be an advantage to manage the service errors. For example, a same service could run on dierent servers in dierent locations around the world. Thus, if a server fails, the service remains available using the other instances. Moreover, a service error doesnt aect the other services running on dierent servers. This is not possible in a centralized system where all the services would run on the same machine and if the machine crashes, all the services are no longer available. Moreover, if a service software crashes, it will maybe aect the other software running on the machine and cause some troubles. Security As said earlier, in a perfect world, this system could work. But, the world is what it is and there are malicious people everywhere. This system has obviously some security issue. An attacker could create its own service to provide fake information, try to do phishing, etc. But, using the XML format, it would be dicult for the attacker to attack the users computer by injecting malicious code.

Modiability If the broker wants to oer new general messages, new API, or everything else to the user, all the services have to update their implementation to understand the new messages. From a more general point of view, if the broker change its kind of API, all the services have to be updated and the old services may not work correctly anymore. So, it is very important to think, from the beginning, at all the needed possibilities to provide a robust system. Whether changes should be made, it is important to support the ascending compatibility.

1.7

Conclusion

The broker pattern is an architectural pattern particularly ecient for a distributed system where services could come and be developed from dierent sources, like dierent development companies. This illustration shows particularly well the interoperability and the scaleability of a system using the broker pattern. Furthermore, this architectural pattern has been successfully used in distributed applications like CORBA.

2
2.1

Model View Controller pattern

Brief reminder

The MVC pattern proposes to divide the system in three parts, by separating the data and the display. The Model encapsulates core data and functionality, the View displays the information obtained from the Model and the Controller is the link between the two rst components: all the events (click, text entered, ...) are translated to requests for the Model or the View. The typical components interactions are shown in the gure below. After the client made an action (e.g. a click), the dispatcher requests the correct controller. The controller performs the logic. If needed, the controller uses models to access stored data. Once the controller has nished its job, it hands it to a view. Finally, the view can build a fully rendered view with the data obtained from the controller and return it to the client.

Figure 1: Traditional structure of a MVC system.

2.2

Illustration: CarpeStudentem.org

CarpeStudentem.org is a website for students in Louvain-la-Neuve. It is maintained by a kot-` a-projet. I had the chance to live there two years in a row and I worked on the new website development using CakePHP, a web MVC framework. 2.2.1 Scenario

CarpeStudentem proposes a calendar with all the activities organized in Louvain-la-Neuve, a photo gallery of events and parties, articles and online contests. These data are displayed in a template designed for computer screens, but another template is currently designed to oer a better display on mobile and tablet screens. 2.2.2 Model

The Model is the heart of the system. There is a main abstract model which is CarpeObject (including some generic elds like the ID, the author, the permissions, the date, etc.) and there are several submodel extending the CarpeObject model. For example, there is a model for the articles, the events, the users, etc. As CakePHP obviously uses PHP, models are PHP classes (in sense of OOP). Thus, a model can be instantiated (e.g. new 8

Article();) and, it also has static methods to play with multiple data. (e.g. Article->getLastTen();). Each model encapsulates methods to handle the validation (mainly verication of user inputs), storage and retrieval of the data to/from the MySQL server. All the models (except the abstract CarpeObject) have a corresponding MySQL table to store the data. 2.2.3 Controller

There is one controller per model (e.g EventController). A controller is a PHP class and there is one method per available user action (e.g EventController->show() or EventController->add()). In the most cases, each action corresponds to a view, or, in this case, a web page. This approach looks more like the MVC2 pattern2 than the MVC pattern. Basically, the controllers role is to prepare the data to be displayed (on the view) or to store/modify data entered by the user. In the rst case, the controller can either display default data (for example, EventController->index() will display the last events) or display data according to a parameter passed through the URL and a GET method (for example, EventController->show() will display the event with the number given in the URL. The second case mostly happens when the user lls a form and click a validation button. In this case, data are passed using a POST method. In both cases, the controller uses the Model to retrieve or store data. Then, the values to be displayed are passed to the View using a global variable (e.g. $view->set(variable,value);). The CakePHP magic does the job to make available these variables in the View. 2.2.4 View

The views are HTML pages where we will display the information. As said above, the CakePHP magic makes the Controllers variables available in the HTML le. Then, to correctly display these information, you just have to use PHP and print the variable previously prepared in the Controller. You can also use PHP loops or other PHP functions to manipulates data. But, the goal here is to put all the logic in the Model and the Controller. So,
2 The MVC2 pattern is the same than the original MVC but there is just one controller receiving and forwarding all the requests.

normally, you dont have to modify variables values in the View. Modifying and manipulating data in the View is a bad smell in a MVC architecture and must be avoided as much as possible. To communicate with the Controller, a View can either use a HTML form (with a POST method) or pass data through an URL (with a GET method). Then, the data can be retrieved in the Controller using the $ POST or $ GET global PHP variables. For the CarpeStudentem case, we developed two dierent templates: a desktop template and a mobile template. By using this MVC architecture, we just have to indicates in the Controller which view to use to display a dierent template according to the users device. Moreover, CakePHP oers a theme feature which further simplies the work.

2.3
2.3.1

Advantages
Easy change of view

With a such architecture, it is extremely simple to use dierent views. It can be used, as we did, for a dierent template according to the users device, but it also can be used to propose dierent themes to the user. In big projects, this MVC architecture oers the possibility to programmers and designers to work separately. This is particularly interesting when the template designing is outsourced to another department or company. 2.3.2 Code clarity

With a such separation, we can have a code very clear and easy to understand. It is particularly interesting when a lot of dierent people have to work on the same project or if a people has to dive into the code of someone else. Moreover, as we can have one controller per view, it is also easy for dierent developers to work on dierent parts of the application. However, with the presented MVC architecture (one controller per model), it is dicult for two people to work on dierent actions (because all the related actions are stored in the same class, in the same PHP le).

10

2.3.3

Modiability

The separation of concerns oers the possibility to easily change one layer. For example, if we want to switch from a MySQL database to a PostgreSQL database, we just have to modify our Models without touch anything to the Controllers or the Views. This is obviously also possible for a View update. 2.3.4 Fast web development

This last advantage is more focused on the use of web MVC framework, but it is worth to be said. By using one of these, we could quickly develop web applications, especially when the framework automatically takes care of the access to the DB or the requests forwarding. Furthermore, most of the available frameworks takes care of the security of the data entered by the user.

2.4

Disadvantages

For a such illustration, it is dicult to nd disadvantages as the MVC framework ts particularly with the needs of a website development. 2.4.1 Increased complexity

The main disadvantage of the MVC architecture is that it increases the complexity of your project. Indeed, the separation of layers implies three times more les, one for each layer. Moreover, you have to develop the requests forwarding between the three layers. So, for (very) small projects, it is often easier and faster to use a single le per page, especially if you dont have to use a database. In the same idea, it is sometime dicult for a beginner to understand the MVC architecture and to dive into a project using this pattern. But, as this pattern is more and more used in web applications, I think every web developer should know this architecture. 2.4.2 Performance

As there could be multiple requests to display a view, we can have a lot of dierent method calls if the view has to be updated very frequently, especially 11

if there are a lot of data to be retrieved. This could imply some performance issue. In the case of a web application, the problem doesnt arise as the user display a web page and, in the most cases, takes its time to read it. 2.4.3 Debugging

As said in the previous section, a dierent classes and methods are involved to display the data to the user. So, if there is something wrong in the view, the debugger has to check the view le, the controllers methods and the models methods and it could be hard to follow the method calls path.

2.5

Conclusion

The MVC architecture ts particularly well for web applications. But, it could be used in a lot of dierent systems. We could almost say that this pattern could be used in every project involving a graphical interface. One of the advantage of this pattern is the ability to have dierent views up to date according to a unique Model. But, even when you dont need dierent views, using this pattern improves the code clarity and readability.

12