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.

Starting Over

Before I start blogging on this page, I would like to link up my earlier scribbles I made elsewhere. If you want to have a glimpse of that please click on BLOG: Arijit Chakraborti

As in my previous BLOGs, I will primarily post technology scribbles, but you may find some not-so-techie jots as well. Intermittently, I will also try to re-post some of my earlier BLOGs here.

IIS 6.0 Web Service Extensions

This is a new thing that I learned today. To give you a background, we have a running suite of applications on Windows2000 and IIS 5.0. Now, there is a move to upgrade the apps to Win03. After installing IIS, we realized the ASP files are not at all running on the web server while the HTML files are fine. Using the good old experience we thought it must be an installation problem, and the IIS got a faulty setup.

Then we realized the new administrative control came with IIS 6.0. It allows you to enable/disable dynamic content. Referring back to my original problem, the extension ASP was set disabled through this control, perhaps it was a default setting, or may be something really goofed up during the installation steps. But for sure, this was not a old-day's installation glitch, which could be resolved only by uninstallation and reinstallation.

IIS Manager for IIS 6.0 provides interfaces for allowing or prohibiting certain extensions related to dynamic content. You are allowed to allow/prohibit all ISAPI and CGI extensions on a server, but it's not a recommended practice to allow all ISAPI/CGI extensions to prevent the machine being suceptible to computer viruses or worms that use these technologies. So, as a good practice, allow only the required extensions.

You will find more information in the following URL http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a9fc0395-f03b-4213-9c62-1592bcfcf53f.mspx

SendOneWay is the answer

The answer to the aynchronous web service calls found in the following URL: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwse/html/wsemessaging.asp

WSE2.0 has the implementation called SendOneWay that can be used for such purpose. Would like to go thru' more details about it.

Asynchronous Event Subscription

Getting into an interesting problem domain, where I think asynchronous event subscription could work as an answer given the architecture is based on SOA. Of course, there could be many possible ways and some would be better than this one.

The problem description can go like this:
-- Application creates/updates/deletes a specific entity. There are many units of such entity in the application.
-- Each entity is identified with a unique identifier and some specific attributes.
-- There are more than one subsidiary applications that would like to subscribe the changes happened on the units of this entity.
-- Not all subsidiary application are interested in all units undergone changes. Rather most of them would like subscribe a subset based on the specific attribute settings.

One possible solution could work like this:
-- Each unit change will publish an event
-- The event will be subsribed by the applications asynchronously.
-- All events will be subscribed by the subsidiary applications.
-- Individual applications will only do followup work if their specific attribute criteria get satisfied, i.e. if the application is interested in that particular activity.

Will do a few more work to find out what's inside.