dotnet web services: I am trying to keep some cached information across several
SoapExtensions:

In my project there are client applications (web and console) that ask
a web service. The web service is also mine. But both the client and
the server could be different as long as they keep to the message
format defined. The information goes through some SoapExtensions in the
server and the client to do some processing like signing, schema
validation, signature validation.

There is a piece of information that I get from another web service.
This piece is used in the client and in several of the soap extensions.
Since it is the result of a network operation, I try to cache it, but,
since it is not explicitly part of the message, I don't know how to
pass it from client to client SoapExtension and across SoapExtensions.
I don't intend to pass it from client to service since each could be
done with a different technology.

I have tried with Session variables but I found that, while I have
access to the Session object in the client SoapExtensions, probably
because I tried with a web application, the Session is null in the
SoapExtensions of the service.
I have added EnableSession=yes to the web method and web.config has:
<sessionState mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data
source=127.0.0.1;Trusted_Connection=yes" cookieless="false"
timeout="20"/>
So I guess that SoapExtensions don't have access to Session state.

I have rejected SOAP headers since I don't know how to fill them from
the client and the information should not be transmitted to an unknown
web service or client.

I could use the Apllication state, but either I keep only the result of
one check disabling the processing of parallel web service request, or
it could grow big from storing many pieces that might never be used
again.

So I think that I have to use the Cache state from the client and the
SOAP extensions. I have to find a key that avoids collisions between
the different requests, and the Cache will purge itself from old data.

Is that the proper way?

--
David Mediavilla <6kjfsyg02@sneakemail - com>

[quoted text, click to view]

The Cache state works in the Soap Extensions, but I now realize that I
will not have a Cache in the console client.

Ideas?

[quoted text, click to view]

--
David Mediavilla <6kjfsyg02@sneakemail - com>

[quoted text, click to view]


Please be more clear about the flow of this piece of information. Does the
server get it from another web service during a client request, and is it
then used back on the client? Is it a SoapExtension on the server which
retrieves the information, and is it a SoapExtension on the client which
consumes it, or is it the client application itself?

In general, and without knowing the answers to the above questions, I'd
suggest you take another look at SOAP Headers, which are frequently used for
sending out of band information between SoapExtensions.

John

[quoted text, click to view]

Sorry, I'll try.

This p=ECece of information is about the X.509 certificate used to sign
the message. It is obtained from a web service in another organization.
It is required by the client application, several client SOAP
extensions and several server SOAP extensions. The server SOAP
extensions cannot trust the client so at least one asks the remote web
service itself with input extracted from the message.

Some of the SOAP extensions are used in both the client and the server,
so I'd like not to have to distinguish where the extension is.

[quoted text, click to view]

Can the SOAP headers be passed from the client application to its SOAP
extensions?
I'd have to manually delete them before actually putting the SOAP
message on the wire, wouldn't I?

[quoted text, click to view]

Thanks.

--
David Mediavilla <6kjfsyg02 - sneakemail.com>

The client can create the header, and then the client SoapExtensions will be
able to see it as the message heads out towards the server. The server
SoapExtensions will also be able to see it.

There is no reason not to allow it to pass from the client to the server. In
fact, that's how the server SoapExtensions will see it.

Of course, your WSDL will have to describe the fact that the header exists,
and that the operation which accepts the header supports it.

John