October 28, 2003
@ 07:55 PM

The typical PDC attendee is very special. PDC is not like TechEd where you get very practical information on today’s shipping products. PDC is about futures and it requires a lot of imagination of how applications could look and could work on the new platform. It’s about building excitement for the things to come. PDC attendees are the folks who will make the first wave of applications happen. They are excited about technology and they love to code.

Don Box’ talk yesterday afternoon (WSV201) was very much about now. I heard a few people complain that he didn’t show enough new code. I don’t think he should have. I found his talk very important and Don delivered his message very well. Don’s talk was very much about architecture. No matter how much you want to see code, it’s not the 1990’s anymore. Simply hacking up an app won’t let you play in a connected application ecosystem that’s powered by Web services. WinFX will enable better applications by simplifying coding complex applications in a big way and making developers more productive. You’ll code less. Code isn’t all that matters. Architecture matters. Negotiation and contracts matter. Design matters.

There were four key takeaways from his talk: Boundaries between applications are explicit. Indigo’s programming model is different from previous distributed programming models such as COM and Remoting, because it doesn’t make objects implicitly remote. You need to declare things as being remote. The fact that you’re theoretically able to write a local application and can then write a configuration script that distributes this application across multiple machines using Remoting was a naïve approach. Likewise, writing a COM application that’s built as a local application and reconfiguring it to run as a distributed application using a different registry setup is a naïve approach. With Indigo, you will need to start writing applications explicitly as being remote. If you love objects, you will find a few things very restricting in this world, and at first sight. There are no automatically marshaled callbacks, interfaces and objects. There are messages, not object references going across the wire. The endpoints of communication, called services, aren’t fragments of the same application based on the same types and classes. Services are autonomous units which adhere to compatible data contracts and policy, not dependent units that use identical implementations. We share schema, not type.

Don recommended, as I’ve done earlier here on the blog, one of the most important Indigo talks for anyone who’s building software on today’s platform (that means: everyone at PDC): WSV203, “Indigo”: Connected Application Technology Roadmap; Wednesday, 11:30am, 409AB.  Go.

Wednesday, October 29, 2003 1:22:01 PM UTC
Hurrah for your point about the importance of architecture regardless of code. I agree that Don's was a fine talk about the philosophy of service oriented architecture, but remember that's not for everybody. A lot of people work only inside the service boundary, building smaller structures within the grand design, and for them the talk offered little. By contrast, those of us who work across the service boundary have probably come across a great deal of this stuff already.

Nevertheless, for me, this was a bravura performance, a great articulation of the whys and wherefores. I just wanted to highlight to people considering going to the repeat what to expect and what not to expect.
Wednesday, November 05, 2003 2:27:03 AM UTC
Could you please eloborate on why that "Remoting was a naïve approach"? I am looking at architecting a solution that uses remoting to connect an application server running business logic to presentation layers of ASP.NET and Windows Forms. It seems to me when you have .NET on both ends of the wire that remoting gives you a richer environment than Web Services.

Thanks,
Kerry Jenkins
Kerry Jenkins
Friday, November 07, 2003 11:36:08 AM UTC
Two comments:

"Services are autonomous units which adhere to compatible data contracts and policy", actually, I think that this is legacy from remoting (and if you don't break this rule you are actually doing not much more than remoting).

SOA is about consumer oriented message exchanges, not about producers defined contracts. I could even argue than in a SOA the equivalent of an API is a conversation (where message formats could still be decoupled by the glue in between).

Kerry: .NET remoting is not necessarily bad. Ingo Rammer have published a matrix about when you should and should not use .NET remoting, this is a very useful document to look at.

WSE 2.0 seem to offer a lot, it is now also the official direction of Indigo !

JJ-
Comments are closed.