Matias Woloski’s Blog

Lito has started implementing Biztalk Server 2006. The customer field is financial services and the scenario is messaging + orchestation. He also started blogging about this experience and the challenges faced.

If you selected the C# profile in VS 2005 you will find some annoyances.
I’ve read this post today from Scott Guthrie
talking about some tweaks to do on VS 2005 via Tools->Options and I
thought it would be nice to have it summarized and handy.

Enable the output window to show up on
build.
To enable
this by default, select the Tools->Options menu item.  Then under Project and Solutions->General
select the “Show Output Windows when Build starts” checkbox.

Show MSBuild Output Verbosity “Normal”:
Tools->Options menu item.  Then under
Project and Solutions->Build and Run you can select the MSBuild project
verbosity dropdown to be: “Quiet”, “Minimal”, “Normal”, “Detailed”, and “Diagnostic”.

Track Active Item in Solution Explorer (my favorite)
To enable
this feature in the C# profile, select the Tools->Options menu.  Under Projects and Solutions->General
select the “Track Active Item in Solution Explorer” checkbox.

[via ScottGu]

One of the challenges presented when developing Service-Oriented
application is how to setup the authorization for services. That means
"Role salesman is granted to access CreateOrder service"

The ideal would be:

1. to have a pipe & filters pluggable architecture where you
   could add/remove components without affecting the code of the services
   (this is also called cross-cutting concerns)
2. to have a nice GUI to manage Tasks and Roles
3. to have a programmatic API to do the access check in an agnostic
   provider way so if we want to change the Authorization provider in the
   future, make it painless.

Luckily these days of continous innovation we have all of these to support it:

1. WSE 3 and it Policy Assertions
2. AzMan (Authorization Manager)
3. Enterprise Library or RoleProvider of ASP.Net 2

Regards (1) I’ve already written in a previous post about the Policy
Assertions and its purpose. The idea would be to plug a Policy
Assertion that would call AzMan through EntLib or RoleProvider. In this
assertion we take the Action name of WSE using envelope.Context.Addressing.Action.Value and the WindowsPrincipal if we are using KerberosToken in WSE.

In (2) we have this great GUI (Azman.msc) to manage Tasks and Roles.

To install AzMan on Windows XP Professional

Install the Windows Server 2003 Administration Tools Pack, which you
can download from
http://www.microsoft.com/downloads/details.aspx?FamilyID=e487f885-f0c7-436a-a392-25793a25bad7&DisplayLang=en.
This tools pack enables remote server management of Windows Server
2003, but it also includes AzMan.

Note that if you are running Windows XP Service Pack 2 or later, you
must also install Service Pack 1 or later of the Windows Server 2003
Administration Tools Pack.

To install AzMan on Windows 2000

Install the Windows 2000 Authorization Manager Runtime, which you can
download from
http://www.microsoft.com/downloads/details.aspx?FamilyID=7edde11f-bcea-4773-a292-84525f23baf7&DisplayLang=en.
You must be running Windows 2000 Server Service Pack 4 or later. You
must also install MSXML 4.0 or later.

Note that this installs the runtime components only; it does not
install the AzMan administration MMC snap-in. You can still use the MMC
snap-in on a Windows Server 2003 system, or on a Windows XP system that
has the Windows Server 2003 Administration Tools Pack installed, to
remotely administer AzMan on a Windows 2000 Server.

On Windows XP and Windows 2000, you must install the primary interop
assembly for the AzMan COM object into the global assembly cache. This
assembly is already installed in the global assembly cache on Windows
Server 2003 systems.

Finally regards (3) we could use Enterprise Library Security Application Block which implements an AuthorizationProvider based on Azman. I show in this post
how to use it. Using EntLib will abstract us from the store which in
this case is AzMan and this will lead to more flexibility because in
the future we could use another store (SQL Server, ADAM, AD, etc).

The thing I didn’t like about AzMan was that it is bounded to Windows
Tokens. But after some research I found the Custom SID story.

These series of posts talk about how to implement it.

Read this article for an indepth on this post: Combine the Powers of AzMan and WSE 3.0 to Protect Your Web Services from the November 2005 of MSDN Magazine

I couldn’t agree more with this post from Andres Aguiar. The model for databinding in Winforms 2 was greatly enhanced with BindingSource, BindingNavigator and cia. However the intermediaries controls in ASP.Net 2 are not useful at all. I see them only used on very simple scenarios with a very simple
business layer or in a prototypes for the case of SqlDatasource. I’m
sure this is very useful for people doing small applications that like
development ala MS Access drag n drop, but for enterprise scenarios
these controls are a big no. I hope to see some new *DataSource
controls that addresses these issues.

Finally I see an example of how AOP will be so easy in C# 3.0…

Setup secure conversation using WSE 3 was very simple. You just need to
add two attributes to the secure policy assertion
(usernameOverCertificate, mutual, etc).

establishSecurityContext="true" renewExpiredSecurityContext="true"

The
problem was when I wanted to establish the secure conversation, get the
token and use it in further requests. Secure conversation means just
this:

1. Send a first request with a UsernameToken (username/password), BinarySecurityToken (certificate).
2. The service will reply with two messages: the response of the
   original request and a RequestSecurityTokenResponse which will have the
   SecurityContextToken issued
3. Grab the SecurityContextToken
4. Send a second request with a SecurityContextToken (now there is
   no need to send UsernameToken or whatever which means more performance
   and security)

How this four steps are translated into code?

1 and 2.

WseProxy proxy = new WseProxy();proxy.SetClientCredential(new UsernameToken(txtUser.Text, txtPass.Text, PasswordOption.SendPlainText));proxy.SetPolicy(“ClientPolicy”);SomeResponse respone = proxy.DoRequest();

3.

SecureConversationCorrelationState correlationState = proxy.ResponseSoapContext.SessionState.Get();if (correlationState != null){     // Get the SCT for the current conversation
     sct = correlationState.Token as SecurityContextToken;}

4.

WseProxy proxy = new WseProxy();proxy.SetClientCredential(sct);proxy.SetPolicy(“ClientPolicy”);SomeResponse respone = proxy.DoRequest();

The trick is in the step 3 where we are getting the
SecurityContextToken from the session state under the response soap
context. We could store this sct in the ASP.Net Session, or in a static
variable for Winforms and use it for further requests.

I’ve been playing with WSE 3 because I wanted to fully understand how Policy Assertions, SoapFilters and the Pipeline work. My tools were: Reflector and a test harness example consisting of a custom Policy Assertion that creates a SoapFilter that logs to an xml file. Note: I’ve used WSE 3.0.5152 which is the June CTP because I was using VS 2005 Beta 2.

I recommend you reading this post from Mike Taulty so we are all on the same page.

My tests:

1. The normal execution flow
2. What happens when an Exception is being thrown from the webservice?
3. What happens when an Exception is being thrown from a SoapFilter?
4. Short-circuitingon client-output, client-input, service-input and service-output

I’ve created some nice drawings to illustrates what is happening in each case. So here we go…

Here  I decided to go with reflector because the short-circuiting
was not behaving as I expected, so I found the ProcessInputMessage and
ProcessOutputMessage from the Pipeline class.

ProcessOutputMessage

 using (IEnumerator enumerator1 = ((IEnumerator) this.outputFilters.GetEnumerator()))            {                  while (enumerator1.MoveNext())                  {                        SoapFilter filter1 = enumerator1.get_Current();                        SoapFilterResult result1 = filter1.ProcessMessage(envelope);                        if (result1 == null)                        {                              throw new InvalidOperationException(string.Format("SoapFilter of type ‘{0}’ did not return a valid result from ProcessMessage", filter1.GetType().ToString()));                        }                        if (result1.Stop)                        {                              flag1 = false;                              goto Label_014A;                        }                  }            }

ProcessInputMessage

using (IEnumerator enumerator1 = ((IEnumerator) this.inputFilters.GetEnumerator()))            {                  while (enumerator1.MoveNext())                  {                        SoapFilter filter1 = enumerator1.get_Current();                        SoapFilterResult result1 = filter1.ProcessMessage(envelope);                        if (result1 == null)                        {                              throw new InvalidOperationException(string.Format("SoapFilter of type ‘{0}’ did not return a valid result from ProcessMessage", filter1.GetType().ToString()));                        }                        if (result1.TargetMethod != null)                        {                              method1 = result1.TargetMethod;                              goto Label_012A;                        }                  }            }

Note that both methods are using either on the client-side and the service-side. What attracted my attention was that ProcessInputMessage doesn’t analyze the result whether is Continue or Stop.

So I would not be able to do any short circuiting when messages get

into the service or the client. A very common use of this is doing

idempotent where I check the message id and reply with a already

processed message stored in a cache.

Am I missing something here?

Anyway, I will try again when WSE gets out on November.