The first public drop of Service Factory is available on the workspace.

Download it and give feedback on the message boards! If you want to
keep updated with this project, here you have a list of Service Factory
bloggers:

I will post more about this exciting project in the next weeks.

Don Smith announced today that Service BAT Service Factory is finally a public project. I’ve been part of this project since the beginning of the year and I can tell you that I’m pretty excited about it. Jason Hogg said that this were going to change the way we develop SO applications.

This is a great moment for people writing Service Oriented apps using Microsoft technologies!

First, if you are not aware of patterns & practices latest
activities, let me tell you that they’ve been creating BATs, Baseline
Architecture Toolkits, which are more than App Blocks. They cover the
whole thing! The first one was the SC-BAT (for Smart Client apps using CAB) which was more than successful. So here is the definition:

 What is a BAT? A BAT is a collection of various forms of guidance (written
guidance like patterns, reusable code like application blocks,
executable code like reference implementations, and guidance packages
embedded in Visual Studio) to help .NET developers and architects build
a certain kind of application.

What is the scope of Service BAT Service Factory? In short, from the proxy to the database.

Join this project if you want to

  • Write Service Oriented apps using WCF or ASMX
  • Leverage the best practices and the experience of a 50 recognized experts in the
    field (the advisor board) and a group of Redmond brainees
  • Automate the menial tasks of creating a Service by leveraging the use of GAT
  • If you were looking for the Grail on writing backends for Enterprise Applications :)
  • Solve most of the cross-cutting concerns (Exception Shielding, Logging, Versioning, Security, Data Entitlement, and more)
  • Align to WCF
  • Have great tooling for WCF

See you there!

UPDATE: want to see some early screenshots? look at Edward Bakker post. Christian Weyer also blogged about it.

UPDATE 2: Service BAT was rebranded. Now it’s Web Service Software Factory.

Blog moved

September 10th, 2005

My Blog has been moved… This is the new url: http://blogs.southworks.net/blogs/matiaswoloski

MBI 3 Identity Matrix

March 19th, 2005

How useful is the ASP.Net identity matrix? I’ve queried it a lot…


I created the same matrix for MBI 3.


The scenario is a client calling MBI 3 through DispDirect which uses the WebService transport. IIS configurations below apply to the FwkWebServiceTransport virtual directory. The variable means:



  • Command = cmd.User.Login
  • Thread = System.Threading.Thread.CurrentPrincipal.Name
  • WindowsIdentity = System.Principal.WindowsIdentity.GetCurrent().Name

These variables are queried in an MBI business action.

Note: whenever the Anonymous is checked, it will override any other checkbox (integrated, digest, etc.)
Note 2: NT AUTHORITY\NETWORK SERVICE is the user that runs the ASP.Net worker process in Windows 2003. For older versions is the MACHINE\ASPNET user.
















































































































































IIS anonymous
Principal sent via Dispatcher Variable Identity resutlant
WindowsPrincipal Command “”
  Thread “”
  WindowsIdentity NT AUTHORITY\NETWORK SERVICE
GenericPrincipal Command User provided in GenericIdentity
  Thread User provided in GenericIdentity
  WindowsIdentity NT AUTHORITY\NETWORK SERVICE
Nothing Command “”
  Thread “”
  WindowsIdentity NT AUTHORITY\NETWORK SERVICE
IIS integrated windows
Principal sent via Dispatcher Variable Identity resutlant
WindowsPrincipal Command Domain\UserName
  Thread Domain\UserName
  WindowsIdentity NT AUTHORITY\NETWORK SERVICE
GenericPrincipal Command User provided in GenericIdentity
  Thread User provided in GenericIdentity
  WindowsIdentity NT AUTHORITY\NETWORK SERVICE
Nothing Command “”
  Thread “”
  WindowsIdentity NT AUTHORITY\NETWORK SERVICE
IIS integrated and web.config with
Principal sent via Dispatcher Variable Identity resutlant
WindowsPrincipal Command Domain\UserName
  Thread Domain\UserName
  WindowsIdentity Domain\UserName
GenericPrincipal Command User provided in GenericIdentity
  Thread User provided in GenericIdentity
  WindowsIdentity Domain\UserName
Nothing Command “”
  Thread “”
  WindowsIdentity Domain\UserName

Recently, I had to get deep on AzMan for a project. This tool helps you to manage operation and roles for a custom application. It runs on Windows 2000, Windows 2003 and Windows XP which developers generally use. Just install the Windows Server 2003 Administration Tools Pack and you’ll get an MMC snap in like this

azman

In a nutshell, AzMan allows you define Roles, Tasks and Operations. Operation is the atomic unit of AzMan. In terms of EDRA or MBI an operation will map to a Business Action. This way we can group operations in a task. For example, the system actions in MBI could be grouped all together in a task System Actions, and then we can define a role that has access to that task.

Task could nest task or operations and roles could nest roles, task and operations. This gives you a lot of flexibility to manage authorization for your app.

Now, the issue is how we can integrate this beatiful UI with our services. AzMan has a COM api available via Interop to .Net, that exposes the whole functionality. We are intereseted in one method specially which is the AccessCheck. This method will check authorization of a user against an operation

result = context.AccessCheck( "operation" )

In terms of EDRA or MBI, we need to grant or revoke access to services or actions. We have the concept of pipelines and filters (handlers) which give us lot of flexibilty and extensibility. What we should do is create a handler and put it in the interface pipeline (in MBI there is a single action pipeline, so we should replace the common Authorization handler with this one). The handler will do the AccessCheck and it will throw an exception wheter the user has access or not to execute a given service action.

The type of the EDRA handler will be an Atomic one, because we just need to intercept on the request in the interface, cutting any bad request from the ground. Here is the code for the Execute method of the handler (the MBI version)

public void Execute(IContext context)
{
    Command cmd = ContextHelper.GetCommand( context );
    bool authorize = true;
    IAzApplication azApp = null;
    IAzClientContext azContext = null;

    foreach( string excludedAction in _config.ExcludedActions )
    {
        if ( excludedAction == cmd.Action )
            return;
    }

    string userName = Thread.CurrentPrincipal.Identity.Name;
    // check user exists for the application
    try
    {
         azContext = GetClientContextFromName( userName, _config.ApplicationName, out azApp );
    }
    catch
    {
        authorize = false;
    }

    // now check roles
    if ( authorize )
    {
        // check user is authorized to execute the action
        authorize = AzManHelper.CheckAccess( cmd.Action, userName, azContext, azApp );
    }

    if( !authorize )
    {
        throw new TechException( Resource.ResourceManager[ Resource.MessageKey.NotAuthorized, cmd.Action, userName ] );
    }
}

For an EDRA version you should change cmd.Action for context.ServiceActionName and throw a BusinessRuleException instead of a TechException.

I wrote an AzManHelper which helped abstract and encapsulate the AzMan api. I think the code is straightforward in terms of simplicity. We are doing this:

  1. IF the action being executed is excluded from configuration, just return to the pipeline. This is for actions that we want to bypass the access check.
  2. Get the username from the current principal
  3. Get the client context of AzMan for a given user and a given application (the application is the same that you created in the AzMan UI). If there was any problem getting the context set the flag to false
  4. If the context was obtained, try the AccessCheck for the executing action, username and context
  5. If it couldn’t be authorized throw an exception

You can find the full source code for the handler: AzManHandler.zip (6.77 KB)

Thanks to Federico Winkel who helped a lot on this.

Great week! (Chile)

January 7th, 2005

This week I did an architecture review together with German Marin, from Microsoft Consulting Services Chile for an MS partner, Novared, who is willing to implement a large application including Biztalk in the Middleware to conceive a unique customer database. Novared wanted to make the decision whether to use or not MBI 3 as the business framework in cooperation with Biztalk.


Happily, after one week implementing a proof of concept they decided that MBI will be the framework they will use from now on for their applications. Indeed, they realized that using it, will lead to:



  • shorter development time;
  • better support; 
  • improvement on the development team workload distribution;
  • enhaced quality on the solution;
  • opportunity to create a base framework and have isolated development teams that implement the business actions
  • and some other benefits.

The proof of concept included among other things:



  • Single and Batch actions;
  • Command Pattern & Service Oriented approach; 
  • Request-Response sync communication with Biztalk 2004 orchestations;
  • Business Event publishing using Output Providers;
  • use of the MSMQ transport to inject data to Biztalk; 
  • discussion of BAM (Business Activity Monitoring) in conjuction with MBI;
  • Authorization Manager (AzMan) integration within MBI;
  • Extensibility and Flexibility of the pipe & filters pattern;    

I’m leaving Chile with a lot of ideas spinning on my head. Specially regards EDRA / MBI 3 / Biztalk Server 2004 integration. I splashed the first ideas on under: EDRABiztalkIntegration