This paper aims at presenting Reifier, a tool for prototyping modules of JEE applications by the means of a model-driven development. 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 implement 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
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 technologies 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 computation 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 involved in developments, and therefore the number of bugs introduced during developments, as formal verication is made possible thanks to the componentbased 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 developing 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
The meta-model of web services is dened by the means of the syntactic category 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 dened 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), relational 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 paramemodel = (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 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 dened 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 compound component by valuated parameters. Such methods then consist of wrappers 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. Verifying 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 parameter. Moreover, some naming conventions are veried: for instance, each entity (resp. component, service) name has the model name concatenated with "entities" (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 component) 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 relationships. 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 component. 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
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 objects. 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 several 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 resources 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 implementations 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 verify 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 references 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 components throughout their libraries as compound component and service implementations 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
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 provided 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 neither 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 associated 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
This work follows the recommendation from [
A interesting way to embed preconditions or eects into our approach can
be drawn out from [
This work is highly related to that of [
Reifier has been successfully applied to the development of several JEE applications. 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 investigated 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.