Tuesday, February 08, 2005
« Can a Service have Tiers? | Main | patternshare.org is online!! »

I just finished watching Eric Rudder’s keynote on Indigo at VS Live in San Francisco. As with all keynotes, it had glitz and glamour and gave a high-level view of what Microsoft is thinking.

 

(for those who don’t know, Eric is the Microsoft VP in charge of developer-related stuff including Indigo)

 

Among the various things discussed was the migration roadmap from today’s communication technologies to Indigo. I thought it was instructive.

 

From asmx web services the proposed changes are minor. Just a couple lines of code change and away you go. Very nice.

 

From WSE to Indigo is harder, since you end up removing lots of WSE code and replacing it with an attribute or two. The end result is nice because your code is much shorter, but it is more work to migrate.

 

From Enterprise Services (COM+, ServicedComponent) the changes are minor – just a couple lines of changed code. But the semantic differences are substantial because you can now mark methods as transactional rather than the whole class. Very nice!

 

From System.Messaging (MSMQ) to Indigo the changes are comparable in scope to the WSE change. You remove lots of code and replace it with an attribute or two. Again the results are very nice because you save lots of code, but the migration involves some work.

 

From .NET Remoting to Indigo the changes are comparable to the asmx migration. Only a couple lines of code need to change and away you go. This does assume you listened to advice from people like Ingo Rammer, Richard Turner and myself and avoided creating custom sinks, custom formatters or custom channels. If you ignored all this good advice then you’ll get what you deserve I guess :-)

 

As Eric pointed out however, Indigo is designed for the loosely coupled web service/SOA mindset, not necessarily for the more tightly coupled n-tier client/server mindset. He suggested that many users of Remoting may not migrate to Indigo – directly implying that Remoting may remain the better n-tier client/server technology.

 

I doubt he is right. Regardless of what Indigo is designed for, it is clear to me that it offers substantial benefits to the n-tier client/server world. These benefits include security, reliable messaging, simplified 2-phase transactions and so forth. The fact that Indigo can be used for n-tier client/server even if it is a bit awkward or not really its target usage won’t stop people. And from today’s keynote I must say that it looks totally realistic to (mis)use Indigo for n-tier client/server work.

Tuesday, February 08, 2005 12:45:28 PM (Central Standard Time, UTC-06:00)
Rocky,

Thanks for setting the perspective right from a development/architecture point of view. What are the chances we could get a similar viewpoint from a deployment point of view?

i.e. Enterprise Services/MTS packages etc. were a pain to administer/deploy. Remoting is much easier, web services are even easier. .. That kinda comparison. :)

Thanks,

- Sahil
Tuesday, February 08, 2005 1:31:32 PM (Central Standard Time, UTC-06:00)
Well, they didn't actually show any deployment of anything anywhere :) My speculation is that they've been focusing on the development stories, and haven't really gotten around to the deployment stories - at least for public discussion.
Tuesday, February 08, 2005 6:29:53 PM (Central Standard Time, UTC-06:00)
Hey Rocky,

What about looking at things from a slightly different perspective? It is clear we are never going to fully get past this debate.

Today, ES/Remoting/asmx are really about solving deployment problems. Sure, you can create a wide-reaching platform agnostic service using asmx, but unless you have a solid understanding of your service boundaries and what is really happening under the covers when you create your service interface, it still is very easy to create a tightly-coupled service using asmx. Unless you make proper use of xsd:any and lean towards the open content model using XML, you end up with a type system that is just as fragile as those used in the other mentioned technologies. Instead of being tightly bound to a single platform, we are now tightly bound on many platforms. :) - Not good.

Moving forward, I do not think it is really going to matter if people use remoting or Indigo. The performance comparisions will most likely be neglibile. The real challenge remains the same - creating truely loosely coupled services in a true SOA environment is still going to be hard and will be the biggest challenge. Unless people get a grasp on this and really understand what it means, we will be seeing systems as fragile and ill-performant as ever. I agree with your concerns that people are going to think that just because they are building services using asmx or Indigo, they will by definition be service-oriented. The problem goes a bit deeper than that.

So again, focusing on the coupling aspect to decide where and when and how you should create your service seems like a better approach to me rahter that getting hung up on your comminication choice.



jk
Jim Kieley
Tuesday, February 08, 2005 11:40:22 PM (Central Standard Time, UTC-06:00)
Thanks Rocky. I am anxious to see the Indigo CTP next month or so. :)

I'll keep my eyes glued to your blog for anything good you may learn and share.
Wednesday, February 09, 2005 9:56:54 AM (Central Standard Time, UTC-06:00)
Jim, I think you are totally right - the communication protocol is far less important than the architecture/design requirements and differences between the SO and n-tier models.

However, having just built a CSLA-style DataPortal using asmx technology I can tell you that it takes quite a bit of code to pull it off. In my case that is fine, because the communication is totally encapsulated inside the DataPortal, but as someone pointed out, most people aren't that good at encapsulating this type of functionalty.

Without encapsulation of the communication code, the choice of protocol becomes important. What can be done for an n-tier model in 1 line of code with remoting takes 10 in web services. Conversely, in an SO model, what takes 1 line of code in web services may very well take 10 lines of code in remoting (if it possible at all).

So while I agree that the focus should be on the architecture/design choices, the fact remains that at some point everyone does need to pick a technology for implementation and some are better for n-tier and others are better for SO. Indigo is trying to be good for both, and so we must all be diligent in watching Indigo to see how it will impact our current n-tier or SO choices going forward.
Monday, December 12, 2005 9:53:02 AM (Central Standard Time, UTC-06:00)
Hi Rock

i have seen your information very useful, but i could see a deviation
after that announcement by this blog posting can you comment on the same?

http://blogs.msdn.com/richardt/archive/2004/03/05/84771.aspx

Regards
Rajaraman
Rajaraman
Comments are closed.