What is this Agile Programming

Everybody talks about it. Everybody thinks this is going to be the next process mantra. The clients ask about it. Some even demand it.

But what is this all about? Better coding? Better implementation? Something that would make life easy?

God knows, of course. And known by some geeks. Did you ask for a design document? Sorry, it's agile programming, no design will be documented. Did you ask to demo the application? Yes indeed, see these buttons here, and links there. Nothing is functional, but that's what agile programming is. Are you worried about costs? Who cares, this is about agile programming, not cost control anyway.

What the **** this agile programming is? This was my first reaction to the answers quite some time back, when I encountered about Agile Programming. Over the period of time, I learned some by reading writings by different self-proclaimed agile gurus, and while visualizing my own projects from those perspectives. The best definition obviously came from Wikipedia: Agile software development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life-cycle of the project.

And then, Wiki says there are many methods in the name of Agile Programming. In the next a few blogs I will try to describe my understanding of agile programming, and where it fits well and how much better it actually is comparing to its tall claims.

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.