In today’s guest post, Roberto Rodriguez-Echeverria, Víctor M. Pavón and Fernando Sánchez-Figueroa introduce the MIGRARIA project.
MIGRARIA defines a model-driven systematic and semi-automatic process to modernize legacy non-model-based data-driven Web Applications into Rich Internet Applications (RIA).
Its main motivations can be summarized in two issues. First, there is still a lot of enterprise systems laying behind Web 1.0 layers, then neglecting the added value provided by new interface technologies such as better performance and user experience. And second, during the last years we are attending to the rise of new technologies redefining the way people is accessing applications on the Web, such as, the ones related to Web 2.0, or RIA or, more recently, the ones defined for mobile devices. That way companies are constantly facing the effort of implementing new interfaces to their enterprise systems to increase or at least to keep their market share. In this context, MIGRARIA aims to alleviate such efforts by applying sound model-driven engineering methods and techniques.
The legacy web applications (LWA) considered within MIGRARIA are mainly characterized by:
- Most of them were designed as web front-ends of enterprise information systems.
- They were developed before MDWE approaches were mature enough, so no MDE methodology was applied in their development.
- They were developed by means of Web application frameworks (WAF) that implement the MVC pattern and use a collection of heterogeneous technologies.
- Additionally they usually present a lack of documentation and good maintenance strategy.
A modernization process
MIGRARIA conceives the process of developing more refined and interactive interfaces for an existing enterprise system as a modernization process. We think the best target architecture representing this evolutionary scenario is the one presented by the next figure.
From a conceptual point of view, the target system can be seen as an extension of the original system. Its main components are: a RIA client and a server-side connection layer providing the generated client with different modes of operation with the underlying business logic at server side.
The defined approach is fundamentally organized in two different stages: (1) generation of a conceptual representation of the legacy WA; and (2) generation of the RIA front-end and its infrastructure.
On the first stage, to get a comprehensive representation, the process framework performs static and dynamic analysis of the software artifacts at both client and server side. Then the models extracted can be refined to eliminate redundancy and ambiguity producing intermediate representations. In this sense, the process defines three different information extraction plans: RE-C-D (Reverse Engineering-Client-Dynamic), RE-S-S (Reverse Engineering-Server-Static) and RE-S-D (Reverse Engineering-Server-Dynamic).
During the last year, the RE-S-S plan has been defined. This plan entails reverse engineering sever-side software artifacts by means of static analysis.
First of all, we have defined a conceptual representation (Struts-MVC metamodel) to specify the information related to the navigation from the point of view of our WAF of reference: Struts 1.X. Additionally, we have had to define Struts-technology-dependent metamodels in order to get a comprehensive representation of the Web layer of the LWA (Struts-JSP, Struts-Config and Struts-Java metamodels).
Once defined those metamodels, by means of MoDisco, we perform text2model transformations to generate models from every software artifact of the LWA. And finally, by means of ATL, we define a model2model transformation to get an homogeneous representation which integrates all the navigation information scattered over all the software artifacts into only one uniform view.
Optionally, an additional step can be performed to generate a conceptual representation according to a concrete Model Driven Web Engineering approach. Some experiments have been performed to obtain WebML and OOH4RIA representations of a LWA. They have helped us to validate and benchmark our approach.
Regarding RE-C-D extraction plan, we have been analyzing different dynamic extraction techniques at client-side and we are currently evaluating the best integration approach with the work we have done at server-side. And RE-S-D extraction plan is on an early experimental phase. Describing the second stage of MIGRARIA project is out of the scope of this post.
More information about MIGRARIA project on: http://www.unex.es/eweb/migraria
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
MIAGRA would’ve been funnier as an acronym 😉
Anyway, some serious remarks/questions:
1. Reason 2 is not a reason unfortunately, as it would imply that all projects would’ve been MDE-projects…
2. The architecture/paradigm/convention of the source application seems to be quite fixed (4-layer, Struts 1.x for describing flow, etc.): how moldable is this approach if those “meta parameters” change?
3. Have you thought of making the harvesting of the source code highly manual-automated in the sense that the discovery rules are more-or-less 100% custom per application but that the target harvesting meta model is fixed and the subsequent m2m is as well?
Meinte,
Thanks for your comment!
“MIAGRA: powerful MD performance when you want it” Interesting… I note it down for a future project 😉
“No MDE projects” was not stated as a reason but as a characteristic of the legacy systems we are considering. The application domain of our project is roughly defined by legacy systems with those four characteristics.
Though we have used Struts 1.X as WAF reference in this work, MIGRARIA process is defined at a more abstract level. Basically, it is driven by the idea that any WAF based on MVC pattern shares a core set of conceptual elements. They are implemented on different ways by every WAF, so we focus on defining a common representation for them. That way we think our approach is adaptable to different configurations of such “meta parameters” defined at technology level by providing the proper m2m transformations from technology-dependent models to our MVC-based models.
Finally, MIGRARIA process is conceived to assist the engineer in the modernization tasks by providing the information at the proper level of abstraction to help her making the right decissions. We are currently working on the tool. We dont think dicovery rules are 100% custom per application, we state there is a high percentage related to the implementation technology. Then we focus on identifying those common implementation patterns on the involved technologies. So we can reuse those rules on the modernization of different applications sharing a common implementation technology.