Preparing for Indigo—Choosing the Right Technology Today : Page 4

Indigo Migration
With such benefits and advantages, you should strive to move to Indigo sooner rather than later, or at the very least, prepare your application for Indigo as best you can today to ease the transition and mitigate the cost. Whenever you adopt a new technology, there are two elements to the cost—syntactical changes and semantic changes. Syntactical changes are usually easy, trivial, and low in cost and effort. For example, imagine converting a C# code base to VB .NET or a C code base to Pascal. Syntactical changes are simply the act of translation or the mapping of similar concepts and constructs from one technology to another.

What is truly impressive about Enterprise Services is the set of services it offers.

Semantic changes, on the other hand, are usually very difficult and can be horrendously expensive. For example, consider the cost involved in changing an event-driven application to an application that is not event-driven. Even if you maintain the implementation language such as C#, the cost of such a change is far from trivial. For another example, consider changing a single-threaded application to a multi-threaded application, or a transacted application to non-transacted. The reason semantic changes are so expensive is because they are actually changes to the application programming model. Changes to the programming model amount to design changes after the application is already developed. Any veteran developer can attest that such changes are probably as expensive as changes can get, often costing hundreds more in time and effort than what it would have taken to implement the design differently in the first place.

Migrating to Indigo is no different, and you will have to pay for both syntactical and semantic changes. To minimize the cost, you should choose a programming model that is most compatible with the Indigo programming model, because the semantic changes are where the cost will be.

As it turns out, the Indigo programming model resembles the Enterprise Services model. Both technologies use attributes to declaratively apply connectivity services and the component or service code itself can be free of plumbing, and dedicated to the business logic at hand.

For example, consider a transactional component. Without Enterprise Services, you are responsible for enlisting the resources, propagating the transaction to other components and resources, deciding on the outcome of the transaction, and instructing the resources to commit or abort the changes performed. This pollutes the code with the transaction management and coordination logic. When using Enterprise Services to manage the transaction, here is the required code:

   using System.EnterpriseServices
   public interface IMyService 
   {   
      void MyMethod();
   }
   
   [Transaction]
   public MyService : ServicedComponent,IMyService
   {
      [AutoComplete] 
      void MyMethod()
      {...}
   }

The code inside MyMethod() is dedicated to the business logic implementation, without any shred of transaction management.

Here is the equivalent code using Indigo (pre-Beta 1):

   [ServiceContract] 
   interface IMyService 
   {   
    [ServiceOperation(TransactionFlowAllowed = true)]
    [ServiceOperationSettings(
       TransactionRequired = true,
       AutoComplete = true)]
   void MyMethod();
   }
   class MyService : IMyService
   {
   void MyMethod()
      {..}
   }

Due to NDA restrictions, the Indigo code snippet is only pseudo code, yet the actual namespaces, attributes, properties names, and values are irrelevant—the important thing is the programming model—the code inside the method is free of any transaction-management plumbing. Now consider the two pre-Indigo implementations and what it would take to port them to Indigo. If you were using Enterprise Services, the changes would be syntactical-change the Enterprise Services namespace and attributes to the Indigo ones, removed the derivation from ServicedComponent, and you are done. If you were managing the transaction yourself, you are now facing the delicate task of surgically removing that code from the business logic code, then applying the Indigo services on top. That is, of course, an expensive semantic change.

The Indigo programming model resembles that of Enterprise Services the most

Almost all of the Indigo services can be mapped in a similar manner to Enterprise Services: from security, to disconnected asynchronous calls, to loosely-coupled events, object activation, hosting, and so on. Table 1 summarizes the various plumbing aspects you will encounter when migrating an existing application to Indigo and the expected changes, with and without Enterprise Services.

Table 1: Considerations when planning a migration to Indigo, with and without Enterprise Services.

Aspect	Without Enterprise Services	With Enterprise Services (ES)
Security	Remove custom mechanism	Change ES attributes to Indigo attributes
Transactions	Remove custom mechanism	Change ES attributes to Indigo attributes
Asynchronous, disconnected calls	Remove custom mechanism	Change ES attributes to Indigo attributes
Reliable messaging	Remove custom mechanism	Change ES attributes to Indigo attributes
Publish/subscribe event management	Remove custom mechanism	Change ES loosely-coupled event class to Indigo attributes
Concurrency management	Remove custom mechanism	Change ES attributes to Indigo attributes
Remote calls and service Host	Remove custom host	Change ES host to Indigo host
Instance management	Remove custom mechanism	Change ES attributes to Indigo attributes
Administrative tools	Remove custom tools integration	Start using Indigo tools

The conclusion is clear; when anticipating Indigo, if you want to minimize changes and the cost of changes to your code today, you should use .NET Enterprise Services inside your service, and wrap the service with a Web service if you require boundary crossing.

Previous Page