1 / 78

IRMAC Metadata Special Interest Group

IRMAC Metadata Special Interest Group. Panel Members : Mark Leide - RBC Royal Bank Paul Quigley - iWorks Group Inc Wayne Harrison - BMO Bank of Montreal Ron Klein - Information Systems Mgr Frank McCormick - Economical Insurance

kreitzer
Download Presentation

IRMAC Metadata Special Interest Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IRMAC MetadataSpecial Interest Group

  2. Panel Members : Mark Leide - RBC Royal Bank Paul Quigley - iWorks Group Inc Wayne Harrison - BMO Bank of Montreal Ron Klein - Information Systems Mgr Frank McCormick - Economical Insurance Liang Zheng - Government of Ontario Tony Tsang - AT&T Canada XML Session Format - 1 hour Panel Presentations - 1 hour Q&A Discussion on XML XML – PANEL DISCUSSION

  3. Panel Member - Mark Leide for RBC Insurance & Royal Bank XML COMMITTEE & XML USER GROUP XML SCHEMA - Standards, Guidelines & ‘Best Practices’ RBC EXPERIENCES RBC INSURANCE – Life Insurance Standards Organizations : ACORD XMLife SCHEMA & CLIEDIS XMLife SCHEMA ‘RELATION’ OBJECT Discussion LIFE COMPANY CENTRAL (LCC) COMMON APPLICATION FRAMEWORK APPROACH & BENEFITS XML INTERNATIONAL WEALTH MGMT Initiative XML – RBC Insurance & RBC Royal Bank

  4. Panel Member -Terry McLeod XML COMMITTEE *concrete deliverables *executive sponsorship Focus point for adoption & proliferation of XML across RBC Financial Group All Areas & Business(s) Represented : …development, infrastructure, architecture… Banking, Insurance, Investments, Capital Markets etc. Define Standards & Guidelines for development on .NET & J2EE Platforms - Frequent communication with developers via News Briefs, Internal Website, XML Users Groups, working sessions and meeting minutes. XML USER GROUP * information sharing within RBC *no firm commitments Communication Forum for Developers using XML & related technology Co-Chaired by an Application Developer & a Tools Specialist RBC XML Committee & User Group

  5. Panel Member -Frieda Bilan (for Alex Cameron) XML SCHEMA re-use ‘common RBC Enterprise’ XML schema(s) developed by subject area i.e.. Location,Client/Involved Party etc. & data dictionary XML TAGs for element/attribute consistent names. RBC Best Practises supplement these Recommended References: W3C XML Specifications i.e. Primer docs W3C XML Schema Design Patterns: Avoiding Complexity at xml.com siteXFRONT site ‘ XML Schemas: Best Practices’ Real-world XML Schema on the developerWorks site. XML Schema Naming Standards & Guidelines: UCC (upper camel case) for complex/simple types LCC (lower camel case) for elements and attributes Readable (only industry stnd abbreviations), unqualified e.g.. <address> type=“home” instead of <homeAddress> XML – RBC Best Practices

  6. XML SCHEMA NAMESPACE *valid domain name, reference URI http://<qualifier><.rbc.com>/namespaces/<top-level-NS-docname>/yyyy-mm-dd-status>Status of : draft, proposed, recommended all published in XML registry for easy sharing.Specify Default Namespace (either with ‘tns’ prefix or same as target namespace) Consistent prefixes for names from the W3C namespaces(.xsd for schema ns). RBC Best Practises Promote GLOBAL use : elementFormDefault=“qualified” (improves readability) attributeFormDefault=“unqualified” (default) prefer re-use by Global COMPLEX / SIMPLE TYPES & then by for any Global ELEMENTs using REF= <element> EXTENSIBILITY Promoted by: Use Extensible Content models: #anyAttribute, ##any anyNamespace 4 Extensible Techniques: ABSTRACT extension, CHOICE, Element SUBSTITUTION, SUBSITUTION GROUP. - Do not use Default or Fixed values in a schema (if no validating parser available). XML – RBC Best Practices

  7. Panel Member - Mark Leide for RBC Insurance & Royal Bank XML COMMITTEE & XML USER GROUP XML SCHEMA - Standards, Guidelines & ‘Best Practices’ RBC EXPERIENCES RBC INSURANCE – Life Insurance Standards Organizations : ACORD XMLife SCHEMA & CLIEDIS XMLife SCHEMA ‘RELATION’ OBJECT Discussion LIFE COMPANY CENTRAL (LCC) COMMON APPLICATION FRAMEWORK APPROACH & BENEFITS XML INTERNATIONAL WEALTH MGMT Initiative XML – RBC Insurance & RBC Royal Bank

  8. Panel Member – Mark Leide RBC Experiences Intersystem Communication & Messages Documents Multiple platforms Microsoft (Windows & .NET) IBM (AS/400 & OS/390) Cross platform Web Services XML – RBC Experiences

  9. ACORD ACORD is a nonprofit insurance association whose mission is to facilitate the development and use of standards for the insurance and related financial services industries. Developed and maintained Life insurance Standards Mid 90’s OLiFE Late 90’s XMLife / TXLife XMLife / TXLife is Public Domain XML – Life Insurance Standards Organizations

  10. CLIEDIS Canadian Life Insurance EDI Standards organization Made up of both Insurance carriers and Software Vendors In early 2001 adopted ACORD’s XMLife schema Acts as a REGIONAL MANAGEMENT ASSOCIATION FOR CANADA in support of ACORD's XMLife standards. Standards Review Committee (SRC) CLEDIS Commission Working Group (CCWG) XML – Life Insurance Standards Organizations

  11. XMLife / TXLife Originated from ACORD’s OLife model Publicly available Global Standard Has a series of “top level objects” which can be related to one another using unique ID’s The XMLife Schema is BIG! (over 450k in size) TXLife provides a transactional model based on XML that uses XMLife documents as a payload. XML – XMLife / TXLife

  12. XML – XMLife / TXLife

  13. <?xml version="1.0"?> <OLifE/> XML – A Valid XMLife Document

  14. Relation Object A top level object in the XMLife schema XML – Relation Object Party (client) Holding (policy) Relation • Used to link any two objects or structures together using ID’s

  15. Relation Object Example The following example shows a how we can link the owner of a policy to a policy. <Relation id="Relation_9" OriginatingObjectID="Party_80" RelatedObjectID="Holding_7992"> <OriginatingObjectType tc="6">Party</OriginatingObjectType> <RelatedObjectType tc="4">Holding</RelatedObjectType> <RelationRoleCode tc="8">Owner</RelationRoleCode> <RelationDescription tc="0">Unknown</RelationDescription> </Relation> XML – Relation Object

  16. Benefits Provides a common way of describing a Life Insurance policy which is understood worldwide Provides a common way of conducting business XML – XMLife/TXLife Benefits

  17. Life Company Central (LCC) Common Business Portal for the Canadian Life Insurance Industry(Similar to FundServ for the mutual fund industry)) Multitude of transactions Electronic Applications / Inquiries / Transactions Will use XMLife Standard Founding Members are: Clarica/Sun Life, Canada Life, Manulife, RBC Insurance, Standard Life. Positive support and commitment from the top distribution companies and the IDA Participation will be open to the entire industry More information at: www.lccexchange.net XML – Life Company Central (LCC)

  18. International Wealth Management: Common Application Platform Initiative Objective: Eliminate continuing proliferation of stand-alone applications Wheel reinvention avoidance: No need for n-number of disparate permissions modules, auditing, workflow, transformation, and content delivery solutions etc. Integration!, Integration!, Integration! Objective: Deliver a generic reusable services based infrastructure to be leveraged for future business solutions. Implementation of a series of single best-of-breed service applications for each of the most common infrastructure verticals Services to include authentication & authorization, workflow, rules engine, auditing, data transformation, personalization etc. Objective: Maximize benefits from existing infrastructure investment Rather than a strategy of “rip and replace” for legacy applications, focus on their introduction into a services based infrastructure. Don’t rebuild everything. XML – International Wealth Management

  19. Intl Wealth Mgmt: Common Application Platform Initiative cont. A number of business solutions developed using CAP approach Extensive XML and Web-Services usage to deliver solutions Visual Studio .NET & JAVA (Host based – Websphere environment) web services implementation. Extensive direct .NET and JAVA interoperability. XSLT usage for common XML to HTML transformations. XML schemas and MS BizTalk used for transformations and document routing requirements. Leveraging RBC standards identified by the XML Working Group. XML – International Wealth Management

  20. Any Questions ? Next Panel Member Presentation iWORKS - Paul Quigley

  21. Meta Data as used by iWORKS iWORKS markets a Data Quality Software Suite written completely in Java, with XML as its meta transport layer Used to define all data accessed by the application, and also the processes and business rules executed by the application Describes the structure of the data as defined by the record layout Describe the storage of and access to data as defined by the data collections Exists at three processing layers Job layer (consists of multiple business processes) Business Process layer (consists of multiple data processes) Data Process layer (components that do the work) Data Access layer (components that physically access data stores) XML – Paul Quigley for iWORKS Group Inc

  22. XML as used by iWORKS XML is the transport mechanism for the Meta Data All the Meta Data and processing results are stored in the XML Meta Template table The DTD (Data Template Definition) describes the rules about how the XML document is structured (input fields, output fields, labels, etc.) The DTD defines the user interface for the processing components XML can be used to exchange Meta Data between applications (outside of iWORKS’ Data Quality Suite) XML – iWORKS Group Inc

  23. Examples of iWORKS’ use of Meta Data: Data Quality Analysis Compare actual data vs. expected Identify potential problemsat the start of the process Data Transport & Data Transformation Design and execute processes Detailed audit log (run logs) Result sets presented to user(content vs. format) XML – iWorks Group Inc

  24. Any Questions ? Next Panel Member Presentation Bank of Montreal – Wayne Harrison

  25. Panel Member -Wayne Harrison; Bank of Montreal Financial Group Process XML Senate Establish working groups for development of guidelines and standards Developed a governance model for creating and administering standards Two working groups defined, the XMLSI and the XML governance teams XMLSI Standard interface project defines standard interfaces using XML Objective is to provide standard structures for data interchange within BMO applications XML Governance Developed accountabilities and roles for developing and administering detailed standards, finding and promoting re-usable constructs. XML – BMO Standard Interface

  26. XML – BMO Standard Interface XMLSI team identified these uses for XML • Messaging: • between our application servers and host systems • Between our application servers and client machines • Presentation of information • Data storage • Messagingis the focus for standardization • XMLSI standard is partitionedinto CORE and MODULES • Core - common re-usable elements • Modules – application specific elements

  27. XMLSI Core and Application Modules Core Common message structure Common message headers Common message control mechanisms (e.g. records control) Placeholder for common data structures (e.g. “Customer”) Modules LOB/Application specific semantics Allow independent development/evolution Each owned separately XML – BMO Standard Interface

  28. Current status Modules are implemented as XML Namespaces (NS), allowing independent Module development/evolution Core is a separate namespace, containing enterprise standard constructs, derived from data models (e.g. Party, Product), common headers, control structures. Security and control header defined. Party / Location common schema in place An inventory of all XML constructs managed centrally. Namespaces are administered by Information Resource Management Versioning is an issue XML – BMO Standard Interface

  29. Any Questions ? Next Panel Member Presentation Consultant – Ron Klein

  30. Panel Member -Ron Klein Consider Loose Coupling Insulates internal systems from external changes Shares XML documents instead of making function calls or APIs The execution of methods is contained totally within the application Implication Shifts the burden from integration to XML XML carries not only content but also the action required XML – Design

  31. XML – Design Panel Member -Ron Klein • Adopting Standards • Use simple, consistent, and repeatable mappings • As it grows, more attention goes to the quality and extensibility of XML interfaces

  32. XML – Design Case 1: Inter government agencies – Worst Practises • Created one DTD for each form that the public needs to fill (32) • Created one DTD wrapper for appending pdf form files • Applications is not agile and flexible therefore costing more

  33. XML – Design <?xml version="1.0"?> <?xm-well_formed path="C:\Documents and Settings\klein\My Documents\IJ-FORM\2597.dtd"?> <form><IJ_FORM_NUMBER>14A</IJ_FORM_NUMBER> <IJ_FORM_ID>2597</IJ_FORM_ID> <IJ_FORM_VERSION>3</IJ_FORM_VERSION> <IJ_FORM_SUBVERSION>2</IJ_FORM_SUBVERSION> <IJ_FORM_VERSION_DATE>2002/08/19</IJ_FORM_VERSION_DATE> <civilCase_courtFileNumber>VA50</civilCase_courtFileNumber> <civilCase_titleOfProceedings_richtextMax/> <civilStatementFiled_date></civilStatementFiled_date> <IJ_BLOCK_B20> <civilStatementReceiver_nameTitlePrefix>Miss</civilStatementReceiver_nameTitlePrefix> <civilStatementReceiver_lastName>Locks</civilStatementReceiver_lastName> <civilStatementReceiver_firstName>Goldy</civilStatementReceiver_firstName> …… </IJ_BLOCK_B20> <documentFiled_courtDocumentSerialNumber></documentFiled_courtDocumentSerialNumber> <documentFiled_date></documentFiled_date> </form>

  34. XML – Design <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd"/> <xsd:annotation> <xsd:documentation xml:lang="en"> Partial Schema for Efile's form: 2597_2 </xsd:documentation> </xsd:annotation> <xsd:include schemaLocation="IjSharedTypes.xsd"/> <xsd:element name="form" type="Form_2597_2_Partial_Type"/> <xsd:complexType name="Form_2597_2_Partial_Type"> <xsd:sequence> <xsd:group ref="ijSIEPartial"/> <xsd:element name="civilCase_courtFileNumber" type="ijVA50" minOccurs="0"/> <xsd:element name="civilCase_titleOfProceedings_richtextMax" type="ijXHTML" minOccurs="0"/> <xsd:element name="civilStatementFiled_date" type="ijDate" minOccurs="0"/> <xsd:element name="IJ_BLOCK_B20" type="IJ_BLOCK_B20_Partial_Type" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> </xsd:schema>

  35. XML – Design • Case 2: Large publishing multinational – Best Practises • Created neutral interchange format not tied to metadata of any individual company nor specific delivery engines • Applications are not affected at all • Created DTDs wrappers for the destination delivery engine • Load to services require a DTD wrapper for documents, the interchange DTD is used within the wrapper.

  36. XML – Design • Consider Loose Coupling • Insulates internal systems from external changes • Shares XML documents instead of making function calls or APIs • The execution of methods is contained totally within the application • Implication • Shifts the burden from integration to XML • XML carries not only content but also the action required

  37. Any Questions ? Next Panel Member Presentation Economical Insurance Group – Frank McCormick

  38. Panel Member – Frank McCormick Current Project:Tailor third-party Policy Administration software package; integrate with existing legacy systems. Integration Team: ·Architect (hardware/software compliance, business/systems SME) ·Data Analyst (conceptual model, XML/DTD, standards) ·Integration Analyst (MQSI) ·Lead Programmer (parsing, interfacing with legacy systems) ·Third-party software company resources (as required) XML at ECONOMICAL INSURANCE GROUP

  39. Modeling software used to create conceptual model of all high-level entities/relationships, and occurrence levels. Get consensus from subject matter experts (systems and business resources). Iterative process. XML Spy used to create high-level XML Document and generate DTD for all segments (representative aggregates and elements). Where possible, use established standards for aggregate/element names, data definitions. CSIO XML Business Message Specification (Centre for Study of Insurance Operations – Canada). · ACORD XML Business Message Specification (Association for Cooperative Operations Research and Development – U.S.A.). XML at ECONOMICAL INSURANCE GROUP

  40. Get consensus from integration team members, project manager and third-party software project manager. Iterative process. Build in-depth XML/DTD entries (and applicable copybooks for legacy systems) for all segments at rate of one segment per week. As each segment is completed, pass to other integration team members to continue development effort. XML at ECONOMICAL INSURANCE GROUP

  41. Populate Metadata Repository Glossary Business Element Data Element Domains XML Segment (available for reuse) Aggregates/Elements (Tags) Business Rules Data Mapping (Source/Target) Generate XML Text File Generate Repository Reports (Detailed Design Specs) XML at ECONOMICAL INSURANCE GROUP

  42. Any Questions ? Next Panel Member Presentation Ontario Government - Zheng Liang

  43. Panel Member -Zheng LiangManagers – Norman Lee, Thomas Chen XML in Ontario (XiO)Corporate Architecture Branch (CAB) Management Board Secretariat OUTLINE XML in ONTARIO (XiO) Corporate Architecture Branch • Purpose • e-Government Context • Results of XiO Phase I • XiO Phase II • Discussions

  44. IRMAC Meta Data SIG – XML Session XML in ONTARIO (XiO) Corporate Architecture BranchPurpose • Present XML in Ontario project objectives and deliverables • Outline some preliminary findings to-date • Solicit feedback from IRMAC members

  45. Government of Ontario G2G Government Of Canada G2G Foreign Governments G2C G2G G2B G2B B2C Citizen B2B Business Other Provincial and Municipal Governments Business IRMAC Meta Data SIG – XML Session Ontario e-Government Environment

  46. Integrated Service Delivery (ISD) Providing Ontario services over the counter and electronically to individuals and businesses Citizen Engagement Enabling two-way public interaction Sectoral Reform Using I&IT to drive and enable sectoral reform Electronic Service Delivery (ESD) Providing services electronically to our clients Enterprise Resource (HR and Financial) Systems and e-commerce processes Corporate Systems and Enablers Common I&IT Infrastructure Underlying technology to support both enterprise-wide and business specific applications IRMAC Meta Data SIG – XML Session e-Government Context * Standards based interoperability (XML) * Secure and reliable messaging (XML) * Business process support (ebXML) * Accessible, distributed information stores (Reg/Rep) * Loosely coupled collaboration between parties (ebXML)

  47. OSDML META DATA CDES & CLUSTER SCHEMAS TRANSACTION SCHEMAS ebXML Registry/ Repository SECURITY SERVICE, TARGET & MAINTENANCE PROFILES COMMON COMPONENTS TRANSFORM- ATIONS FOR OPS PROGRAMS IRMAC Meta Data SIG – XML Session OPS ebXML Vision FAX CALL CENTRE PORTAL COUNTER ENVIRONMENT FUTURE SERVICES - DELIVERY SERVICES - Presentation Layer Presentation Layer Presentation Layer XML Services Layer XML Services Layer XML Services Layer OPS Programs OPS Programs OPS Programs

  48. HTTP JDBC Application Server J2EE.NetXML User Interface HTML XML SOAP ODBC XML XML, others IRMAC Meta Data SIG – XML Session N-tier Framework APIs exist in all blue boxes ebXML Registry UDDI SOAP, XML SOAP, XML XML, SOAP Web Services Repositories Msg Broker XML XML Underlying Protocols: BEEP, TCP/IP, SSL, SMTP, etc.

  49. IRMAC Meta Data SIG – XML Session Example of multiple levels of XML schema ESDI 2003 ServiceSpecifications Ministry B Message Schemas Ministry C Message Schemas Ministry A Message Schemas Ministry A Message Schemas Ministry A Message Schemas Ministry B Message Schemas Ministry C Message Schemas Message Envelope Schema OSDML Schemas Ministry A Common Elements Ministry B Common Elements Ministry C Common Elements Common Data Element Schemas Standards, eg. ebXML / SOAP

  50. IRMAC Meta Data SIG – XML Session Results of XiO Phase I • OPS XML Vision • CDEM (Common Data Element Model) (part of IIP) • CDES (Common Data Element Schema) • Corporate developed XML schemas based on Common Data Elements models; adopted by Electronic Service Delivery for Individuals project. • OSDML (Ontario Service Delivery Markup Language) • Standard language of describing services and transaction • Recommendation of ebXML adoption

More Related