During the past couple of years Dirigible evolved from an RAP based Web IDE for simplification and adaptation of SOAP based Web services to a full fledged Dev Platform with its own yet unique to some extents architecture and features.
Besides the main driving principles like In-System Development Model, Dynamic Alteration, Content Centric LM, Toolset Completeness, Vertical Scenarios Coverage and the other concepts that can be found easily at the front pages at the Web site, here we will give you more detailed insights of how Dirigible compares to the other similar frameworks and platforms. We will explain the current focus, priorities and future vision.
Blocking vs. non-Blocking
Events and Flows
There are plenty of package management tools and dependency management descriptor files out there. Starting with the fact that the major Linux distributions use their own package managers such as APT, RPM, YUM, Zipper, throughout the language specific “default” descriptors such as MANIFEST.MF, package.json, gemspec, etc. and even the build tools dependency descriptors such as pom.xml, build.xml, bower.json, etc. it seems that there is no a silver bullet solution for this problem… obviously. What is for sure - the problem is complex and as much as one tries to fix it completely with very descriptive manifest files and complicated algorithms for strict dependency resolutions, the outcome is that the manifest files become too hard to be maintained. This leads to incorrect content and at the end leads to the fact that it is quite difficult to have such systems, based on such strict dependencies up and running at all. The “global install” has its drawbacks e.g. with version conflicts via transitive dependencies, but to go to the ‘npm’ style that leads to duplications is simply unacceptable. Another unacceptable decision is the strongest OSGi approach, which could prevent a plugin or even the whole application from starting, if there is an unsatisfied dependencies issues. The standard Java way so far, with no explicit dependencies check at all at run time, beats them all. Yes, you ever face such a problem, it will happen at the worst possible time - when somebody actually start using the chain, which has a dependency issue - Class Not Found case. In the same time you can work with all the other chains, which do not have any issue. In theory this is wrong because it is not perfect, but in the reality this is the only working model for the large scale applications combining huge set of components contributed by the teams that are distributed and diverse. Hence, in Dirigible we choose the “non-blocking” approach - the dependencies declarations are only to help you to navigate and pull the right components, without stopping you if a single dependency is not present at the moment.
Domain Driven Design vs. Model Driven Architecture
Domain Driven Design (DDD) is the natural choice of what Dirigible aims to provide - the dev platform for business services. The starting point of the development of a business application is the definition of the domain model entities. At this phase nothing else matters - only the players and theirs interactions. The ultimate goal of any toolkit is after this design and definition phase to generate and run a full-fledged application auto-magically. We are not there yet, although you can in just a couple of seconds expose your entity from a database table, thru the RESTful service with pattern-based HTML5 user interface. But the important point here is that we know this kind of automatic generation is just to have a scaffold as a preview quickly. In this way we can have an idea how the real application will look like eventually, when it is ready. The real work on customizations based on the consumer’s requirements just begins. What happens if you have to change the model, but you have already made lots of changes in the generated code? Bad news, you have to do them again after the generation of the new artefacts or you can skip the generation step and go and apply the needed modifications derived from the model changes on your own. Can Model Driven Architecture (MDA) help here? If yes, do we see MDA as an essential part of Dirigible? In short - yes for both. Sometimes the “preview” state is good enough to be used “in the time being”. But we have to be clear here, such a “magic” that can solve this problem completely - does not exist. MDA approach comes with performance degradation it is never optimized enough for your specific case. User interface is never fancy enough nor extensible enough. The behavior that comes from the MDA framework doesn’t necessarily match your need, but it is hard or impossible to change. Hence, in Dirigible we see DDD with one-time generation as a primary approach and MDA as just an option.
Microservices vs. Monoliths
There is a big noise related to the Microservices concepts although they are neither new nor unknown in the technology space until now. How do they reflect on Dirigible? How can we build a business application in the Cloud following the Microservices architecture? First of all it is possible to do this. What’s more, in Dirigible this style of componentization is even kind of enforced. But here comes the major difference - in Dirigible we leverage an unified platform, which the services can run on - the Dev Platform. Hence, whether you decide to divide your components to run on separate instances (to scale separately) or to have them all in a single instance - this is entirely your choice. We keep the unified approach, because in the most of the cases the performance of the local communication channel between the components, for example, is the only acceptable choice. To be fair here, the Microservices architecture does not come because it is the best option - that is because this is an approach to solve the current situation, where many different components are written in different languages, run on different platforms, hence the unification for the deployment of all these can be done only at a very low level - OS, VM, containers and the communication channel can be established on a very high (and expensive) level - TCP/HTTP/File System.
Roles Separation vs. One Man Army
Depending on the project scale, there is a common suggestion, which constantly appears - separation of roles. This leads to the implied conclusion that the different roles (personas) mean different persons. And this, on the other hand, means that the different persons can use different tools during the development process of a single solution, doesn’t it? In Dirigible we take this very seriously - we strive to provide the full set of tools as well as runtime foundation required by all the roles concerning a given project. Whether you will decide to bring the whole crew to work on the project or you will do it alone - it is your decision - you can do both. Dirigible claims to cover all your needs, with the appropriate tooling and runtime engines to develop your next generation business application.
Open Source vs. Proprietary
Dirigible is an open source project. It is based on a huge set of the open source frameworks. If there weren’t such open source methodologies and initiatives, our world would never be the same, that’s for sure. Dirigible would have never appeared. The collective intelligence - the major benefit of the open source, proved already many times that it can beat any other proprietary yet closed way of innovations. This leads us to the natural evolution of the Dev Platform concept - Dirigible to be used as the unified foundation for open source business services and utilities. Stay tuned for the exiting news in the next couple of weeks.