1 / 30

Journey of a SOA Service Definer

Journey of a SOA Service Definer. Serving the Present, Intercepting the Future. Larry L. Johnson TethersEnd Consulting Co-Chair, OMG Government Domain Task Force Member, OMG Board of Directors Larry.Johnson@TethersEnd.com. The National Archives and Records Administration.

ull
Download Presentation

Journey of a SOA Service Definer

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. Journey of a SOA Service Definer Serving the Present, Intercepting the Future Larry L. Johnson TethersEnd Consulting Co-Chair, OMG Government Domain Task Force Member, OMG Board of Directors Larry.Johnson@TethersEnd.com

  2. The National Archives and Records Administration • Their mission is to… • Safeguard and preserve the records of our Government • Establish principles, policies, and responsibilities for Records Management throughout the Federal Government • And to help Government agencies achieve effective Records Management!

  3. Government to Citizen Government to Business Internal Efficiency & Effectiveness Government to Government E-Training Recruitment One-Stop Enterprise HR Integration E-Clearance E-Records Management E-Payroll E-Gov Travel Integrated Acquisition Environment eGovernment Initiative Portfolios

  4. Context of Presentation • Not about Records Management, per se. • Just one example • More about our experiences and lessons learned in ServiceDefinition • Precision, • Technology Independent • Simultaneously well defined, yet pliable. • Services that can: • Deploy to environments today • Deploy to SOA environments tomorrow • Evolve over time. Simultaneously well defined, yet pliable and formable to unanticipated environments.

  5. Overview of Journey’s Start… • NARA undertook RMS Definition • For Today’s and Tomorrow’s Environments. • Future of Federal Architectures is SOA, but… • Federal SOA not yet here but steadily emerging • Agencies each define own EA thereby assuringdiversity • SOA will evolve in concept as well as deployment • RMS Community of Practice (CoP) • Formed under leadership of NARA • Began as 18 Federal Agencies facilitated by NARA • Focused on defining functional requirements

  6. … and End • RMS CoP employed Model Driven Architecture (MDA) • For Platform Independent Service Definition • For mapping Service Definition tospecific technology • To assure interoperability and consistency • Service Definition is only part of the solution • Optimal ROI requires effective business processes • Thus Records Management Maturity Model is born

  7. Electronic records are a reality Impacts almost all technology acquisitions RM Business Practices are diverse Many Current Systems Do not formally identify RM functions… …but are performing them nonetheless… …and are not interoperable. The National Archives and Records Administration recognized this is a reality within government today and into tomorrow and plotted a course to the future. In the Beginning… NARA and Others Realized

  8. The Target: Federal Service Oriented Architecture In June 2008 the Architecture and Infrastructure Committee of the Federal CIO Council in collaboration with The American Council for Technology / Industry Advisory Council’s Enterprise Architecture Shared Interest Group published v1.1 of: “A Practical Guide to FederalService Oriented Architecture”

  9. The Nature of the Target Architecture From the Practical Guide For Federal SOA • Forward Looking • Envisioningemerging SOA related best practices and technologies, and then… • “Imagining an organization that has fully embraced and adopted the service oriented model.” FederalServiceOrientedArchitecture

  10. Service Definers’ Dilemma • How do you define a service that can be provisioned to an environment definition that is: • Forward Looking • Envisioned • Emerging • Imagined • Different depending on any agency’s particular Technology Platform

  11. The Target Architecture From the Practical Guide For Federal SOA Can’t Change Can Change Can’t Change SOA Serenity: “Provide me the serenity to accept things I can't change, the courage to change the things I can and the wisdom to know the difference.”

  12. Our Starting Place • In the longer term • Standards will emerge for SOA Infrastructure • Enterprise Service Buses, • Service Registries, • etc. • But we can’t wait for that • In the short term • The target environment is not well defined so start by … • bringing in the experts • focus on the business requirements

  13. RMS Interagency Project TeamParticipating Agencies

  14. RMS IPT Issued their Final Report September 7, 2006 • Report Contains: • Functional Requirements Only • UML Representations • Now What?! • Advance availability and interoperability of RMS Tools • Advance RM Maturity

  15. Functional Requirements Done.Now What? • CoP initiated two key OMG standards: • RM Service specification using OMG’s Model Driven Architecture to assure • consistent behavior, • interoperability, • uniform semantics, and • data exchange • Records Management Maturity Model to • enable assessment, • gap analysis, and • facilitate optimal RM processes

  16. Model Driven Architecture AutoMagical Transformation (Built into the MDA Tooling) • Platform Independent Model (PIM) for Composable Services • Service Contract: exact definition of available operations • Information Sharing: common semantics • The Hard Part! • Automated Transformation forProvisioning Agility! • Platform Specific Model (PSM) for binds to Target Environment Contract Fulfillment

  17. MAPPING One PIM Maps to Multiple PSMs YadaYada… C++ DotNet JAVA Platform Independent Model Based on Business Requirements WSDL Platform Specific Models Based on Technology

  18. DOMAIN MODEL

  19. Services Defined

  20. SERVICE MODEL

  21. Voila! Tons of WSDL Angle Brackets! • <?xml version="1.0" encoding="windows-1252"?><wsdl:definitions name="ManagedRecords" targetNamespace="www.omg.org/spec/rms/managedRecords" xmlns:tns="www.omg.org/spec/rms/managedRecords" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"><wsdl:types><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" ><xs:element name="CaseFileRecord" type="CaseFileRecord"/><xs:complexType name="CaseFileRecord"><xs:complexContent><xs:extension base="ManagedRecord"><xs:sequence><xs:element name="creationdate" type="xs:dateTime" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>See the CaseFile package of the RmsDomainModel for a definition of this element.</xs:documentation></xs:annotation></xs:element><xs:element name="closeddate" type="xs:dateTime" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>See the CaseFile package of the RmsDomainModel for a definition of this element.</xs:documentation></xs:annotation></xs:element><xs:element name="authority" type="Authority" minOccurs="1" maxOccurs="1"/><xs:element name="action" type="CaseFileAction" minOccurs="0" maxOccurs="unbounded"/></xs:sequence></xs:extension></xs:complexContent></xs:complexType><xs:element name="ManagedRecord" type="ManagedRecord"/><xs:complexType name="ManagedRecord"><xs:sequence><xs:element name="id" type="xs:ID" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>See the ManagedRecord package of the RmsDomainModel for a definition of this element.</xs:documentation></xs:annotation></xs:element><xs:element name="capturedate" type="xs:dateTime" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>See the ManagedRecord package of the RmsDomainModel for a definition of this element.</xs:documentation></xs:annotation></xs:element><xs:element name="description" type="xs:string" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>See the ManagedRecord package of the RmsDomainModel for a definition of this element.</xs:documentation></xs:annotation></xs:element><xs:element name="recordcreatorid" type="xs:ID" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>Unique identifier of the record creator as managed by the Parties service.</xs:documentation></xs:annotation></xs:element><xs:element name="attributableobjectid" type="xs:ID" minOccurs="1" maxOccurs="1">

  22. Business Process Maturity: It’s the Business Process… ! • For SOA Success • Must support Business Process point of view • Don’t automate failure! • Mature Processes facilitate Service Definition No matter how great the hammer is, it doesn’t work well if you don’t know how to use it properly.

  23. The old way: Records Management as an Application • The application through which a record is captured, is different than the application used to generate it. • Users must learn yet another application. • The use of the application must be inserted in uncountable places in the business process.

  24. The new way: Records Management as an environment, realized through SOA

  25. Status • The RMS Specification has been approved by the Object Management Group’s Domain Technology Committee and the Board of Directors as a Beta Specification. • A Finalization Task Force has been chartered to address issues encountered in implementation • One of its tasks in progress is to formally model each operation in each services <<capability>> with activity or sequence diagrams.

  26. Roadmap of Standards – the Future • RM Maturity Model • RMS v2 (Administrative Functions) • RMS Test Suite • v1 • v2 • RMS/Preservation • RMS/AutoFile • Other Platform Specific Models (e.g., Java)

  27. Imagine the Possibilities • Auto-differentiation of records from non-records including email. • Assure Legal and Legitimate Destruction. • Auto-processing of records based on • content • context • creator/receiver • Allowing scalability and cost efficiency removing the burden from the user.

  28. Its Not Just Government yada yada yada OSHA Part 1904 Security Exchange Commission Rule 17a NY Stock Exchange Rule 440 EPA Clean Air Act 40 CFR Parts 61 and 63 Sarbanes Oxley IRS Revenue Procedure 97-22 United Nations Model Law on Electronic Commerce FDA Part 11 Records Management through SOA is an idea whose time has come for everyone.

  29. Resources • The Object Management Group: http://www.omg.org/ • The Government Domain Task Force: http://gov.omg.org/ • The Interagency Project Team Report, “Functional Requirements, Attributes, and Unified Modeling Language Class Diagrams for RMS” : http://www.omg.org/cgi-bin/doc?gov/2006-09-13 • The Object Management Group’s Records Management Services Specification (Beta 1): http://www.omg.org/spec/RMS/index.htm • Home page of the RMS Finalization Task Force http://gov.omg.org/gov-ftf-rms.htm

  30. Questions?

More Related