Re: [Axis2] Generated element objects vs. business objects

2006-05-30 Thread Dennis Sosnoski

Hi Tom,

Another option is for to you to use the JiBX data binding option with 
Axis2. JiBX (http://www.jibx.org) lets you work with you existing data 
classes, while also providing extensive control over how these classes 
are converted to and from XML. The downside is that you have to create a 
binding definition file that tells JiBX how to do these conversions.


There are tools to help in going from Java classes to a binding 
definition and then to the corresponding XML schema, but these are 
somewhat out of date - meaning they more or less work, but don't really 
take full advantage of current JiBX features. There's another tool that 
uses a schema to generate a set of Java classes and a corresponding 
binding definition, but that's even more out of date. I'll be working on 
improving these tools in June-July for a JiBX 1.2 release, which will 
also include integrating the code generation tool with WSDL2Java.


Right now the WSDL2Java implementation of JiBX binding requires you to 
have the Java classes and a binding definition already created, and just 
links up the Axis2 code to your classes. I'm working on some 
improvements to the WSDL2Java handling now (unwrapping the top level 
structures to reduce the number of data classes), and once that's done 
I'll post some examples. You can view the existing Axis2-JiBX 
documentation at 
http://ws.apache.org/axis2/1_0/jibx/jibx-codegen-integration.html


 - Dennis

Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117



[EMAIL PROTECTED] wrote:


Hi Rodrigo,

This sure helps. Like you say, there are multiple ways of dealing with 
it, and it seems to be related to style, ease of implementation, and 
consistency of data. Each method has some pros and cons. I'll give it 
some more thought...


Thanks, also to Robert Lazarski for his response.
Tom


Rodrigo Ruiz <[EMAIL PROTECTED]> wrote on 05/30/2006 02:39:31 PM:

> Hi Tom,
>
> There are some options more or less "practical" to get what you want.
>
> One is to replace your domain class with the generated one. This will
> probably mean moving the "non-bean" functionality in your domain
> Customer to another class, maybe something like "CustomerHelper". Of
> course, this is not always possible, as you may have some internal
> fields in your domain class you want to keep there.
>
> Another option is to make your domain class to subclass the generated
> class, or include it as an internal field.
>
> Copying does not have to be so bad. If you have a fixed mapping between
> what you have in your domain classes and what you want to return as XML
> beans, you can implement the copying in a helper class. This will 
reduce

> the probability of an error. If you use the same names for your bean
> attributes in both classes, commons-beanutils maybe of help, as it
> provides some methods to perform "conversions" between bean classes.
>
>
> My own experience tells me that using the same object for internal and
> XML binding purposes is not always a good idea. If your service 
modifies

> the state of your domain objects, using them for serialization will
> probably result in incoherences in your returned data.
>
> Think about it. If you return your Customer, Axis 2 starts 
deserializing

> it to build the response, and in another request somebody changes some
> fields in the same object, the response may contain inconsistent data.
> Take into account that, once you "release" your object to Axis, you
> loose control over the transactionality of any operation on that 
instance.

>
> I am not saying this is the end of the world. This scenario might 
not be
> possible in your services, or even if possible, it may have little 
or no

> importance. But if you do need returned data to be consistent, copying
> field values into an XML bean may be the only way to get a valid
> snapshot of your data.
>
>
> Hope this helps,
> Rodrigo Ruiz
>
>
> [EMAIL PROTECTED] wrote:
> >
> > Hi,
> >
> > I'm struggling a bit with the following.
> >
> > Say, I have a web service that allows you to search for customers. It
> > accepts a customer name, and returns a set (any number) of customers.
> > The response xml may look like
> >
> > 
> > 
> > 123
> > John Doe
> > 
> > 
> > 987
> > Jane Doe
> > 

> > 
> >
> > Obviously, in my application I have a Customer class. Now if I 
create a
> > wsdl for this web service, and generate the server side code for 
it, one

> > of the classes that is generated is a customer class, that represents
> > the customer in the xml response. On the other hand, I have the 
Customer

> > domain object, which is a different one. To generate the response, I
> > have to create 'xml response' customers, and basically copy the
> > information from the Customer class to it. The above example is ver

Re: [Axis2] Generated element objects vs. business objects

2006-05-30 Thread vandenberget

Hi Rodrigo,

This sure helps. Like you say, there
are multiple ways of dealing with it, and it seems to be related to style,
ease of implementation, and consistency of data. Each method has some pros
and cons. I'll give it some more thought...

Thanks, also to Robert Lazarski for
his response.
Tom


Rodrigo Ruiz <[EMAIL PROTECTED]> wrote on
05/30/2006 02:39:31 PM:

> Hi Tom,
> 
> There are some options more or less "practical" to get what
you want.
> 
> One is to replace your domain class with the generated one. This will

> probably mean moving the "non-bean" functionality in your
domain 
> Customer to another class, maybe something like "CustomerHelper".
Of 
> course, this is not always possible, as you may have some internal

> fields in your domain class you want to keep there.
> 
> Another option is to make your domain class to subclass the generated

> class, or include it as an internal field.
> 
> Copying does not have to be so bad. If you have a fixed mapping between

> what you have in your domain classes and what you want to return as
XML 
> beans, you can implement the copying in a helper class. This will
reduce 
> the probability of an error. If you use the same names for your bean

> attributes in both classes, commons-beanutils maybe of help, as it

> provides some methods to perform "conversions" between bean
classes.
> 
> 
> My own experience tells me that using the same object for internal
and 
> XML binding purposes is not always a good idea. If your service modifies

> the state of your domain objects, using them for serialization will

> probably result in incoherences in your returned data.
> 
> Think about it. If you return your Customer, Axis 2 starts deserializing

> it to build the response, and in another request somebody changes
some 
> fields in the same object, the response may contain inconsistent data.

> Take into account that, once you "release" your object to
Axis, you 
> loose control over the transactionality of any operation on that instance.
> 
> I am not saying this is the end of the world. This scenario might
not be 
> possible in your services, or even if possible, it may have little
or no 
> importance. But if you do need returned data to be consistent, copying

> field values into an XML bean may be the only way to get a valid 
> snapshot of your data.
> 
> 
> Hope this helps,
> Rodrigo Ruiz
> 
> 
> [EMAIL PROTECTED] wrote:
> > 
> > Hi,
> > 
> > I'm struggling a bit with the following.
> > 
> > Say, I have a web service that allows you to search for customers.
It 
> > accepts a customer name, and returns a set (any number) of customers.

> > The response xml may look like
> > 
> > 
> >         
> >                 123
> >                 John
Doe
> >         
> >         
> >                 987
> >                 Jane
Doe        
> >         
> > 
> > 
> > Obviously, in my application I have a Customer class. Now if
I create a 
> > wsdl for this web service, and generate the server side code
for it, one 
> > of the classes that is generated is a customer class, that represents

> > the customer in the xml response. On the other hand, I have the
Customer 
> > domain object, which is a different one. To generate the response,
I 
> > have to create 'xml response' customers, and basically copy the

> > information from the Customer class to it. The above example
is very 
> > simple, but you can imagine more complexe cases that would involve
a lot 
> > of copying from domain objects to xml representation objects.
This is 
> > very tedious and error-prone work -- typically work that I would
like to 
> > avoid.
> > 
> > Is there an elegant way to solve this issue?
> > 
> > 
> > Thanks,
> > Tom
> > 
> > 
> > 
> > 
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.394 / Virus Database: 268.7.4/351 - Release Date:
29/05/2006
> 
> -- 
> ---
> GRIDSYSTEMS                
   Rodrigo Ruiz Aguayo
> Parc Bit - Son Espanyol
> 07120 Palma de Mallorca        mailto:[EMAIL PROTECTED]
> Baleares - España              Tel:+34-971435085
Fax:+34-971435082
> http://www.gridsystems.com
> ---
> 
> 
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.7.4/351 - Release Date: 29/05/2006
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


Re: [Axis2] Generated element objects vs. business objects

2006-05-30 Thread Rodrigo Ruiz

Hi Tom,

There are some options more or less "practical" to get what you want.

One is to replace your domain class with the generated one. This will 
probably mean moving the "non-bean" functionality in your domain 
Customer to another class, maybe something like "CustomerHelper". Of 
course, this is not always possible, as you may have some internal 
fields in your domain class you want to keep there.


Another option is to make your domain class to subclass the generated 
class, or include it as an internal field.


Copying does not have to be so bad. If you have a fixed mapping between 
what you have in your domain classes and what you want to return as XML 
beans, you can implement the copying in a helper class. This will reduce 
the probability of an error. If you use the same names for your bean 
attributes in both classes, commons-beanutils maybe of help, as it 
provides some methods to perform "conversions" between bean classes.



My own experience tells me that using the same object for internal and 
XML binding purposes is not always a good idea. If your service modifies 
the state of your domain objects, using them for serialization will 
probably result in incoherences in your returned data.


Think about it. If you return your Customer, Axis 2 starts deserializing 
it to build the response, and in another request somebody changes some 
fields in the same object, the response may contain inconsistent data. 
Take into account that, once you "release" your object to Axis, you 
loose control over the transactionality of any operation on that instance.


I am not saying this is the end of the world. This scenario might not be 
possible in your services, or even if possible, it may have little or no 
importance. But if you do need returned data to be consistent, copying 
field values into an XML bean may be the only way to get a valid 
snapshot of your data.



Hope this helps,
Rodrigo Ruiz


[EMAIL PROTECTED] wrote:


Hi,

I'm struggling a bit with the following.

Say, I have a web service that allows you to search for customers. It 
accepts a customer name, and returns a set (any number) of customers. 
The response xml may look like




123
John Doe


987
Jane Doe




Obviously, in my application I have a Customer class. Now if I create a 
wsdl for this web service, and generate the server side code for it, one 
of the classes that is generated is a customer class, that represents 
the customer in the xml response. On the other hand, I have the Customer 
domain object, which is a different one. To generate the response, I 
have to create 'xml response' customers, and basically copy the 
information from the Customer class to it. The above example is very 
simple, but you can imagine more complexe cases that would involve a lot 
of copying from domain objects to xml representation objects. This is 
very tedious and error-prone work -- typically work that I would like to 
avoid.


Is there an elegant way to solve this issue?


Thanks,
Tom




No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.4/351 - Release Date: 29/05/2006


--
---
GRIDSYSTEMSRodrigo Ruiz Aguayo
Parc Bit - Son Espanyol
07120 Palma de Mallorcamailto:[EMAIL PROTECTED]
Baleares - España  Tel:+34-971435085 Fax:+34-971435082
http://www.gridsystems.com
---


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.4/351 - Release Date: 29/05/2006


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Axis2] Generated element objects vs. business objects

2006-05-30 Thread robert lazarski
Depends how you've mapped your domain objects. For example, instead of
populating your domain object, you could just populate your complex
object. And in some cases - such as hibernate -  you're going to
run into lazy issues as you can't transfer those objects across jvm's.
So in the latter case you mostly need to seperate the 
domain  and complex  objects anyways. 

In practice at least for me, the advantages of seperations of concerns
have outweighed the tedious gets and sets between your domain and
complex objects. This has been especially true in web services work,
where there is often more ways than one to get and use the data. 

Now if your domain objects were xml or could be mapped as xml easily
via frameworks such as hyperjaxb, it could open up your options. 

Just my 2 cents. 

HTH,
Robert
http://www.braziloutsource.com/On 5/30/06, [EMAIL PROTECTED]
 <[EMAIL PROTECTED]> wrote:

Hi,

I'm struggling a bit with the following.

Say, I have a web service that allows
you to search for customers. It accepts a customer name, and returns a
set (any number) of customers. The response xml may look like


        
         
      123
         
      John Doe
        
        
         
      987
         
      Jane Doe    
   
        


Obviously, in my application I have
a Customer class. Now if I create a wsdl for this web service, and generate
the server side code for it, one of the classes that is generated is a
customer class, that represents the customer in the xml response. On the
other hand, I have the Customer domain object, which is a different one.
To generate the response, I have to create 'xml response' customers, and
basically copy the information from the Customer class to it. The above
example is very simple, but you can imagine more complexe cases that would
involve a lot of copying from domain objects to xml representation objects.
This is very tedious and error-prone work -- typically work that I would
like to avoid.

Is there an elegant way to solve this
issue?


Thanks,
Tom



[Axis2] Generated element objects vs. business objects

2006-05-30 Thread vandenberget

Hi,

I'm struggling a bit with the following.

Say, I have a web service that allows
you to search for customers. It accepts a customer name, and returns a
set (any number) of customers. The response xml may look like


        
         
      123
         
      John Doe
        
        
         
      987
         
      Jane Doe    
   
        


Obviously, in my application I have
a Customer class. Now if I create a wsdl for this web service, and generate
the server side code for it, one of the classes that is generated is a
customer class, that represents the customer in the xml response. On the
other hand, I have the Customer domain object, which is a different one.
To generate the response, I have to create 'xml response' customers, and
basically copy the information from the Customer class to it. The above
example is very simple, but you can imagine more complexe cases that would
involve a lot of copying from domain objects to xml representation objects.
This is very tedious and error-prone work -- typically work that I would
like to avoid.

Is there an elegant way to solve this
issue?


Thanks,
Tom