Creating an enterprise application involves many decisions. There are so many options, and with each decision, number of other options emerge. One way to reduce the scope to deal with is to organize the application into layers. For each layer in an application, there are different design considerations. These consideration and what impact each choice has, is one of the hardest tasks in architecturing enterprise software. Many things can be learned from textbooks although they are limited to a specific context, other things are learned from doing – experience. Sometimes hard and painful experience. While things look to be easy enough, when things start to operate with other things and scale, what sounded easy is actually not. In my 11th Lecture in the Design and Implementation of Software course, the goal is to look at the complete design from web layer to the database and how all the pieces come together, Application Architecture.
In the first section we look at the big picture and design consideration for each of the three principal layers. They are different concerns and considerations to think about. In the Web Layer its all about keeping the web presentation logic from the domain layer, and deciding what is on the gray area. We have to understand different client types. While back in them old ways people would run Windows native clients that accessed a server, today we have multiple of choices for clients. Sometimes we don’t even decide.
Then there is different type of content. Content is not just content. A web site may have static content, editable content and dynamic content. The static content is any graphical asset that you might get from an graphical designer. Examples are logos, backgrounds, themes and things like that. These are not edited frequently and could be done all at once, for example if the web site changes themes. Then there is editable content. This content that the operator wants to edit, possible frequently. If your web site has lots of editable content, consider using a Content Management System. The last category is dynamic content. This is the domain data that is provides by the data in the database and any domain specific logic that manipulates the data.
For the domain layer the main consideration are where to put the domain logic. Two choices are presented. First is using an application server that is just a container for code. Other systems can look of the code and call it. EJB contains is an example of this. Most application servers (at least in the Java world) have web servers built in, so they do not need to be distributed. Another way is to use lightweight container. An example of that is the Spring application context that we have used in the course.
The considerations of the data source layer depend partly on the domain. The key is to allow structured access to the database. In the lecture we look at table gateways, which is a very common choice in enterprise software. Other choices are using Object-Relational Mapper tools, like Hibernate. These tools are by now very stable and can actually improve the data access due to the optimization that has been built in.
The slides and lecture video can be found here: Lecture L11 Application Architecture
Cover image by: wagaboodlemum
The World Wide Web is over 20 years old technology and can now be called a fundamental platform for software development. In the early days it was not clear that having a web interface would be the appropriate thing for enterprises. Today, it is the essential form. It is so important that we can consider the web as the default and standard interface to enterprise application, be they for desktop computers or mobile devices. My 10th lecture in my Design and Implementation of software is about Web Programming.
When the web started to gain popularity, mostly with static sites manually edited, most enterprise programs were client-server programs. These programmes were installed on users (employees) machines. Microsoft Windows was in the 90s the most dominant operating system so enterprise software was usually Windows clients that accessed some servers that had access to the database.
Most enterprise developers ignored the web as user interface since it was very primitive and clearly a step back. Each interaction, for example pressing a button on the web page, resulted in sending some request to the web server, generating a new page and sending it back. Compared with native Windows program, responsiveness was horrible for the web. Add to this the general scepticism on security issues.
However, the benefits of the web – its simplicity and universal availability outweigh the drawbacks and slowly people started to use the web as the preferred platform.
First programs were CGI programs. CGI stands for Common Gateway Interface. This allowed web servers to execute programs and use the output of the program as a response to the web browser. CGI could be written in any programming language but Perl became popular, not only because it is flexible and powerful, mostly because it is interpreted and does string manipulations very well.
All these technologies use very simple and fundamental design pattern that first appeared in the 70s, Model View Controller. The idea is to break user interface components into three distinct roles. The Controller is the entry of the request, and handles the parameters that come with the request. The controller uses the model for the “state” or domain logic, be it calculations or getting some data. The model will deliver some data that needs to be rendered. It is the responsibility of the view to render the user interface.
In the lecture, the Model View Controller (MVC) design pattern is covered and some ways to create the controller and the view.
The lecture can be found here: L10 Web Programming
One of the interesting types of programming is tracking behaviour. Most enterprise design patterns are about structure. For example, the Data Source Layer patterns introduced in lecture L08 are structural patterns. They deal with moving data to and from the database. They try to solve the impedance mismatch problem. However, they do not have any logic as to when and under what circumstances data should be loaded to from the database and when written. Clearly accessing the database is slow, and doing so needlessly hurts performance. This is where behavioral programming comes in.
Consider the problem of maintaining multiple objects in memory and working with them. Having updated them we need to persist them back. One way to do this is to load the object from the database, change them, then persist them again. Clearly that is easy to do and avoids any possible errors, for example forgetting to save the object back. Most request-response sites would do it like this. But what if you want to keep the objects in memory and write them to the database when the session is over? One way is to just flush everything out to the database but that does not take into account that many of the objects might not have changed. Then how would we keep track of objects that are changed and those that are not. The solution is to use Unit of Work design pattern.
The Unit of Work (UoW) pattern defines a data structure that keeps track of objects and their state. When an object is loaded, it is registered as clean within the UoW. Any update to the object and the status is changed to dirty. When time comes to save objects, the UofW knows which objects are changed and can save them to the database.
Another problem is due to loading of multiple objects. Let’s say you need to load objects and it may happen that the same object is loaded twice. This can cause multiple of problems, not only space and time complexity but also the risk of concurrency problems as two or more objects might be updated in memory with different updates. To solve this we can use Identity Map (IM), a data structure that holds all objects loaded. Whenever an object is needed we can consult the IM, get it there, but if it is not there, get it from the database and put it in the IM. Clearly combining the UoW and IM is a good choice. As a bonus, the IM works as a cache as objects that are needed multiple of times, are already in memory.
The third problem is with loading objects that have references to other objects. So if you load an orders object (to take the classical example) should you load the customer object also since the order object has a reference to the customer. One way to solve this is not to have object references to other objects in general but use ids and keep each object separate. However, we find ourselves with a solution which has a rich object graph and we need to solve this loading problem. This is where the design pattern Lazy Load (LL) comes in handy. With LL we place markers in the object indicating that the reference is not loaded, but when a get method is called, we will load the referred object and change the marker to indicate that the object is loaded.
In lecture L09 Behavioural Programming we look at these behavioural problem. How to solve issues like writing only changed record back into the database, loading only the needed data once, and how to load the data model partially. We introduce the three design patterns mentioned: Unit of Work, Identity Map and Lazy Load.
Last week, the annual EL/WLA Sports Betting Seminar took place in Marrakesh, Morocco. Betware got the opportunity to speak and I did a lecture titled Opportunity knocks… The talk was.
At a the resent Nordic game conference in Malmö I noticed that not many people carried laptops. Instead they had tablets, mostly iPad. Few speakers also presented using a tablet..
Tech news over the Easter weekend were dominated by one device: the over-hyped iPad. Every major and not so major tech source has done a review of this thing. Opinions.
Image that you are looking for a restaurant and you go on the Internet to find a good place to eat. Go to any restaurant website and you will get.
It was the year of the iPad, social networks, Farmville, Android, and Wikileaks Social was the term to describe 2010. Social networking, social media, social gaming, social everything. As usual.