Well, if there was one word we use in this industry that you would think would be pretty well defined (and unambiguous) it should be "semantics" right?
Wrong. I was recently in a meeting with a colleague from the Emerging Technologies group and we were discussing the notion of "semantic integration" and as the conversation grew more and more confused. Finally one of us (can't remember which) stopped - "hang on... what do you mean?" And, so starts the discussion, what semantics do you attach to the word "semantics" in this context?
Well it seems that he had in mind the notion of behavioral semantics which is not surprising as we have both come from the UML world where we typically mean that we want to know how this *thing* is to behave, how does it respond to the world and so on. Specifically the UML specification defines it's metamodel in terms of the semantics of each element. Now... that's not what I meant, I was look at how we might apply ontologies to the problem of integration (this could be characterized as the "semantic web" version of the meaning of... oh well you get the idea). Now, in fact it is interesting that true integration of services in an automatic fashion will requre both behavioral and "content meaning" matching.
If we are really to get to a state where we are able to take two services and watch them interrogate each other and connect together they need to know much more about their behavior than simply the signature of methods on their interfaces, they need to understand that the "signon()" operation must be called and successfully return a "ticket" before you may call any other operation. We also need to know that signon may be a synonym for logon, login and possibly connect... that PID may stand for Product ID or Process ID, but if found within a document called "Product Detail" it is more likely to be the former...
So, why is this interesting other than having thrown two usually intelligent and articulate individuals into gibbering confusion? Well right now any discussion on such semantic integration seems to focus on the attachment of information to complete and published interfaces so that integration can occur. But does this imply that those tagging an interface post deployment understand the business context and requirements that created the service in the first place? Does this role understand the nuance of meaning that can cause the real expensive mistakes?
Perhaps we need to think about how early lifecycle models and tools can be leveraged in the construction of interfaces (operations and documents) that are either constructed from an ontology-backed model or which can be connected to such a model.[Read More]
Tooling platforms and RESTful ramblings
skjohnston 120000GMPN 435 Visits
I want to just note briefly that my humble thoughts here seem to be, if not causing a stir, causing a level of reference from friends at Microsoft. Now, it seems that there is a link from Harry Pierson's column on the MSDN architecture site as well as a more detailed commentary from Stuart Kent on his welog. Now, I do hope to come back and make some comments on Stuart's posting, specifically addressing some of his comments. However, I have just received my copy of Jack Greenfield and Keith Short's book on Software Factories and I intend to give it a good read first.
I have worked with both Jack and Keith as well as Steve Cook (another contributor to the work) and a little with Stuart - they are all excellent leaders in this area and I want to read and understand their position a little better to make sure I am not mischaracterizing their use of the term software factory; Stuart suggested that
The characterization of sofware factories suggested by Simon is at best an over-simplification of the vision presented in this book.I hope that I didn't do that, but I will take the time to read the book and then post my further comments, and if necessary clarifications on my earlier thoughts.[Read More]