axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: Design question on using Java classes v/s hashes or arrays
Date Wed, 25 Dec 2002 02:01:24 GMT

----- Original Message -----
From: "Rajal Shah" <rashah@cisco.com>
To: <axis-user@xml.apache.org>
Sent: Thursday, December 19, 2002 15:51
Subject: RE: Design question on using Java classes v/s hashes or arrays


> I see your point.. If business functionality changes though, then maybe
you
> need to change the method name or something and deprecate the old method..
> to solve the issue you bring up. (and work on your SLAs with the clients
to
> make them understand the new behavior or provide both business logic
> options).
>
> I am referring to the versioning of services for extending the
functionality
> of a data object. And having 2 end points can serve the needs to backward
> compatibility and avoid me to define my objects as hashes.

If you use doc/lit messaging rather than rpc/enc, you can add new stuff to a
message (But obviously these need to be optional additions, you cannot
subtract, and you need to keep semantics 100% consistent. Even so, it does
give doc/lit a bit of flexibility. And equally importantly, shows up
versioning issues in API signatures fast.

>> I talk about versioning a bit in http://iseran.com/Steve/papers/wstw/
>
> Your document is pretty comprehensive and well thought out!

I still have doubts there. There are lots of issues we are let to learn, and
only that trial and error will find. I sort of wrote that paper as I was
going along, but decided it was time to get stuff out the door.

with my current project I wrote the proto server, then did the client (swing
based), and soon redid bits of the api for ease of programming and long haul
perf. For example one call returned #of items in a queue, another listed the
queueID of all elements, and the third took one queueID and returned
info about that element.

Now what do I do for long haul? Do I boost throughput with a message that
lets you specify a list of queue items. Good for http1.0 nagling, saves on
net sockets used (good for the server),... But it could make the UI less
responsive. Right now I can fill the list in one at a time, with a worker
thread to talk to the server. But with a bulk call I dont get an update till
the update is complete.

I dont see any 'best answer' here. I'll probably add the bulk call for when
somebody wants it, but maybe only fetch small chunks, say 4 items at a time,
for responsiveness.

-steve


Mime
View raw message