journey of a soa service definer

30
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]

Upload: ull

Post on 06-Jan-2016

16 views

Category:

Documents


1 download

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 Presentation

TRANSCRIPT

Page 1: Journey of a SOA Service Definer

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

[email protected]

Page 2: Journey of a SOA Service Definer

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!

Page 3: Journey of a SOA Service Definer

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

Page 4: Journey of a SOA Service Definer

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.

Page 5: Journey of a SOA Service Definer

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

Page 6: Journey of a SOA Service Definer

… 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

Page 7: Journey of a SOA Service Definer

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.

Page 8: Journey of a SOA Service Definer

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”

Page 9: Journey of a SOA Service Definer

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

Page 10: Journey of a SOA Service Definer

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

Page 11: Journey of a SOA Service Definer

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:

Page 12: Journey of a SOA Service Definer

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

Page 13: Journey of a SOA Service Definer

RMS Interagency Project Team

Participating Agencies

Page 14: Journey of a SOA Service Definer

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

Page 15: Journey of a SOA Service Definer

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

Page 16: Journey of a SOA Service Definer

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)

Page 17: Journey of a SOA Service Definer

One PIM Maps to Multiple PSMs

WSDLJAVA

C++DotNet

YadaYada…

Platform Independent Model Based on Business

Requirements

Platform Specific Models Based on

Technology

MAPPING

Page 18: Journey of a SOA Service Definer
Page 19: Journey of a SOA Service Definer

Services Defined

Page 20: Journey of a SOA Service Definer
Page 21: Journey of a SOA Service Definer

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">

Page 22: Journey of a SOA Service Definer

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.

Page 23: Journey of a SOA Service Definer

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.

Page 24: Journey of a SOA Service Definer

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

Page 25: Journey of a SOA Service Definer

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.

Page 26: Journey of a SOA Service Definer

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)

Page 27: Journey of a SOA Service Definer

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.

Page 28: Journey of a SOA Service Definer

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

Page 29: Journey of a SOA Service Definer

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

Page 30: Journey of a SOA Service Definer

Questions?