TSS Interop Blog: Contract-First or Code-First Design - Part 5

Discussions

News: TSS Interop Blog: Contract-First or Code-First Design - Part 5

  1. This is the fifth and final of a multi-part series on Web services, in which Ted Neward asserts: "You cannot try to force XML into a "type system" through XSD!" A snippet:
    Adrian: I think it's fair to state that it's the exception, rather than the rule, for an organization to use just one language, right? Far more often, many organizations will require a blend a number of different languages, for a lot of different and valid reasons. Some languages (e.g. C#, Java) provide good support for code-first approaches; while others (e.g. C++) do not. It seems inappropriate to place interface specification (and consequently, implementation) in the hands of just one part of the organization (those that use a preferred language). Also, it impairs your ability to redeploy new implementations of services in different languages later on: the new language may generate a different interface contract. Ted: Well, I could take that argument and run with it further, suggesting that it's unfair to place interface specification in the hands of somebody speaking a language (e.g. XML) that doesn't cleanly map to any of the implementation languages, and that you're basically just exacerbating the problem further, not simplifying anything. And while I might challenge the idea that C++ isn't a good language for doing code-first approaches, I won't, since that's not something I have particular facts on at the moment. ... Frankly, I think if you’re serious about trying to separate implementation from interface, then you have to consider the idea that XML is just a data representation, and not a type system of its own, and that therefore you cannot try to force XML into a “type system” through XSD. And I think the argument about interface and implementation being separated from one another is a red herring–I’ve rarely run into situations where we wanted to have distinctly different implementations to the same interface in a distributed scenario. When dealing with CORBA and RMI and .NET Remoting, that was necessary to facilitate the compiler’s type-checking of the arguments passed in to the remote call, but now we’re in a different space, where we don’t want the tight coupling that the old CORBA/DCOM/RMI-based approaches brought us. If we’re serious about trying to build services that will stand the test of time, we need to take a step away from the old model of object RPC, and go back to the world’s original loosely-coupled technology, that of message-passing.
    Contract-First or Code-First Design - Part 5
  2. Well, the beer was not so good since they last up to part 5 (where are the others ?). Anyway, it seems that they didn't miss the chance to spread some FUD. Why do CORBA/DCOM/RMI bring tight coupling ? Maybe is not the technology by itself, maybe is the bad use of the technology. Is message passing the solution for dumb design/implementation ? Guido.
  3. When a program makes an RMI style call, it generally knows what it is calling -- as there is some kind of interface or specification to adhere to. That isn't quite "tight coupling", but it does imply some level of coupling as the client must know the methods the service offers. If a client needs to invoke 10 services under certain conditions, it may need to make 10 calls (or you could make another service to abstract those calls, and so on, you get the idea). In a messaging system, this does not need to be the case. The client might send out some general object over an event queue or topic. From that message, any number of services could perform operations. 10, 100, or 1000+ services could be invoked from one call, the client doesn't know. If communication needs to happen back to the client, it could be worked out to occur on another fairly generic queue/topic (usually, it depends on the requirements). In a messaging system you are shifting the interface from some list of methods to the data that is being passed around -- which can be less onerous in some situations. Now, is that extra level of abstraction really useful? Is messaging better than RMI? Those are questions loaded with opinion that will depend quite a bit on the requirements of each individual project. There is no "always correct" answer.
  4. When a program makes an RMI style call, it generally knows what it is calling -- as there is some kind of interface or specification to adhere to.

    That isn't quite "tight coupling", but it does imply some level of coupling as the client must know the methods the service offers. If a client needs to invoke 10 services under certain conditions, it may need to make 10 calls (or you could make another service to abstract those calls, and so on, you get the idea).

    In a messaging system, this does not need to be the case. The client might send out some general object over an event queue or topic. From that message, any number of services could perform operations. 10, 100, or 1000+ services could be invoked from one call, the client doesn't know. If communication needs to happen back to the client, it could be worked out to occur on another fairly generic queue/topic (usually, it depends on the requirements).

    In a messaging system you are shifting the interface from some list of methods to the data that is being passed around -- which can be less onerous in some situations.

    Now, is that extra level of abstraction really useful? Is messaging better than RMI? Those are questions loaded with opinion that will depend quite a bit on the requirements of each individual project. There is no "always correct" answer.
    I think that this has nothing to do with message passing. You are describing an event driven system. And, anyway, it is a matter of perspective, not of technology. You can build an event driven system with RMI. You can build RPC over a messaging system and viceversa. Are there any goodies brought by XML here ? Wasn't better talking about sex ? Guido.