axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <...@sosnoski.com>
Subject Re: [Axis2] Reading POJOs at client side
Date Sun, 20 Aug 2006 00:31:32 GMT
We've discussed VTD previously, on the Seattle Java users group list. 
Since that list isn't public I'll repeat my main points here.

VTD is basically an indexing schema that stores offsets into the 
document for XML components. I see this as of limited usefulness for 
most developers, who generally only want to work with a document one 
time, rather than going through the same document repeatedly. Since both 
the entire document text and the constructed index are stored in memory, 
the memory usage is generally considerably higher than what you have 
with a data binding approach (let alone an approach that processes data 
on the fly). VTD is also read-only, and cannot be used to modify or 
create XML documents, unlike data binding and document model approaches.

Leaving aside the limitations of VTD, the "benchmarks" given on the site 
are deceptive. You only time your indexing of the documents, not any 
retrieval of the data; in order to actually do anything with the data in 
the documents you'd have to run through a separate retrieval. The time 
for SAX/StAX, on the other hand, includes providing the data to the 
application. I pointed this out to you several months ago and you have 
neither changed the benchmarks nor added any comment about this difference.

As I said before, I do think the VTD approach has very interesting 
potential. There are many situations where a reasonably compact, 
indexed, data store for XML documents could come in really useful - for 
instance, in handling encryption and signing, where a full document 
model of the data otherwise needs to be constructed. But to be usable 
for this purpose VTD would need StAX event stream reader/writer (where 
the reader would just access data out of VTD, and the writer would 
generate VTD with indexing) and canonicalization support, along with the 
ability to replace portions of the document. I see similar issues with 
other potential use cases for VTD - the requirement that everything be 
stored in memory makes it useless for very large documents, and the 
fixed maximum sizes on documents, names, prefixes, and nesting levels 
are all potential problems for many applications. I personally wish 
you'd focus on redesigning VTD to get around some of these limitations.

  - 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



Jimmy Zhang wrote:
> Working with a generic XML Document tree model isn't necessarily slow
> http://vtd-xml.sf.net/
>
> Object binding maybe easy to use but it makes the applications too 
> tightly coupled,
> when data format evolves, object binding tends to break applications...
>
> ----- Original Message ----- From: "Dennis Sosnoski" <dms@sosnoski.com>
> To: <axis-user@ws.apache.org>
> Sent: Friday, August 18, 2006 2:44 PM
> Subject: Re: [Axis2] Reading POJOs at client side
>
>
>> Even reflection-based data binding can be faster than working with 
>> object models - but in this case, it looks like the BeanUtil code 
>> used for the conversions is building the tree in any case, rather 
>> than working directly with the parser. It also looks like it builds 
>> the reflection metadata every time through. So I suspect you're right 
>> that working directly with OM is going to be much faster than using 
>> this.
>>
>> Performance aside, I'd think the programming advantages of working 
>> with classes rather than directly manipulating a document model would 
>> be a more important concern for most users. If they really need speed 
>> they're much better off using ADB or JiBX for the conversions to and 
>> from XML. JiBX is certainly much faster than using OM, and lets users 
>> work with their existing POJOs.
>>
>>  - Dennis
>>
>> robert lazarski wrote:
>>> Performance advantages in the context of OM and Stax versus the axis2
>>> implementation of RPC and arrays, as the OP wanted ? AFAIK that case
>>> has not been thrown against jmeter but my hunch is that OM and Stax
>>> will run circles around anything involving the reflection based
>>> RPCMessageReceiver. If you think otherwise I suppose we could agree to
>>> a test case and do the pepsi challenge via jmeter ;-) . I'd be happy
>>> to stand corrected.
>>>
>>> Cheers,
>>> Robert
>>> http://www.braziloutsource.com
>>>
>>> On 8/18/06, Dennis Sosnoski <dms@sosnoski.com> wrote:
>>>> What kind of performance advantages are you talking about, Robert? 
>>>> AFAIK
>>>> the only way OM has any performance advantage is if it's not fully 
>>>> built
>>>> (i.e., when it's used in conjunction with data binding, where the data
>>>> binding handles actual data conversions to and from objects). 
>>>> Otherwise,
>>>> it's just a somewhat heavy-weight document model.
>>>>
>>>>   - Dennis
>>>>
>>>> robert lazarski wrote:
>>>> > OM has lots of performance advantages among many others so go with
>>>> > that if in doubt.
>>>> >
>>>> > HTH,
>>>> > Robert
>>>> > http://www.braziloutsource.com
>>>> >
>>>> > On 8/18/06, Charak, Vikas <vikas.charak@cns-inc.com> wrote:
>>>> >> I guess, I am still trying to find out for interoperability
>>>> reasons or
>>>> >> what is recommended way .If I should be using OMElement as input

>>>> and
>>>> >> output for my methods [raw xml format] or should it be more
>>>> structured
>>>> >> like using POJO etc.?
>>>> >> The one issue I see with RawXml is generating XML using OMElement's
>>>> >> API's where as I can easily create POJOs from my data.
>>>> >> Any recommendations.
>>>> >>
>>>> >>
>>>> >> -----Original Message-----
>>>> >> From: robert lazarski [mailto:robertlazarski@gmail.com]
>>>> >> Sent: Friday, August 18, 2006 2:51 PM
>>>> >> To: axis-user@ws.apache.org
>>>> >> Subject: Re: [Axis2] Reading POJOs at client side
>>>> >>
>>>> >> AFAIK RPCMessageReceiver just follows the old jax-rpc JSR much 
>>>> in the
>>>> >> way axis 1.x does , and the integration tests reflect that.  So
if
>>>> you
>>>> >> find a problem file a jira but I do expect that you can use these
>>>> >> examples between languages.
>>>> >>
>>>> >> HTH,
>>>> >> Robert
>>>> >> http://www.braziloutsource.com/
>>>> >>
>>>> >> On 8/18/06, Charak, Vikas <vikas.charak@cns-inc.com> wrote:
>>>> >> > I might be wrong. This will work if client is a Java Client.
What
>>>> >> > happens if the client is non-java, then is this way 
>>>> recommended or
>>>> >> > should I be using OMElement as input and output for my method.
>>>> [Data
>>>> >> > goes in and out only in raw xml format]
>>>> >> >
>>>> >> > Any suggestions?
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > -----Original Message-----
>>>> >> > From: robert lazarski [mailto:robertlazarski@gmail.com]
>>>> >> > Sent: Friday, August 18, 2006 1:16 PM
>>>> >> > To: axis-user@ws.apache.org
>>>> >> > Subject: Re: [Axis2] Reading POJOs at client side
>>>> >> >
>>>> >> > In the latest source there is some integration tests:
>>>> >> >
>>>> >> > modules/integration/test/org/apache/axis2/rpc/RPCCallTest.java
>>>> >> >
>>>> >> > That has some array examples and should get you started.
>>>> >> >
>>>> >> > HTH,
>>>> >> > Robert
>>>> >> > http://www.braziloutsource.com/
>>>> >> >
>>>> >> > On 8/18/06, Charak, Vikas <vikas.charak@cns-inc.com>
wrote:
>>>> >> > > Using RPCMessageReceiver I was able pass person POJO to
my 
>>>> client
>>>> >> from
>>>> >> > a
>>>> >> > > web service
>>>> >> > >
>>>> >> > >         public User[] getUsers() {
>>>> >> > >                 return User array;
>>>> >> > >         }
>>>> >> > >
>>>> >> > > Now I have ,
>>>> >> > >
>>>> >> > > public void addUsers(User[]) {
>>>> >> > > }
>>>> >> > >
>>>> >> > > Any idea on writing a java client to send user arrays
to 
>>>> addUsers
>>>> >> > method
>>>> >> > > of the same web service. User is a plain java class with
>>>> getters and
>>>> >> > > setters.
>>>> >> > >
>>>> >> > > Any help is appreciated.
>>>> >> > >
>>>> >> > >
>>>> >> > > Thanks.
>>>> >> > >
>>>> >> > >
>>>> >> > >
>>>> >> > >
>>>> >> > >
>>>> >> > >
>>>> >> > >
>>>> >> > >
>>>> >> 
>>>> ---------------------------------------------------------------------
>>>> >> > > 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
>>>> >> >
>>>> >> >
>>>> >> >
>>>> ---------------------------------------------------------------------
>>>> >> > 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
>>>> >>
>>>> >>
>>>> >> 
>>>> ---------------------------------------------------------------------
>>>> >> 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
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>

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


Mime
View raw message