journey of a soa service definer
DESCRIPTION
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 [email protected]. The National Archives and Records Administration. - PowerPoint PPT PresentationTRANSCRIPT
Journey of a SOA Service Definer
Serving the Present, Intercepting the Future
Larry L. JohnsonTethersEnd Consulting
Co-Chair, OMG Government Domain Task ForceMember, OMG Board of Directors
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!
eGovernment Initiative Portfolios
• 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
Context of Presentation
• Not about Records Management, per se.– Just one example
• More about our experiences and lessons learned in Service Definition– 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.
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
assuring diversity – 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
… and End
• RMS CoP employed Model Driven Architecture (MDA) – For Platform Independent Service Definition– For mapping Service Definition to specific 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
In the Beginning… NARA and Others Realized• 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.
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 Federal
Service Oriented Architecture”
FederalServiceOriented
Architecture
The Nature of the Target Architecture
• Forward Looking– Envisioning emerging SOA
related best practices and technologies, and then…
– “Imagining an organization that has fully embraced and adopted the service oriented model.”
From the Practical Guide For Federal SOA
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
The Target Architecture
From the Practical Guide For Federal SOA
Can’t Change
Can’t Change
Can Change
“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.”
SOA Serenity:
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
RMS Interagency Project Team
Participating Agencies
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
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
TransformationTransformation
Platform Independent
Model
Platform Independent
Model
Platform SpecificModel
Platform SpecificModel
Automated TransformationAutomated
Transformation
MDA Tool
Model Driven Architecture
• Platform Independent Model (PIM) for Composable Services
– Service Contract: exact definition of available operations
– Information Sharing: common semantics
– The Hard Part!
• Automated Transformation for Provisioning Agility!
• Platform Specific Model (PSM) for binds to Target Environment
AutoMagical Transformatio
n
(Built into the MDA Tooling)
One PIM Maps to Multiple PSMs
WSDLJAVA
C++DotNet
YadaYada…
Platform Independent Model Based on Business
Requirements
Platform Specific Models Based on
Technology
MAPPING
Services Defined
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">
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.
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.
The new way: Records Management as an environment, realized through SOA
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.
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)
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.
Its Not Just Government
Records Management through SOA is an idea whose time has come for everyone.
NY Stock Exchange Rule 440
IRS Revenue Procedure 97-
22FDA Part 11
Sar
ban
es O
xley
United Nations Model Law on
Electronic Commerce
OSHA Part 1904
Security Exchange
Commission Rule 17a EPA Clean Air Act 40 CFR Parts 61 and 63
yada yada yada
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
Questions?