Operation inference and Contract-first Design

After Tomas's comment on my last blog, I've been thinking about the operation inference feature in Christian's WSCF tool.

I'm not sure that inferring operations based on the message name has been standardized. (Please correct me if I'm wrong) I've, nevertheless, noticed that several companies such as eBay name their messages in a standard manner similar to that used to infer operations by the WSCF tool.

My thoughts were that to do this right we would need to enable a wizard, similar to the "Text Import Wizard" in Excel, to import messages and create a contract. That way, a user could specify how to infer the operations based on message attributes and not be forced to name his messages in a particular manner.

Either way, I'm not sure that operation inference is a high priority. If we give users a manner to manually select the messages types/data types for a particular operation, we have made a huge leap. Automating the operation creation is simply a lower priority.

While this feature may be somewhat important to true message-first design, as users will claim that they should not have to think about operations, I'm not convinced that forcing users to name messages in a manner so that operation can be inferred is really that useful, unless, they were going to name their messages in that manner anyways.





Comments (3)

  1. Ali,

    I actually wasn’t referring to the Operation Inference feature explicitly, though that is a nice feature for sure. I was talking mostly about the fact that I want to model messages and then model operations as simply tying together behavior with messaging: i.e. name, message in, message out, headers, done!.

    What I do for sure don’t want to do is model methods and arguments. I sure as hell don’t want to model classes, either, even if that is what is generated behind the scenes. If I wanted to do that, I would just use the class designer, which for sure works good enough for that purpose and is certanly faster than typing parameters in a grid (who in gods name thought that was better than writing the code in the first place?)

    To me, messages are more than just the serializable class that might get generated underneath. I’m perfectly OK with DataContracts (and I’ve been a long time lover and enthusiast of XmlSerialization), but there are key features of designing your message that are more than just class name and fields. What about namespaces, attributes vs. elements, being able to explicitly define extensibility points in the message schemas, and so on?

    I hope I’m making myself more clear now 🙂

  2. MSDN Archive says:

    Actually, I totally understood what you meant when you mentioned it earlier. I should have been more clear. 🙂 I agree with what you have said as I did before. This is how I also think about this issue.

    I have, however, seen that people use XSD to define their messages today. I wonder if people will continue to want to do so if we offer them viable alternative. One that is not classes, methods and parameters…

    However, you comment did spin off another thread in my head, which is this one. This is why I blogged about it as a seperate post. 🙂

    Can you point me to a link or give me some insight into what extensibility points you are referring to?



  3. By extensibility points I mean explicitly leaving places open in your messaging for extension elements/attributes or simply for extended data. As you probably know, XSD has some issues with where (and how) extensibility can be added to schemas without breaking the OPAR (Dare has good articles on this http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=4d18d061-8895-46e0-b5b5-7d51c7fb8898 and http://www.xml.com/pub/a/2004/07/21/design.html?page=1.  So these are things to take into account, certainly, mostly in designing messaging that are more adaptable and easier to version and evolve.

Skip to main content