=Paper=
{{Paper
|id=Vol-1725/demo9
|storemode=property
|title=Reifier: Model-Driven Engineering of Component-Based and Service-Oriented JEE Applications
|pdfUrl=https://ceur-ws.org/Vol-1725/demo9.pdf
|volume=Vol-1725
|authors=Jérôme Rocheteau,David Sferruzza
|dblpUrl=https://dblp.org/rec/conf/models/RocheteauS16
}}
==Reifier: Model-Driven Engineering of Component-Based and Service-Oriented JEE Applications==
<pdf width="1500px">https://ceur-ws.org/Vol-1725/demo9.pdf</pdf>
<pre>
            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 dened 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 verication 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 specic model of web services. A domain-specic
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 dened 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
specic entities. We argue that such a meta-model makes possible to dene 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 verication 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
verication operations (naming uniqueness, type system hierarchy, component
consistency). The section 2 presents the programming interface required for de-
veloping atomic components that ease their verication. 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 dened 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 verication. 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 specied 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 specied 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 denition 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 dened by the component as the sum type of abstract
components or compound components. Both types of components are dened 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 qualied 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.

Verication Model verication focuses on names, entities and components. Ver-
ifying names consists in detecting naming collisions i.e. dierent elements in a
given model have the same name. It is also veried that only inputs and outputs
of abstract or compound components can be parametric names; neither entity,
component, service nor parameter names can partially be dened by a param-
eter. Moreover, some naming conventions are veried: 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
verication ensures that no conict will happen during source code generation
i.e. a single le will be generated twice for two dierent 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 verication
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 specications
(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 veried 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 species 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 conguration 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
denes 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 specication and their implementations. In fact, they are used to ver-
ify that component implementations meet their specication. These annotations
all concern either elds or local variables within component implementations.
They are all dened 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
dened by qualied 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 verication
of abstract components as Reifier type system is embedded into component
implementation annotations. However, this correspond to a shallow verication
as the compliance between annotations and the elds or local variables that they
concern is not veried.
    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-eects, 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 veried 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 dened either by Java primitive type wrappers that associated
to Reifier primitive types or by Java classes that are generated from entities.
A specic 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 identier

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 specic methods. These classes correspond to data
structures only. Moreover, a XML le is also created that species 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 sux.
    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 dened by the generated class of these
methods. Finally, the XML le web.xml that species, 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 reies 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 dened by that of the Reifier method response and, potentially, such
Java methods have an argument dened 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 dened 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
specied by their behavior that consist in inputs and outputs but also in pre-
conditions and eects. Although our web service denition takes into account
inputs and outputs, it lacks of higher order specications as preconditions and
eects.
    A interesting way to embed preconditions or eects 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 renements 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, specic 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
verication. These tools have a lot in common with respect to these guidelines.
However, they dier one to another at some extent. The main dierence 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 eort
dierently: 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
dene explicit design patterns. It secondly consists in strengthen verication 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 workows: Balancing
   between exibility and support. Computer Science - R&D 23(2), 99113 (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. 7380.
   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. 11961203. ACM (2016)
4. Lautenbacher, F., Bauer, B.: Creating a meta-model for semantic web service stan-
   dards. pp. 376381. 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), 670687 (2014)
6. Scheidgen, M., Etinge, 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. 205216. Springer (2016)

</pre>