I wrote this small article for the EC some years ago and I think it's not out of date. I wanted to explain to the management why I choose and promote the N-tier architecture with JSON micro services. These concepts are older than me like the dll or the remote procedure call, etc. But it was never perfect. With the XML SOAP and web services it was a good try. But they are not fast enough, consume a lot of energy too. Rest services or micro json services help really for the scaleability and the separation of layers. I also learn that small dedicated applications is better that huge one. Micro services and modern web client application can really help to achieve that.
From my experience with the application of the commission the best architecture is a SOA architecture. Because the SOA architecture is not based on language but on communication between layers and on a structure that fit from the bottom to the top the entities of an application. Base also on reliability, interoperability, scalability. Even if at the commission, as I know, we only use Oracle, MySQL, Java, ColdFusion, PHP (Drupal), SharePoint (SQL server ?). All these technologies can talk to each other’s. The aim of this architecture is also allowed an easy maintenance by reducing complexity. And in bonuses you can consume other services instead of developing it, again and again…/
They've at least three layers in applications with end users.
1. The Database Layer (Oracle, MySQL,…)
2. The Process Layer (Java, ColdFusion, php,…)
3. The Presentation Layer (HTML5, CSS3, JavaScript)
The database layer can be split depending on the complexity of the applications and for security reason, same for the process layer.
They can have a discussion on which layer the business should be written. Database layers or process layers.
Most of the business I had to handle in the past can be done in Oracle. But this validation should also be a service and be isolated from the basic DML functions. Because it can be called, for instance, by the presentation layer too. But for any reason it can also be in the process layer. The important it's not to mix, spread the same business rules through different layers. But at the commission the stables technology since more than 20 years is Oracle. It’s the reason it’s a good first choice. But it can depend on the complexity of the business.
One of the important things, it’s to respect basic development rules like split the code in functions/classes. And it’s really language independent… Who never see function of thousands of lines in Oracle to validate a transaction. It’s sure, it’s not a thing to do.
I would like to put in evidence that in the SOA architecture each layer should do for what he was designed. I’ve the feeling that each layer would like to say. “Hey, I can do what the other does.” So JavaScript does business, Oracle has HTTP server, java compile HTML, JavaScript and CSS. And in ColdFusion it was, why not put everything in a page, I’m all by myself…
The important in SOA architecture it’s not to have specialized developers but full-stack developer. That’s meant a developer should be good in all the layers, even if he only does one layer on the projects. It’s better if he’s good in all technologies and has some affinity with one. Each developer of layers should understand all the concepts and respect it, work for it also. Each developer should also backup the other developer. It can be hard if you don’t know one of the languages. But usually, you can imitate what the other do and understand it. Also a developer should be able to develop this architecture alone. Even if sometimes you need a kind of consultancy for optimization but usually full stack developer have stronger point, it’s also promoting co-operation and knowledge sharing. SOA should be working together instead of “That’s not my problem, it’s not my technologies…”
The process layer is usually a thin layer we do most of the time data in, data out. ColdFusion was easy to use to do that receive JSON by post or get translate it for the call of oracle storeproc and send back some JSON. This layer mainly allows the UI to talk to the DB no more. But it can be done easily in php , java, … the important is in that layer they’ve no database queries, no HTML generation.
The interoperability of the communication between process layer and database layer can be more encapsulated like in some java or .NET framework. But as we only use Oracle and MySQL and never, as I know, at the same time, it’s not a big deal. Each layer must be split to become the more atomic they can. Complexity can only come from multiple smaller service or DB call. From these kind of architecture, it’s also easier to generate code from a template to keep development more consistent. It’s also easier to do unit testing. The presentation layer can be developed independently of other layers by consuming static JSON files. But even if we go to mango DB for specific project ColdFusion and java can communicate easily with it and still respect the service agreement between the layers. As java and ColdFusion can be replaced in the future by NodeJs without any trouble with other layers.
It’s also interesting to identify which services the application will generate and which services it will consume. For instance, in Infrep, they’ve service that must come from outside like the get user info, get user grants, get user roles, etc. It should come from service of port security. We also use a table for the organisation unit inside your DG. But it can also come from PORT or even from another DG! But we need a specific functionality, like history or snapshot.
SOA architecture also means rapid development application. All must be simple, fast and structured. Rapid doesn’t mean bypassing all rules. It also means work in teams inside the DG and outside the DG.
It’s also important in the presentation layer to not mixed concept. The UI must be friendly, responsive, and rich. But it must be staying simple and maintainable by everyone. And less you use libraries, better it is. It’s the same for all languages and technologies. But maybe more true now as the web evolution is quicker than the rest. And it’s the layer where the business ask the most often for modification.
All layers should also be split vertically by functionality, action in services. To be easily rewriting or removed. It’s important to limit dependencies, it’s more the REST philosophy. I should be able to go to that screen without passing by 5 steps on top, direct access it’s very important.
The problem with SOA architecture is that services multiplied quickly and you’ve to maintain a directory of services. They’ve standard for classical SOAP web service but it’s not the case for REST or JSON(micro) services. They had tried but it seems that they don’t have a big success. Even if an enterprise bus seems to be a solution, it must come from DIGIT and be adopted by all DG, at a level of DG we can just make a bus stop… Implement security is not out of the box especially with rest services.
http://www.service-architecture.com/articles/web-services/web_services_explained.html
The good thing with SOA architecture that respect tiers, it’s that you can easily make code generator and use templates.
I also prefer one shot code generators instead of an application that does all by itself and adapt itself in real time depending on what they’ve in the data or data structure. Like Stakeholder for instance. Usually, the result is quick but the maintenance is very expensive and built gas factory. It also makes made a unit testing easier.
Application is rarely finished, it’s like a continuous development. And a SOA architecture is more maintainable and scalable than other architectures.
The SOA application has the advantage to use multiple languages, technologies but rationalised. It also open up the world of re usability or the use of services in multiple applications and even inter DG. The SOA architecture is not dependent on a specific language. But one of the aims of this architecture is that everyone communicate in the same language (formatted json, SOAP,…) even if the native one is different. SOA architecture allow to use the best of all technologies with the KISS principle in background or at worst split complexity or hide it to over layers... A layer can be rewritten without impacting the others. It’s strange, for me, when you’ve to change the colour of a button that you’ve to recompile a package, or go to the database modify table data, or if you change the name of a table field you’ve to change the user interface, and some ColdFusion files and so on. SOA avoid that.
I also prefer applications where database is made handcrafted respecting all the best practice. Data should be the most important thing in an application especially if you want to make big data and keep it usable. It’s not linked with the architecture or language but it is obvious that all the data should be used at a higher level. And the database should be explained by itself not by the application that uses it. And even if an application died, the data should not.
(*This point of view was shared with Richard, Tan, Joël and Serge and also approved by them. A rewriting of port security was done with success to do a proof of concept (in a WE), a working prototype of code generators, too (More days of work and it is still at an early stage). The technologies used was Oracle PL/SQL, ColdFusion 10 and HTML5, CSS3 and JavaScript (jQuery and bootstraps)