Board index » delphi » Memory Management SOAP dynamic array

Memory Management SOAP dynamic array


2007-04-12 02:09:53 AM
delphi230
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 is 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
 
 

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 is only the latter, then I'd 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 will 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.
 

Re:Memory Management SOAP dynamic array

Hi Bruneau,
Thanks for hints it is 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" <XXXX@XXXXX.COM>writes
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 is only the latter, then I'd 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 will 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.


 

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 is 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 is 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 is explicitly
told to allow multiple outs. you will 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.