CTS200: Service Orientation and the Developer

  • Article

Don Box and Doug Purdy kicked off the Connected Systems track with a typically off-the wall, outspoken thesis of development. Although this session was nominally described as a technology overview, it would better have been described as a philosophy, but I'm not convinced that the TechEd level definitions stretch that far… (NB For the avoidance of doubt, these are my notes from the session, rather than my own views. Treat me as your friendly reporter on the ground as far as this goes!)

The central concept of the session was the following: "There is only one program and it is still being written" . Everything you work on is part of one fundamental program - you provide functionality to other pieces of that program. The idea of a closed system is effectively dead, so our development practices need to take account of this change. Service Orientation brings tremendous value to the distributed space.

With many previous technologies, applications were trying to link things together but were very homogeneous - they didn't truly accept the premise that applications span systems. The premise of Java was that you can change everything, but nobody has this much control over "the program". You can only change your own neighbourhood to a limited extent - the program itself is very hard to change.

WS-*, ASMX, Indigo all provide mechanisms and facilities to support distributed application development where everything is interconnected. Life changes when you accept this premise. The primary evidence for this is the loader - we have the ability to add code to the program as it runs. We have no ability to reboot it - we can take parts offline and replace them, but the aggregate computation is never going to stop.

Don described his four tenets of development. I'm not going to recapitulate them here beyond the headings, however, since they are a repeat of WSV201 from the PDC:

  • Boundaries are Explicit
  • Services are Autonomous
  • Share Schema, Not Class
  • Policy-based Compatibility

The number one thing you try to nail down in many systems is a shared understanding of semantics, but that's very hard to do. Many object orientated systems have failed because of an inability to truly share such an understanding. Service orientation acknowledges that objective interpretation is an oxymoron. Code generators based on schemas are lying to you - and indeed there are many schemas that can be generated from a single XML instance document. Service orientation is about enabling compatibility across multiple interpretations, but this is a broad departure from object orientation. However, it's still vital to have agreement on concepts such as privacy. With XML schemas (XSD), we tried to conflate the notion of a grammar for structural description from a nominal typing system for such comments - and we failed. Service orientation gives us a means of achieving agreement on interpretation outside of the underlying grammar. (In the COM world, the concept of marker interfaces was analogous.)

The protocols therefore become the integration substrate. We're never going to get everyone to agree on something like the CLR, but we can get some agreement on how different services written on different platforms can communicate.

How much COM does "The Program" need? There are many pieces of the program that will be written in unmanaged code in the future - it will take decades to get all code converted to managed code. As long as there is unmanaged code, we will need COM. With .NET v1, we took a stab at making COM a good citizen in the service orientated world. COM+ 1.5 has a facility to expose components as web services. Going forward, we are taking our Indigo investments and making sure that there is first-class access from unmanaged code. VBA needs to be able to talk over Indigo to web services, for example. Remoting is an OO technology that makes many presumptions about the environment. For that reason it will probably not be part of the "spine" moving forward. However, DCOM has its strengths: it's fast and secure. Enterprise Services is the best (although not the only way) to take advantage of this and is a good solution.

The fewer WS-* protocol standards we have, the more useful they will be. If the standards get out of control, it will reduce interoperability because the chances of two services sharing the same protocol reduce.