Reifier: Model-Driven Engineering of Component-Based and Service-Oriented JEE Applications Jérôme Rocheteau1 and David Sferruzza2 1 ICAM / 35, avenue du Champ de Man÷uvres, 44470 Carquefou, France jerome.rocheteau@icam.fr 2 LINA - UMR CNRS 6241 / F-44322 Nantes Cedex 3, France david.sferruzza@univ-nantes.fr Abstract. This paper aims at presenting Reifier , a tool for prototyp- ing modules of JEE applications by the means of a model-driven develop- ment. Web services are dened as parametric components which enables to express web service patterns, to verify them formally and to reuse them in other contexts. Although Reifier requires developers to imple- ment components compliantly to a lightweight API, it provides modelers design exibility and verication support of their web service models. https://www.youtube.com/playlist?list=PLirnqO5cc9voQv_9NDQrRw9zaOsydYj0L Introduction ICAM drives 50 applied research projects per year in various application elds either as a supplier of companies within their inner short-term projects or as partner in long-term collaborative projects. In the information technology eld, projects mainly lead to develop prototypes based on web services, web technolo- gies and mobile technologies in order to highlight innovative features. Adopted approach mostly consists in a 4-step methodology: (1) need and requirement analysis that encompasses state-of-the art and reverse engineering of existing solutions, (2) modelling, (3) prototype development and proof-of-concept, (4) skills and knowledge transfer. In fact, models are central to this approach: on the one hand, they correspond to the outputs of the two rst steps and, on the other hand, they correspond to the input of the two last ones. It has been noticed that the average time spent for developing the prototype (including bug xes) is at least twice that of spent to modelling  whereas prototyping merely consists of transforming models into source codes. The opposite would be better: to spend more time in modelling and to save time in verifying model implementations. Thus, since 2014 and for its own applied research activities, ICAM began to develop a prototype, called Reifier, able to automatically generate the source code of JEE applications from a specic model of web services. A domain-specic language for web services has been designed in order to deal both with data and process models within the same model. Data model corresponds to entities with properties, inheritance and many-to-one relationships to other entities. Processes corresponds to parametric components dened by their inputs and outputs. The latter can be split, on the one hand, into atomic components, each of them linked to a computational unit manually developed and provided throughout libraries and, on the other hand, into compound components that stand for computa- tion ows. Web services can therefore be seen as component specializations over specic entities. We argue that such a meta-model makes possible to dene web service patterns which tends to reduce the number of atomic components in- volved in developments, and therefore the number of bugs introduced during developments, as formal verication is made possible thanks to the component- based formalization. Reifier's novelty thus consists in applying theorem proving techniques to web engineering and in demonstrating that it is relevant. This paper is organized as follows: The section 1 details the meta-model of web services and its associated verication operations (naming uniqueness, type system hierarchy, component consistency). The section 2 presents the programming interface required for de- veloping atomic components that ease their verication. The section 3 explains how JEE applications are generated from such models. Finally, the section 4 compares our approach to others found in the literature. 1 Meta-Model The meta-model of web services is dened by the means of the syntactic cate- gory model in the gure 1. It has been designed in order to match needs and requirements about verication. It does not aim to become another standard but rather to support mapping from and to web service meta-models like RAML and Swagger for instance. This category model is specied as a product type of 4 attributes: a name, a list of entities that stands for the data model, a list of components that stands for the process model and the web services that compose both entities and processes. Firstly, entities are represented by the syntactic category entity which is de- ned by its name and a list of properties. An entity can optionally inherit from another entity as specied by its attribute  entity:entity? . A property merely consists of its name and its type; a type being either a primitive type (string, boolean, integer, etc) or an entity. Primitive-type properties corresponds to the strict denition of entity properties whereas entity-type properties corresponds to many-to-one relationships between the entity that they belong to and the entity that they reference. This data meta-model consist in the minimal and common one among UML object-oriented data models (class diagrams), rela- tional data models and conceptual ones (entity/association diagrams). Secondly, components dened by the component as the sum type of abstract components or compound components. Both types of components are dened by their name, their lists of inputs and outputs and a list of parameters. Moreover, compound components own a list of concrete components. The latter correspond to abstract or compound components specialized with some valuated parame- model = (name:name,entities:entity*,components:component*,services:service*) service = (name:name,path:name,methods:method*) method  component[protocol:protocol,request:message,response:message] message = (content-type:string,content-encoding:string,headers:string*,type:type) protocol ::= get | post | put | delete | head | options | trace | connect component ::= abstract | compound abstract = (name:name,inputs:variable*,outputs:variable*,parameters:variable*) concrete = (component:component,parameters:parameter*) compound  abstract[components:concrete*] parameter  variable[term:term] term ::= variable | constant variable = (name:name,type:type) constant = (type:type,value:object) name ::= abstract-name(name:string) | concrete-name(name:string) | compound-name(names:name*) entity = (name:name,stored:boolean,entity:entity?,properties:property*) property = (name:name,type:type,required:boolean,indexed:boolean) type ::= void | string | boolean | integer | oat | date | entity Fig. 1. Meta-Model of Web Services ters. The name of abstract component stands for the Java qualied name of its implementation. Finally, a web service  formalized by the syntactic category service  is de- ned by its name, its path and a list of methods. The syntactic category method extends that of concrete components i.e. it specializes a given abstract or com- pound component by valuated parameters. Such methods then consist of wrap- pers around concrete components with a given method protocol the signature of its required requests and that of its provided responses. Verication Model verication focuses on names, entities and components. Ver- ifying names consists in detecting naming collisions i.e. dierent elements in a given model have the same name. It is also veried that only inputs and outputs of abstract or compound components can be parametric names; neither entity, component, service nor parameter names can partially be dened by a param- eter. Moreover, some naming conventions are veried: for instance, each entity (resp. component, service) name has the model name concatenated with "enti- ties" (resp. "components", "services") as a namespace. This naming convention verication ensures that no conict will happen during source code generation i.e. a single le will be generated twice for two dierent model elements. If an entity (resp. a component) does not verify such a condition, it is assumed that it points to an existing third-party entity (resp. component) and a verication is therefore performed in order to ensure that this entity (resp. this compo- nent) is provided by a library. Verifying entities consists in checking that the type system is well-founded i.e. that no cycle exists over entity inheritance rela- tionships. Verifying components as well as methods of services consists, rstly, in checking that abstract component implementations meet their specications (see section 2) secondly, in checking compliance between input and output types of inner components of compound components and, thirdly, in checking that every parameters of a concrete component must be declared by its inner compo- nent. It is also veried that inner component output exists within a compound component that overrides the output of one of its previous inner components. Moreover, every services must embed only components without any free variables or non-valuated parameters. 2 Programming Interface An application programming interface (API) for developing implementations of abstract components is provided by the means of a Java library that contains:  2 Java interfaces: Component and Resource,  5 Java annotations: Parameter, Input, Output, Request and Response. This API involves that of the Java servlets. The Resource interface merely consists in two methods setUp and tearDown able to initialize and nalize ob- jects. The rst method setUp is applied to a servlet context as parameter. This API therefore enables resource implementations to provide some real resources throughout servlet context sessions. Such resources can be shared between sev- eral components while initializing them. In fact, the Component interface species three methods setUp, tearDown and doProcess. Whereas the rst method setUp consists of initializing objects of classes that implements this interface, the second one corresponds to its dual i.e. it consists in destroying these objects. The rst method is applied to a servlet context and a servlet conguration which makes possible to retrieve some re- sources previously inserted into the servlet context attributes. Hence resources can be shared between several components. As for the third method doProcess, it denes the computation of such components. Abstract component implementa- tions can then process HTTP requests and responses such that it makes possible to wrap them into HTTP servlets in order to build computation ows. The ve annotations provided by the Reifier API bridge the gap between component specication and their implementations. In fact, they are used to ver- ify that component implementations meet their specication. These annotations all concern either elds or local variables within component implementations. They are all dened by a name and a type that must comply the Reifier type system. This means that types are either primitive types or entities that are dened by qualied names of Java classes or interfaces. Types can also be refer- ences to parameters of these component implementations which type is a Java class. The latter corresponds exactly to parameter terms that are variables in the Reifier meta-model. That is why these annotations could ease verication of abstract components as Reifier type system is embedded into component implementation annotations. However, this correspond to a shallow verication as the compliance between annotations and the elds or local variables that they concern is not veried. This API encourages developers to provide ne-grained and focused compo- nents throughout their libraries as compound component and service implemen- tations are automatically generated from a given model as well as web service descriptions. However, it does not tackle side-eects, asynchronous method calls, rst-order pre/post conditions within component implementations, as this API has been designed to be the more lightweight possible for developers. 3 Model to Text Transformation Code generation is performed thanks to a Maven plugin and generated JEE applications rely on the Reifier API library, Hibernate core library and on Hibernate Search library when plain text search is enabled for some indexed properties of entities (i.e. when the indexed attribute of an entity property is set to true). These libraries remains the required dependencies involved by the source code generation. It reads a XML le that describes a model compliant with the meta-model presented in the section 1. Models are then built and veried before being serialized by the means of a template engine as follows: Firstly, entities are created as Java classes. The name of these classes is pro- vided by the name of the entity. Private elds are declared within such classes from the entity properties, the name of elds is provided by that of properties and its Java type is dened either by Java primitive type wrappers that associated to Reifier primitive types or by Java classes that are generated from entities. A specic eld called id of type long per stored entity (i.e. those which attribute stored is set to true in a given model) is inserted that stands for the identier or primary key of these entity occurrences. These Java elds are annotated by annotations that are provided by the Java persistence API, the Hibernate API and the Hibernate Search API accordingly. Public setters and getters for such Java elds are inserted within these Java classes. The latter do no hold nei- ther constructor nor other specic methods. These classes correspond to data structures only. Moreover, a XML le is also created that species a Hibernate object-to-relational mapping between these Java classes and SQL tables from stored entities. Secondly, compound components are created as Java classes that implements the Component interface provided by the Reifier API. Private elds and asso- ciated setters and getters are inserted within these classes from the parameters of their components. The setUp method constructs every inner components and calls their respective setUp methods. In the same way, the doProcess method (resp. tearDown method) merely calls inner component doProcess methods (resp. tearDown methods). Moreover, every methods of services are created the same manner as Java classes that implements the Component interface; their Java class name is provided by their service name with their protocol name as sux. Thirdly, services are created as Java classes that extend the HttpServlet class. A private eld is declared per method, the protocol name provides this eld name. The Java type of such elds is dened by the generated class of these methods. Finally, the XML le web.xml that species, on the one hand, the previous servlet context listener and, on the other hand, both the available paths and their associated HTTP servlets is generated. This achieved the model-to-text transformation that reies the JEE application. In addition, a Java class that stands for a HTTP client is created per service thanks to the Apache HTTP client library. Every HTTP clients have a string eld that corresponds to the server name of the generated JEE application. They all have two methods setUp and tearDown with no parameter for initializing and nalizing them. They also have a Java method per Reifier method; its return type is dened by that of the Reifier method response and, potentially, such Java methods have an argument dened by the Reifier method request. 4 Related Work This work follows the recommendation from [6, Ÿ6] that meta-model approaches are suitable for server-side code generation instead of a meta-programming one. Moreover, the meta-model presented in the gure 1 share the same concepts with that of [4]. In fact, web services are dened as pairs composed of a process and a behavior. Processes correspond either to an action (single-step process) or a composite one (multiple-steps process). In addition, single-step process are specied by their behavior that consist in inputs and outputs but also in pre- conditions and eects. Although our web service denition takes into account inputs and outputs, it lacks of higher order specications as preconditions and eects. A interesting way to embed preconditions or eects into our approach can be drawn out from [5]. In fact, a innovative web engineering methodology is designed that starts by extracting requirements from mockups i.e. quick designs of application use cases and end-user screens. Then, some renements can be introduced into extracted models with the concept of tags. Tags help to specify application features such as some operations over data structures, navigation, search queries, specic actions, etc. This tag system seems lightweight for de- velopers or modelers and this could be applied to our work through out Java annotations for atomic component implementations. This work is highly related to that of [1] with the Declare tool and those from [2] to [3] with the M3D tool, the latter extending the previous one. In fact, M3D generates web application code source from a 4-layer meta-model: information layer by the means of UML class diagram, service layer by the means of BPMN, presentation layer by the means of ad hoc meta-model and a process layer by means of Declare an event constraint language based on the temporal logic LTL. Code generation is achieved using a model-to-text approach with the Xpand language. These tools aim at providing developers the higher exibility possible as well as the better support possible  the less to develop and verify but the easiest to customize. This exactly is Reifier development main guideline. Our work specially focuses on the design-time support (see [1, Ÿ 3.1]) even if still requires to explicitly express services and it does not yet support formal verication. These tools have a lot in common with respect to these guidelines. However, they dier one to another at some extent. The main dierence consists in the fact that M3D generates web applications i.e. both server-side and client- side applications whereas Reifier only generates web services i.e. server-side applications although it used to generate both sides on its earlier versions. Conclusion Reifier has been successfully applied to the development of several JEE appli- cations. It has been noticed that the set of abstract component implementations reaches both quantity and quality stability over the time. It then reduces the lines of code manually written and, therefore, the number of bugs. It tends to reduce development time for server-side JEE applications and to dispatch eort dierently: less for developers, more for designers. Three main prospects are here sketched: The rst prospect corresponds to an ongoing work at ICAM and consists in building other model-driven approaches on the top of Reifier thanks to model-to-model transformations. This is investi- gated for service-oriented management systems of sensor and actuator networks. The second and third prospects are investigated during David Sferruzza's PhD thesis. It rstly consists in turning models into parametric models in order to dene explicit design patterns. It secondly consists in strengthen verication by the means of formal methods; an axiomatic semantics for components that could reach this goal has been designed. References 1. van der Aalst, W., Pesic, M., Schonenberg, H.: Declarative workows: Balancing between exibility and support. Computer Science - R&D 23(2), 99113 (2009) 2. Bernardi, M.L., Cimitile, M., Di Lucca, G., Maria Maggi, F.: M3D: a tool for the Model Driven Development of Web Applications. In: Fletcher, G.H.L., Mitra, P. (eds.) Proceedings of the Twelfth International Workshop on Web Information and Data Management, WIDM 2012, Maui, HI, USA, November 02, 2012. pp. 7380. ACM (2012) 3. Bernardi, M.L., Cimitile, M., Maggi, F.M.: Automated development of constraint- driven web applications. In: Proceedings of the 31st Annual ACM Symposium on Applied Computing. pp. 11961203. ACM (2016) 4. Lautenbacher, F., Bauer, B.: Creating a meta-model for semantic web service stan- dards. pp. 376381. INSTICC Press (2007) 5. Rivero, J.M., Grigera, J., Rossi, G., Robles Luna, E., Montero Simarro, F., Gaedke, M.: Mockup-driven development: Providing agile support for model-driven web en- gineering. Information & Software Technology 56(6), 670687 (2014) 6. Scheidgen, M., Etinge, S., Marticke, F.: Metamodeling vs Metaprogramming: A Case Study on Developing Client Libraries for REST APIs. Lecture Notes in Com- puter Science, vol. 9764, pp. 205216. Springer (2016)