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?
Thanks,
Ali
Comments
- Anonymous
March 06, 2006
The comment has been removed - Anonymous
March 06, 2006
The comment has been removed - Anonymous
March 06, 2006
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.