evaluating xmlbeans and best practices

Hi All,

We have a requirement where in we need to communicate with a
web service
WSDL. Currently we are generating set of java classes (using
xml beans) out
of this wsdl.

Our application will be using these java classes to set the
data before
calling the web service and also will get data wrapped in
these classes.

We did a proof of concept for the same and everything looks
manageable for a
small example but we have around 35 different types of web
service calls to
make (to & fro) each with a huge xml payload.

We do not have much idea on xml beans or java to xml binding
and would like
to know what are some of the guidelines best practices to
adopt

One observations these xml beans generated classes do not
have
an inbuilt relationship (inheritance tree) which limits
reusability.

I would like to know would it be a good idea to use these
xml beans
generated classes as transfer objects or can I create custom
classes
(transfer objects) extending these generated
classes & introduce some business logic in these custom
classes.


Also currently in our code we have to do a lot of checks
like null pointer
checks for each & every field before fetching and
setting values because of
inherent nature of the underlying xml elements &
attributes.
WHat i fear is when we go about creating code for moving
data between
application transfer objects & xmlbean generated classes
there would lot of
null pointer checks making the code unnecessarily ugly.
But using a separate transfer objects layer also keeps the
client code
separate and would not be affected if there are any changes
to the
underlying WSDL and we can carry out the modifications at a
centralised
location (i.e. some sort of mapper layer).

Do post your suggestions on the pros & crons of each
approach.

-- 
View this message in context: http://www.nabble.com/evalu
ating-xmlbeans-and-best-practices-tf4440007.html#a12668083
Sent from the Xml Beans - User mailing list archive at
Nabble.com.


------------------------------------------------------------
---------
To unsubscribe, e-mail: user-unsubscribexmlbeans.apache.org
For additional commands, e-mail: user-helpxmlbeans.apache.org

Hi Jacob,

Those replies were  indeed very helpful.

Regarding schema design pattern I don't have much idea about
various schema
design patterns and their advantages.
The java application which we are working on communicates
with web service
which is exposing a wsdl. We plan to use xmlbeans to
generate the java
artifacts
representing the wsdl.

The reason I posted that question on inheritance hierarchy
was we wanted to
figure
out how can we get a ready made domain model to work with 
from the underlying wsdl itself rather than investing time
in creating 
another domain model at our application layer.

By transfer objects what i meant to ask was can we get a 
readymade domain model with the business logic in the form
of generated
classes
or they would be dumb objects (just getter/setter) as it is
currently in our
case
Will study at the links you posted on extension mechanism.


Directly accessing the generated classes inside the
application code can
cause problems when there are changes to the underlying WSDL


So one option was too create a set of classes (one per
generated xml class).
These custom
classes will extend the generated xml classes. 
So we can have business logic in these custom classes and
the app code
communicates with these
custom classes and will not be interacting directly with the
xml generated
classes.
This way the application code will also be shielded from any
changes to
underlying WSDL.

Another option would be too create these set of custom
classes and have a
mapping with xml generated
classes. This involves creating a mapper utility to transfer
data from the
xml generated classes to
their custom counterparts. Sounds a bit more overhead here.

Do let me know your viewpoints

-- 
View this message in context: http://www.nabble.com/evalu
ating-xmlbeans-and-best-practices-tf4440007.html#a12687453
Sent from the Xml Beans - User mailing list archive at
Nabble.com.


------------------------------------------------------------
---------
To unsubscribe, e-mail: user-unsubscribexmlbeans.apache.org
For additional commands, e-mail: user-helpxmlbeans.apache.org