Los arreglos culturales en la sociedad Wayúu

By default, EMF persists models using the XMI representation format. Our approach relies also on XMI to save the models internally, however, 1_{When the identifier flag is not used, the fallback behavior looks for an attribute called}

4.3. MAPPING EMF AND REST

Listing 4.1: Partial JSON representation of the example model

1 { 2 " f o r m ":{ 3 " n a m e ":" a d d M o v i e F o r m " , 4 " v i e w C o m p o n e n t P a r t s ":{ 5 " s i m p l e F i e l d " : [ { 6 " uri ":" h t t p s :// e x a m p l e . com / r e s t / I F M L M o d e l / A d d M o v i e / i n t e r a c t i o n F l o w E l e m e n t s / A d d M o v i e W i n d o w / v i e w E l e m e n t s / A d d M o v i e F o r m / v i e w C o m p o n e n t s P a r t s / p i c t u r e "} ,{ 7 " uri ":" h t t p s :// e x a m p l e . com / r e s t / I F M L M o d e l / A d d M o v i e / i n t e r a c t i o n F l o w E l e m e n t s / A d d M o v i e W i n d o w / v i e w E l e m e n t s / A d d M o v i e F o r m / v i e w C o m p o n e n t s P a r t s / t i t l e "} ,...] , 8 ... 9 } , 10 " v i e w E l e m e n t E v e n t s ":{ 11 " o n s u b m i t e v e n t " : { " uri ":" h t t p s :// e x a m p l e . com / r e s t / I F M L M o d e l / A d d M o v i e / i n t e r a c t i o n F l o w E l e m e n t s / A d d M o v i e W i n d o w / v i e w E l e m e n t s / A d d M o v i e F o r m / v i e w e l e m e n t e v e n t s / add "} 12 } 13 } 14 }

models are offered to clients using both JSON and XML formats in order to comply with the representation-oriented constraint of the REST architecture (see Section 2.1 in Chapter 2).

For JSON, we adhere to the following structure. Model concepts are represented as JSON objects containing key/value pairs for the model at- tributes/references. Keys are the name of the attribute/reference of the concept and values are their textual representation in one of the data types supported in JSON (i.e., string, boolean, numeric, or array). For attributes, their values are mapped according to the corresponding JSON supported data type or String when there is not a direct correspondence (e.g., float- typed attributes). When the attribute is multi-valued, its values are repre- sented using the array data type. 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 4.1 shows an exam- ple 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 viewComponentPartsreference

includingSimpleFieldandSelectionFieldJSON 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

Listing 4.2: Partial XML representation of the example model 1 <f o r m> 2 <n a m e> A d d M o v i e F o r m < /n a m e> 3 <v i e w C o m p o n e n t P a r t s> 4 <s i m p l e F i e l d> 5 <uri> h t t p s :// e x a m p l e . com / r e s t / I F M L M o d e l / A d d M o v i e / i n t e r a c t i o n F l o w E l e m e n t s / A d d M o v i e W i n d o w / v i e w E l e m e n t s / A d d M o v i e F o r m / v i e w C o m p o n e n t s P a r t s / p i c t u r e < /uri> 6 < /s i m p l e F i e l d> 7 <s i m p l e F i e l d> 8 <uri> h t t p s :// e x a m p l e . com / r e s t / I F M L M o d e l / A d d M o v i e / i n t e r a c t i o n F l o w E l e m e n t s / A d d M o v i e W i n d o w / v i e w E l e m e n t s / A d d M o v i e F o r m / v i e w C o m p o n e n t s P a r t s / t i t l e < /uri> 9 < /s i m p l e F i e l d> 10 ... 11 < /v i e w C o m p o n e n t P a r t s> 12 <v i e w E l e m e n t E v e n t s> 13 <o n S u b m i t E v e n t> 14 <uri> h t t p s :// e x a m p l e . com / r e s t / I F M L M o d e l / A d d M o v i e / i n t e r a c t i o n F l o w E l e m e n t s / A d d M o v i e W i n d o w / v i e w E l e m e n t s / A d d M o v i e F o r m / v i e w E l e m e n t E v e n t s / add < /uri> 15 < /v i e w E l e m e n t E v e n t s> 16 < /v i e w E l e m e n t E v e n t s> 17 < /f o r m>

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 4.2 shows an example of the content format in XML format.

4.3.3

Uniform Interface

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, 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 4.3 shows the code to modify the name of the form called AddMovieForm using EMF generated API for

4.3. MAPPING EMF AND REST

Listing 4.3: Update the attribute of a concept using EMF generated API.

...

a d d M o v i e F o r m O b j . s e t N a m e ( " t o t o " ) ; // a d d M o v i e F o r m O b j is of t y p e F o r m ...

Listing 4.4: HTTP request and JSON representation to update the name of the addressed form.

1 PUT h t t p s :// e x a m p l e . com / r e s t / I F M L M o d e l / A d d M o v i e / i n t e r a c t i o n F l o w E l e m e n t s / A d d M o v i e W i n d o w / v i e w E l e m e n t s / A d d M o v i e F o r m 2 {" f o r m ":{ 3 n a m e :" t o t o " 4 } 5 }

the AddMovie model. The same operation can be done on our Web API by sending the PUT HTTP request containing the JSON representation of the new Form model element, as shown in Listing 4.4.

Table 4.1 shows how each CRUD operation is addressed along with sev- eral URL examples. The first column of the table describes the operations.

Table 4.1: Supported operations in the generated API.

OPERATION HTTP URL MODEL

METHOD

CREATE and add ele-

ment to the collection POST .../a/bs

A

B C

bs 0..* c 0..1

READ all the ele-

ments from the

collection

GET READ the element

(1) identified by <id>, (2) in the <i> position of the collection, or (3) the element c

GET

UPDATE the element (1) identified by <id>, (2) in the <i> position of the collection, or (3) the element c PUT (1).../a/bs/<id> (2).../a/bs?index=<i> (3).../a/c

DELETE the element (1) identified by <id>, (2) in the <i> position of the collection, or (3) the element c

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.

4.4

A

EMF-REST F

We provide also support for validation and security aspects in the generated REST Web API.

4.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 notnull) and cannot satisfy complex validation scenarios for model integrity (e.g., a form must have at least one field). To cope with this issue, we rely on OCL [WK99] to define constraints as annotations in the model elements. OCL, which was presented in Chapter 2 (see Section 2.3), provides a declarative language to create queries and constraints over MOF-based models. 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 4.4. 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 architectures, 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 ele- ments requires several steps to fulfill cardinality constraints), we allow this validation process to be temporary deactivated. The results of the validation