July 15, 2004
WSE 2.0 Service Pack 1
Service Pack 1 will be released very shortly. We've tried to address the major pain points that people found after the product was released. Here's a list of the changes from the readme file:
Core product changes:
- WSE no longer throws an exception due to a SOAP message being signed by a KerberosToken security token in a time zone east of GMT.
- The value of the maxTokens attribute for the <limits> element specifies the maximum number of security tokens that may be contained within an incoming SOAP message. Previously, only natively supported security tokens counted towards the limit.
- All members of the ElementList class now use by value parameters. Previously, the Remove and IndexOf methods used by reference parameters.
- When a SOAP request does not contain a SOAPAction HTTP header, WSE throws an Microsoft.Web.Services2.Addresssing.AddressingFormatException. Previously, a System.NullReferenceException was thrown.
- WSE now generates WSDL files with unique operations when a Web service is built using the WSE Messaging API and it contains multiple Web service methods with identical names. Previously, WSE generated an incorrect WSDL document for this scenario.
- WSE no longer throws an exception during WSDL generation for Web
services built using the WSE Messaging API that contain a method with an System.Xml.XmlElement parameter.
- The GetBodyObject method of the Microsoft.Web.Services2.SoapEnvelope class now supports System.Data.DataSet objects.
- Invalid policy documents that contain multiple <Role> or <SubjectName> claims in a <SecurityToken> assertion will now fail to load.
- SecurityContextToken and UsernameToken security tokens with the same key as a cached security token can now be cached using the CacheSecurityToken method. Previously, the security token would not be cached.
- A new protected virtual method, named RaiseDispatchFailed, has been added to the Microsoft.Web.Services2.Messaging.SoapTransport class. Any class derived from SoapTransport can raise the Microsoft.Web.Services2.Messaging.SoapTransport.DispatchFailed event by calling this method.
- A new flag named IncludeReferenceProperties has been added to the Microsoft.Web.Services2.Security.SignatureOptions enumeration. This flag can be used to specify that all elements in the SoapContext.Addressing.Destination.ReferenceProperties.AnyElements collection are signed. This flag is only valid for outgoing SOAP messages.
- When dispatching a SOAP message based on an Microsoft.Web.Services2.Addressing.EndpointReference, the wsu:Id, SOAP actor and mustUnderstand attributes are now ignored.
- While retrieving an x.509 certificate, WSE is now capable of using an RFC3280 compliant algorithm to generate a key identifier for X.509 certificates that do not have the Key Identifier extension. To enable this algorithm, add an <x509> element to the receiving application's configuration file and set the useRFC3280 attribute to "true". The default value for the useRFC3280 attribute, which is new for SP1, is "false". Setting the attribute to "false" specifies that WSE uses an algorithm that is not RFC3280 compliant, as it did prior to SP1.
- After processing the SOAP envelope through all the input filters, WSE runtime will remove the SOAP header element if it no longer contains any child elements.
- When a security token request does not have an Microsoft.Web.Services2.Policy.AppliesTo (RequestSecurityToken.AppliesTo is null), WSE no longer adds an AppliesTo. Previously, WSE would default the destination to the URL for the security token service.
Visual Studio tool integration changes:
- The type attribute for settings on security token managers and binary security token managers is now an optional setting in the WSE Settings 2.0 tool. when the type attribute is not specified, the built-in security token managers are used, such as Microsoft.Web.Services2.Security.Tokens.X509SecurityTokenManager. Previously, it was required.
- The Time Tolerance in Seconds setting on the Security tab of the WSE Settings 2.0 tool now updates the <ttlInSeconds> element in the application's configuration file, even if one already exists. Previously, the value was only inserted into the <ttlInSeconds> element when the element was not currently in the configuration file.
- The X509Certificates... link on the TokenIssuing tab of the WSE Settings 2.0 tool now opens the certificate store location specified on the Security tab. Previously, it would always open the CurrentUser store.
- The Security Settings Wizard can now be used on Microsoft Windows 2000 to select, add, and view X.509 certificates. Previously, the Select Certificate, Add Certificate, and View Certificate buttons were not functional on Windows 2000.
- A new check box named Use RFC3280 has been added to the Security tab in the WSE Settings 2.0 tool that enables you to specify that WSE generates RFC3280 compliant key identifiers when an X.509 certificate does not contain the Key Identifier extension. When set, the Policy Wizard generates RFC3280 compliant PKI too.
WseWsdl2 tool changes:
- The WseWsdl2 tool now properly generates proxy classes when an Web service exposes multiple operations with the same name but with unique action names. The tool will now create a proxy correctly for this scenario by setting the new UniqueMethodName property of the SoapMethodAttribute class to a unique name.
- Proxy classes will now be generated for services containing relative URI values for SOAP action names.
- Generated proxy classes for Web service methods that use a DataSet type for a parameter or return value, now use the DataSet type as the Web service method. Previously, the proxy class would generate the System.Xml.XmlElement type for DataSet types.
- When a SoapService has an SoapActor attribute applied to it, an EndpointReference with a Via reference property is required to send a SOAP message to the Web service. To build a SoapClient that calls a Web service that has an SoapActor attribute applied to it, use the new WseWsdl2 tool command line parameter, name, and specify the logical name that is specified in the Web service's SoapActor attribute. The generated SoapClient proxy class will correctly address the Web service with a fully specified EndpointReference. For an example of how to specify the EndpointReference without using the WseWsdl2 tool, see the TcpSyncStockService QuickStart sample.
- When a WSDL contains a schema definition that is registered with an empty namespace and if any of the message part elements contain a Type attribute the tool will no longer throw an exception.
- The WseWsdl2 tool can now process WSDL documents that have nested <import> elements. That is, WSDL documents that contain an <import> element that references a WSDL document, which in turn has an <import> element that references another WSDL document, and so forth. To specify the level of recursion that the WseWsdl2 tool will go through to download the imported WSDL documents, two new command line parameters have been added to SP 1: noRecursion and recursionLevel. To specify how many levels of recursion you want the tool to go through, use the recursionLevel followed by an integer representing the number of levels or documents you want the tool to go through. The default is 3. If you do not want the tool to download WSDL documents specified in <import> elements, use the noRecursion command line parameter. If both parameters are used, the noRecursion parameter takes precedence.
- Like the WSDL.exe tool, the WseWsdl2 tool now generates methods to communicate with a Web service asynchronously. That is, for every Web service method, a BeginXXX and EndXXX method are generated. The XXX in the name of the method is the name of the synchronous method. Use the BeginXXX method to initiate an asynchronous call and the EndXXX method to complete it.
X509 Certificate Tool changes:
- When choosing a certificate, the X509 Certificate tool will also display the RFC3280 compliant PKI for that certificate.
Posted by herveyw at July 15, 2004 05:45 PM
Thanks Hervey,
Problably is too late to report the following sugestions for changes in the Messaging core:
1. The SoapClientAsyncResult class:
Getting the Transport from the ReplyTo endpoint instead of the client.Destination
This change will allow to use a transport scheme specified in the ReplyTo (Response) endpoint instead of the Destination (Request) transport scheme.
2. The SoapClientAsyncResult.OnSendComplete method:
Passing the client's reference to the BeginReceive state instead of the null value.
This change will allow to obtain the client's properties (for instance Timeout) in the InputChannel's receiver handler.
3. The SoapTransport.DispatchMessage method:
The method locked the all Input Channels for invoking the channel1.Enqueue(message) function.
That's fine in the case of an in-memory message queing.
Note that the Enqueue method is overridable, so in the case, for instance, soap.msmq custom transport, queing the received messages into the in-memory is not necessary, and it should be not used for many reason (transactional messaging, etc.) and rather a message passed direct to the Receiver in synch manner.
This enables controlling the messages from the queue.
Comming to my point, when Enqueue method is possible overriden, than it's very easy to block all input channels by single receiver for infinite time.
The above sugestions are my experience from implementation and heavy testing my soap.msmq custom transport [1].
Thanks in advance.
Roman
[1] http://www.codeproject.com/useritems/SoapMSMQ.asp
Any of chance of getting a proxy generated with Properties rather than fields? That makes binding to DataGrids and the like much easier.
I'd might as well throw in my two cents...
Please, please, please, please, please provide a public implementation of the policy OM (i.e. parser). FWIW, *dynamic* policy generation and interpretation by endpoints (to ensure things like QoS) would be super nice.
how soon ? i am biting my nails in anticipation
Thank you for the useful information on SP1. One more general question that I have not found answered anywhere: how will WSE 2.0 relate to Visual Studio 2005 (Whidbey)? Surely it won't be completely replaced?
I would like to know how soon. I am working on something right now that needs the config tool to work on 2000. Can you provide a rough estimate or even a general fix for just this silly problem of it not running on 2000? Also, is there a good copy of the policy file standards laying around somewhere? If sp1 does not meet my needs I may just end up writing my own config tool
Perhaps reiteration is wasteful, but I could really use the ability to load / apply policy documents somewhere other than the app.config for my proxy. At the moment, one of the target host processes for my web service proxy is ASP using a CCW. I'm having quite a difficult time getting my custom app.config to load when the CLR gets instantiated by ASP, especially in light on the numerous processes that potentially host an ASP thread. This effectively removes my ability to use WS-Policy, and forces me to code everything in by hand. Ack.
Thomas S. Trias
Senior Developer
Afni Insurance Services
http://www.afniinc.com/
I think the configuration tool generates an erroneous assembly name for SP1. Version number written to the config file is 2.0.0.0, shouldn't it be2.0.1.0?
Generated with SP1 config tool:
Microsoft.Web.Services2.WebServicesExtension, Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
[gac contains version number 2.0.1.0]
Your post has been highlighted on TheServerSide.NET. We welcome your comments on the posting as well as any additional information you have for our readers.
Thanks,
Paul Ballard, Editor
TheServerSide.NET