Texo is also very usefull when developing a RCP solution. The solution architecture has 2 parts:
- an EMF generated user interface which uses EObjects
- a Texo generated persistence layer on the server, using standard JPA/ORM
To support this architecture Texo provides a new EMF resource (to be used in the RCP client): the TexoResource. This implementation has 2 subclasses implementing different scenarios:
- EPersistenceTexoResource: for direct integration in the same systems layer with the ORM, the 2-tier architecture.
- JSONTexoResource: for a full 3-tier architecture with EObjects on the client, JPA on the server and JSON for the communication.
The 2-tier architecture is supported through the EPersistenceTexoResource which is located in the org.eclipse.emf.texo.server plugin. This resource implementation makes use of the Texo EntityManager integration to have access to an EntityManager to retrieve and read information.
In this 2-tier architecture the EMF Resource talks directly (through Texo) with the ORM layer and the database.
Texo also supports a 3-tier architecture using the JSONTexoResource:
- Front-end: the user interface - client using standard EMF generated code
- Middle-tier: the web server layer provides a CRUD JSON web service function and the JPA/ORM persistence
Using the Texo Resource
Information can be loaded in the Texo resource in 2 ways:
- by setting the types URI parameter in the URI of the resource, the types parameter should be a comma delimited list of JPA entity names, normally the EClass name is used. For example: http:/localhost:8080/texo?types=Library,Book
- by directly calling the query method on the TexoResource, the query method allows free format HQL/JPQL queries with named parameters.
The TexoResource internally uses an instance of EObjectStore. You can get this object through the getEObjectStore method on the TexoResource. The EObjectStore provides additional methods which can be very usefull:
- cross-referencing: find all the objects that refer to a specific target object
- counting using a query
- refreshing an object from the server
Persisting your changes can be done by calling the save method (the one without the outputstream parameter) on the resource. Updates, new objects and deletions are persisted.
The JSONTexoResource - setting up a server side
The Texo JSON Resource has some additional specific points to take into account.
First it needs a running server, see here for an example project and video for such a server side.
Then next, the URI for creating the resource must be a valid web address pointing to the Texo server environment. For example the following web address is used in the test environment of Texo: http://localhost:8080/texo/jsonws
The JSONTexoResource resolves proxies by doing HTTP requests to the server side to load the proxied objects. EMF proxies only work correctly if the EMF resource is created through a ResourceSet.
When sending objects from the client to the server (when saving a resource) the server side is allowed to change objects before persisting. The changes are send back to the client and merged into the client-side objects.
If the client needs to authenticate against the server then you need to create your own subclass of the JSONEObjectStore. This class has several overriding points for changing the URL or adding authentication to the HttpUrlConnection. See here on how to tell Texo to use your specific subclass of the JSONEObjectStore.
The JSONTexoResource is specifically targeted for usage in a RCP. For the RCP environment/client side you need 2 plugins:
And in addition the EMF plugins ofcourse. You can find these plugins through the Texo update site.
The EPersistenceTexoResource uses the Texo EntityManager integration to have access to an EntityManager, please check out the Texo EntityManager wiki page for more information.