Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-user@ws.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <46A9E57D.6090004@sosnoski.com>
Date: Sat, 28 Jul 2007 00:30:53 +1200
From: Dennis Sosnoski <dms@sosnoski.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: axis-user@ws.apache.org
Subject: Re: Axis2 article with databinding comparison
References: <46A922CE.9040909@sosnoski.com> <46A9D33C.7020509@gmail.com>
 <46A9DCCE.9010604@sosnoski.com> <46A9DE97.9080305@opensource.lk>
In-Reply-To: <46A9DE97.9080305@opensource.lk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I only mentioned the POJO support in passing, and only because I'm 
discussing the JiBX support for working with existing classes. The 
difference between the two is that with JiBX you control the form and 
structure of the XML representation, and can also handle any kind of 
Java data structure you want while still decoupling the Java structure 
from the XML representation. In this JiBX is much more comparable to 
JAXB than to POJO support.

But I'll ask to have the POJO reference dropped completely, since it's 
not really a data binding approach in any case.

  - Dennis

Deepal Jayasinghe wrote:
> Dennis Sosnoski wrote:
>   
>> Hi Deepal,
>>
>> I don't really consider POJO support as appropriate for web services
>> of any complexity, since it directly exports the object model as part
>> of the service definition. It also is generally unable to cope with
>> data structures of any complexity, such as hash maps and even
>> collections (other than typed arrays), or any form of object graphs.
>> These are the same issues which led to the deprecation of rpc/enc -
>> though rpc/enc at least had support for object graphs.
>>     
> Yes I totally agree with this and what I am always recommending is the
> contract first approach.
>   
>> Based on my experience with client organizations, I've seen very few
>> real-world applications which could successfully be exposed directly
>> using POJO service support. And based on the POJO guide for Axis2 I
>> wouldn't call the use of POJO very easy on the client side.
>>     
> Well, I just look at the document and seems it bit out dated and our
> POJO support much more richer than what the denouement says. Having said
> that even for the client side the best approach is the code generation.
>
> I just wanted to say that the your conclusion is not match with the
> current Axis2 code base , though I agree contact first approach is the
> much better one.
>
> Thanks
> Deepal
>   
>> Do you disagree on these points?
>>
>>  - Dennis
>>
>>
>>     
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org