Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

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

Today .NET offers three distinct technologies for application connectivity: Web services, remoting, and Enterprise Services. Each offers something that the other does not: interoperability, extensibility, and productivity. In preparing for Indigo, you need to choose today a technology that best approximates its programming model, most likely Enterprise Services.


advertisement
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.



Juval Lowy is a software architect and the principal of IDesign, Inc., a consulting and training company focused on .NET architecture consulting and advanced .NET training. His latest book is 'Programming .NET Components, 2nd Edition' (O'Reilly, 2005). Juval is a frequent presenter at development conferences and Microsoft's Regional Director for the Silicon Valley. Over the last two years Juval has been part of the Indigo Strategic Design Review process. Microsoft recognized Juval as a Software Legend as one of the world's top .NET experts and industry leaders. Contact him at www.idesign.net
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap