Indigo application concerns

I recently read Yasser Shohoud's article about creating Indigo applications using the PDC Whidbey bits, and it has me a little worried. I missed the PDC, and this article was really my first look at the details of writing code against Indigo.

In particular, I'm worried about the Service Framework (SFx)-level client APIs. One of the beauties of the ASMX/Web Reference model in .NET 1.x was its simplicity - especially for clients. At first look, the SFx programming model isn't nearly as Mort-friendly as the Web Reference model. For example, we've gone from this:

HelloService service = new HelloService();

Console.WriteLine(service.Greeting("Indigo client"));

to this (using Yasser's example):

ServiceEnvironment se = ServiceEnvironment.Load();
ServiceManager sm =
   se[typeof(ServiceManager)] as ServiceManager;
se.Open();
Uri uri = new Uri("soap.tcp://localhost:46001/HelloService/");
IHelloChannel channel = (IHelloChannel)sm.CreateChannel(
   typeof(IHelloChannel), uri);

Console.WriteLine(channel.Greeting("Indigo client"));
Console.WriteLine("Press enter to exit");
Console.ReadLine();
se.Close();

This is not what I would consider a very Mort-ly API. In fact, I'm worried that many of my company's customers would run screaming if they saw that bit of sample code. These are not dumb people - they're just trying to build applications that solve business problems, not necessarily build infinitely scalable multi-stage web service pipelines. Many of these people are coming from the VB6 environment, which was (and probably still is) the primary development environment for internal corporate Windows applications for many years. Heck, a lot of these people are still trying to get their heads around inheritance, and interface based programming was hidden well enough by VB6 that even though they could do it, they mostly didn't.

I agree that ASMX hides too much both the server and client. There are times that I very much miss the fact that I don't have access to the underlying XML. But looking at that sample makes me think that maybe Indigo has gone too far the other way. If it's too complex, the average corporate developer won't embrace it. Imaging how COM would have fared if VB6 hadn't spared the average corporate developer from the complexity of IDL, proxy/stubs, event sinks, etc.

As I said, my expose to Indigo is minimal thus far, so perhaps I just don't understand the model well enough (I'm still fuzzy on the scope of ServiceEnvironments, for example).  Or perhaps VS.NEXT will hide some of that complexity in the next incarnation of the Web Reference. But right now I'm left wishing for a little more country, a little less rock and roll.

 

8 Comments

  • This is in fact a developer preview. The PDC build was based on M4 of Indigo and the programing model (especially for the Service Model) currently get revamped for M5 - as the guys sais a trillion times at PDC, in articles and in interviews :-)

    So I would not worry too much at this point in time. Expect it to become a lot more 'convinient' ... but it definitey will differ from the ASMX model which is good, IMHO.

  • Indigo offers two general programming models, targeting very different levels of control.



    The Service Model is the one you are looking for, it works much the same way that ASMX works today.



    The Indigo Connector model is the more complex and low level messaging model. This is where you will manually create channels and configure all the low level details.



    I will suspect that once beta 1 is out there will be a lot more focus on the Service Model.

  • You're sort of mixing apples and oranges here.



    The fact that in v1 you can new up an object and invoke a remote operation transparently without knowledge of the messaging details is a by-product of three things: 1) the wsdl.exe utility, 2) the tight integration wsdl.exe has with VS.NET, and 3) some important BCL blobs living in System.Web.Services.Protocols. Your client proxy is auto-magically generated based on a WSDL contract that you feed in, allowing you - the consumer - to point, click, and fire SOAP messages as though they were local method invocations.



    Whether this model is good or bad, well... that's still yet to be determined. I've heard a lot of arguments for the latter, and I tend to agree.



    So, with Indigo you get a choice. You can take the red pill and control the messaging at a very low level (similar to the way in which WSE works today), tasking you with the orchestration of channels, ports, and messages; or, you can take the blue pill and allow Indigo to hop into the driver's seat (enabling such things as point-click-fire messaging), in which case you would deal mostly with the service model.



    Both routes offer up a variety of messaging models like sync, async, pub/sub, but still live together within the same stack. It's clear that the surace area of the blue pill choice is smaller, and thus easier for the average programmer; but, that model isn't right for everyone.

  • Joe (and Morten),

    Actually, I think I'm comparing apples to apples here. The sample I included is the Service Framework (SFx) sample from Yasser's article (the high-level framework), not the lower-level MFx version. It's fantastic that Indigo gives you access to the low-level stuff - I'm not debating that. My point is that the high-level stuff isn't high-level enough. At the moment, the blue pill is looking a bit on the purple side. :)



    Perhaps, as Christian says, this is simply because Indigo isn't fully baked yet. But since I don't have access to anything beyond PDC bits, I'm limited to commenting on what I got. MS keeps saying "gives us your feedback" on their pre-release stuff, so I'm happy to oblige. ;)



  • I kind of lacked a point to my last post.



    I buy the half-baked theory. Perhaps leaving the purple pill in the oven longer somehow strengthens the blue pigmentation... who knows. ;)



    Now my point: wsdl.exe is what makes it so easy right now. I guess my [unstated] assumption is that tools will be layered on top of all of these crazy Indigo-isms once the foundation is stable enough to do so. At which point, the blue pill comes out of the oven, ready for some good ole' fashioned pill popping. X, eat your heart out.

  • I hope you're right that the higher-level tools will improve as Indigo bakes. The article mentions the WSDLGEN tool, which presumably is the Indigo equivalent of WSDL.EXE. From the look of it, currently it only spits out an interface definition, which is then used in conjunction with the ServiceManager to communicate with the service. I'm hoping that the next increment of WSDLGEN (or another tool) will add an additional layer of insulation between the client and the ServiceEnvironment/ServiceManager/Channel goop.



    Unfortunately, MS isn't talking yet about the final(er) programming model. I'm hoping we don't have to wait for B1 to hear more details, because by then I'm guessing things will be pretty much set in stone.

  • It is very intereting to read your comments. here are my Comments:



    (1) MS should develop a better template to abstract concept and let Developer write less code. I think code generate in Long Horn Whidbey tool is not that informative. eg. what does Service.Close() means ? In fact, I moved all code into a window Form and seperate out Close behind a button. But each every time the WinForm Close itself after client get out.



    (2) I think Don Box alread made up his mind to made everything explicit. ie. no more "new HelloService()". From my field experience, using "new" is actually more confusing since we have to touch configure file for Remoting or WS Proxy file for tweeking. Wouldn't that be wonderful if we can write just code to made everything work ?

  • If you take a look at the PDC SLIDES instead of the PDC BITS, you'll find traces of the much more refined M5 model. M4 (PDC bits) is frustrating for everyone ;)

Comments have been disabled for this content.