interact interactive manual assembly operations for the ...services to ease the data management...
TRANSCRIPT
The INTERACT project (611007) is co-funded by the European Commission under the 7th Framework Programme.
This document reflects only authors’ views. The Europena Commission is not liable for any use that may be done of the information contained
therein.
INTERACT – Interactive Manual Assembly Operations for
the Human-Centered Workplaces of the Future
Grant Agreement Number : 611007
: INTERACT
Project Start Date : 1st October, 2013
Consortium : DAIMLER AG (DAIMLER)- Project Coordinator
ELECTROLUX ITALIA S.P.A. (ELECTROLUX)
INTRASOFT INTERNATIONAL SA (INTRASOFT)
IMK AUTOMOTIVE GMBH (IMK)
EMPHASIS TELEMATICS AE (EMPHASIS)
HADATAP SP ZOO (HADATAP)
UNIVERSITY OF PATRAS (LMS)
UNIVERSITAET ULM (IMI)
DEUTSCHES FORSCHUNGSZENTRUM FUER KUENSTLICHE
INTELLIGENZ GMBH (DFKI)
Title : Aggregated datastore implementation
Reference : D4.2.1
Availability : Public (PU)
Date : 31/03/2015
Author/s : DAIMLER, ELECTROLUX, INTRASOFT, IMK, EMPHASIS, LMS, IMI, DFKI
Circulation : EU, INTERACT consortium, Public
Summary:
This deliverable accompanies the software prototype of the Aggregated datastore. It provides a first
glance of the implementations and the services provided towards supporting the heterogeneous data
needs of INTERACT’s modules/services.
INTERACT 611007
1
Table of Contents
1. EXECUTIVE SUMMARY ..................................................................................................... 2
2. INTRODUCTION ................................................................................................................... 3
3. INTEGRATED DATASTORE ............................................................................................... 4
3.1. Ontology Server ............................................................................................................... 4
3.1.1. Persistence Layer ................................................................................................ 4
3.1.2. Service Layer ...................................................................................................... 4
3.2. Data Management Server ................................................................................................. 6
4. UML DIAGRAMS ................................................................................................................ 10
4.1. Ontology Server ............................................................................................................. 10
4.1.1. Class Diagrams ................................................................................................. 10
4.1.2. Sequence Diagrams .......................................................................................... 15
4.2. Data Management Server ............................................................................................... 17
4.2.1. Class Diagrams ................................................................................................. 17
4.2.2. Sequence Diagrams .......................................................................................... 20
5. CONCLUSIONS ................................................................................................................... 22
6. GLOSSARY .......................................................................................................................... 23
INTERACT 611007
2
1. EXECUTIVE SUMMARY
This deliverable scope is to document the “Aggregated Datastore” implementation. The “Aggregated
Datastore” aims at providing solution for the data needs of the various INTERACT developments as a
single point of access for data requirements. Moreover the “Aggregated Datastore” will provide
services to ease the data management hiding from the modules the underlying complexity of data
manipulation. These services are envisaged to be integrated into Enterprise Application Platform
(EAP) service registry developed under WP5 to extend the EAP functionalities regarding data
provisioning and storage.
This deliverable is divided into 2 major sections with additional introductory (section “2
Introduction”) and concluding (section “5 Conclusions”) sections. Section “3 Integrated Datastore”
shows the systems composing the prototype divided into the underlying storage (“Persistence Layer”)
and the provided services (“API”), and section “4 UML Diagrams” documents in UML diagrams the
services behaviors.
INTERACT 611007
3
2. INTRODUCTION
The “Aggregated Datastore” was foreseen to be an implementation of the designed Ontology in
“D4.1.1 Design of aggregated datastore for planned and sensor data”. As the INTERACT modules
and applications were evolving, as the EAP functionalities were detailed, data requirements were
emerging, posing functional requirements in terms of schema-less data support as well as non-
functional requirements such as performance and scaling. These requirements where undertaken by
“Task 4.2: Aggregation datastore implementation” providing both a solution for Ontology data as well
as a dedicated data management system to serve as a single point of data storage and acquisition.
Moreover the dedicated data management system would complement the EAP services by providing a
“Data Management” service for EAP’s applications and other registered services.
It is of importance to state that the implementations will not to handle sensor data as these kinds of
data are considered sensitive private information. Instead sensor data are going to be securely
transferred from the sensor platform (WP3) directly to the “Motion Recognition” (T4.3) module for
processing and then will be discarded.
In the next sections technical documentation will be provided for both systems implementation.
INTERACT 611007
4
3. INTEGRATED DATASTORE
3.1. Ontology Server
The Ontology server that will host the “Motions Recognition Semantic Repository” is implemented
using the Apache Jena framework in combination with the Spring development framework. The
implementation outcome is a web application with an embedded triple store exposing an API as
RESTful services for data manipulation, and simple GUI for importing, exporting data in the owl
format.
3.1.1. Persistence Layer
For the persistence layer the Jena TDB component is used serving as RDF storage. The actual storage
space is located inside the web application’s file system. The Server on top of TDB manages multiple
repositories to be loaded/unloaded as well as imported/exported.
Persistence layer’s functionality for multiple repositories is accompanied by a GUI for allowing
import and export of owl files
Figure 1 Import/Export functionalities
3.1.2. Service Layer
This layer supports the ontology data manipulation through the SPARQL language. It exposes actions
for tuples manipulation (listing, insertions and update), rules manipulation (inserting, removing,
activating, deactivating and validating) and repository manipulation services (delete, list, get/export,
insert). These services might be enriched as “Task 4.3: Automated recognition, classification of
executed assembly operations and operations' deltas” might poses further requirements on Ontologies
services until the final prototype in M24.
3.1.2.1. API
The Ontology services are implemented as RESTful services. In section 7.1 of the Annex there is an
overall wadl document describing these operations.
3.1.2.1.1. Tuples Manipulation
The Tuple API consists of two methods namely “insertOrUpdate” and
“query”. Both methods accept a SPARQL formatted alphanumeric value. The first method inserts or
updates a specific tuple whitout providing any output while the second method queries the repository
and returns a representation of the results in OWL format
INTERACT 611007
5
“insertOrUpdate”
<resource path="/tuple/set/{repositoryId}/{query}"> <method id="insertOrUpdate" name="GET"> <doc title="TupleRestService.insertOrUpdate" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="template" type="xs:string" required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="query" style="template" type="xs:string" required="true" /> </request> </method> </resource>
“query”
<resource path="/tuple/get/{repositoryId}/{query}"> <method id="query" name="GET"> <doc title="TupleRestService.query" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="template" type="xs:string" required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="query" style="template" type="xs:string" required="true" /> </request> </method> </resource>
3.1.2.1.2. Rules Manipulation
The ontology Rules API consists of three methods namely “setRules”, “unsetRules” and
“validateRule”. The first two registers and unregisters rules while the latter performs the reasoning. It
is worth to state that the rules by themselves are treated as Tuples supporting RDF reasoning rules.
“setRules”
<resource path="/rules/set/{repositoryId}/{rules}"> <method id="setRules" name="GET"> <doc title="RulesRestService.setRules" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="template" type="xs:string" required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="rules" style="template" type="xs:string" required="true" /> </request> </method> </resource>
“unsetRules”
<resource path="/rules/unset/{repositoryId}/{rules}"> <method id="unsetRules" name="GET"> <doc title="RulesRestService.unsetRules" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="template" type="xs:string" required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="rules" style="template" type="xs:string" required="true" /> </request> </method> </resource>
“validateRule”
<resource path="/rules/validate/{repositoryId}/{rule}"> <method id="validateRule" name="GET"> <doc title="RulesRestService.validateRule" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="template" type="xs:string" required="true" />
INTERACT 611007
6
<param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="rule" style="template" type="xs:string" required="true" /> </request> </method> </resource>
3.1.2.1.3. Repository Manipulation
The ontology repository API consists of four methods namely “insertRepository”, “deleteRepository”,
“getAllRepositories” and “getRepository”.
The first two creates and deletes repositories in the Ontologies Server, the third is a repositories listing
method while the last exports an existing repository. The data format supported for import
(“insertRepository”) and export (“getRepository”) is OWL. The repositories are identified and
managed by a name given to the repository upon their creation.
“insertRepository”
<resource path="/repository/insert"> <method id="insertRepository" name="POST"> <doc title="RepositoryRestServices.insertRepository" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="query" type="xs:string" required="false" /> <ns2:param xmlns:ns2="http://wadl.dev.java.net/2009/02" xmlns="" name="owlFile" style="query" type="" required="true" /> </request> </method> </resource>
“deleteRepository”
<resource path="/repository/delete"> <method id="deleteRepository" name="GET"> <doc title="RepositoryRestServices.deleteRepository" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="query" type="xs:string" required="true" /> </request> </method> </resource>
“getAllRepositories”
<resource path="/repository/all"> <method id="getAllRepositories" name="GET"> <doc title="RepositoryRestServices.getAllRepositories" /> </method> </resource>
“getRepository”
<resource path="/repository/get"> <method id="getRepository" name="GET"> <doc title="RepositoryRestServices.getRepository" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="query" type="xs:string" required="true" /> </request> </method> </resource>
3.2. Data Management Server
INTERACT must handle a big diversity of data, namely Motion data (constrain set, Motion Graph
internal states, synthesized motions), task list data (tasks in CNL language), application data (sensor
configurations, ergonomics assessment, basic assessment and user input). Each unique entity provides
its own data format like bvh, json, alphanumeric lists or arbitrary formats like the “morphable graph
input” (constrain set). Also individual records are linked conceptual to form a greater data set (i.e. task
list produce elementary action list which produce motion constrains which produce motion).
INTERACT 611007
7
Even though Ontology systems have been under progress in the recent years, using just
triplestore/SPARQL implementations poses potential performance cost. On the other hand traditional
RDBMS solutions require complete information schema to be available a priory. This gave rise to
NON-SQL solutions that would address functional requirements derived from apps/module regarding
data storage and arbitrary data models as well as indirect non-functional requirements for performance
and data scaling.
NON-SQL solutions can be grouped into four different categories depending on the underlying model
and functionality provided:
Key/Value based systems. These systems work by matching keys to values with no structural
limitation (data model) but lacking relational support.
Column based systems. Like the Key/Value systems they create key/value pairs but these
pairs can be multiple for a single record. They are schema-less and efficient on managing big
number of records as well as big-data records (records with lots of information)
Document based systems. These systems work like the Column based one but allows data
nesting (record inside record inside record) supporting complex schemas. Their drawback is
during querying which process the whole record set affecting performance
Graph based systems. These systems work in a completely different way of the other three
utilizing underlying tree structures (graphs) for linking and grouping information. They are
efficient in applications where data relationship matter most.
Although for the INTERACT data requirements the crucial part is performance, scaling and schema-
less data, linking capabilities are also needed to be supported which led to a deeper look in Column
based NONSQL systems. The leading solutions in this area are Apache Cassandra and HBase (data
store for Apache Hadoop). Both solutions are based on the same principles of Bigtable definition with
similar performance and scalability functionalities thus the decision was based on the out-of-the-box
functionality provided by the systems. At this point architectural decisions made by the EAP where
evaluated and specifically significant role played the ability of the system to manage JSON formatted
data (as the format supported by most of the INTERACT services). Apache Cassandra clearly took
the lead with its internal support for indexing collections. Collection indexing allows the storage of
JSON files as maps and querying using JSON attributes.
Again the implementation of the Data Management Server is a Spring web application with a NON-
SQL persistent layer (Cassandra db) wrapped by RESTful services.
3.2.1.1. Meta-Model
Each information to be stored (record) in the server is accompanied by three metadata properties that
allow the quick retrieval of data by indexing these specific fields.
These fields are:
id: Representing each data unique identifier. This is an auto-generated value to ensure
uniqueness
domain: A field representing the domain that data comes from.
groupId: A field that correlates data from different domain that represent a different aspect of
the same dataset (i.e. data coming from sensors and data generated from Motion Recognition
by parsing the specific sensor data).
3.2.1.2. API
The services exported are implemented as RESTful services following the CRUD (Create, Read,
Update and Delete) data operations. The input and output of these services support JSON format. In
section 7.1 of the Annex there is an overall wadl document describing these operations.
INTERACT 611007
8
Each data record is considered to be framed by the meta-model presented above. These records are
referenced as Entities in the following API. There are two operations for creating and deleting
Entities and fives operations for searching each one with a unique grouping clause.
3.2.1.2.1. Entity creation and removal.
“insertOrUpdateEntity”
<resource path="/data/insert-update/{domain}/{groupId}"> <method id="insertOrUpdateEntity" name="POST"> <doc title="StorageRestService.insertOrUpdateEntity" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="domain" style="template" type="xs:string" required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="groupId" style="template" type="xs:string" required="true" /> </request> </method> </resource>
“deleteEntity”
<resource path="/data/delete/{id}"> <method id="deleteEntity" name="GET"> <doc title="StorageRestService.deleteEntity" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="id" style="template" type="xs:string" required="true" /> </request> </method> </resource>
3.2.1.2.2. Entity search operations
“getEntity” (by entity id)
<resource path="/data/get/{id}"> <method id="getEntity" name="GET"> <doc title="StorageRestService.getEntity" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="id" style="template" type="xs:string" required="true" /> </request> </method> </resource>
“getEntitiesByDomain”
<resource path="/data/get/domain/{domain}"> <method id="getEntitiesByDomain" name="GET"> <doc title="StorageRestService.getEntitiesByDomain" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="domain" style="template" type="xs:string" required="true" /> </request> </method> </resource>
“getEntitiesByGroup”
<resource path="/data/get/group/{groupId}"> <method id="getEntitiesByGroup" name="GET"> <doc title="StorageRestService.getEntitiesByGroup" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="groupId" style="template" type="xs:string" required="true" /> </request> </method> </resource>
“getEntitiesByDomainAndGroup”
<resource path="/data/get/domain-group/{domain}/{groupId}"> <method id="getEntitiesByDomainAndGroup" name="GET"> <doc title="StorageRestService.getEntitiesByDomainAndGroup" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="domain" style="template" type="xs:string"
INTERACT 611007
9
required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="groupId" style="template" type="xs:string" required="true" /> </request> </method> </resource>
“getAllEntities”
<resource path="/data/all"> <method id="getAllEntities" name="GET"> <doc title="StorageRestService.getAllEntities" /> </method> </resource>
INTERACT 611007
10
4. UML DIAGRAMS
The following sections provide a technical insight of the datastores implementation. It is provided as
software documentation, intended for technicians for reasoning regarding performance and
incremental development. The following UML diagrams are broken down into two categories. Class
Diagrams to provide the internal structure of each datastore and Sequence Diagrams to depict the
behaviour of the systems.
4.1. Ontology Server
4.1.1. Class Diagrams
Figure 2 Jena Server Presentation Layer
INTERACT 611007
11
Figure 3 Jena Server Internal Services & Repository wrapper
INTERACT 611007
12
Figure 4 Jena Server Rest Services (API)
INTERACT 611007
13
Figure 5 Jena Server & Spring Configuration and Utility Classes (1 of 2)
INTERACT 611007
14
Figure 6 Jena Server & Spring Configuration and Utility Classes (2 of 2)
INTERACT 611007
15
4.1.2. Sequence Diagrams
In this section a sequence diagram for a tuple insertion into Ontology Server will be provided using
the RESTSful API depicting the interaction of Ontology Server classes with the usage of Jena
Framework.
The same principles follow the other methods implementation (querying tuples,
creating/deactivating/validating rules)
INTERACT 611007
16
Figure 7 insertOrUpdate Tuple Rest Service
INTERACT 611007
17
4.2. Data Management Server
4.2.1. Class Diagrams
INTERACT 611007
18
Figure 8 Internal Services, RESTful Services, Domain and DAO layers
INTERACT 611007
19
Figure 9 Spring Configuration and Utility Classes
INTERACT 611007
20
4.2.2. Sequence Diagrams
The diagram below demonstrates the sequence of events following an insertion&update RESTful service call. The
same principles follow the other methods implementation (querying and deleting records)
INTERACT 611007
21
Figure 10 insertOrUpdate record Rest Service
INTERACT 611007
22
5. CONCLUSIONS
This deliverable document the work performed under task “Task 4.2: Aggregation datastore
implementation”. The outputs are two server applications fully implemented (as documented in
previous sections) for data storage, one Ontology based to be used by the “Motion Recognition”
module and the other NON-SQL based to serve as the EAP’s support for the hosted applications and
modules. Both are consider essential tackling different requirements and complementing each other.
Even though task T4.2 ends, further developments are envisaged as applications and modules are
reaching their final stage and the provided storages will be further stress tested and potential
performance issues will be handled accordingly.
INTERACT 611007
23
6. GLOSSARY
EAP Enterprise Application Platform
UI User Interface
GUI Graphical User Interface
DAO Data Access Object
API Application Programming Interface
RDF Resource Description Framework
SPARQL SPARQL Protocol and RDF Query
Language
RESTful/REST Services Representational State Transfer (Web)
Services
OWL Web Ontology Language
RDBMS Relational Database Management System
SQL Structured Query Language
JSON JavaScript Object Notation
CRUD Create, Read, Update and Delete
CNL Controlled Natural Language
INTERACT 611007
24
7. ANNEX
7.1. Ontology Server RESTful wadl
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <application xmlns="http://wadl.dev.java.net/2009/02"> <doc title="Spring REST Service WADL" /> <resources base="http://localhost:8080/jena-server/v2/application.wadl"> <resource path="/repository/delete"> <method id="deleteRepository" name="GET"> <doc title="RepositoryRestServices.deleteRepository" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="query" type="xs:string" required="true" /> </request> </method> </resource> <resource path="/repository/all"> <method id="getAllRepositories" name="GET"> <doc title="RepositoryRestServices.getAllRepositories" /> </method> </resource> <resource path="/repository/get"> <method id="getRepository" name="GET"> <doc title="RepositoryRestServices.getRepository" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="query" type="xs:string" required="true" /> </request> </method> </resource> <resource path="/repository/insert"> <method id="insertRepository" name="POST"> <doc title="RepositoryRestServices.insertRepository" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="query" type="xs:string" required="false" /> <ns2:param xmlns:ns2="http://wadl.dev.java.net/2009/02" xmlns="" name="owlFile" style="query" type="" required="true" /> </request> </method> </resource> <resource path="/rules/set/{repositoryId}/{rules}"> <method id="setRules" name="GET"> <doc title="RulesRestService.setRules" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="template" type="xs:string" required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="rules" style="template" type="xs:string" required="true" /> </request> </method> </resource> <resource path="/rules/validate/{repositoryId}/{rule}"> <method id="validateRule" name="GET"> <doc title="RulesRestService.validateRule" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="template" type="xs:string" required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="rule" style="template" type="xs:string" required="true" /> </request> </method> </resource> <resource path="/rules/unset/{repositoryId}/{rules}"> <method id="unsetRules" name="GET"> <doc title="RulesRestService.unsetRules" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="template" type="xs:string" required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="rules" style="template" type="xs:string" required="true" />
INTERACT 611007
25
</request> </method> </resource> <resource path="/tuple/get/{repositoryId}/{query}"> <method id="query" name="GET"> <doc title="TupleRestService.query" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="template" type="xs:string" required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="query" style="template" type="xs:string" required="true" /> </request> </method> </resource> <resource path="/tuple/set/{repositoryId}/{query}"> <method id="insertOrUpdate" name="GET"> <doc title="TupleRestService.insertOrUpdate" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="repositoryId" style="template" type="xs:string" required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="query" style="template" type="xs:string" required="true" /> </request> </method> </resource> </resources> </application>
7.2. Data Management Server RESTful wadl
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <application xmlns="http://wadl.dev.java.net/2009/02"> <doc title="Spring REST Service WADL" /> <resources base="http://localhost:8080/aggregated-datastore/v2/application.wadl"> <resource path="/data/get/{id}"> <method id="getEntity" name="GET"> <doc title="StorageRestService.getEntity" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="id" style="template" type="xs:string" required="true" /> </request> </method> </resource> <resource path="/data/delete/{id}"> <method id="deleteEntity" name="GET"> <doc title="StorageRestService.deleteEntity" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="id" style="template" type="xs:string" required="true" /> </request> </method> </resource> <resource path="/data/get/domain/{domain}"> <method id="getEntitiesByDomain" name="GET"> <doc title="StorageRestService.getEntitiesByDomain" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="domain" style="template" type="xs:string" required="true" /> </request> </method> </resource> <resource path="/data/get/domain-group/{domain}/{groupId}"> <method id="getEntitiesByDomainAndGroup" name="GET"> <doc title="StorageRestService.getEntitiesByDomainAndGroup" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="domain" style="template" type="xs:string" required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="groupId" style="template" type="xs:string" required="true" /> </request> </method> </resource>
INTERACT 611007
26
<resource path="/data/all"> <method id="getAllDocuments" name="GET"> <doc title="StorageRestService.getAllDocuments" /> </method> </resource> <resource path="/data/get/group/{groupId}"> <method id="getEntitiesByGroupId" name="GET"> <doc title="StorageRestService.getEntitiesByGroupId" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="groupId" style="template" type="xs:string" required="true" /> </request> </method> </resource> <resource path="/data/insert-update/{domain}/{groupId}"> <method id="insertOrUpdateEntity" name="POST"> <doc title="StorageRestService.insertOrUpdateEntity" /> <request> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="domain" style="template" type="xs:string" required="true" /> <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="groupId" style="template" type="xs:string" required="true" /> </request> </method> </resource> </resources> </application>