Search |
|||||||
Question: how to bind SOAP ORM JPA ?Posted by felipegaucho on September 3, 2008 at 1:57 AM PDT
Few days evaluating my options about binding my SOAP message objects to my JPA entities.... I have:
As you can deduct from the short code samples, every time my
web-service receives a SOAP message containing values that should be
persistent in the database, I should convert the received objects to the
JPA entities. And every time I read the data base to respond a
service request, I should convert the read entity in the respective
object that can be serialized in the SOAP messages. A dual channel
repetitive copy mechanism - a copy layer - or binding framework. I don't
like the term Questions: How to copy the values between the SOAP Message elements and the JPA entities?Options I am considering right now:
I certainly will blog here if I find a good workaround to this problem, so I hope to hear from you something new :) * This is a reviewed text of the same question I posted few days ago on the Metro forum. So, feel free to offer your wisdom here or in the forum. »
Related Topics >>
Web Services and XML Comments
Comments are listed in date ascending order (oldest first)
Submitted by rodrigolopes on Wed, 2008-09-03 02:42.
I'd stay with the "Simple, fast and the most reliable solution".
Submitted by dwalend on Wed, 2008-09-03 06:13.
Felipe,
Whatever you do, definitely keep the code outside these two classes. Don't go with option 4. You'll be kicking yourself in six months.
How many of these do you have to do? What are you trying to accomplish?
If it's a dozen or so for a short-term project, go brute force and pound out the code. (You could try generating both sets of data access code in a one-way code generator. Not sure I'd recommend that. There's better approaches.)
If you've got a huge number of these and can sink some time into it: You can rescue the recursive reflection option for deep copies if you imitate serialization's approach. Build up a list of all of the objects to be stored and a directed graph of the relationships between them, then walk the directed graph to rebuild the structure in the new form.
You might consider building out an intermediate set of objects independent of both the SOAP and JPA code. That way you'll retain some control of the system when someone else moves to a new version of the SOAP or database. (You could try generating the SOAP and JPA code from the code for the independent objects. It's light work, but hard to do well if you have to share with others.)
Hope that helps,
Dave
Submitted by ljnelson on Wed, 2008-09-03 08:45.
http://dozer.sourceforge.net/ might help.
Best,
Laird
Submitted by caroljmcdonald on Thu, 2008-09-04 06:44.
I have 2 examples in my blog, one that uses jax-ws and JPA
http://weblogs.java.net/blog/caroljmcdonald/archive/2007/09/sample_appli...
and one that uses JAX-RS and JPA
http://weblogs.java.net/blog/caroljmcdonald/archive/2008/08/a_restful_pe...
I built both of them using code that Netbeans generates for JPA and JAX-RS or JPA, JSF, and JAX-WS respectively.
Here is an example of JAXB code generated by the Netbeans JAX-RS wizard , Item is a JPA entity class:
@XmlRootElement(name = "item")
public class ItemConverter {
public ItemConverter(Item entity) {
this.entity = entity;
}
@XmlElement
public Long getId() {
return getEntity().getId();
}
....
Submitted by florent_garin on Thu, 2008-09-04 13:49.
When we started designing the DocDoku project we had the same problem.
And we decided to not bind but to use the same object !
JPA and JAXWS push some constraints on entity type and Soap type design.
But finally, these frameworks are enough flexible to make it possible to use the same object for the both concept.
For example our Activity class is annoted by annotation from JPA and JAX.
https://docdoku.dev.java.net/source/browse/docdoku/trunk/DocDoku-Common/...
Of course, that strategy is easer to apply when starting from scratch.
|
|||||||
|
|