When designing the electronic mortgage standard for Fannie Mae, my goal was to design a flexible container that could travel with the content, protect the content, log its use and render it in multiple views. Of course, I was leveraging my programming experience and encoding the MVC pattern in XML. In my latest book, I refined the concept into this diagram:
Most recently, at the FOSE conference I moderated a panel on Information Sharing. In that panel, I discussed some of the principles of “Information As Product” and compared these XML containers to the packaging and labeling of physical products. A panel member suggested I examine the LEXS standard as an example of such an XML container. I was pleased to see the strong similarity between this work and the electronic mortgage specification (now a MISMO standard called SmartDoc).
I see Information MVC as a key XML technique to enable information products that make particular content relevant to specific consumers. The difference between information and an information product is making information suitable for groups or segments of consumers. Enabling the content to expose a different view based on who is accessing it helps us increase the relevance, privacy and security of our content. For programmers this is probably old news, but for data architects and data architecture it is a new concept. Have you used this concept or seen it used? If so, let me know…
Also, for those interested in Information Products, I just posted the first chapter of my latest book online.
Until next time, see you in the XML trenches. - Mike
Feels very similar to XForms.
XForms are an input mechanism to capture form input in XML. That is different than a container mechanism for capturing models and views. The controller is split into two parts - declarative rules triggered by services in an SOA. Thanks for stating this because I should have explained the diagram better. Regards, - Mike
Enabling the content to expose a different view based on who is accessing it helps us increase the relevance, privacy and security of our content.
The same goal is achieved in relational systems with role-based querying using a relationship between the system users and roles table. Active Directory implementations are common. Is the XML approach clearer, cleaner, more robust?
Hi Len,
Certainly true that database views provide some of this functionality. For the electronic mortgage and other "information products" I have seen, the product needs to pass outside of a single organization/environment. In my experience, this is where the database approach falls down. With the XML container, you can pass it around while preserving the integrity of the models (via say a digital hash/signature), log who has accessed it, etc.
So, you get the robustness of MVC in a packaged, transportable container. - Mike
Can you elaborate on what you mean by "declarative rules triggered by a service" and how this is different from the XForms model? All of our XForms use "bind" statements which are declarative rules and we use the w3c events to trigger the rules.
I think you have a great design and it appears to be a good example of convergent evolution!
I am looking forward to your book. I appreciate all the work you did on the NIEM. We use it every day!
- Dan
Thanks Mike. That is what I was looking for. Once packaged on the wire, MVC maintains the relationships. This goes back to our earlier conversation about XML model utility: on the wire, there is no contest. On the other hand, forcing relational schema designs from a model that is designed for on-the-wire bulk loads might not be such a good idea.
It is an issue of the scale of the server farm over the number of agencies who get their services from that vendor. I think we will see more of the HLS applications sourced from vendors capable of managing very large farms. Now the problem is how to meet those security requirements given the push to reduce the number of server farms engaged in this particular enterprise to reduce the attack surface area.
Some kind of service type partitioning seems likely.
Hi Dan,
Yes, I will try and elaborate. First, let me make it clear that I like XForms and feel it is good technology. Let me also state that I have not looked at that spec in awhile so my knowledge may be a bit dated. I also feel that some of the concepts in XForms are similar to what I am expressing here only in a more limited, reverse manner. In other words, my understanding is that XForms starts with a view (HTML), captures data, binds that to an XML model to send an instance document to the server. Correct?
Let me assume so to continue (just jumped over to scan a quick xforms tutorial and I think that explanation holds water :) ...
In the information MVC model, it is not really about input - though if I thought about it some more - I could see XForms fitting in nicely into the paradigm to generate the model. This seems like a good area for further study...
Ok, back to Information MVC ... Views are self-explanatory, the semantic model is the XML Schema (though it could also be RDF/OWL, etc.), the part you asked about was the controllers.
To implement the controllers, I am recommending declarative rules in a rule language rule standard triggered by a web service. While I of course have seen web services and business rules, I have not seen them really combined yet except in some crude instances or in custom rules engines (I did a rule engine for Fannie Mae to valide the electronic mortgages). The way it would have to work is as follows, the product has business rules for key parts of the model (something like [if (sales > 10000) then salesperson.bonus += 2000)] ... this would need to be read by the web services that ingested the information product to enable the controllers. Then when key user interaction events occur, a web service would be executed which in turn would execute the ingested rules and update the model in the information product!
TaDa! Of course, if you don't want to wait for a declarative business rule standard you can hardcode the rules like most applications due and get the same (though non-shareable) effect.
Hope that explanation helped ...
I am really glad you are using NIEM and getting value out of it!!
Best wishes,
- Mike
Ummm... just-in-time business rule ingestion? Umm... instead of a three tier system with business objects, I have a dynamic rule processor?
Performance?
Security?
Reliability?
Competition?
I must not understand this. I don't want to share the business rules. That is where the competitive advantages are. I think that is one of the impediments to the Semantic Web. It doesn't enhance the services market. It kills it.