Serialization of SOAP requests

[marco]

Hello there,

I've got a new problem which I don't know how to address best.

I've got a C# web service which is invoked by various SOAP clients. One
of the clients performs some batch processing by accumulating many
requests which are sent to the service by dedicated sequential calls.

In order to speed up the processing by limiting the network overhead I
would like to serialize the batch of SOAP requests, passing them at
once to some wrapper of my service which would deserialize them,
process them by the standard WS (locally) and serialize back the
results to the calling client.

What's the best way to parse the serialized SOAP requests?

Cheers and thank you already!

-- Marco --

 

[Kevin Spencer]

In order to speed up the processing by limiting the network overhead I

would like to serialize the batch of SOAP requests, passing them at
once to some wrapper of my service which would deserialize them,
process them by the standard WS (locally) and serialize back the
results to the calling client.

I'm not following you. A SOAP request IS serialized (as XML). And a Web
Service DOES deserialize them.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[marco]

Hi Kevin,

let me explain better: I've got a webmethod f() which is called by
several SOAP clients. Processing time for f() is very limited compared
to the network overhead.

One of the clients needs to call f() on a bunch of requests (x1...xn)
so instead of calling f(x1), f(x2).. f(xn) sequentially (spending the
connection setup time for each request) I could "pack" the requests and
pass the resulting object (X) at once to a wrapper F(X) method which
could "unpack" them and invoke f(xi) on the single requests locally on
the server. F() would pack the single replies afterwards and send them
back to the callee.

Is it meaningful in your opinion?

What I wonder is whether there's a way to specify that "X is an Array
of f's parameters" reusing somehow the f's interface defition which the
dotnet framework is usually hiding from me.

Parallelizing the requests to f(xi) on the client side would mean
dealing with threads in an environment which is outside my control so
I'd prefer avoiding it.

Cheers!

 

[Kevin Spencer]

I think you're introducing something into the mix which is more likely to
increase the load than to reduce it.

The greatest latency issue is the HTTP Request/Response issue. Once on your
server, yes, the Request has to be deserialized, but from then on it runs as
fast as any .Net application, until it's time to reserialze and send the
Response.

"Packing" multiple serialized Requests adds another layer of overhead to the
process. Your app will have to keep track of which Request belongs to which
client and so on. And it will still have to deserialize the Requests in
order to process them. So, IMHO, rather than optimizing it, you're adding
another layer of overhead and complexity to it.

Web Services is a lot slower than Remoting. Depending upon the needs of your
clients, you might consider using Remoting instead, which offers binary
serialization.

And keep an eye out for Indigo. This will definitely take the place of both
Web Services and Remoting, and perform better and more reliably than either.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.