MS Business Scorecard Accelerator

While installing the MS Business Scorecard Accelerator, I found the following as the pre-reqs:
-- Windows 2003 Server - I have Enterprise version
-- MS SQL Server 2000
-- MS SQL Server 2000 SP3a
-- MS Sharepoint Services
-- MS Analysis Services

After installing MS Sharepoint Services, double check that your website is running as expected. This may become problematic if you already have a website configured for some other application (which happened to me). So I would recommend to do the following:
1. Create a brand new website in a separate directory of your choice.
2. Make that website running on port 80 - Sharepoint services will pick up the site on port 80, you will not have a choice here
3. Test the website with a HelloWorld.asp

So far, it appears, I can play with Windows user account only. My next attempt would be to find out if it works with SQL Sever user accounts.

WSE 3.0 will have it all (hopefully)

I was trying to have some hold around these WS-* stuff by reading here and there. Microsoft seems to be incorporating all these things into WSE 3.0, which is available as beta right now. Somewhere, I saw IBM's WSTK latest version is already having it in public.

Anyway, I was going through Microsoft's plan of releases, and found some striking points to note:
-- Microsoft's WSE 3.0 will be running on .NET Framework 2.0. Which means, for those running on .NET 1.1, you need to remain happy with WSE 2.0 SP3, whatever you get there.
-- You will need Visual Studio.NET 2005 to develop using WSE 3.0. Which means it would not be easy to make it working with your existing .NET application, unless you decide to port it to new development environment.

So, moving forward quite a few tests are to be done before taking any decision. I can think of a few points right away for me:
-- Currently, my application and web service both running on .NET 1.1. If I migrate the web service to .NET 2.0, will I be able to implement WS-Coordination and WS-Transaction in my web service?
-- Even if I can implement that in my web service, will I be able to keep my application in old .NET 1.1 to realize the full benefit?
-- Will I be able to keep my existing components in .NET1.1 while the new components of the same application will be developed on .NET 2.0? If yes, what would be the key points/limitation I should keep in my mind?

I think I need to wait for some more time till I find good answers to all these.

WS-Coordination

WS-Coordination is a new specification prepared by a group of software product manufacturers. The group includes big names like Microsoft, IBM, BEA, and others. The specification attempts to address the situation where relatively large number of participants get engaged in complete a unit of business processing, which may be composed of serveral long-lived activities at different ends.

WS-Coordination does not address how transaction should be completed, but it sets the stage on which transaction specific activities can be conducted.

The model of this specification is based on three simple services:
1. Activation Service - this allows creation of an instance of a coordinator or creation of a context of a coordinator instance
2. Registration Service - this allows the individual applications to register for coordination
3. A set of coordination protocols - this is an extension provision to allow different protocols for different purposes

So, if we try to look into the specific components within a coordinator, we will see an activation service, a registration service, and one or more protocol services based on how many protocols are in use.

Depending upon how disparate are the applications are, there may be multiple coordinators to facilitate the operations between two applications. One additional namespace has been defined: wscoor.

Managing Transactions - Revisited

Last year, I have been putting some thoughts into words while blogging about managing transactions. Those who are enthusiastic, can visit this link of my earlier posts on transactions. I have been primarily limited around managing transactions using a transaction coordinator, or more specifically, an application server like COM+. I also explored of having transaction boundaries spread across components and bridged through synchronous events.

Over the period to time, the requirement of having transactions over HTTP is becoming acute. The primary driver to this requirement is the killing success of web services, and its proliferation beyond the traditional boundaries: political, geographical, or organizational.

I am feeling the heat too. Increasingly, I am trying to grapple up with the issues of data inconsistency across the applications that happened due to partial failure of the processes. While defining the business the requirements, these requirements came up as a single unit of work. However, the underlying steps mandate dealing with multiple applications, one being the base application, and the others are dealt via web services. Consuming web services do not remain limited to consuming data, but many times, it means insert/update/delete into the database of other applications. And, the problem starts from there. I am seeing data updated on the base application, but not on the remote application, and vice versa. The users are scared to death when they see their updates are not getting reflected, the operations people are tearing their hairs to correct data/records, and I am sure all are equally angry to see themselves landing into such a trouble.

WS-Transaction specification has come to address some of these problems and to meet the business requirements the way they are getting defined in today's world. In the subsequent BLOGs, we can speak more about this specification and perhaps will try out some sample codes, if possible.

Ignore Extensions and Ignore URLs

These are the two parameters you would be tempted to set while configuring a SiteMinder policy server. The purpose is simple - "Ignore Extensions" will help you to bypass the authentication for the specified file extensions while the "Ignore URL" will make you to bypass authentication for the specified URL. If you put ASP as a value to the "Ignore Extension" parameter, the SiteMinder will not perform the authentication for any HTTP request for any ASP file sitting on the web server. In some cases, the scope of the server includes mutliple websites residing on the same server. Similarly, if you put a URL of a website into "Ignore URL" parameter, all documents within that website will become accessible over HTTP without any authentication.

Looking into these two parameters, my first impression was that these don't meet my practical requirements. As example, I have a website, which I need to keep fully secured so that all pages can be accessed after authentication through the SiteMinder. The only exception would be the login page, which I have designed and developed for the specific application. It means, I needed to open unauthenticated access to one ASP, one JS, one CSS, and a few GIFs. If I put all these as "Ignore Extensions", it would open the full site, literally.

Fortunately, SiteMinder treats the full URL (including directory and file name) as a URL. So, I could use the parameter "Ignore URL" to put the specific file access URLs to make to unprotected. Later, I moved all these files into one sub-directory called "Login" and replace the earlier URLs with a single one: http://myserver/Login/. As it appears now, the requirement has been met. This has been put into testing now, till then I am keeping my fingures crossed.