Galore wrote:
I've got an application that calls lots of web services, throught the
Internet. I need to keep track of every web service call (every data
that's transfered), and log it into a DB. Some WS uses SSL.
This sounds like a good candidate for creating an infrastructure service
that would sit in the message processing pipeline and logs the SOAP message
to a database. An infrastructure service is a Web service that is configured
to process the SOAP message on its way in or out of a service. This is the
same mechanism used for securing the message, attachments, etc., so far from
being escoteric, that's what the message processing pipeline is designed
for. One major advantage of this approach is that one logging infrastructure
service is all that you'll need, you don't have to write custom code for
each client or service they call to make it work. See Figure 2 in
Messaging -- Application Architecture: Conceptual View [1] for what the
message processing pipeline looks like architecturally.
Also, because the logging infrastructure service intercepts SOAP messages in
the message processing pipeline, that makes it compeletely independent of
transport security such as SSL: a message outbound from your application
will be processed through the entire pipeline before it is passed to the
transport channel where it gets encrypted; similarly, incoming messages are
decrypted on the transport before they are processed by the inbound message
processing pipeline.
How you implement and configure an infrastructure service depends on what
technology you are using. With ASP.NET XML Web Services (ASMX), take a look
at SOAP Extensions [2].
In WSE 2.0, infrastructure services may be configured through WS-Policy [3],
although writing a custom logging policy may be somewhat more challenging.
Cheers,
Stuart Celarier, Fern Creek
[1]
http://msdn.microsoft.com/library/en...nmessaging.asp
[2]
http://msdn.microsoft.com/library/en...extensions.asp
[3]
http://msdn.microsoft.com/library/en...derstwspol.asp