MISMO Trimester Meeting January 23-27 2012 Jacksonville Florida Using the Reference Model...

MISMO Trimester MeetingJanuary 23-27 2012 Jacksonville Florida

Using the Reference Model Internally: Enterprise

Systems Jim Metzger, Harland

Greg Alvord, RealEC


The Tasks

• Mapping to Legacy– Approach– Tools

• Converting to/from legacy– XSLT– Object Model


Mapping to Legacy

• Build a spreadsheet– Lots of people know how – No way to verify/test– Artifact disconnected from final process

• Use a tool– I like Altova Mapforce

• Test map• Document Map• Produce XSLT 1.0 , 2.0, Xquery, C#, C++, Java

– Code generation has it own issues.

– Other tools available


Converting To/From Legacy

• XSLT -- Map is Data– Fast to do– Interpreted or Compiled– Changes by changing a file (good/bad)– Unpredictable memory usage– Can be slow


Converting To/From Legacy

• Object Model – Map is compiled code– Development cycle to do– Less developer experience available– Changes by good process– Known memory model– Fast!!!!


What do Developers Say?

• Developers with relational data background love MISMO 3.x– Team background is important



• The multidimensionality and repeatability of sections of the model needs to be well understood. The repeatability of containers was a significant change for developers who had only previously worked in a fixed length flat file environment.

• People used to 2.x service messages and flat data models are skeptical.• Team training in model important.



• Legacy systems that reserve memory for every possible data point have a hard time with 3.x– Legacy system using new model

• Needs optional field implementation

– Legacy system using old models• Middle system filters to data to Legacy



• “Floppy-disk syndrome” occurs with people who coded to Intel 8086 memory limits and see the big new messages.– I coded before Floppy Disks and 8086– Grow with the times– Train for the times



• Best to dedicate a team with the responsibility of mapping legacy data models to the new model.– BA or Developers? – Both!!

• Crosses legacy management lines.



• Provide funding for the effort by applying it to visible software projects that will generate revenue.



• An internal “global lexicon” became essential for us, because it insulated the internal model from MISMO release changes.– LDD is a best Practice– Must digest MISMO releases to internal needs



• The benefits of a single standard do eventually start to show themselves – multiple products can talk to multiple third-party services after writing one interface. – SOA is a best practice– Canonical XML within a the design essential– MISMO 3.x as Canonical candidate leverages

100 thousand man hours



• Developers need to be aware that constraints and conditions may be placed at both a data point level and at a container level by the trading partner. These may be more restrictive than the MISMO schema. Developers may not be attuned to thinking about conditionality at a container level, in addition to a data point level.– ULDD uses model– ULDD limits field sizes– Freddie Mac data constraints different from Fannie Mae



• MISMO LDD breaks data into lowest component pieces. Legacy systems may not store and process data at the same level of granularity. This can provide some challenges and require changes to legacy systems or translation layers between MISMO and legacy data. Legacy proprietary code translation into MISMO data can be complex, actually breaking down into 3 or more MISMO data points.– Data normalization a best practice



• The model may seem overly complex to those who are implementing to support simpler business use cases.– Any use case is a subset of the model.– MISMO needs to publish the Use Case driven

IGuides– Yes there are many alternate designs. – Compatibility across use cases has value. Real

measurable $ and time value.– If pushed to a simple one off get a blood oath.

• Accountability flows up and down the org chart. • NOT just down.



• There was a steep learning curve on the concept of Loan States. There was nothing similar that had existed before, so working with it the first time was difficult. Having some MISMO examples of its usage would have been helpful.• MISMO needs to publish the Use Case driven

IGuides



• Trading partners seem to like the immediate feedback that a parser provides letting them know if their file is not well-constructed which is a plus with the common MISMO XML.– Schema validation is good– Business validation is better



• In general, the lack of written materials explaining the reference model and its usage was seen as a negative. Developers are looking for more guidance. One particular area that was called out was on the usage of EXTENSIONS.

• MISMO needs to publish the Use Case driven IGuides



• Large number(unmanageable) of objects share the same namespace when code is generated…it would be better if the schema was sub divided a bit more.– MISMO uses W3C strategy for Namespace

management– Confusing XML Namespace with Code Namespace.

• Need to be managed differntly

– Arch WG MAY break up the schema more.



• Some defined types (like Integer) might be better as “Int” as they convert to generic strings when generated– The xsd:integer issue– Arch WG to consider solution



• Choice Groups when cast into Object Model need additional code to enforce the choice on deserialization.– Deficiency of XSD.EXE?

• May be a missing option setting



• Enumerations should have a separate file– Wants file per enumerated type.– Arch WG will consider



• It would help if a base datatype was defined so we could extend it as needed– 3.2 Now has a base type for each data type– Including enumerated types.


Conclusion

• Developers comments positive• Still some MISMO improvements needed• MISMO needs to publish the Use Case

driven IGuides

MISMO Trimester Meeting January 23-27 2012 Jacksonville Florida Using the Reference Model...

Documents

Transcript of MISMO Trimester Meeting January 23-27 2012 Jacksonville Florida Using the Reference Model...