We have recently presented the newest version of our tool, EMF-REST, at SAC’16 (The 31st ACM/SIGAPP Symposium on Applied Computing). EMF-REST takes EMF models as input and generates for them a Web API following the REST principles and relying on well-known libraries and standards, thus facilitating its comprehension and maintainability.
EMF-REST provides the basis to develop model-based solutions on the cloud as well as an enhanced collaborative support for Web-based modeling tools.
The tool leverages on Java EE capacities (EJBs, CDI,…) and runs on an application server to better manage transactions and objects life-cycle. A glimpse of the features offered by EMF-REST is shown bellow.
- RESTful API: EMF-REST automatically creates a RESTful API conforming to the JAX-RS 2.0, allowing you to access and manage efficiently your models online using HTTP methods.
- JSON or XML serialization: You can choose between JSON or XML formats to communicate with the API.
- Validation: Annotate your Ecore model with OCL constraints in order to enable OCL-based validation in the generated API.
- Security: The tool provides Authentication and Authorization mechanisms, allowing you to have a full control on who can access your API. A rich admin view is also provided in order to manage your users and their roles.
EMF-REST is licensed under the Eclipse Public License with the source code available on GitHub.
You can take a look at the presentation below.
Or read the full paper (here or below)
1 Introduction to EMF Rest
Model-Driven Engineering (MDE) methods and techniques have been matured along recent years. In the last years, the emergence of distributed architectures, specially Cloud-based ones, and mobile devices have promoted the development of model-based applications on the Web and over portable devices. Current modeling environments (e.g., Xtext, Epsilon or EMFText) and frameworks (e.g., the plethora of modeling facilities in Eclipse such as EMF or GMF) have successfully contributed to the broad use of MDE techniques. However, model-based applications on the Web require relying on Web technologies rather than on current heavyweight desktop environments and frameworks.
Web services offer a suitable solution to expose model-driven environments for remote access. Among the different approaches for designing distributed services (e.g., SOAP, WSDL or WS-* specifications), there is a rising trend to use lightweight solutions based on plain HTTP, referred to as REpresentational State Transfer (REST) [9] services. REST proposes the development of stateless distributed services and relies on simple URIs and HTTP verbs to make the Web services broadly available for a number of front-end devices. With the increasing interest in developing model-based applications on the Web, some approaches have appeared [12, 16, 20] to cope with the model-driven generation of Web services, however, their support to generate RESTful Web APIs is very limited.
In this paper we present EMF-REST, an approach that leverages on MDE techniques to generate RESTful Web APIs out of EMF models, thus promoting model management in distributed environments. The generated RESTful Web API relies on well-known libraries and standards with the aim of facilitating its understanding and maintainability. Unlike other existing MDE-based approaches targeting the generation of Web services, ours provides a direct mapping to access data models by means of Web services following the REST principles. Additionally, EMF-REST takes advantage of model and Web-specific features such as model validation and security, respectively.
By using EMF-REST, developers have the ground to leverage on Platform-as-a-Service (PaaS) providers, in which model management would take advantage of their scalability capabilities. Also, adopting a Web-based solution would promote the collaboration between modelers, thus facilitating the collaborative development of new software models.By using EMF-REST, developers have the ground to leverage on Platform-as-a-Service (PaaS) providers, in which model management would take advantage of their scalability capabilities. Also, adopting a Web-based solution would promote the collaboration between modelers, thus facilitating the collaborative development of new software models.
The remainder of this paper is structured as follows. Section 2 presents some background of REST and MDE. Section 3 describes how we devised the mapping between EMF and REST principles, while Section 4 describes the additional EMF-REST features. Section 5 presents the technical architecture of the generated REST API. Section 6 describes the steps we followed to generate the API. Section 7 discusses some related work. Finally, Section 8 concludes the paper and presents the future work.
2 Background
2.1 The MDE paradigm
The MDE paradigm emphasizes the use of models to raise the level of abstraction and to automate the development of software. Abstraction is a primary technique to cope with complexity, whereas automation is the most effective method for boosting productivity and quality [19].
Modeling languages express models at different abstraction levels, and are defined by applying metamodeling techniques [5]. In a nutshell, models are defined according to the semantics of a model for specifying models, the so called metamodel. A model that respects the semantics defined by a metamodel is said to conform to/to be an instance of such a metamodel.
The Eclipse Modeling Framework (EMF) [2] has become the main reference for modeling in Eclipse [8]. Among its features, EMF allows creating metamodels – by using the Ecore language, a subset of the UML class diagrams – and their instances. Along this paper, we refer to metamodels as Ecore models, and their instances as model instances. Ecore can be considered as an implementation of Meta-Object Facility (MOF) [14], a modeling and metamodeling standard developed by the Object Management Group (OMG). Additionally, EMF provides a generative solution which constructs Java APIs out of those models to facilitate their management, thus promoting the development of domain-specific applications.
On the other hand, model transformations generate software artifacts from models, either directly by model-to-text transformations (e.g., using languages such as EGL1 or JET2 ) or indirectly by intermediate model-to-model transformations (e.g., using languages such as ATL3 or ETL4). By means of modeling languages and model transformations, it is possible to increase both the level of abstraction and provide automation in MDE, respectively.
In EMF-REST we use EMF and we apply a set of model-to-text transformations using JET and EGL templates to generate a Web application exposing the management of Ecore models by the mean of REST APIs.
2.2 REST principles
In 2000, Roy Fielding identified specific design principles that led to the architectural style known as REpresentational State Transfer (REST) [9]. By relying on the HTTP protocol, this architectural style consists of several constraints to address separation of concerns, visibility, reliability, scalability and performance. REST principles are defined as:
- Addressable resources — Each resource must be addressable via a Uniform Resource Identifier (URI).
- Representation-oriented — A resource referred by one URI may have differentrepresentation formats (e.g., JSON, XML, etc.).
- Statelessness — Servers cannot hold the state of a client session Instead, data representation formats provide information on how to manage the state of the application for each client (e.g., using embedded URIs).
- Uniform and Constrained Interface — A small set of well-defined methods are used to manipulate resources (i.e., HTTP verbs).
The last two principles are maybe the most distinguishing features of REST from other Web services specifications. According to these principles, each request is treated as an independent transaction and must only rely on the set of operations of the HTTP protocol. HTTP methods are used in REST as follows:
- GET is used to retrieve a representation of a resource. It is a read-only, idempotent and safe operation.
- PUT is used to update a reference to a resource on the server and it is idempotent as well.
- POST is used to create a resource on the server based on the data included in the body request. It is the only nonidempotent and unsafe operation of HTTP.
- DELETE is used to remove a resource on the server. It is idempotent as well.
- HEAD is similar to GET but returning only a response code and the header associated with the request.
- OPTIONS is used to request information about the communication options of the addressed resource (e.g., security capabilities such as CORS).
Being a collection of principles rather than a set of standards, several resources on best practices and recommendations were written to help developers to write RESTful Web services. In order to generate a high-quality RESTful Web API, we apply in EMF-REST the best practices described in [13].
3 Mapping EMF and REST principles
Being a collection of principles rather than a set of standards, several resources on best practices and recommendations were written to help developers to write RESTful Web services. In order to generate a high-quality RESTful Web API, we apply in EMF-REST the best practices described in [13].
Figure 1: Simple Ecore model of an IFML subset.
To illustrate the approach, we will use a running example consisting on creating a distributed application aimed at managing IFML (Interaction Flow Modeling Language) models. IFML is an OMG standard language designed for expressing the content, user interaction and control behavior of the front-end applications developed for systems such as Computers and Mobile phones [6]. Figure 1 shows an excerpt of the IFML metamodel. As can be seen, IFMLModel is the top-level container of all the model elements and represents an IFML model. It contains an InteractionFlowModel which is the user view of an application. The concepts extending ViewContainer, ViewComponets, ViewComponentPart, and ViewElementEvent represent the visual elements of an IFML model.
Figure 2 shows an IFML model which consists of a form allowing to add a movie. The model is composed of (i) a Window container named AddMovieWindow, (ii) a Form component named AddMovieForm, (iii) a list of fields of types SimpleField and SelectionField representing the elements of the form, and finally (iv) a ViewElementEvent of type OnsubmitEvent allowing to submit the form. In what follows we will see how we would allow creating the AddMovieForm form by calling a REST API generated from the IFML model following the REST principles.
Figure 2: IFML model of AddMovie
3.1 Addressable Resources
Models in EMF are addressed via a URI, which is a string with a well-defined structure as shown in the expression (1). This expression contains three parts specifying: (1) a scheme, (2) a scheme-specific part and (3) an optional fragment. The scheme is the first part separated by the ”:” character and identifies the protocol used to access the model (e.g., platform, file or jar ). In Eclipse we use platform for URIs that identify resources in Eclipse-specific locations, such as the workspace. The scheme-specific part is in the middle and its format depends on the scheme. It usually includes an authority that specifies a host, the device and the segments, where the latter two constitute a local path to a resource location. The optional fragment is separated from the rest of the URI by the # character and identifies a subset of the contents of the resource specified by URI, as we will illustrate below. The expression (2) shows an example of a platform-specific URI which refers to the AddMovie model, represented as a file AddMovie.xmi contained in a project called project in Eclipse workspace. It is important to note that in EMF model instances include a reference to the Ecore model they conform to.
[scheme:][scheme-specific-part][#fragment] (1)
platform:/resource/project/AddMovie.xmi (2)
We map the previous URI to a Web URL as follows. The base URL pattern of a model instance is defined by the expression (3). In the pattern, the part https:// [application-Link]/rest is the URL of the Web application, modelId is the identifier of the model (e.i., the Ecore model) and ModelInstanceId is the identifier of the model instance being accessed (the XMI file). The URL (4) represents an example to retrieve the IFML model used in the example. As can be seen, while the URI can address a file representing a model instance (where a reference to the Ecore model is included), the URL requires indicating the identifier of both the Ecore model and the model instance.
https://[applicationLink]/rest/[ModelId]/[ModelInstanceId] (3)
https://example.com/rest/IFMLModel/AddMovie (4)
This URL acts as the entrypoint for a particular model instance and points to its root element, which is normally the case in EMF. When the model instance has more that one root, we point at the first.
Once pointing to the root of a model instance, addressing a particular element of the model in the EMF is done by using the part fragment in (1). The navigation is done using the reference names in the Ecore model. For instance, the concept IFMLModel has the reference interactionFlowModel to access the InteractionFlowModel. Using the EMF API, the URI is shown in (5), while using the Web API, the URL is shown in (6).
platform:/resource/project/AddMovie.xmi#//@interactionFlowModel (5)
https://example.com/rest/IFMLModel/AddMovie/interactionFlowModel (6)
Depending on the cardinality of the reference this will return a specific element if it is single-valued (like in the case of interactionFlowModel ) – or a collection of elements – if it is multi-valued. Accessing a specific element contained in a collection can be done using (i) the identifier of the element or (ii) its index in the list. Also, when navigating through the references contained in elements being subclasses of a hierarchy, the appropriate filtering is done on the fly. For instance, the URI (7) retrieves the element representing title in EMF, while in EMF-REST it is done using the call (8). Note how the latter navigates through the reference viewElements, which is only included in ViewContainer element. To identify an element, we rely on the identifier flag provided by Ecore, which allows setting the attribute acting as identifier for a given class5.
platform:/resource/project/AddMovie.xmi#title (7)
https://example.com/rest/IFMLModel/AddMovie/ interactionFlowElements/AddMovieWindow/viewElements/ AddMovieForm/viewComponentsParts/title (8)
On the other hand, the call (9) will retrieve the first element of the collection of viewComponentsParts in the EMF API. In our approach, it is done by adding the parameter index in the URL as illustrated in the call (10).
platform:/resource/project/AddMovie.xmi#//.../@viewComponentsParts.0 (9)
https://example.com/rest/IFMLModel/AddMovie/ interactionFlowElements/AddMovieWindow/viewElements/ AddMovieForm/viewComponentsParts?index=0 (10)
3.2 Representation-Oriented
By default, EMF persists models using the XMI representation format. Our approach relies also on XMI to save the models internally, however, models are offered to clients using both JSON-based and XML-based storages in order to comply with the representation-oriented principle of the REST architecture.
For the JSON, we adher to the following structure. Model concepts are represented as JSON objects containing key/value pairs for the model attributes/references. Keys are the name of the attribute/reference of the concept and values are their textual representation in one of the datatypes supported in JSON (i.e., string, boolean, numeric, or array). For attributes, their values are mapped according to the corresponding JSON supported datatype or String when there is not a direct correspondence (e.g., float-typed attributes). When the attribute is multi-valued, its values are represented using the array datatype. For references, the value is the URI of the addressed resource within the server (if the reference is multi-valued, the value will be represented as an array of URIs). Listing 1 shows an example of the content format in JSON. Note that references containing a set of elements from model hierarchies are serialized as a list of JSON objects corresponding to their dynamic type (see viewComponentParts reference including SimpleField and SelectionField JSON objects).
In XML, model concepts are represented as XML elements including an XML element for each model attribute/reference. Attribute values are included as string values in the XML element representing such attribute, references are represented according to their cardinality. If the reference is single-valued, the resulting XML element will include only the URI of the addressed resource in the server. On the other hand, if the reference is multi-valued, the resulting XML element will include a set of XML elements including the URIs addressing the resources. Listing 2 shows an example of the content format in XML format.
Listing 1: Partial JSON representation of the example model
1 {
2 "form":{
3 "name":"addMovieForm",
4 "viewComponentParts":{
5 "simpleField":[{
6 "uri":"https://example.com/rest/IFMLModel/AddMovie/interactionFlowElements/AddMovieWindow/viewElements/AddMovieForm/viewComponentsParts/picture"},{
7 "uri":"https://example.com/rest/IFMLModel/AddMovie/interactionFlowElements/AddMovieWindow/viewElements/AddMovieForm/viewComponentsParts/title"},...],
8 ...
9 },
10 "viewElementEvents":{
11 "onsubmitevent":{"uri":"https://example.com/rest/IFMLModel/AddMovie/interactionFlowElements/AddMovieWindow/viewElements/AddMovieForm/viewelementevents/add"}
12 }
13 }
14 }
Listing 2: Partial XML representation of the example model
1 <form>
2 <name>AddMovieForm</name>
3 <viewComponentParts>
4 <simpleField>
5 <uri>https://example.com/rest/IFMLModel/AddMovie/interactionFlowElements/AddMovieWindow/viewElements/AddMovieForm/viewComponentsParts/picture</uri>
6 </simpleField>
7 <simpleField>
8 <uri>https://example.com/rest/IFMLModel/AddMovie/interactionFlowElements/AddMovieWindow/viewElements/AddMovieForm/viewComponentsParts/title</uri>
9 </simpleField>
10 ...
11 </viewComponentParts>
12 <viewElementEvents>
13 <onSubmitEvent>
14 <uri>https://example.com/rest/IFMLModel/AddMovie/interactionFlowElements/AddMovieWindow/viewElements/AddMovieForm/viewElementEvents/add</uri>
15 </onSubmitEvent>
16 </viewElementEvents>
17 </form>
3.3 Uniform and Constrained Interface & Statelessness
EMF supports loading, unloading and saving model instances after their manipulation. In our approach, these operations are managed by the application server. Models are loaded (and unloaded) dynamically as resources when running the application managing the Web API, and they are saved after each operation is done, thus conforming to the REST statelessness behavior.
To manipulate model instances, EMF enables the basic CRUD (i.e., create, read, update and delete) operations over model instances by means of either the EMF generated API or the EObject API. We map the same CRUD operations into the corresponding HTTP methods (POST, GET, PUT, and DELETE ). For instance, Listing 3 shows the code to modify the name of the form called AddMovieForm using EMF generated API for the AddMovie model. The same operation can be done on our Web API by sending the PUT HTTP method containing the JSON representation of the new Form model element, as shown in Listing 4.
Listing 3: Update the attribute of a concept using EMF generated API.
1 ...
2 addMovieFormObj.setName("toto");//addMovieFormObj is of type Form
3 ...
Listing 4: HTTP call and JSON representation to update the name of the addressed form.
1 PUT https://example.com/rest/IFMLModel/AddMovie/interactionFlowElements/AddMovieWindow/viewElements/AddMovieForm
2 {"form":{
3 name :"toto"
4 }
5 }Table 1 shows how each CRUD operation is addressed along with several URL examples. The first column of the table describes the operations. As can be seen, the first two rows represent operations over collections, enabling adding new elements (see first row) and reading their content (see second row). The rest of the rows describe operations over either individual elements of a collection (see cases 1 and 2 of these operations) or elements contained in a single-valued reference (see case 3). The second column shows the correspondent HTTP method for each operation while the third column presents the corresponding URL for each case. Finally, the last column includes a small model to better illustrate the cases considered in the table.
Table 1: Supported operations in the generated API.
| Operation | http Method | URL | Model |
| CREATE and add element to the collection | POST | …/a/bs |  |
| READ all the elements from the collection | GET | ||
| READ the element(1) identied by <id>,(2) in the <i> position of the collection, or(3) the element c | GET | (1) …/a/bs/<id>
(2) …/a/bs?index=<i> (3) …/a/c |
|
| UPDATE the element(1) identi_ed by <id>,(2) in the <i> position of the collection, or(3) the element c | PUT | ||
| DELETE the element(1) identi_ed by <id>,(2) in the <i> position of the collection, or(3) the element c | DELETE |
4 Additional EMF-REST Features
We provide also support for validation and security aspects in the generated RESTful Web API.
4.1 Validation
Support for validating the API data calls is pretty limited in current web technologies. The most relevant one for our scenario would be the Bean Validation specification to enforce the validation of Java Beans. However, this specification can only ensure that fields follow certain constraints (e.g., a field is not null) and cannot satisfy complex validation scenarios for model integrity (e.g., a form must have at least one field ). On the other hand, MDE provides specific support for validating models, for instance, the Object Constraint Language [21], a language complementing UML [17] that allows software developers to write complex constraints over object models. Thus, we employ OCL to define constraints as annotations in the model elements.
OCL annotations can be attached to concepts in the model as invariants. An example on the IFML example model is shown in Figure 3. As can be seen, concepts include a set of invariants inside the annotation OCL plus the annotation Ecore/constrains which specifies the invariants to execute. Invariants are checked each time a resource is modified (i.e., each time the Web API is called from a Web-based client using the POST, PUT or DELETE methods). This validation scheme is imposed to comply with the stateless property of REST architetures, however, it may involve some design constraints when creating the model. In those cases where models cannot be validated each time they are modified (e.g., creating model elements requires several steps to fulfill cardinality constraints), we allow this validation process to be temporary be deactivated. The results of the validation process are mapped into the corresponding HTTP response messages (i.e., using status codes)
Figure 3: Annotations on an excerpt of the example model.
4.2 Security
While there is little support for security definition and enforcement from the MDE side, we have plenty of support from web technologies. In particular, our approach allows designers to provide some security annotations on the model that are then translated into security restrictions as described below. As part of the generation, we also create a separated admin view where additional security information (like users and passwords) can be maintained.
In order to secure a Web application, we have to: (i) ensure that only authenticated users can access resources, (ii) ensure the confidentiality and integrity of data exchanged by the client/server, and (iii) prevent unauthorized clients from abusing data. In order to address the previous requirements, we rely on a set of security protocols and services provided by Java EE which enable encryption, authentication and authorization in Web APIs, as we will explain in the following.
- Encryption: The Web defines HTTPS protocol to add the encryption capacities of SSL/TLS to standard HTTP communication. We enforce the use to HTTPS to communicate with its services.
- Authentication: We rely on basic authentication to provide the authentication mechanism since it is simple, widely supported, and secure by using HTTPS. The basic authentication involves sending a Base64-encoded username and password within the HTTPS request header to the server.
- Authorization: While the authentication is enabled by the protocol/server, the authorization is generally provided by the application, which knows the permissions for each resource operation. We use a simple role-based mechanism to support authorization in the generated Web API. Roles are associated to users (i.e., authentication) and operations in the Web API (i.e., authorization). In our approach roles are assigned to resources by adding annotations to the model. Figure 3 illustrates the use of these annotations (e.g., see annotation Ecore/roles in the Form concept).
5 EMF-REST API Architecture
To implement the features described in the previous sections, we devised the application architecture presented in Figure 4. This architecture can then be seamlessly accessed with a variety of clients.
Figure 4: Architecture of the generated application.
The Web application is split into three main components according to the functionality they provide: (1) content management, (2) validation and (3) security. The application relies on EMF as modeling framework and uses the following additional frameworks/specifications for each component, respectively: (1) Java Architecture for XML Binding (JAXB) to enable the content format support, (2) Eclipse OCL framework to provide validation before updating the model, (3) Java Persistence API (JPA) to provide security support by storing the system users and their permissions in an embedded database. The Web application also leverages on Enterprise Java Bean (EJB), Context dependency Injection (CDI) and Java API for Representational State Transfer (JAX-RS) specifications. EJBs enable rapid and simplified development of distributed, transactional, secure and portable applications. They are in charge of loading the EMF resources from the persistent storage and providing the necessary methods to manage the resources (e.g., obtaining objects from the resource, removing objects) in a secure and transactional way. These EJBs are then injected into JAX-RS services using CDI technology. Thus, JAX-RS is used to expose EMF resources as Web services. In the remaining of the section we describe how all these technologies are used in each component.
5.1 Content Management
This component addresses the mapping between EMF and REST principles. It is in turn split into two subcomponents: (1) content format, which addresses the mapping of the second REST principle (i.e., Representation-Oriented); and (2) navigation/operation, which addresses the rest of the REST principles.
Regarding the content format, we enrich the EMF generated API with JAXB6 annotations, which enable the support for mapping Java classes to XML/JSON (i.e., marshalling/unmarshalling Java object into/from XML/JSON documents). The Listing 5 shows an example of the use of JAXB annotations to produce the corresponding representation in JSON (as shown in Listing 1) and XML (as shown in Listing 2). As can be seen, each concept class is mapped to an XmlRootElement element, while either XmlElement or XmlElementWrapper elements are used to map the attributes or references of the class, respectively. Other annotations are used to deal with the references and inheritance. For instance, XmlJavaTypeAdapter and XmlAnyElement are used to associate a reference of an element with the corresponding representation.
Navigation and operations are enabled by using JAX-RS, which provides a set of Java APIs for building Web services conforming to the REST style. Thus, this specification defines how to expose POJOs as Web resources, using HTTP as network protocol. For each concept (e.g., IFMLModel ) a resource will be created (e.g., IFMLModelResource) annotated with @Path (e.g., @Path(“IFMLModel”)). The @Path annotation has the value that represents the relative root URI of the addressed resource. For instance, if the base URI of the server is http://example.com/rest/, the resource will be available under the location http://example.com/rest/IFMLModel. To produce a particular response when a request with GET, PUT, POST and DELETE is intercepted by a resource, resource methods are annotated with @GET, @PUT, @POST and @DELETE what are invoked for each corresponding HTTP verb.
Listing 5: Part of the ViewComponent concept.
1 @XmlRootElement(name="viewcomponent")
2 @XmlSeeAlso({ViewComponentProxy.class,//...
3 })
4 public class ViewComponentImpl extends ViewElementImpl
5 implements ViewComponent {
6 // ...
7 @XmlElementWrapper (name="viewComponentParts")
8 @XmlAnyElement(lax=true)
9 @XmlJavaTypeAdapter(value=ViewComponentPartAdapter.class )
10 public EListgetViewComponentParts(){
11 if(viewComponentParts==null){
12 viewComponentParts = new EObjectContainmentWithInverseEList(ViewComponentPart.class,this,IfmlPackage.VIEW_COMPONENT__VIEW_COMPONENT_PARTS,IfmlPackage.VIEW_COMPONENT_PART__VIEW_COMPONENT);
13 }
14 return viewComponentParts;
15 }
16 // ...5.2 Validation
Our approach leverages on Eclipse OCL7 to validate the data by means of annotations including the constrains to check the model elements. The generated API relies on the provided APIs for parsing and evaluating OCL constraints and queries on Ecore models. When constraints are not satisfied, the validation process will fire an exception that will be mapped by JAX-RS into an HTTP response including the corresponding message indicating the violated constraint.
5.3 Security
We rely on the combination of Java EE and JAX-RS for the authentication and authorization mechanisms by using the concept of role, while encryiption is provided by using HTTPS. To enable authentication, the deployment descriptor of the WAR file (i.e., WEB-INF/web.xml) has been modified to include the security constraints (i.e., <security-constraint>) defining the access privileges. Assigning permissions for HTTP operations based on the roles provided in the model is done by using the @RolesAllowed annotation. For example, as shown before, Figure 3 shows that the role allowed for the Form concept is admin.This will restrict access to the resource to the users having the role ADMIN. To express this in the generated API, the annotation @RolesAllowed({“ADMIN”}) is placed on top of FormResource. If no role is assigned to a concept, a @PermitAll annotation is placed on the resource class meaning that all security roles are permitted to access this resource. Note that security roles assigned to a resource are not inherited by its sub-resources.
To manage the list of users and their roles, we generate an admin view that allows the manager of the API to add, edit and remove users. All created users have a default role (i.e., user ) allowing them to access unannotated concepts. The manager can assign more roles to a user in order to grant him/her access to a specific resource.
6 Code Generation and Tool Support
In order to generate the REST APIs we created a Java tool available as an open-source Eclipse plugin [1]. Figure 5 shows the steps followed by the tool to generate the application starting from an initial Ecore model.
Figure 5: EMF-REST generation process.
Step I of the process generates a Maven-based8 project that serves as a skeleton of the application. Maven allows a project to be built by using the Project Object Model (POM) file, thus providing a uniform build system. The POM is initialized with the required library dependencies described in the previous section.
In Step II, the EMF code generation facility has been extended to include the required support for JAXB and validation. In particular, the JET templates used by EMF to generate Java code have been extended to produce the code corresponding to the JAXB annotations and the required methods to execute the OCL validation process.
Step III performs a set of model-to-text transformations using EGL to generate the remaining elements, including: (1) the JAX-RS, CDI and EJB implementation classes, (2) the admin view developed and (3) a simple JavaScript API to facilitate Web developers to build clients for the generated Web API. For each part of the application (e.g., JAX-RS resources, etc.), an EGL transformation template has been implemented to generate the appropriate behavior according the input Ecore class. Since this step requires several transformations, the MTC tool [4] has been used to orchestrate the flow of the EGL templates.
7 Related Work
Several efforts have been made to bring together MDE and Web Engineering. This field is usually referred to as Model Driven Web Engineering (MDWE) and proposes the use of models and model transformations for the specification and semiautomatic generation of Web applications [7, 10, 11, 15, 18, 22]. Mainly, data models, navigation models and presentations models are used for this purpose.
Some of these works provide support for the generation of Web services as well, but support for generation of RESTful APIs is very limited [12, 16, 20]. Moreover, these approaches require the designer to specifically model the API itself using some kind of tool-specific DSL from which then the API is (partially) generated. To the best of our knowledge, only Texo [3] provides an extension to EMF in order to support the creation of RESTful APIs but providing a proprietary solution which requires extending the user’s meta-model with metadata to drive the API generation. Instead, our approach is able to generate a complete RESTful API from any data model.
8 Conclusion
In this paper we have presented EMF-REST, an approach to generate RESTful Web APIs out of EMF models. We believe our approach fills an important gap between the modeling and Web technologies, thus enabling MDE practitioners to bring their models into the Web. EMF-REST has been released as an Eclipse plugin and is publicly available [1].
As further work, we plan to extend the current support for security (e.g., a more fine-grained security mechanism) and validation (e.g., supporting transactions). Also, we would like to work on a small configuration DSL to help designers parameterize the style of the generated API (e.g., configuring the URIs to the resources). Existing approaches, like WADL9 and RSDL10 , which also propose DSLs to describe Web APIs could be useful here. We are also interested in exploring the benefits of using EMF-REST in combination with client-side modeling environments, for instance, in Eclipse, thus enabling developers to deal with large EMF models in a transparent way (i.e., models in Eclipse that are remotely stored using an EMF-REST backend).
9 REFERENCES
[1] EMF-REST website. http://emf-rest.com/ (last accessed on Dec. 2015). [2] EMF. http://www.eclipse.org/modeling/emf/ (last accessed on Dec. 2015).
[3] Texo. http://wiki.eclipse.org/Texo (last accessed on Dec. 2015).
[4] C. Alvarez and R. Casallas. MTC Flow: A Tool to Design, Develop and Deploy Model Transformation Chains. In ACME workshop, pages 1–9, 2013.
[5] M. Brambilla, J. Cabot, and M. Wimmer. Model-Driven Software Engineering in Practice. Morgan & Claypool Publishers, 2012.
[6] M. Brambilla, P. Fraternali, and et al. The interaction flow modeling language (ifml), version 1.0. Technical report, Object Management Group (OMG), http://www.ifml.org, 2014.
[7] S. Ceri, P. Fraternali, and A. Bongio. Web Modeling Language (WebML): a
Modeling Language for Designing Web Sites. J. Comp. Netw., 33:137–157, 2000.
[8] Eclipse website. http://eclipse.org (last accessed on Dec. 2015).
[9] R. T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, 2000.
[10] N. Koch and S. Kozuruba. Requirements models as first class entities in model-driven web engineering. In ICWE Workshops, pages 158–169, 2012.
[11] B. Marco, J. Cabot, and M. Grossniklaus. Tools for Modeling and Generating Safe Interface Interactions in Web Applications. In ICWE conf., pages 482–485, 2010.
[12] E. Maximilien, H. Wilkinson, N. Desai, and S. Tai. A Domain-Specific Language for Web APIs and Services Mashups. In ICSOC conf., pages 13–26. 2007.
[13] B. Mulloy. Web API Design – Crafting Interfaces that Developers Love. Apigee, 2012.
[14] OMG MOF Specification. http://www.omg.org/mof (last accessed on Dec. 2015).
[15] X. Qafmolla and V. C. Nguyen. Automation of Web Services Development
Using Model Driven Techniques. In ICCAE conf, volume 3, pages 190–194, 2010.
[16] J. M. Rivero, S. Heil, J. Grigera, M. Gaedke, and G. Rossi. MockAPI: An Agile Approach Supporting API-first Web Application Development. In ICWE conf., pages 7–21, 2013.
[17] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Pearson Higher Education, 2004.
[18] A. Schauerhuber, M. Wimmer, and E. Kapsammer. Bridging Existing Web Modeling Languages to Model-driven Engineering: A Metamodel for WebML. In ICWE conf., 2006.
[19] B. Selic. The Pragmatics of Model-Driven Development. IEEE Softw., 20(5):19–25, 2003.
[20] N. A. C. Tavares and S. Vale. A model driven approach for the development of semantic restful web services. In IIWAS conf., page 290, 2013.
[21] J. Warmer and A. Kleppe. The Object Constraint Language: Precise Modeling with UML. Addison-Wesley, 1999.
[22] WebRatio. http://www.webratio.com (last accessed on Dec. 2015).
1 http://www.eclipse.org/epsilon/doc/egl/
2 https://eclipse.org/modeling/m2t/
4 http://www.eclipse.org/epsilon/doc/etl/
5 When the identifier is not used, the fallback behavior looks for an attribute called id, name or having the unique flag activated.
7 http://www.eclipse.org/modeling/mdt/?project= =ocl
9 http://www.w3.org/Submission/wadl/
My name is Hamza Ed-Douibi. I am a postdoctoral fellow working in the SOM Research Lab at the Internet Interdisciplinary Institute (IN3) of the Open University of Catalonia (UOC) in Barcelona.
Recent Comments