Or possibly, I am too dumb.
Owe posted the first real article in our ping-pong series here
And my initial impression was. Wha? who? huh?
‘Service Contract’, ‘Data Contract’, ‘Message Contract’?
It sounds like something you could sell to a manager, but what does it DO?
Now, this is not a criticism of Owe, or the project he is working on, it is more of an admission on my part that I have not encountered the problem space that he has been tasked with solving and so have not built up the abstract model in my head of the particular ‘gotchas’ of his current area of work.
It does however remind me of the early days of Ruby on Rails, when it was our proud assertion that you only needed 2 books to be a rails developer. (The pickaxe and the Agile Rails book) Pickaxe is the definative RUBY book, and the agile development book was the only (at that time) rails book available.
Many articles of the time tried to draw comparisons between those two books and the mountain of paperwork needed if you where for instance a Java JSP developer.
After Owe submitted his post, we got talking, specifically about the asynchronous situation. And it all sounded nice, but as I thought about it afterwards, several special cases came to mind that would complicate the situation for me.
Please, understand I am talking from an orifice other than my mouth in the following discussion as I have never used tools to do this and have no experience in this particular area to back up my suppositions and assertions. If I am wrong, please, let me know, but don’t shout, I scare easily.
The principle is that when the user tickles the user interface to cause something to be done, (deleting a line from an invoice for instance), the event triggeres a message from the front to the back end that requests that the record in the database be deleted. At this point, the frontend will disable the invoice line within the open invoice window so that no other actions can take place.
The actual removal of the line from the list, must wait on the success message coming back, and this is where things get interesting. In order to not hold the user up, the user interface does not wait for this success (or failure) message, but continues to process user requests.
The user can do ANYTHING else, other than do something with the line which has been disabled.
The system must know the context (which window, which list etc) to alter when the success message comes back. This as far as I can see significantly complicates the handling of the returning events.
For instance, what if the user closes that invoice window and opens another one for a different invoice?
Once that happens, the system has to be smart enough to realise it should do nothing, as the original window is no longer onscreen to alter, but another wondow (of the same class, flavour, type?) IS.
Further… What if the user closes and re opens the same invoice? How is the user interface to know it should disable the previously deleted line?
One way would be to post into a list of ‘expected messages’ an object containing enough context to allow the handler to cope with the return. But as you can imagine it surely starts to complicate things.
Surely, things get more complex. For instance, if there is an outstanding event to delete an invoice line, not only must that line be disabled on all subsequent edits of the invoice prior to the success (or failure) message lands, but in addition, other business logic needs to be asserted. For instance, the invoice must be marked as ‘dirty’ in some way, to ensure that the user interface will not allow it to be printed before the known pending update to its details has been completed successfully.
Please, don’t attempt to tell me that all of these situations and borderline cases are just ‘handled’. There is enough diversity and complexity in this situation to ensure that no automatic process could work without having first identified every sticky situation.
Ok, I have made a fool of myself enough, exposed enough of my ignorance to make any certified MCE chuckle and turn away. So lets examine something else.
The attempt at Microsoft Office lockin, its failure and subequent birth of OOXML.
A while ago (3, 4 years?) Microsoft offered future office users (especially corporate users) a poison challice in the shape of their secure document framework (can’t remember what they called it, but it did the following).
It offered corporates the opportunity to lock up their documents so that if a sensitive memo escaped, it would be unreadable. If they wished, they could say that a documents contents could not be printed, but only viewed on screen. It allowed for documents to be ‘revoked’ or ‘expired’ so they would be unusable after a certain date or as a consequence of a particular event.
All of this sounds wonderful. But, it had the benefit (for microsoft) of ensuring that those documents would only ever be available on microsoft operating systems using microsoft applications forever and ever amen. No more choosing to move to a competing package, because all your old documents would be locked within the microsoft structure. Once you have that, purchasing departments loose all leverage on microsofts pricing policy. All previous data would be held hostage.
Microsoft offering these options sent a ripple through the IT world as the true consequence of accepting these shiney new options was understood.
I believe this was the impetus for large corporate and governmental customers to demand more open file formats from the beast of Redmond. So, what did they come up with?
OOXML. (wikipedia, defective by design)
There are more criticisms of this ‘standard’ than I can really review in any single lunchtime. And that is just at a technical level.
Microsoft then spent considerable effort and money to ensure that OOXML would be ratified as an ECMA standard
OOXML is ratified as an international standard against the express wishes of members of the actual committees formed to decide the matter. See here for details. Brazil, UK, South Africa, Denmark, India, all lodge complaints about this brazen manipulation of the international standards process.
Ok, so, after the rant, we need open standards unencumbered by patent or copyright requirements that can be used without fear of legal reprisal. Anything else is soo skewing the playing field as to completely destroy any pretense of having a free market for information infrastructure.