Databases
StackOverflow2013
Postsdbo
POProviding entities to the client using JAX-WS
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POProviding entities to the client using JAX-WS
    primarykey
    data
    text
    <p>I am trying to create a web service using JAX-WS (SOAP) allowing CRUD operations on some entities. I am also writing a desktop client with an UI which provides easy means of doing CRUD on those entities via the web service.</p> <p>However, I am running into some design issues. I would like the client to only be able to view and manipulate certain fields of an entity, and I'm not sure what's the best way to impose this restriction.</p> <p>For instance, given:</p> <pre><code>@Entity public class Customer { @Id @GeneratedValue public Long id; public String name; // neither read nor write from the web service public String password; // read-only from the web service @Temporal(TemporalType.DATE) public Date joinedAt; @ManyToOne @LazyCollection(LazyCollectionOption.FALSE) private List&lt;Order&gt; orders; // .. boilerplate getters and setters } @Entity public class Order { @Id @GeneratedValue public Long id; public String name; } </code></pre> <p>I would like to provide the client with these basic operations:</p> <ol> <li>get the list of all customers with their orders <ul> <li>he can see all the fields EXCEPT for <code>password</code></li> </ul></li> <li>create a new customer with some orders <ul> <li>allow control to all fields EXCEPT FOR <code>joinedAt</code> and <code>password</code></li> </ul></li> <li>modify a customer <ul> <li>same as above, you're not allowed to modify <code>joinedAt</code> or <code>password</code></li> </ul></li> </ol> <p>.</p> <ol> <li><p>My current solution for (1) is to add @XmlTransient to the password field. This is problematic if you want to send the password to certain clients but not to others. Another solution would be to do <code>customer.setPassword(null);</code> before marshalling that entity via the webservice. But is this really the way to do it? A third solution would be to create a base class <code>BaseCustomer</code> which contains all the fields except for <code>password</code> and then Customer would be a <code>BaseCustomer</code> with the added <code>password</code> field. The user would receive a BaseCustomer object instead of a Customer one. But this has problems with create/update as well.</p></li> <li><p>Same as for (1), one solution is to do <code>customer.setJoinedAt(my_value); customer.setPassword(my_value); customer.setId(null);</code> when the client wants to create a new customer. Is manually nulling the <code>id</code> really best practice? I find that hard to believe. Should the <code>id</code> be XmlTransient as well? But then how would the user of the web service be able to modify/delete entities?</p></li> <li><p>When the client wants to change a <code>Customer</code>, he retrieves the list of customers, makes changes to one of the <code>Customer</code> objects, then marshals that object and passes it back to the web service. There are a few problems with this: if the <code>id</code> field is XmlTransient, then the EntityManager's persist won't know which row to modify and would likely create a new one. A similar issue raises if the user is evil and simply refuses to pass an <code>id</code>, so I have to manually check that the <code>id</code> is non-null. Moreover, the user has not received the <code>password</code> field, so now the server has received an object with a null <code>password</code> field which it will attempt to persist. I believe this will cause the EntityManager to completely remove the password of that existing Customer. Having the user specify exactly which fields he wants modified and to which values seems impractical.</p></li> </ol> <p>Note that this is just a proof-of-concept of what I need to do in a nutshell, I have far more entities, relations and operations to provide.</p> <p>I am new to using these technologies and I was hoping that being so high level and having so many abstractions would make my life easier, but so far it has been mostly headaches. It appears very difficult to achieve this common, basic task. Am I doing something wrong? Please don't suggest creating a web application instead :)</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USuser1792968
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. POProviding entities to the client using JAX-WS
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POProviding entities to the client using JAX-WS
      1. USSym-Sym
      1. VTFavorite
    3. VO
      singulars
      1. POProviding entities to the client using JAX-WS
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI would recommend against transferring objects as entities over soap. Consider using transfer objects: map data from entities to the transfer objects.
      singulars
      1. POProviding entities to the client using JAX-WS
      1. USSami Korhonen
    2. COBut wouldn't that cause a lot of code duplication? Or would the entities inherit the transfer objects? Also, wouldn't I have to manually write a lot of `entityobj.setField(transferobj.getField())` to convert from one to the other? Is that okay?
      singulars
      1. POProviding entities to the client using JAX-WS
      1. USuser1792968
    3. COIf the problem domains are different, having two identical lines of code should not be considered as code duplication - proper use of transfer objects can and will make your code more verbose. With entities you are limited to following operations: getCustomer() and getCustomerOrders() while with transfer objects you could write operations that have business meaning such as: getCustomerDetails() and getCustomerDetailsWithOrderSummary(). And yes, you will have to write a lot of mapping code manually - it's perfectly ok. Consider creating separate classes for mapping.
      singulars
      1. POProviding entities to the client using JAX-WS
      1. USSami Korhonen
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload