Policy MDE vs. MDE Policies

[Shane.Durham@lexisnexis.com]

One of my 'ToDos' from the last face-to-face (at CTC9)...

...was to compose an email to restate my position on our approach to 'policy'.

 

The debate is really about this:

Should there exist a single, consolidated policy set, describing the behavior of all implemented MDEs participating in a system?  Or, should each implemented MDE express its own policy set, describing the behavior and code-sets of that specific MDE?

I think John poetically described the issue this way: "Is there a PolicyMDE... or are there MDE Policies?"

 

To understand my position, you first need to understand how I perceive 'policies'.

 

I see 'Policy' as the MDEs' "rules of engagement" - a set of rules to describe the interactive behavior of our implemented MDEs

 

'Policy' can describe things such as:

- The valid codes you may use or expect when performing an interaction with the MDEs.

- The argument extensions or restrictions to the 'normalized' set of MDE interactions.

- The set of (link to) business rules regarding MDE interactions (court hours, font size).

 

Furthermore, I see policies as describing the interactions of any our implemented MDE.

 

Others see 'Policies' as describing (or controlling) only interactions with the court, whether it be an interaction we have categorized as FilingReview, or whether it is an interaction we have assigned to CourtRecord.   Their point of view is often reflected in their nomenclature: 'Court Policies', rather than simply 'Policies'.  

 

To be fair, all of the Policies we have discussed so far, happen to only be concerned with how we interact with the court.  For example, we have not yet discussed policies for FilingAssembly, because, coincidentally, our scope has not officially recognized any queries or transactions into the FilingAssembly MDE (aside from a Callback function), though, we all agree that FilingAssemblyMDE could define transactions and queries, and, presumably, those interactions would then have the potential to have associated policies.

 

Perhaps, the lingering 'Court Policy' concept reflects that some of us are not entirely on-board with the 'MDE' approach to the system.  That's fair enough - MDE is merely an architectural concept which might or might not be successful for us in the long run - but, nevertheless, at this point, for this version of LegalXML, we have decided to pursue the MDE approach, and, I feel, we need to be thoroughly consistent with it.

 

If we have agreed to organize our court interactions into 'FilingReview' and 'CourtRecord', then, we should also agree to categorize the MDE's 'rules of engagement' along those same lines:

These are the 'FilingReview' rules...

And Those are the 'CourtRecord' rules...

At the face-to-face, I seemed to get some decent buy-in on that concept.  It was noted that some of our rules (such as query extensions/restrictions) are distinctly MDE-specific, and those policies should therefore be organized by MDE. 

 

But, just because we might agree that policies should be organized by MDE, does not mean that they could not continue to be consolidated into a single file.  The question remained: Should there exist a single file to express all policies of all implemented MDEs?.. or should the system consist of  multiple policy files, one per implemented MDE?

 

So, do we want to see something like this?:

SystemPolicy

    CourtRecord (MDE 1)

        CodeSet1, QueryExtension2,  QueryRestriction3, etc.

    FilingReview (MDE 2)

        CodeSet1, QueryExtension2,  QueryRestriction3, etc.

 

Or, something like this?:

Policy-1 for CourtRecord ( MDE 1 )

        CodeSet1, QueryExtension2,  QueryRestriction3, etc.

 

Policy-2 for FilingReview ( MDE 2 )

        CodeSet1, QueryExtension2,  QueryRestriction3, etc.

 

Now, I look around me for another real-world example of the proposed singleton approach.

I can think of none.

 

- Some may refer to Windows registry as an example of a consolidated set of rules

First of all, this is a bad example: WindowsRegistry isn't really intended to be a way for system components to describe themselves to one another.  The registry might persist component settings but it is not intended to be a publisher of settings.  For example: MicrosoftWord has a documented API by which you can learn of its settings - you are not supposed to go poking through WindowsRegistry to learn about word's settings. 

 

Nevertheless, we'll run with this example....

....if you were to look at distributed systems that rely on WindowsRegistry to persist settings, you would find that a single windows registry is not used to capture all settings of the entire system.  If you were running in a Windows environment, each of your distributed components (on separate machines) would use their local windows registry to manage their settings.  And, in a distributed environment, there would not exist a single registry from which all components exchange their configurations.   Component-A doesn't learn about Component-B by means of a shared WindowsRegistry.   In windows (COM or DCOM), Component-A typically learns about Component-B's settings... by directly interacting with Component-B's API.

 

(Note: Component-A learns about the existence of  Component-B through another mechanism, which we have referred to as a 'directory'.  'Directory' describes the location of a component - it is not related to 'policy'. )

- Some might think of DNS as an example of a consolidated set of rules.

DNS is, in fact, an example of a directory of other systems.  It provides a consolidated means to find other systems. It does not represent a consolidated set of rules for interacting with those systems.  It is little more than a list of addresses.

- Some may refer to UDDI, for WebServices, as an example of consolidated rules.

UDDI is an excellent example of how components might publish their 'rules of engagement.   However, UDDI does not represent the singleton approach. 

 

UDDI  represents a singular access point for finding or obtaining individual rules (i.e. WSDLs - the syntactical rules of a WebService).   A consumer still asks the UDDI host for WSDLs, one by one.  The WebService rules are *still* organized, and segregated, by the individual WebServices. 

 

(Truth be told, I feel that UDDI is a much better example of the position I am advocating than as an example of the singleton approach.)

 

I have further basis for my position on this issue.  I drafted a larger email illustrating how the singleton approach gets to be very difficult to implement once the system begins to incorporate multiple CourtRecordMDEs (court-1 and court-2 policy), or if the system begins to incorporate FilingAssembly queries...  

 

....but, for now, I'm going to pause here for feedback on this much:

 

Consider:

 

1) Do we agree that Policies are MDE-specific ( Such as MDE-query extensions/restrictions?  )

 

2) If so, then, can we agree that Policies should then be organized by MDE (MDE-1's policies vs. MDE-2's policies)?

 

3) Can we agree that the proposed 'singleton' approach is inconsistent with other types of distributed multi-component systems?

 

 

If we can agree on that much, then why would we want to adopt the proposed 'singleton' approach?

 

If I left my position at this much:

 'MDE policies' is an approach that is most consistent with other distributed system designs (UDDI)....

 

or , conversely,

 

 'PolicyMDE' is an approach that is inconsistent with other distributed system designs....

....then, is anyone able to disagree with that assessment?

...and/or, is anyone willing to provide an explanation of how the 'singleton' approach is still better and worthy of pursuit?

 

Will my dissenters please stand?

 

- Shane

LexisNexis