 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Patrick Paquette
Guest
|
 Posted: Wed Apr 11, 2007 11:09 pm Post subject: Memory Management SOAP dynamic array |
 |
|
Hi,
I want to know how work memory management with webservice SOAP.
example: I have and array of TRemotable descendant.
If i call a function on the webservice who set the length of array and
return it to my client.
who should allocate length of the array ? client or server
TMetaData = class(TRemotable)
private
FName: WideString;
FValue: array of WideString;
published
property Name: WideString read FName write FName;
property Value: array of WideString read FValue write FValue;
end;
TArrayOfMetaData = array of TMetaData;
IDocutheque = interface(IInvokable)
['{A3B122C9-D158-407C-8B01-1975B614F93B}']
function RetrieveMetaDatas(sUserName, sPassword: string; sResID:
string; var aMetaDatas: TArrayOfMetaData): Integer;
end;
main:
var
aMetaDatas: TArrayOfMetaData;
begin
// I think that i should create all TMetaData.create() for each element
in the array and also set length of FValue array. but i wish not
(HTTPRIO as IDocutheque).RetrieveMetaDatas(sUserName, sPassword: string;
sResID: string; var aMetaDatas: TArrayOfMetaData)
// is it true, or SOAP will manage it without us ?
// it's can be very painfull to allocate all memory before call the
function who populate the array, cause we have no idea how long is the
dynamic array.
someone can advice
thanks |
|
| Back to top |
|
 |
Jean-Marie Babet
Guest
|
| Posted: Thu Apr 12, 2007 2:36 am Post subject: Re: Memory Management SOAP dynamic array |
|
|
Hello Patrick,
On the client you are responsible for freeing all objects created. However,
the SOAP runtime creates objects that represents data sent back from the
service.
In the case of RetrieveMetaDatas, are you also sending data to the service,
or only receiving? If it's only the latter, then I would expect the 'out'
instead of 'var' modifier.
But even in the case where you're sending and receiving, the SOAP runtime
will resize the array to match whatever came back. You'll be responsible for
freeing any objects still in the array after RetrieveMetaDatas returns.
Does that make sense? Please let me know if I can provide more information.
Cheers,
Bruneau. |
|
| Back to top |
|
|
Patrick Paquette
Guest
|
| Posted: Thu Apr 12, 2007 7:03 pm Post subject: Re: Memory Management SOAP dynamic array |
|
|
Hi Bruneau,
Thanks for hints it's now clear
Conclusion:
The client (programmer) should free memory allocated by the SOAP response.
That All !
We don't have to allocate suffisant memory to receive response, a bit like
windows API.
Out parameters are frequently used with distributed-object models like COM
and CORBA.
If you tell me that is also used at large in WebService, i will use it.
Thanks
Patrick
"Jean-Marie Babet" <bbabet (AT) borland (DOT) com> wrote in message
news:461d54dd$1 (AT) newsgroups (DOT) borland.com...
| Quote: | Hello Patrick,
On the client you are responsible for freeing all objects created.
However,
the SOAP runtime creates objects that represents data sent back from the
service.
In the case of RetrieveMetaDatas, are you also sending data to the
service,
or only receiving? If it's only the latter, then I would expect the 'out'
instead of 'var' modifier.
But even in the case where you're sending and receiving, the SOAP runtime
will resize the array to match whatever came back. You'll be responsible
for
freeing any objects still in the array after RetrieveMetaDatas returns.
Does that make sense? Please let me know if I can provide more
information.
Cheers,
Bruneau.
|
|
|
| Back to top |
|
|
Jean-Marie Babet
Guest
|
| Posted: Thu Apr 12, 2007 10:08 pm Post subject: Re: Memory Management SOAP dynamic array |
|
|
Hello,
| Quote: | Out parameters are frequently used with distributed-object models like COM
and CORBA.
If you tell me that is also used at large in WebService, i will use it.
|
I should probably qualify this. The specification allows for 'out'
parameters [i.e. a part that's in the output message of an operation but not
in the input message] but for the sake of interoperability most WebServices
stick to a maximum of 'out' strictly-out parameter(*). That parameter is
what maps to the return value of a function when generating a binding to the
WebService. Languages such as C++ do not support 'out' parameters, hence
cannot accurately (elegantly) represent that operation.
In Delphi we had a problem with multiple strictly-out parameters: how to
tell which one maps to 'Result' (the function's return value). It's not
always possible to proceed by elimination (for example the response may
contain xsd:any types). We use to say - "Well, if the XML element is named
"Result" or 'return', it is the data for the function's return value". Of
course that fails with certain services. For example, .NET tends to use
"<operationName>Response" as the return node.
In the end we opted to stick to Procedures when there's more than one
strictly-out parameter. That way we don't *lose* the name of any part.
If interoperability is not a big issue, 'out' are fine. If it is, then
having a single complex return type is preferable to 'out' parameters.
Cheers,
Bruneau.
(*) At least for doc|lit services, you can find out about them because the
latest importer won't unwrap cases of multiple 'out' unless it's explicitly
told to allow multiple outs. You'll see something along the lines of the
following in the generated file:
// Cannot unwrap:
// - More than one strictly out element was found
// Headers: HumanVerification:pIn
function ListMessages(const ListMessages: ListMessages2):
ListMessagesResponse2; stdcall;
The above is from YahooMail's webservice. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
