I have done quite a few presentations and demos this year. The most fun was the one in MS TechED Asia 2004 in Malaysia where I did 2 sessions on Web Services Enhancements (WSE) 2.0 and 1 on UDDI where I met so many cool people.

I will close out my presentations of the year 2004 with a presentation on MSDN Technology Day here in Singapore (Dec 15 2004) on a topic which I have been doing some research and work on.

• Category: Architecture
• Topic: Moving towards Service-Orientation: What is it actually and is it right for you ?
• Short Synopsis:
  I will attempt to explain the facts behind all the maketing hype behind Service-Orientation and why is it so focused on standards and interoperability. Get a better and clearer picture of one of the hottest buzzwords of IT today as I debunk the myths associated with SO(A) today. I will also explain on the guiding principles of Service-Orientation and the impending steps you need to take to embrace this architectural and idea philosophy in moving forward.

Register yourself here.

I will be presenting on Web Services Roadmap in Microsoft's Architect Forum on the 3rd Dec 2004 Friday (yes, short notice...Thanks Microsoft Singapore ).

The topic of the forum is ".NET Architecture for Enterprise Agility". This forum is divided into 2 tracks namely ".NET Enterprise Architecture" and the "Service-Oriented Architecture".

I will also meet up with Enterprise Customers who are considering more extensive use of Web Services and who are interested in finding out more as well as to understand what is in the pipeline from Microsoft for Advanced Web Services, its plans and progress.

I hope to be able to answer questions from the architects from the enterprise organizations on the suitability of this growing standard for each specific scenarios.

If I have the time, I would really hope to be able to touch on the offerings of Indigo as well to the audience.

I have heard some presentations from MSFTies and blogs that followed that quotes Lincoln as saying “I didnt have time to write you a short letter so I wrote you this long one instead”

It seems that the people who are re-presenting those topics are using the same quotes again and again.

Lets get the facts straight: It was Mark Twain (1835 - 1910), US humorist, novelist, short story author, & wit who said that and NOT Lincoln.

While doing some deep plumbing work, I discovered that Lutz Roeder's ultimate awesome Reflector() tool is already throwing up some wonderful Whidbey VB.NET keywords. AND I dont even have .NET 2.0 installed on that machine yet. Cool

One of the keywords used is TryCast. TryCast is a new VB.NET Keyword in VS2005 which essentially combines 2 type checks into 1. For example

Instead of

Do this

Of course, performance is the differentiating issue here. TryCast, as its name suggests, will try the cast and, if it succeeds, return the value cast to that type, else, it returns nothing.

Think of it as VB.NET's answer to C# “As” keyword. Here is also a good blog about it.

Word from the man Hervey himself. Find it here.

WSE2.0 SP2 Pre-release Full product and the Runtime

Contents from the ReadMe:

Core product changes:

• A new compatibility section is used to select the wire format on the sending
  side. The mode attribute tells WSE runtime to generate a message which will be
  compatibable to a particular release of WSE. By default, the mode is WSE2RTM. It can be WSE2RTM, WSE2SP1 WSE2SP2 and so on. On the receiving end, a particular version of WSE runtime will be able to accept all types of wire format in all its previous releases. In a request-response message exchange, a server will generate a response message which is compatible with the request message. The server will, by default, still use the compatibility section to generate its response if it cannot determine the compatibility mode based on the request message.
  
• A new implementation of the Kerberos token based on SSPI interfaces is included in this release. The new token is named KerberosToken2. Please see the reference documentation for more details.
  
• The TokenIssuer element in the KerberosToken security token assertion is
  no longer supported on the receiving end.
  
• The SecurityTokenManager no longer throws exception in LoadTokenFromXml() when token.IsCurrent returns false. WSE security input filter will continue checking that and throw exception if token.IsCurrent returns false.
  
• The inclusion of unencrypted Username tokens in a message may represent a security vulnerability. The SecurityTokenServiceClient class will now automatically encrypt any Username tokens included in a request. Similarly, the SecurityTokenService class will automatically encrypt any username tokens included in a response.

  The following methods have been added to the token issuing framework:

  protected virtual void SecurityTokenServiceClient.EnforceRequestUsernameTokenEncryption().
  Called from EnforceRequestPolicy(), this method enforces the requirement that any Username tokens in an RST message must be encrypted. The issuerToken is used as the encrypting token. This method will throw an exception if it cannot encrypt the UsernameTokens in an RST message.
  Override this method to suppress this behavior.

  protected virtual void SecurityTokenService.VerifyRequestUsernameTokenEncryption().
  Called from VerifyRequestPolicy(), this method verifies that tokens in an RST message are encrypted. This method will throw an exception if it encounters an unencrypted UsernameToken in an RST message.
  Override this method to suppress this test.

  protected virtual void SecurityTokenService.EnforceResponseUsernameTokenEncryption().
  Called from EnforceResponsePolicy(), this method enforces the requirement that any Username tokens in an RSTR message must be encrypted. The ResponseEncryptingToken is used as the encrypting token. This method will throw an exception if it cannot encrypt the UsernameTokens in an RSTR message.
  Override this method to suppress this behavior.

  protected virtual void SecurityTokenServiceClient.VerifyResponseUsernameTokenEncryption().
  Called from VerifyResponsePolicy(), this method verifies that tokens in an RSTR message are encrypted. This method will throw an exception if it encounters an unencrypted UsernameToken in an RSTR message.
  Override this method to suppress this test.
  

• A new method, protected virtual void SecurityTokenServiceClient.ClearRequestSoapContext(), has been added. This method was added to fix a bug in which successive requests for a SecurityContextToken, made through a single instance of SecurityContextTokenClient, would fail. The problem was caused by a failure to clear security elements and tokens from the soap context after a request was made. In the event that a sub-class of SecurityTokenServiceClient requires that security elements or tokens in the soap context be preserved from one request to another, the new behavior may be suppressed by overriding the ClearRequestSoapContext method.
  
• SoapService will now send back an empty SoapEnvelope back if the soap method it is invoking returns null for a request/response scenario.
  
• EncryptedData.Decrypt will only support decryption to one and only one xml element. It throws a security fault otherwise.
  
• In the SoapHttpOutputChannel.Send method, if the response has an unsupported content type, such as text/html, the response stream will be read and stored in the exception text.
  
• Two new properties, SimpleDisplayName and FriendlyDisplayName, have been added to the X509Certificate class.
  
• The default Label used in DerivedKeyToken has changed from "WS-SecureConversation" to "WS-SecureConversationWS-SecureConversation".
  
• If an incoming message contains multiple security tokens with envelope signature inside those tokens, the server was returning a security fault. This is now fixed.
  
• If WSE SOAP messaging stack is used over HTTP/HTTPS transport, a simple WSE805 exception was thrown when the response content type was not supported. Now if the response stream is readable, WSE runtime will read from response stream and throw a WSE805 exception with a more detailed error information read from the response stream.
  
• WSE configuration section will now allow whitespace or comments as child nodes for the following configuration elements: diagnostics/trace, diagnostics/policyTrace, diagnostics/detailedErrors, referralCache/cache, security/x509, security/limits.
  
• When a security context token was deserialized, WSE runtime will retrieve a token from its cache based on its globally unique Identifier. The token retrieved from the cache sometimes have a different Id than the token received from the incoming message. If that happens, WSE runtime would previously fail to verify a signature or decrypt the message. It is now fixed as it will assign the Id of the token from the incoming message to the token retrieved from the cache.
  
• The built-in SecurityContextToken service would previously cache a newly issued security context token instance before those properties defined in the IIssuedToken interface are set. Now it is fixed so that those properties are set before the newly issued token is cached.
  
• WSE runtime would previouly always generate a relative token reference in calculating message signature. When the token is not sent with the message, the receiver will return a security fault. It is now fixed so that an absolute token reference will be generated in the case when the security token is not in the message.
  
• A server fault was thrown previously when a server tries to verify a signature or decrypt a message based on a username token which uses plaintext password option or no password option and does not have nonce and/or created element. The exception is now changed to be a client fault.
  
• SoapService instances configured to automatically issue SecurityContextToken (SCT) security tokens no longer re-use the same instance of the SCT issuer. With this service pack, a new instance is created per request. This instance is accessible via the SoapService.AutoIssueSCTService property. If the old behavior
  is required, there are two work-arounds:
  
  
  
  1. override the SoapService.AutoIssueSCTService property to return a singleton instance of a SecurityContextTokenService, or
     
     
  2. create a wrapper SecurityContextTokenService that delegates to a singleton instance and register it through configuration.

Visual Studio tool integration changes:

• The default value for http Routing handler type is updated.
  
• WSE setting tool can support VS C++ project.
  
• WSE setting tool would always prompt users for confirmation when the Cancel button was clicked. Now it is fixed so that the tool will prompt user only when some changes are made by users.
  
• The Security Settings Wizard can support creating Policy files for remote service.
  

WseWsdl2 tool changes:

• The WseWsdl2 tool now properly generates proxy classes when an Web service uses a Guid type.
  
• If an input schema contains a type definition which is derived from another complex type, the proxy class would generate a class definition for that derived type with incorrect namespace. This is now fixed.

I came across this blog last week, detailing a problem he is facing with WSE 2.0

Now I that realize who he is (Hello Fai ), I peep into his project to see how I could help. Fai, incidentally, is the Academic DE for MSFT Malaysia and I met him in MS Tech.ED 2004 Asia in Msia.

Since I cannot comment on this blog (since theSpoke doesnt allow it and I dont intend to keep another account), I will comment on his problem here.

I reproduce Fai's blog snippets here.

I've been mucking around with WSE 2.0 Messaging, now moving on to SoapSender and SoapReceiver. I noticed a potential problem when I have a class that extends the SoapReceiver class, and within the Receive() method, it also sends out a SoapEnvelope via the SoapSender.Send() method. The problem only arises when I use a real transport protocol, i.e., TCP, but not when I'm using the in-proc transport. I've tried all sort of ways, including transfering the SoapSender code away from the Receive() method to a method in another class. But it still doesn't work.

Http.sys is a kernel-mode networking component of Windows and is baked into the base OS of Windows Server 2003 and now, Windows XP SP2. See here for more information.

According to Don Box here, the thinking is that it's better to have one hardened implementation in the base OS than 4-5 one-off implementations in different products/technologies. Old-timers may recall that early builds of the .NET Framework installed HTTP.SYS in order to get .NET Remoting to work with HTTP (I think it was called the COM+ web server). The fact that we had to ship a one-off HTTP server implementation in .NET Remoting was an unfortunate byproduct of HTTP.SYS not having a ship vehicle that was close to .NET V1. Hopefully making HTTP.SYS part of the base OS will keep others from going down the same path.

VS2005 now comes with a Managed Framework for Http.sys (HttpListener). Even though it was possible to host ASPX and ASMX in any managed process (WinForms, ConsoleApps, WindowsServices...) since .NET v1.0, the HttpListener class that comes with VS2005 makes it a lot easier.

ASP.NET Cassini Web Server is an example of a Windows Application hosting ASP.NET and is used throughout ASP.NET v2.0. It can run on your desktop without the use of IIS.

I will show some very simplistic examples of the how-tos in hosting HTTP Processes in a Console Application using a Console Application in .NET 2.0. In this case, I have built a simple IIS-less Web Server that can churn out Web Pages, SOAP and even SOAP that is WS-* Compliant using Web Services Enhancements (WSE) 2.0 !!!

You can find information related to the above from my previous blog post here. Do take note that the codes show there are for test and demo purposes only. There needs to be major re-work and re-factoring before it can even be considered usable.

On another node, Aaron Skonnard has just published an article here that gives a detailed explanation on the above. Do check it out.