Bonjour,

Les Web Services Enhancements 1.0 sont disponibles sous :

\\olympe\NTline2\SDK\SDK_TOOLS\WEBSERVICE_1.0

Overview :

The Web Services Enhancements (WSE) provides an implementation of the XML Web services architecture for developers creating XML Web services using ASP.NET and Microsoft .NET Framework client applications. That is, the WSE allows developers to incorporate security, routing, and attachment features in their applications. The implementation of XML Web services specifications by the WSE allows three major features to be added to distributed applications that use XML Web services:

Applications can be secured across platforms and trust domains.
The route a SOAP message takes to an XML Web service can be transparently delegated among Web servers.
Communication between XML Web services can contain attachments that are not serialized into XML.
The WSE provides this support by building on the XML Web service support found in the .NET Framework.

Securing XML Web Services

XML Web services can be secured today, but limitations exist when it comes to building scalable distributed applications based on XML Web services. Specifically, it is difficult to build scalable applications that cross security domains. Today, you can secure XML Web services by having the message sent over a secure transport, such as Secure Sockets Layer (SSL), but that only works when the communication is point-to-point. That is, if the SOAP message must be routed to one or more intermediaries before reaching the ultimate receiver and the entire route uses SSL, then the ultimate receiver still has to communicate with the sender to authenticate the sender of the SOAP message. That scenario is difficult to scale.

One of the ways the WSE helps to build scalable distributed applications is by providing an efficient and scalable mechanism to secure XML Web services. It uses the mechanism defined in the WS-Security specification to place security credentials in the SOAP message itself. This is done by having a client obtain security credentials from a source that is trusted by both the sender and receiver. When a client makes a SOAP request, those security credentials, which are generically known as security tokens, are then placed in the SOAP message. When the Web server receives the SOAP request, it does not need to make another network request back to either the client's computer or a trusted third party to verify the integrity of the security tokens. This is possible if the security credentials are from a trusted source. Instead, the WSE cryptographically verifies that the credentials are authentic before passing execution to the XML Web service. By not having to go back to the source of the credentials, at least one network request is saved, further improving application scalability.

Digitally signing and/or encrypting the SOAP message can further secure XML Web services. Digital signing of a SOAP message secures an XML Web service by enabling a SOAP message recipient, such as an XML Web service, to cryptographically verify that a SOAP message has not been altered since it was signed. Encryption of a SOAP message helps secure an XML Web service by making it highly likely that only the intended XML Web service reads the contents of the message.

The WSE provides three features that contribute to the secure transmission of SOAP messages:

Security credentials enable the scalable securing of XML Web services over the complete route a SOAP message takes. This is different from a secure transport, such as SSL, which only secures from one point to another. For details on how to use the WSE to add security credentials, see Adding Security Credentials to a SOAP Message.
Digital signing allows a SOAP message recipient to cryptographically verify that a SOAP message has not been altered since it was signed. For details on how to digitally sign SOAP messages using the WSE, see Digitally Signing a SOAP Message.
The following graphic illustrates the keys needed by the sender and receiver to both sign a SOAP message and to verify the signature. To sign the SOAP message, the sender needs its private key and for a receiver to verify the signature within a SOAP message it needs the sender's public key.

Encryption makes it highly likely that only the intended recipient can read the contents of a message. Encrypting a SOAP message creates a cryptographic secret that is shared with the intended recipient of the message. For details on how to use the WSE to encrypt and decrypt SOAP messages, see Encrypting a SOAP Message.
The following graphic illustrates the keys needed by the sender and receiver to both encrypt and decrypt a SOAP message. To encrypt a SOAP message, the sender needs the receiver's public key and the receiver needs its private key to decrypt the SOAP message..

Routing SOAP Messages

A distributed application using the WSE can be designed such that the network topology implementing the application is transparent to clients. To set up a transparent network topology, set up an intermediate computer that is configured to run the WSE router. Clients then send the SOAP messages to the WSE router instead of directly to the XML Web service. The WSE router then delegates the SOAP message to a computer hosting the XML Web service, which can be changed using a configuration file on the computer hosting the WSE router.

The following graphic depicts sending SOAP messages to a WSE router and the WSE router delegating the SOAP message to another Web server based on the contents of a referral cache. In this sample, the referral cache is configured to send the SOAP message to Web server B, but the referral cache could be modified to send it to Web server C.

One of the benefits of using the WSE router with a distributed application is that a computer hosting an XML Web service can be taken offline for maintenance without modifying either the client code or its configuration. An administrator of the computer hosting the WSE router can make all the changes needed to redirect the SOAP messages to another computer. To do so, an administrator prepares a backup computer to be brought online to host the XML Web service, while the router continues to delegate SOAP messages to the primary computer. Then the administrator prepares a Web.config file that specifies the file containing the referral cache and a new referral cache containing the URL for the backup computer. A referral cache is an XML file containing the ultimate destination for URLs received by the router. Then when the primary computer is taken offline, the Web.config and referral cache are placed on the computer hosting the router. Subsequent SOAP messages are then dynamically routed to the backup computer — all unbeknownst to the client application, which is still sending SOAP messages to the router.

The WSE also supports the forwarding of SOAP messages to their recipients based on information indicating an alternative route for an XML Web service. A recipient of the SOAP message can then dynamically route messages according to the referral without the intervention of an administrator. The WSE only supports the forwarding of SOAP messages that are not intended for a computer running the WSE router.

For detailed steps on how to route SOAP messages using a transparent network topology, see Routing SOAP Messages with the Web Services Enhancements.

Sending Attachments with SOAP Messages

The WSE supports the Direct Internet Message Encapsulation (DIME) protocol, which defines a mechanism for passing attachments in a SOAP message. It is often necessary for an XML Web service to send a large file of text or binary data, such as an image file, in a SOAP message. SOAP messages, by default, are not necessarily a good mechanism for transporting these large files, because they are plain-text XML. To be added to a SOAP message, a file must be serialized into XML, which could be more than double the size of the original file. The DIME protocol solves that problem by defining a mechanism for placing the entire contents of the original file outside the SOAP envelope, eliminating the need to serialize the file into XML.

For detailed steps on how to send attachments with SOAP messages, see Adding Attachments to a SOAP Message Using DIME.

The following table is a summary of the features defined by the XML Web services architecture that are supported by the WSE.

Web service specification Feature supported by WSE
WS-Security Digitally Signing a SOAP Message. Digital signing allows a SOAP message recipient to verify that the SOAP message has not been altered since it was signed.
WS-Security Encrypting a SOAP Message. Encryption creates a cryptographic secret, so that only the owner of a private key or a symmetric key can read the contents of a message. The WSE supports both encrypting and decrypting messages.
WS-Security Adding Security Credentials to a SOAP Message. Security credentials passed in the SOAP message can be especially useful when the SOAP message is routed through destinations other than the ultimate receiver.
WS-Routing Routing SOAP Messages with the Web Services Enhancements. SOAP messages sent using logical names provide network topology transparency.
WS-Attachments Adding Attachments to a SOAP Message Using DIME. Sending attachments in a SOAP message allows a file to be added to the SOAP message without serializing its contents into XML.  

The following graphic illustrates that only the intended recipient of an encrypted SOAP message can access the encrypted portions of the SOAP message, as it is the only one with the private key that decrypts the SOAP message.