Download the entire article in PDF format.Once we got challenged by the statement that Festa might work well in a 'monolythic' architecture, but would not be suited to be applied in an advanced partitioned application architecture. Judge for yourself if we pass the test ...
Introduction
The standard architecture of a Festa application is always depicted as follows:
In general this translates to a development environment setup as follows:
- Model project
- JEE project
- UI 1 project
- ...
- UI n project
These projects are developed 'synchronously' with a deadline in mind where all projects will be released together. All applications will be migrated and deployed in one single maintenance window.
This approach works very well. Especially for applications below 2000 FPs, it is vey much recommended to work this way. However, for applications extending beyond the range of 2000 FPs, the need for partitioning will arise. The same need will apply for large organizations with a large IT infrastructure in place.
Partitioning is the exercise to split an application into smaller, independent parts. A first step is to start partitioning within the application and creating 'functional modules'. A next step is to actually start treating these functional modules as individual applications themselves and possibly even host them on different system landscapes.
The subject of this article is to investigate how Festa technology supports application partitioning. As you will see, Festa supports three partitioning strategies:
- Module Partitioning
- Vertical Application Partitioning
- Horizontal Application Partitioning
To illustrate the partitioning strategies we will use an insurance application as an example. This application has 2 user interfaces: a full-fledged back-office application built with Adobe Flex technology and another self-servicing application that allows customers direct access built with Java JSF technology. On functional level, the application contains customer relationship management (CRM) functionality and insurance administration functionality (INS).
Module Partitioning
When applications become larger, the need will arise to scale up in the development team. More developers will be added and potentially also more information analysts.
The current technology for source control (subversion, among others) is very well able to support larger team settings as long as you are working with text files, and preferably many small ones instead of a few large ones. The 'merging' technique will facilitate the process of multiple people working on the same (text) file.
However, if it comes to binary files, this 'merging' technique is far from flawless and highly likely will fail to support simultaneous working. The 'locking' technique is then applied to circumvent this issue. With locking one person will claim the 'possession of a file'. During this period only this person is allowed to check-in a new version of the file. Other people, who want to acquire a lock on the already locked file, will get an error message.
In small teams, as Festa teams are, in general the 'locking' technique works out fine. However, the moment you start scaling up, the contention becomes more and more of a problem. Module partitioning is then a strategy that can be put to practice reducing the contention headaches.
Module partitioning is very much comparable to refactoring a large class into a few smaller ones. With module partitioning the model is split up in modules. Each module is one file. A module can 'use' another module. UML contains the feature that UML elements in a 'using module' can associate with UML elements from the 'used module'. This technique enriches the UML elements from the 'used module'. Festa plug-ins will accommodate for these extra associations on these elements.
Festa DSL Standard Module Partitioning Strategy
Actually, the Festa DSL comes standard with an out-of-the-box module partitioning strategy as is shown in the diagram below:
A Festa model partitioned following the standard Festa DSL strategy is built upon 2 modules.
- Functional Module (maintained by the information analyst)
- Actor (A)
- Use Case (U)
- Domain (D)
- Data Transfer Object (T)
- Implementation Module (maintained by the developer(s))
- CRUD Service (S))
- Report Service (R))
- Entity (E))
- Connector (C)
For full code generation, Festa Engine will take the 'outer' module as input. From the 'usage' relations it will automatically include the used modules, which can be a deep-nested tree structure. However, for validation purposes it is very much possible to define a Festa Engine launch configuration that takes the functional module as input. This is an interesting thought, since it enables the information analyst to run Festa Engine in order to validate his/her changes to the model, without actually generating code.
DSL Element Category Module Partitioning Strategy
In an extreme form, it is possible to apply the module partitioning strategy on each Festa DSL element category:
This will lead to 8 module files. The Connector (C) module would be the 'outer' module.
Although we think that this strategy is not very practical, it shows the full possibility behind module partitioning.
Functionality Based Module Partitioning Strategy
The example insurance application can be divided into 2 functionalities:
- Customer Relationship Management (CRM)
- Insurance Administration (INS)
It would definitely make sense to split the model up in modules following this division. It also makes sense to apply the standard Festa DSL module partitioning strategy. This mix results in the following module definition:
In a set-up like this, it is possible to have 2 information analysts working in parallel. One would be working on the CRM module and the other on the INS module. Their work would not interfere. The same division applies for the developers working with the implementation modules.
The outer module in this example is the 'INS Implementation Module'.
Vertical Application Partitioning
In many configurations the UI applications will be built alongside the JEE application. This is very much defendable, since in general when you are adding functionality to a JEE application, it will affect the UI applications as well.
However, in some scenarios you can imagine that this is not entirely true:
- Modification of Look&Feel for a user interface
This normally would not affect the JEE application and/or any other user interface application. - Dedicated use case for a certain user interface
Imagine that the Flex back-office application needs a new dashboard feature. This probably affects the JEE application and of course the Flex application, but not the JSF self-servicing application. - You could devise outsourcing schemes where the JEE application is built in-house, but the user interface development is outsourced to an external company.
These scenarios raise the need for partitioning the application development 'vertically'. The diagram below shows the run-time environment of such architecture:
In a vertically partitioned application set-up the applications (Flex, JSF and JEE) can have different life and release cycles. The applications can be built by different IT providers and are possibly hosted on different system landscapes.
Remember that one model governs these three applications. So, how does Festa cope up? Study the next slide:
This slide shows the typical Festa development environment for the example insurance application:
- Model Project
Holds the model files (possibly organized following some module partitioning strategy) - JEE Project
Holds both the generated and manual source files for the JEE application - Flex Project
Holds both the generated and manual source files for the Adobe Flex application - JSF Project
Holds both the generated and manual source files for the Java JSF application
To generate the files for the JEE, Flex and JSF applications, three Festa Engine launch configurations need to be defined:
- JEE Project
includes the plug-ins DSL, JEE and JSON Connector (configured in JEE-mode). The JSON connector will only generate JEE related skeleton files. - Flex Project
includes the plug-ins DSL, JSON Connector (configured in Flex-mode). Note that here the JEE plug-in is not included. The JSON Connector will only generate Flex related stub files. - JSF Project
includes the plug-ins DSL, JSON Connector (configured in JSE-mode). Note that here the JEE plug-in is not included. The JSON Connector will only generate Java related stub files.
In development environments where the applications are all built alongside each other, there is probably one single source repository. Team members will likely have all projects mounted in their IDE. We call this 'monolithic release management'. It is then convenient to have the Festa Engine launch configurations stored in the model project.
However, it is perfectly possible to split this up. Each project could potentially be stored in dedicated source repositories and released independently. The applications would have a 'binary' dependency on the models. We call this 'individual release management'. The application projects would then contain the Festa Engine launch configurations themselves.
The difference in release management is shown in the slide below:
Horizontal Application Partitioning
If applications become truly large (threshold will be around 2000 Function Points), the need will arise to split applications horizontally. For the example insurance application it sounds logical to create a CRM application and an INS (insurance administration) application. Of course we want to add the requirement to be able to host these applications on different machinery.
This is easier said than done. Let's focus on the JEE application. The diagram below shows how the separation would look like:
It is fair to assume that the insurance administration functionality has a unidirectional dependency to the CRM functionality. A new insurance policy will be linked to an existing customer. Business rules will exist that certain customers are not eligible for certain insurance products.
In one single JEE application, this dependency is fine. To implement the insurance administration business rules, the required CRM information is not far away. With two separate JEE applications, this becomes another story.
Use cases can be divided into 2 categories (in the spirit of Function Point Analysis):
- Input Functions (EI)
Use cases of these kind are typically CRUD use cases and workflow use cases and are characterized by the limited amount of information involved: one policy, a few customers, etcetera. For this limited amount of information it is feasible to consult the JEECRM application remotely. It will degrade performance, but this is probably within limits. - Output/Query Functions (EO/EQ)
These use cases are characterized by the large amount of information involved. Queries like 'give all policies for customers born between 1960-1965' can return multiple (even many) hits. This is the main challenge: how to realize these 'cross-application queries'?
One solution to implement 'cross-application queries', is to copy the necessary (subset of) information from the dependent application to the depending application. In the example insurance application this would mean that JEEINS application will contain CRM information for query purposes.
We will not go into debate here if this is the best solution, or whether there are other solutions possible. We do think that any other solution is either database vendor specific (and hence for us out of scope) or a variation on this theme. We will also not discuss here how the information is to be synchronized between the JEECRM application and the JEEINS application, since this is a study on its own. We warned in the beginning that horizontal partitioning is easier said than done.
How does Festa cope up with horizontal partitioning? This is shown in the slide below:
Since we now have 2 JEE applications, we will also have 2 models governing them. The Festa Engine launch configurations are similar for both JEE projects: DSL, JEE and JSON Connector plug-in (in JEE mode).
However, since the JEEINS application is a consumer of JEECRM use cases a third Festa Engine launch configuration needs to be in place. This launch configuration will generate the Java stubs in the JEEINS application from the JEECRM model and only includes the DSL and JSON Connector plug-in (in JSE mode).
The last slide shows how the horizontal partitioning strategy applies for all applications (UI included):
