9 Apr 2010 DM2 WG Agenda1. News:

– FAC meeting this week– JAIWG Federated Data Exchange Pilots Progress– M3 Incorporation of IDEAS Meetings next week

2. New References: • Baseline: DM2 VDD v2.01.doc • DM2 WG Organizational and Meetings Information:

FAC_meeeting__04_06_2010__Announcement_Agenda__V__2.2.doc and FAC_meeting__04_06_2010_BL_V_1.1 wDoDAF.ppt

3. Review new Action Items (“unassigned”)• Start with AIs 507-509 needed for JFCOM Federated Data

Exchange Pilots4. Prioritization of 2.02 AI’s – in reverse order!5. Others:

– In queue but probably won’t have time to get to tomorrow:• 20 SoAML terms to compare to DM2 data dictionary• TBS from WG tomorrow

DM2 Adjustments (DODAF WG)

Many minor model updates Desired Effect structure Design reification and requirements

traceability International Defence Enterprise

Architecture Specification (IDEAS) alignment

XML Schema Description (XSD) Format Beginning absorption of latest OASIS &

Object Management Group (OMG) SoA concepts

UNCLASSIFIED 3

Action Item / Change Request

StatusQuantity

In Ver 2.00 231In Ver 2.01 68Consult IDEAS Group 12

Defer 102Unassigned 24In Progress for Ver 2.02 16

TOTAL 453

DODAF CM Plan (DODAF WG)

UNCLASSIFIED 4

• Annex A: DoDAF Meta Model (DM2) Working Group (WG)

• Annex B: DoDAF Working Group (WG)

5

DoDAF / DM2 CM Plan• Adopts terminology and process from EIA Standard 649, “National Consensus

Standard for Configuration Management” • Contents:

– Configuration Identification– Organizational Roles, Responsibilities, and Interactions, e.g.,

• DoDAF / DM2 Work Group– The DoDAF 2 Data TWG became the DoDAF / DM2 WG– This group has been meeting every Friday since 2007 and has over 190 members and a very extensive

collaboration and research site– DoDAF / DM2 CM Processes and Procedures, e.g.,

• Tracking of Change Requests• Monthly submission to FAC of Configuration Status Accounting Report (CSAR)

– DoDAF / DM2 CM Business Rules– DoD EA COI, e.g.,

• conduct of the DoD EA COI Data Management Working Group– DoDAF / DM2 Review of Federated Architectural Descriptions

Unassigned (New) AI’s• # Title• 476 Dispositional vs Categorical Properties• 477 SoAML Concepts• 478 OASIS SOA RAF Concepts• 479 Necessary and optional foundation elements in XML docs• 480 System vs Service • 481 Mandatory Service Descriptions and Ports• 482 Geostatoinary Point Type• 483 Region of World Type• 484 Project and Project Type have a TI and a PTI• 485 DesiredEffectWholeResourcePartType• 486 ARO as two couples• 487 Agreement constrains activityPerformedByPerformer• 488 Information Traceability to Data• 489 APBP redundancy with APUC• 500 Singleton Types• 501 Capability Phase <> Enterprise Phase• 503 Org/OrgType WP(T) Performer• 505 TV and StdV• 506 LocationType Measures• 507 TypeType…• 508 Forking under Conditions• 509 How to indicate methodology-dependent subclasses• 510 Coordinate AV-1 Defs with DARS• 511 How to categorize Arch Desc• 512 make the full inheritance taxonomy machine-accessible somehow, like in the XSD• 513 Partridge Services Questions & Comments• 514 M3 / LOK Questions and Comments• 515 Performer Flows and Tools• 516 Service Access to Resource or Performer• 517 Powertype Definition

2 Apr 2010 DM2 WG Agenda1. News:

– FAC– DoDAF (inc. DM2) CM Plan review– JAIWG Federated Data Exchange Pilots Progress

• JCSFL in DM2 DB and DM2 PES XML – J89 & APL, JACAE DM2• JMTs in DM2 DB, Services focus – J89 in EA UPDM XMI DM2 PES

DM2 SQL Server DB. OV-2 & SV-1 performer resource flows ARO– M3 Incorporation of IDEAS (LOK Questions)– MODAF Services Analysis

2. New References: • References and Research\State Machines\IDEAS-UPDM Email 2010-03.eml• References and Research\Services\MODAF Analyses\DM2 Benchmark.xls, Services -

again.doc• DM2 WG Organizational and Meetings Information\Questions and Issues summary.docx,

DM2_categorisation_rules.docx, ASRG_CONOPS__1-04-10__V_1 0 (2).pdf

3. Review new Action Items (“unassigned”)4. Prioritization of 2.02 AI’s – in reverse order!5. Others:

– In queue but probably won’t have time to get to tomorrow:• 20 SoAML terms to compare to DM2 data dictionary

– AI 507-509 – Greg and Dave to prep for Tuesday’s JAIWG

Key Cascading Is Not New – JCIEDM Example

AIRFIELD-TYPE

MILITARY-OBSTACLE-TYPE

BRIDGE-TYPE

TASK-FORMATION-TYPE

MILITARY-POST-TYPE

EXECUTIVE-MILITARY-ORGANISATION-TYPE

MILITARY-ORGANISATION-TYPE

PRIVATE-SECTOR-ORGANISATION-TYPE

GROUP-ORGANISATION-TYPE

GOVERNMENT-ORGANISATION-TYPE

CIVILIAN-POST-TYPE

EQUIPMENT-TYPE CONSUMABLE-MATERIEL-TYPE

CONTROL-FEATURE-TYPE

GEOGRAPHIC-FEATURE-TYPE

UNIT-TYPE

OBJECT-TYPE

FACILITY-TYPE MATERIEL-TYPE

ORGANISATION-TYPE

PERSON-TYPE

FEATURE-TYPE

AIRCRAFT-TYPE

ENGINEERING-EQUIPMENT-TYPE

ELECTRONIC-EQUIPMENT-TYPE

MISCELLANEOUS-EQUIPMENT-TYPE

WEAPON-TYPE

CBRN-EQUIPMENT-TYPE

RAILCAR-TYPE

VEHICLE-TYPE

VESSEL-TYPE

BIOLOGICAL-MATERIEL-TYPE

CHEMICAL-MATERIEL-TYPE

RADIOACTIVE-MATERIEL-TYPE

AMMUNITION-TYPE

ROUTE-TYPE

SURFACE-VESSEL-TYPE

SUBSURFACE-VESSEL-TYPEMARITIME-EQUIPMENT-TYPE

HARBOUR-TYPE

Key Cascading Is Not New – More JC3IEDM

RADIOACTIVE-EVENT

NUCLEAR-EVENT RADIOLOGICAL-EVENT

CHEMICAL-BIOLOGICAL-EVENT

NUCLEAR-WEAPON-EVENT

ACTION-TASK-STATUS

ACTION-EVENTACTION-TASK

ACTION

ACTION-EVENT-STATUS

CBRN-EVENT

ACTION-EVENT-DETAIL

DM2 Superclass Association Rough Rules (LOK)

• Rule:• Elements categorized as "if" or "df" cannot be used in any view directly. The above elements are therefore excluded from direct use.• Rule:• Elements categorized as "ifo" or "dfo" can however be used directly within views:• Rule:• All elements that descend from Type can have subtypes of the same kind as the original element itself (superSubtype principle). (It should

be noted that IndividualType descends from Type, i.e. this principle also applies to all that descend from IndividualType.)• Rule:• All elements that descend from IndividualType can have whole-parts of the same kind as the original element itself (WholePartType

principle).• Rule:• All elements that descend from Individual can have whole-parts of the same kind as the original element itself (wholePart principle).• Rule:• All elements that descend from Type can have instances of themselves created based on instantiation provided that these instances have

already bee recognised as distinct elements within DM2. (This is a form of deviation from the general principle and would imply that there could never be an instance of Capability in a DM2 compliant model unless an IndividualCapability element turned up in the DM2 model. It could be argued that this principle would automatically be applicable if typeInstance was placed in the "if" category. This may have unfortunate consequences for PES however.)

• Rule:• A Name element can be attached to anything by means of namedBy (namedBy principle).• Rule:• An Information element can be attached to anything by means of describedBy (describedBy principle).• Rule:• A representation element can be attached to anything by means of representedBy (representedBy principle).• Rule:• A beforeAfter relationship can be created between any elements that descend from Individual (beforeAfter principle) that are of the same

kind. (The same kind restriction does not follow explicitly but represents an imposed constraint.)• Rule:• A BeforeAfterType relationship can be created between any element that descend from IndividualType (BeforeAfterType principle) ) that

are of the same kind. (The same kind restriction does not follow explicitly but represents an imposed constraint.)• Rule:• An overlap n-ary relationship can be established between elements that descend from Individual (overlap principle) that are of the same

kind. (The same kind restriction does not follow explicitly but represents an imposed constraint.)• Rule:• An OverlapType n-ary relationship can be established between any items that descend from Type (OverlapType principle) that are of the

same kind. (The same kind restriction does not follow explicitly but represents an imposed constraint.)

Partridge Services

Analysis for MODAF

Service: A mechanism to enable access to a set of one or more capabilities , where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a Performer.

There is no mandatory link between a service and much else. Why is there not a link to ServicePort? It seems to me that ServicePort is dependent upon Service. Is this just an oversight? I understand that ServicePort is introduced to allow for a ServiceDescription.

There seem to be (at least) three useful senses of Service:1) The set of potential and actual uses of the service by a ServiceConsumer.2) The set of potential and actual uses of service that conform to a specification.3) An implementation of the specification - of which there can be many. The set of potential and actual uses of service that conform to a specification provided by a ServiceProvider's implementation.

The OASIS description here would seem to intend sense 3).However, this can exclude multi-implemented Services - hence MoDAF uses sense 2).However, both sense 2) and 3) are parasitic on sense 1).

Note: Having Performer as a super-type of Service seems to exclude sense 2), as the fusion of multiple implementations would not fit the performer profile.

ServiceContract [New]: Not in DM2 - candidate. What motivates leaving this out?ServiceDescription: Information necessary to interact with the service in such terms as the service inputs, outputs, and associated semantics. The service description also conveys what is accomplished when the service is invoked and the conditions for using the service.

Potential representation issue: Do you provide a description of these or a description of a description of these?The link to ServicePort suggests that this is where the process of interacting with the ServicePort is described. Is it there somewhere the desired effect is described?There appears to be a possibility of misunderstanding, as this describes the ServicePort rather than the Service.

serviceEnablesAccessToResource: An overlap between the Service mechanism and the Performer capabilities it provides access to

Given the goal is a desired effect, rather than than the resources, is this describing the service or its implementation?

ServiceLevel: A measurement of the performance of a system or service.

Not on service diagram. This appears to have no links to Service. The links are at the higher Measure level. Is there intended to be a link?

ServicePort: A part of a Performer that specifics a distinct interaction point through which the Performer interacts with other Performers. This isolates dependencies between performers to particular interaction points rather than to the performer as a whole.

There does not seem to be any link to a Service here. One would expect that a Service Port was a Port that linked to a Service.

servicePortDescribedBy: A tuple that asserts that Information describes a Thing.

Typo [Text is a bit irrelevant - duplicates its parent]. Only a ServicePort has a description, not a service. What motivates this?

Must have Service End Point

MODAF Services AnalysisOASIS-RM[1] TOG-SO SoaML

a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.

A logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports). It is self-contained, may be composed of other services, and is a “black box” to its consumers. (TOG-SSB also includes a second (different) definition: “A service is a repeatable activity that has a specified outcome”[2]. This effectively moves the definition down a level of representation.OASIS-RAF has no direct definition of a Service.)

Service is defined as a resource that enables access to one or more capabilities. Here, the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. This access is provided using a prescribed interface and is exercised consistent with all constraints and policies as specified by the service description. A service is provided by an entity - called the provider - for use by others. The eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider. Identifies or specifies a cohesive set of functions or capabilities that a service provides.

[1] The OASIS-RM definition is used in DM2 and noted in M3.

What is odd in SoaML’s case, is that it appears to have two layers of access. There is a ServicePoint (see below) that provides access to the service and then the service that provides access to the resource – see the figure below.. It is not clear what the motivation for this is (apart from conforming to the UML MetaModel). Until a good motivation is provided. SoaML 7.3.11

ServicePoint A ServicePoint is the offer of a service by one participant to others using well defined terms, conditions and interfaces. A ServicePoint defines the connection point through which a Participant offers its capabilities and provides a service to clients. Description A ServicePoint is a mechanism by which a provider Participant makes available services that meet the needs of consumer requests as defined by ServiceInterfaces, Interfaces, and ServiceContracts. A ServicePoint is represented by a UML Port on a Participant stereotyped as a “ServicePoint.”

MODAF Services Analysis

CapabilityNegotiation, agreement (establishment of execution context)

CapabilityCapability

Service Consumer

Service Port Description, e.g., Methods, Functions, Activities, …

SequencingMetrics

Rules

Access to Capabilities

ServiceProvider

Service P

ort

Service P

ort

Service

UPDM Sample Work Using Hotel Room Service System Example

Discovery includes not just the port, but other capabilities trying to get access to

Hidden part – not described?

SoA Service – performs activity of access to capabilityBusiness Service --

CapabilityNegotiation, agreement (establishment of execution context)

CapabilityCapability

Service Consumer

AMC and AMP Descriptions, e.g., Methods, Functions, Activities, …

SequencingMetrics

Rules

Access to Capabilities

AMProvider

AM

P P

ort

AM

C P

ort

Access Mechanism

Service = Access Mechanism?

Discovery includes not just the port, but other capabilities trying to get access to

Hidden part

Resource3Resource2Resource1

Access to Resources

Resource 4-6 Consumer / 1-3 Provider

AM

Port

AM

Port

Bi-laterals?

Discovery includes not just the port, but other capabilities trying to get access to

Hidden part

Resource6Resource5Resource4

Negotiation, agreement (establishment of execution context)

AMC and AMP Descriptions, e.g., Methods, Functions, Activities, Sequencing, Metrics,

Rules, …-- at varying levels of reification

Resource1-3 Consumer / 4-6 Provider

Access Mechanism

Hidden part

New AIs• # Title• 476 Dispositional vs Categorical Properties• 477 SoAML Concepts• 478 OASIS SOA RAF Concepts• 479 Necessary and optional foundation elements in XML docs• 480 System vs Service • 481 Mandatory Service Descriptions and Ports• 482 Geostatoinary Point Type• 483 Region of World Type• 484 Project and Project Type have a TI and a PTI• 485 DesiredEffectWholeResourcePartType• 486 ARO as two couples• 487 Agreement constrains activityPerformedByPerformer• 488 Information Traceability to Data• 489 APBP redundancy with APUC• 500 Singleton Types• 501 Capability Phase <> Enterprise Phase• 503 Org/OrgType WP(T) Performer• 505 TV and StdV• 506 LocationType Measures• 507 TypeType…• 508 Forking under Conditions• 509 How to indicate methodology-dependent subclasses• 510 Coordinate AV-1 Defs with DARS• 511 How to categorize Arch Desc• 512 make the full inheritance taxonomy machine-accessible somehow, like in the XSD

26 Mar 2010 DM2 WG Agenda1. News:

– FOSE (Federal Office Supply Expo) • AFCEA, NDIA, Service, Combatant Command, and Agency Events (e.g., Marine Corps in

Baltimore), MORS, M&S forums, SSTC, • Outreach schedule – on hold; Mike is POC

– OMG Technical Mtg Jacksonville• Support BPMN RFP for UML profile (Fatma)• Services model; questions cc Rex and Dave Ellis – send email to UPDM team of OASIS and SoAML

resources POC• Mapping DMM to MODAF and DM2. Good understanding of differences between UPDM and DM2.

DMM ~ 90%. Schedule DMM agenda item.• State Machines. Ian Bailey’s email to Graham at Long Beach. Antoine’s traffic light example. Dave

put all info in State Machine folder in R&R.– Related SoA pre-conditions and decision branches for executable architectures.– Inverse relationship between state machines and activity

• Questions about necessary and optionals in Model X DM2 matrix2. New References:

• WG Files\DM2 CMP 2010-03-17.doc3. DM2 CM Plan Draft Overview

• Question about CR’s entered on DoDAF websites – ASRG or DoDAF WG• http://cio-nii.defense.gov/sites/dodaf20/

4. Review new Action Items (“unassigned”)5. Prioritization of 2.02 AI’s – in reverse order!6. Others:

– In queue but probably won’t have time to get to tomorrow:• 20 SoAML terms to compare to DM2 data dictionary

– TBS by WG

Architecture Standards

Management

ASRG

DoD CIO Executive Board

Direct Reporting Compliance/Coordination

CIO/C4

Architecture & Standards Review Group

Chairs: Dir, Enterprise Architecture & Standards

& DISA CSE (GES-E)

Enterprise Guidance BoardChair: DoD DCIO

IA Enterprise Review Group

Chair: PD DASD CIIA

Information Assurance Senior Leaders

Chair: DASD (CIIA)

DoD CIO

• IA Architecture approval and engineering guidance

• IA Standards and configuration management

• Assure integration and compliance of capabilities & solutions

• ES strategic planning, policy & implementation

• Data/Service strategies coord• Solution synchronization• Information sharing• Service registries• Interoperability • ES to tactical edge

• Compliance/Enforcement of Net Ops/Operational IA (policy, guidance)

• GIG certification & accreditation • Compliance/Enforcement of

sustained operations through:- Configuration management- Architecture- GIG Waivers- Operational connections process- Test & integration- Interoperability and supportability

• Architecture approval at the enterprise level

• Manage architecture federation• Define architecture compliance

criteria• Maintain authoritative sources of IT

standards and implementation-level specifications

Enterprise Operations Oversight Committee

Chairs: Dir, Enterprise Operations & STRATCOM

Rep

• Vision high level interpretation & compliance• “Top cover”• Recommends directly to the DoD CIO• “Tie breaker”• Escalated problem resolution

•DoD CIO vision interpretation,strategies & policies

•Capability architectures approval•Acquisition oversight (Non-MAIS & MDAP)•DBSMC Cert/IRB•Issue adjudication • IA policy and

guidance• GIAP guidance

Enterprise Services Review Group

Chairs: DISA (PEO GES); Dir,

Enterprise SvcsIntegration; DNI

DCIO

DM2 WG Duties Assigned by ASRG Guidance Document

• Configuration Management (CM) of the DM2• Data management for the DoD EA COI (DMWG)• Review of architectural descriptions for suitability for

federated data exchange.

CM WGs Report to FAC

DM2 WG (= DM2 CM Body) Reports to FAC

DM2 WG

•Govt•Military• Industry•Academia•vendors

FAC

DM2 CRsCOI Guidance

Architectural Description Review TasksDM2 Baseline Release Direction

DM2 CSARCOI Metrics and Progress ReportArchitectural Description ReviewsDM2 Baseline Release Request and Status

DoDAF WG

DARS WG

Referred CRs Referred CRs

COI Coordination

Groups• DoD MDR WG• DoD COI Forum

Vendors• EA/ITA Tool• M&S• Data Analysis• Repository• Data Integration

Data Exchange

• Pilots• Early Adopters• Federation

Framework & Ontology Groups

• OMG / INCOSE / NDIA

• IDEAS / NAF• UCORE• Enterprise

Vocabularies

Core Process Stakeholders

• CJCSI revs• AT&L SoSE & Acq

Reform• Combatant

Command architectures

• CPM Governance• PA&E

Change Requests to ASRG Routing to WG’s

DM2 AI/CR Processing

A.1

Enter into DM2 AI System

A.9

Implement Solut ionA.8

Bri ef Results and Discuss

A.7

Establish New Baseline

A.6

Reserach AI and DeviseSolutions

0

A.5

Maintain and ReportConfiguration Status

A.4

Mainta in CI Data

A.3

Conduct DM2 WG

A.2

Schedule DM2 WG

CSAR

CSAR

Agenda, Minutes, Read-Aheads, and New R&R Locations

CSAR

New Baseline CI Data Items

Developmental Version

Updated CI

Ujpdated Status and CoA in Past Tense

Directed Solution

New R&R, Updated CoA, Solutions Brief

AI CoA and Actionees

Agenda, Minutes, Read-Aheads, and New R&R Locations

AI DB Update

Routed CR Submitted AI

No Output!

DM2 Configuration

Items

New (“unassigned”) AI’s• 179 Performer vs CapabilityConfiguration• 470 Person WPT• 471 ServiceDescription desribes ServicePort, not Service• 476 Dispositional vs Categorical Properties• 477 SoAML Concepts• 478 OASIS SOA RAF Concepts• 479 Necessary and optional foundation elements in XML docs• 480 System vs Service • 481 Mandatory Service Descriptions and Ports• 482 Geostatoinary Point Type• 483 Region of World Type• 484 Project and Project Type have a TI and a PTI• 485 DesiredEffectWholeResourcePartType• 486 ARO as two couples• 487 Agreement constrains activityPerformedByPerformer• 488 Information Traceability to Data• 489 APBP redundancy with APUC• 500 Singleton Types• 501 Capability Phase <> Enterprise Phase• 502 Performer in XML• 503 Org/OrgType WP(T) Performer• 505 TV and StdV• 506 LocationType Measures• 507 TypeType…• 508 Forking under Conditions• 509 How to indicate methodology-dependent subclasses

4. Design Reification and Requirements Traceability

time

Thing

WorkerTechnicianEngineerArchitectStrategic Executive

Architectural Description

Architectural Description

Pedigree(requirements)

Op Rqmt TLR SLR A-Spec B-Spec C-Specs IOC

Architectural Description

Architectural Description

Architectural Description

describesdescribes

describesdescribes

describes

Pedigree(requirements)

Pedigree(requirements)

Pedigree(requirements)

Pedigree(requirements)

Rules

constrain

Rules

constrain

Rules

constrain

Rules

constrain

Rules

constrain

CBA ICD AoA Perf Spec CDD CPD

Got this one for free too!

Ad-hoc nominees for 2.02 Prioritization• Services model

– pre-conditions and execution context– Implementation level vs higher-level of DoDAF/DM2 so you don’t have

to be compliant with potentially conflicting services models– OASIS SoA RAF – governance, modeling-of, whether policies allow you

to use the service, higher level than SoAML messages. Relevant to JCIDS

• Command Relationships• Capabilities Dependencies• DoDAF implicit methodology• Intersection (for concept mapping)• M&S Support• Superclass usage (e.g., PersonType cannot WPT PersonType)• Subtype completions• CONOPS / OPLANS / COMMPLANS mapping• IFO/DFO legend• RDFS/OWL for info sharing with FBI, including policy issues –

possibly related to UCORE & NIEM

19 Mar 2010 DM2 WG Agenda1. News:

– 2.01 DoDAF web page status– Integrated EA Conference– UPDM Meeting in London – superclass association rules– IDEAS, M3, and NAF– FOSE

2. New References: • Tutorials and Briefings

• DM2-IDEAS 2010-02-27.ppt• DoDAF2_Plenary 2010-02-26.ppt• PES Examples\UPDM SAR

3. DM2 SQL Script4. DoDAF CM5. Review new Action Items (“unassigned”)6. Others:

– In queue but probably won’t have time to get to tomorrow:• 20 SoAML terms to compare to DM2 data dictionary• Prioritization of 2.02 AI’s – in reverse order!

– TBS by WG

Implementation of the International Defence Enterprise Architecture Specification (IDEAS) Foundation in DoD

Architecture Framework 2.0

9 MARCH 2010DAVE MCDANIEL

Contractor, Enterprise Architecture & StandardsOffice of the DoD Deputy Chief Information Officer

+1 (619) 253-9040 davem@silverbulletinc.com

See tutorials and briefings/DM2-IDEAS 2010-02-27.ppt for full briefing

5 Mar 2010 DM2 WG Agenda1. News:

– 2.01 is Baselined! (Greg – date stamping on working copy, version stamping on baselines)

– Plenary, preparation for EA Conference– Integrated EA Conference / UPDM / IDEAS next week– FOSE– NATO DM2 and IDEAS

2. New References: bibliography updated3. Prioritization of Action Items for 2.024. Review new Action Items (“unassigned”)5. Others:

– In queue but probably won’t have time to get to tomorrow:• 20 SoAML terms to compare to DM2 data dictionary• Measures and rules example – Dryer example

– TBS by WG

19 Feb 2010 DM2 WG Agenda1. News:

– FEAF -> FSAM, a common metamodel at OMG mssa– DoDAF Plenary 26 Feb at MITRE McLean– DoDAF session at FOSE Mar– 2.01 progress – QA done; XSDs in progress; documentation updates – CDM, LDM, PES, VDD; MDR,

deprecate 2.00; provide documentation to DoDAF HTML to update DKO and special publically avail DoDAF site – due 28 Feb

– W3C e-gov outreach for data architecture publishing as web artifacts – coord with COI Forum and MDRWG

2. New References:– \References and Research\Services\Open Group SOA Ontology\soa-ontology-200-draft.pdf– \References and Research\Services\Open Group SOA Ontology\draft200.xml (OWL version)– \References and Research\C2\C2 Core

3. Service Description as subtype of Architectural Description – ready for 2.01 or hold off till further study (AI # 365)• Concern about space between interface description model and action model, description model leaves out

details that might need to be referenced in the action model. Don’t want DoDAF to be so low level that policies like GTG are obscured. Evaluation of specific policy statements.

4. 2.01 new XSD walkthru• CUI• Measure Example – SV-7 from UPDM S&R

5. Prioritization of Action Items for 2.02, which resumes next WG• Dependencies, Conditions and Rules, -- see last slide for today for ad-hoc nominees

6. Others:– In queue but probably won’t have time to get to tomorrow:

• 20 SoAML terms to compare to DM2 data dictionary• Measures and rules example – Dryer example

– TBS by WG

IDEA for Service Description Structure

SvcV-2SOV-2 [Architectural Description] SAR Services [1]

«Interface»Search Interface

«ServiceInterface»Maritime Search and Rescue Service

«ServiceInterface»Search and Rescue Service

InitiateSearch (in missingPersonInfo, out searchCaseID)RequestSearchUpdate (in searchCaseID, in status)CancelSearch (in searchCaseID, in reason)

«Interface»Maritime Rescue Interface

RescuePerson (in strandedPersonInfo)

«Interface»Fire Service Interface

RescuePerson (in trappedPerson)

«Interface»Helicopter Service Interface

TransportCasualty (in patientInfo, in transportedTo)

«Interface»Rescue Interface

InitiateRescue (in strandedPersonInfo, out rescueCaseID)

Search Interface

Recue Interface

Maritime Rescue Interface

Helicopter Service Interface

Fire Service Interface

SvcV-2 [Architectural Description] SAR Services [1]

Search SD

Maritime Search and Rescue ServiceSearch and Rescue Service

InitiateSearch

Maritime Rescue SD

RescuePerson

Fire Service SD

RescuePerson

Helicopter SD

TransportCasualty

Rescue SD

strandedPersonInfo

Recue Interface

Makes available descriptions of how to use the S&R Service

Legend:

Services

Subtypes

missingPersonInfo

searchCaseID

RequestSearchUpdate CancelSearch

ActivitiessearchCaseID searchCaseIDreason

Information

Service Descriptions

Resource Flow

InitiateRescue

rescueCaseID

patientInfotransportedTo

strandedPersonInfo

trappedPerson

Uses descriptions of how to use the different S&R performer types

status

Part of

• Service Description <> Service Interface Description

• UPDM used lowest level of SoAML

• Process model for service, preconditions,

• Connotations vs. Denotations

Ken Laskey OASIS SoA RAF Overview (on DM2 site)

XSD format

XSD format

XSD format

12 Feb 2010 DM2 WG Agenda

• News:– EA Conference reservations– 2.01 progress – XSD walkthru next WG, perhaps topic on 22nd UPDM– C2 Core at JFCOM J87 – how to maintain cognizance (Dryer and

McDaniel via Paul Shaw see how)• New References:

– None pending submission by WG• Service Description as a subtype of Architectural Description• SoA Joint Action and Execution Context in DM2• In queue but probably won’t have time to get to tomorrow:

– 20 SoAML terms to compare to DM2 data dictionary– Measures and rules example – Dryer example from NCEM project– Prioritization of Action Items for 2.02

• Others:– TBS by WG– The Open Group SoA Ontology

class Roles for Joint Actions Mappi...

Speaker

Speaking-Action Listening-Action

Listener

Realizing SOAs::Communicativ e-Action

Actor

Joint-Action

Role

StakeholderParticipant

Authority

Action

«model»Social-Structure

Speaker-Role Listening-Role

Speaker Pre-conditions

Real-World-Effect

Listener Pre-Condition

Speaker-Authority Listener-Authority

Ev idence

Joint-Action RWE

The Speaker Authority is what permits Participation in the Comunication Action provided the necessary Pre-Conditons have been met. Each Step in the Choreography has different Pre-Conditions depending on the Social Structures(s) of the Speaker.

The Listener Authority is what permits Participation in the Comunication Action provided the necessary Pre-Conditons have been met. Each Step in the Choreography has different Pre-Conditions depending on the Social Structures(s) of the Listener.

The Speaker and the Listener exchange roles during the negotiation of Execution Context.

member of

performs

enables

performs

participatesparticipates

accumulated from

Enables

adopts

causes

Enables

Chapter 3 of RM

RealizationNeeds evidence to proceed to next action in choreography

ComposeabilityOrganizationalNon-repudiation through a systemOwnership

SvcV-3

SOV-3 [Architectural Description] SAR Services [2]

«Capability»Land SAR

«Capability»Maritime SAR

«ServiceInterface»Land Search and Rescue Service

«ServiceInterface»Maritime Search and Rescue Service

«Expose» «Expose»

CV-7CV-7

Mapping between capabilities and the services that these capabilities enable.

CV-7 [Architectural Description] SAR Services [2]

Land SAR

Maritime SAR

Land Search and Rescue ServiceMaritime Search and Rescue Service

NOTE 1: whole-parts and service port descriptions need not show up on CV-7

Legend:

Capability

Performer supports or provides Capability

Service

Land Search and Rescue Service Port

Land Search and Rescue Service Port

Description

Service Description

Part of1

Describes1

SvcV-3b Services-Services Matrix

SvcV-3a Relationships among between systems and services in a given architecture.

SvcV-3bRelationships among services in a given architecture; can be designed to show relationships of interest, e.g., service-type interfaces, planned vs. existing interfaces, etc.

Mar

itim

e SA

R Se

rvic

e

Land

SAR

Ser

vice

Helic

opte

r Ser

vice

Mar

itim

e Re

scue

Se

rvic

e

Fire

Ser

vice

Maritime SAR Service 1 3 3 1Land SAR Service 3 1 2Helicopter Service 3 1Maritime Rescue Service 1

Fire Service

Degree of interaction between services:0 - none1 - low2 - moderate3 - high(symmetric matrix)

Partial list of services

SvcV-4a

[Architectural Description] SAR Services [SOV-4a]

Name

Land Search and Rescue Service

Maritime Search and Rescue Service

Search and Rescue Service

Name Text

Driving Record

Swim

First Aid

Danger

Any member involved in the operation of road vehicles must have a clean driving record.

All members of the rescue team must be able to swim.

All members of the rescue team must be able to perform basic first aid.

No member of the search and rescue team should put themselves in unnecessary danger.

Service Interface Service Policy

SvcV-10a Services Rules ModelSvcV-10a [Architectural Description] SAR Services

Name

Land Search and Rescue Service

Maritime Search and Rescue Service

Search and Rescue Service

Name Description

Driving Record

Swim

First Aid

Danger

Any member involved in the operation of road vehicles must have a clean driving record.

All members of the rescue team must be able to swim.

All members of the rescue team must be able to perform basic first aid.

No member of the search and rescue team should put themselves in unnecessary danger.

Services Rules

Rule constrains the Activities performed by

Performers that are part of the Service

Legend:

Services

Rules

SvcV-10aOne of three models used to describe service functionality - identifies constraints that are imposed on systems functionality due to some aspect of systems design or implementation

SvcV-5SOV-5 [ServiceFunction] Rescue Person

«ServiceFunction»Rescue Person

«UnmarshallAction»Unmarshall Stranded Person Info

strandedPersonInfo

Reported.

strandedPersonInfo

«ServiceFunctionAction»: Recover Victim

«ServiceFunctionAction»: Reassure Victim

location name

location name

«ServiceFunctionAction»: Apply First Aid

condition

condition

«ServiceFunctionAction»: Transport Victim

locationcondition

«WriteStructuralFeatureAction»Update Condition

object value

«WriteStructuralFeatureAction»Update Location

value object

Updated.

DCO Log• Cory - guest: (11:52) From SoaML: A ServiceContract is the

specification of the agreement between providers and consumers of a service as to what information, products, assets, value and obligations will flow between the providers and consumers of that service – it specifies the service without regard for realization, capabilities or implementation. A ServiceContract does not require the specification of who, how or why any party will fulfill their obligations under that ServiceContract, thus providing for the loose coupling of the SOA paradigm. In most cases a ServiceContract will specify two roles (provider and consumer) – but other service roles may be specified as well. The ServiceContract may also own a behavior that specifies the sequencing of the exchanges between the parties as well as the resulting state and delivery of the capability. The owned behavior is the choreography of the service and may use any of the standard UML behaviors such as an interaction, timing, state or activity diagram.

• Cory Casanave - guest: (11:44) In summary - sure a service description is an arch description - as is most everything in a dodaf model

05 Feb 2010 DM2 WG Agenda

• News:– UCORE, DON CIO, and SPAWAR (NARS and NAERG) at AFCEA West

• NIEM conference – UCORE primarily for display, doesn’t deal with more complex issues. OASIS EDXL-DE addresses additional questions, e.g., choreography.

• Are there samples of data?– 2.01 progress – XSD style– C2 Core at JFCOM J87 – how to maintain cognizance (Dryer and McDaniel via

Paul Shaw see how)• New References:

– None pending submission by WG• SoA Joint Action and Execution Context in DM2

– Ken Laskey & Conrad Bock re Joint Action and OV-4, why UML can’t model yet UPDM 2.0 & DM2

– UPDM Search and Rescue (SAR) SvcV examples (see UPDM references folder for complete document) walkthru and markup to align with OASIS RAF, SoAML, and DM2

• In queue but probably won’t have time to get to tomorrow:– 20 SoAML terms to compare to DM2 data dictionary– Measures and rules example – Dryer example from NCEM project– Prioritization of Action Items for 2.02

• Others:– TBS by WG

Buy Item (e.g. legally Own)• Case 1: Fatma’s Flea Market Inc has pre-negotiated contract with SilverBulletInc.• Case 2: Fatma’s sign states Cups, $4.00, non-negotiable, cash only. (WSDL)• Case 3: Participants policies and RFI, RFQ, RFP (WSDL with many Operations)

– What’s for Sale? (Product inquiry – RFI) Red Items are Shared State.– Cups (RFI response)– How much? (Price Quote –RFQ)– $4.00 (RFQ response)– I will give you $2.00? (Purchase negotiation) Note 1– I won’t go lower than $3.00 plus Tax (Response) Note 2 and 3– Will you take credit card or cash only? (RFP inquiry) Note 4– That will be $3.12 cash (RFP response)– Dave hands cash to Fatma– Fatma hands Cup to Dave

• If Alcohol (license and ID), Firearm (Background Check), Car/House (Title)• Notes

– 1. Dave’s policy is to get product for lowest price– 2. Fatma’s policy is to make at least 10% profit– 3. City/State policy is to tax transaction (This may be illegally omitted)– 4. Fatma’s policy is to only accept credit fro previously vetted customers

Legacy Combat System Analog

• What happens as a result, including “real-time” mini-negotiations

• Systems exchange data on AEGIS ships using real-time communications

– “real-time” negotiations (e.g., RTT’s, ACK’s, …)

DoD Policies -> Navy&DON Policies -> PEO-IWS Policies -> IWS-6 – PMS-400 MOA -> IDS IPT Rules of Conduct -> Software Engineering & Tesing Rules -> Communications Handshakes -> Information Exchange

• Program Manager A’s policy is such and such

• Program Manager B’s policy is such and such

More notes• Condition as in DM2 may not = as in here• Can be multiple levels of negotiation, e.g., as in OSI levels• Higher up negotiation layers are further out projection of something

happening in the future• Negotiations are other services that are part of the overall service• Partner selection, e.g., whether to select Tom’s Boat Tow or CG.

(What• Criteria, pre-conditions, Conditions, post-conditions, pre-requisites,

rules, …

UJTL Condition Top-Level TreeApply to Tasks, to say Task must be

performed under

SvcV-1

SOV-1 [Architectural Description] SAR Services

«ServiceInterface»Search and Rescue Service

«ServiceInterface»Maritime Search and Rescue Service

«ServiceInterface»Land Search and Rescue Service

29 Jan 2010 DM2 WG Agenda

• News – – Tidewater Outreach -- – 2.01 progress – XSD format– UPDM DoD Mtg– C2 Core at JFCOM J87 – how to maintain cognizance (Snyder, Dryer see how)

• New References– References and Research\MDWG– References and Research\DoD COI Forum– Simple Knowledge Organization System (SKOS) for controlled vocabularies?– TDAN?

• SoaML and OASIS SoA RAF -- Joint Action, Contracts, Agreement, Rules– OASIS RAF points to consider– SoAML points to consider– UPDM Search and Rescue (SAR) SvcV examples– 20 SoAML terms to compare to DM2 data dictionary

• Prioritization of Action Items for 2.02• Others –

– TBS

Cory - guest: (11:52) • From SoaML: A ServiceContract is the specification of the

agreement between providers and consumers of a service as to what information, products, assets, value and obligations will flow between the providers and consumers of that service – it specifies the service without regard for realization, capabilities or implementation. A ServiceContract does not require the specification of who, how or why any party will fulfill their obligations under that ServiceContract, thus providing for the loose coupling of the SOA paradigm. In most cases a ServiceContract will specify two roles (provider and consumer) – but other service roles may be specified as well. The ServiceContract may also own a behavior that specifies the sequencing of the exchanges between the parties as well as the resulting state and delivery of the capability. The owned behavior is the choreography of the service and may use any of the standard UML behaviors such as an interaction, timing, state or activity diagram.

Service Choreography for “Place Order”

The role of the consumer (a participant that places orders) and the consumers interface

The role of the provider (an order taker) and their interface

The optional interaction to request a quoteThe optional interaction to return

the quote

The required interaction to place an order

The required interaction to accept or reject the order

A more detailed look at the same service. Note that this models a fully asynchronous SOA – like most business interactions, the document message types are detailed on the next page.

From References and Research\SOAML\SOAMLDM2.ppt

Pre-conditionsWillingness factors before proceeding step in the choreography (may or may not be orchestrated)

Rules

Execution context (SoA RM)Rules

Concept of “Joint Action” (or interface)

From References and Research\SOAML\SOAMLDM2.ppt

WSDL typically has multiple operationsJoint Action not in current SoAML spec

Separate action: Application of intent to achieve an effectJoint Action is coordinated, involves two or more actors

“Authority Vectors”

(in References and Research\OASIS SOA)

deployment Nodes

«executionEnvironment,USPolicy»United States

«executionEnvironment,S2Policy»State Two

«executionEnvironment»county Three

«executionEnviron...City Three

«device»Edge SPOR3

«executionEnvironment,S1Policy»State One

«executionEnvironment,C1P...County One

«executionEnvironm...City One

«device»Edge SPOR1

«device»Edge SPOR4

«executionEnvironment»County Two

«executionEnvironme...City Two

«device»PublSub1

«device»Sub1-EAS

«device»Pub1-Sensor

«device»PubSub2

«device»PubSub3

«device»Sub2-EAS

«device»Edge SPOR2

«device»Edge SPOR5

«device»Edge SPOR7

«device»Edge SPOR6

«device»Edge SPOR8

«device»PubSub4

«device»PubSub5

«device»Edge SPOR9

«device»PubSub6

«device»PubSub8«device»

PubSub7

«device»Pub2-President

«device»PubSub10

«device»PubSub9

«device»Sub3-EOC

Deliver«Flow»

Deliver «Flow»

Inject«Flow»

Exchange

«Flow»

Exchange

«Flow»

Exchange

«Flow»

Exchange

«Flow»

Report«Flow»

Distribute«Flow»

Distribute

«Flow»

Report«Flow»

Report

«Flow»

Exchange

«Flow»

Distribute«Flow»

Report

«Flow»

Deliver

«Flow»

Inject

«Flow»

Deliver

«Flow»

Inject

«Flow»

USPolicies

«PolicyFlow»

StateOnePolicies

«PolicyFlow»StateOnePolicies

«PolicyFlow»

USPolicies

«PolicyFlow»

Report«Flow»

Distribute«Flow»

City Two

«PolicyFlow»

County One

«PolicyFlow»

County Two

«PolicyFlow»

Distribute

«Flow»

Distribute«Flow»

Deliver

«Flow»

Inject

«Flow»

Deliver

«Flow»

Deliver

«Flow»Inject

«Flow»

Exchange

«Flow»

Distribute«Flow»

Exchange

«Flow»

Report«Flow»

Deliver«Flow»

StateTwoPolicies

«PolicyFlow»Deliver

«Flow»

Distribute«Flow»

Report

«Flow»

StateTwoPolicies

«PolicyFlow»

StateOnePolicies

«PolicyFlow»

Exchange

«Flow»

City One

«PolicyFlow»

Report

«Flow»

Inject

«Flow»

Deliver

«Flow»

Deliver

«Flow»

Inject«Flow»

Inject«Flow»

Inject

«Flow»

Deliver«Flow»

Inject

«Flow»

Inject

«Flow»

Inject

«Flow»

Deliver«Flow»

Critical Factors Analysis of the Reference Architecture

From References and Research\OASIS SOA\OASIS SOA RAF CD 09-10-00015.000.pdf

Communication as Joint Action

From References and Research\OASIS SOA\OASIS SOA RAF CD 09-10-00015.000.pdf

class Roles, rights and Responsibilities

Participant

Social-Structure

RoleQualification

Authority

Right

- Transferable: boolean

Responsibility

Skill

Task Action

enables

adopts

has

possesses

defines

requires

member of

requires permits

ensurescompetence

requires

Ellis Input

From References and Research\OASIS SOA\OASIS SOA RAF CD 09-10-00015.000.pdf

15 Jan 2010 DM2 WG Agenda

• News – – DoDAF Outreach restarting

• Need to show how underlying data is coherent, e.g., OV’s related to CV’s. Perhaps submit to Journal after MITRE publish. Need to update 2.0.

• Dave send DoDAF CR and Journal submission location in next announcement– 2.01 progress – cleanup diagrams, defs in docs, model is in cleanup, Ian working on XSD generator for

mandatories and optionals. Casanave org uses MagicDraw XSD generation and open source modelPro tool – template approach.

– UCORE track at AFCEA West upcoming– C2 Core at JFCOM J87 – how to maintain cognizance (Snyder, Dryer see how)– DoD MDR WG – Dave download and put in references folder. Esp. Simple Knowledge Organization

System (SKOS) for controlled vocabularies. Also TDAN.– DoD COI Forum. Dave put in references folder

• New References– References and Research\OASIS SOA\OASIS SOA RAF CD 09-10-00015.000.pdf– References and Research\OASIS SOA\Rex RIM1.docx– References and Research\OASIS SOA\DM2-Discussion.pptx– References and Research\OASIS SOA\DM2-Effect.pptx– References and Research\OASIS SOA\wp_soa_navigate.1.1.docx– References and Research\Pedigree and ProvenanceIBMprovenance and reputation workshopfinala.doc

• SoaML– Overview of Joint Action, Contracts, Agreement, Rules

• Related to DM2 Action Items TBS– 20 SoAML terms to compare to DM2 data dictionary– Dave talk to Mike about a SoA breakout WG

• Prioritization of Action Items for 2.02• Others –

– Ken Laskey & Conrad Bock re Joint Action and OV-4, why UML can’t model yet UPDM 2.0 & DM2

UCORE• Core Community,• As we embrace the New Year, we wanted to reach out to each of you and provide an update on the latest UCore

news.  It was inspiring to meet so many of you in September at the First Annual UCore User's Conference, as presenters and participants.  It was great to hear about your engagements, adoption, and achievements.

• Since the UCore User's Conference, some noteworthy developments have occurred.  There are already 2400 registered members of the UCore website at http://ucore.gov <http://ucore.gov> .  These registrants are from across the Defense Department, Federal and state governments, as well as coalition partners, industry partners, and educational institutions.

• UCore has been approved for incorporation into the Department of Homeland Security (DHS) Enterprise Architecture Technical Reference Model and will be included in the pending update to the DoD Manual for Implementing Net Centric Data Sharing (DOD 8320.02M).

• There will be a full-day UCore track at the Department of the Navy Information Technology Conference Feb. 1- 4, 2010, at the San Diego Convention Center during AFCEA West.  The UCore track will be 3 February 2010.  During the afternoon, we would like to feature UCore community implementations and engagements across the UCore Community.  If you, or your team, would like to be considered to present during the UCore track next month, please register on the UCore website (https://ucore.gov <https://ucore.gov> ) under "DoN IM IT/AFCEA West - Be a Presenter".  To support our planning efforts, as a presenter, please register prior to Friday, 15 January 2010. You will be notified NLT Wednesday, 20 January 2010 whether or not you have been selected to present. 

• Online registration for this conference is now available. Attendees will also have the ability register in person at the convention center during the conference.  The Department of the Navy IT Conference is open to all DON, government, military and support contractor personnel.  No conference fee will be assessed for the DON IM/IT Conference, but registration is required.

• If you have questions about the conference, please contact the UCore Team at the feedback and support link on the UCore.gov website or via email at ucore-help@spawar.navy.mil.

• We look forward to the coming year as we increase UCore adoption and improve information sharing!• v/r• Clay Robinson• Office of the DoD CIO• Enterprise Services and Integration• Chief, Data Strategy• DoD Lead for UCore

class Serv ices -- Joint Action

IndividualType

Resource

Data

Materiel

IndividualType

Activity

PersonType

Performer

Property

Measure

+ numericValue: string

overlapTypeactivityResourceOverlap

Guidance

Rule

overlapTypeactivityPerformedByPerformer

Note the Activ ity that does the producing is typically different from the consumingactiv ity

i.e., Role

Representation

Information

Individual

Individua lResource

SystemOrganizationType

OrganizationService

IndividualPerformer

measureOfTypemeasureOfTypeActivityPerformedByPerformer

overlapTyperuleConstrainsActivityPerformedByPerformer

superSubtypeactivityResourceOverlapTypeInstanceOfRule

measureOfTypemeasureOfTypeActivityResourceOverlap

measureOfTypemeasureOfTypeResource

IndividualType

Condition

overlapTypeactivityPerformab leUnderCondition

PerformerCapableOfResponsibility

Services -- Joint Action

HandoverHandtakeTransfer

Handover Cash HandtakeHandover Cup Handtake

Handover WPT TransferHandtake WPT Transfer

representedBydescribedBy

servicePortDescribedBy DisclosurePoliciesInfo

AuthentificationInfo

CashCoffee Cup

BuyerSeller

DaveFatma

Indiv idualPerson

Handover performedBy BuyerHandtake performedBy SellerHandover performedBy SellerHandtake performedBy Buyer

«IDEAS:powertypeInstance»

«IDEAS:powertypeInstance»

consumer producer

descri ption

«IDEAS:powertypeInstance»

SoAML Initial Key Terms for DM2 Data Dictionary

From References and Research\SOAML\SoaML-defns

Agent An Agent is a classification of autonomous entities that can adapt to and interact with their environment. It describes a set of agent instances that have features, constraints, and semantics in common. Agents in SoaML are also participants, providing and using services.

2 a : something that produces or is capable of producing an effect : an active or efficient cause

Collaboration Collaboration is extended to indicate whether the role to part bindings of CollaborationUses typed by a Collaboration are strictly enforced or not.

3 : to cooperate with an agency or instrumentality with which one is not immediately connected

CollaborationUse CollaborationUse is extended to indicate whether the role to part bindings are strictly enforced or loose.

Milestone A Milestone is a means for depicting progress in behaviors in order to analyze liveness. Milestones are particularly useful for behaviors that are long lasting or even infinite.

2 : a significant point in development

Participant A participant is the type of a provider and/or consumer of services. In the business domain a participant may be a person, organization or system. In the systems domain a participant may be a system, application or component.

: one that participatesparticipate: to have a part or share in

something

Real World Effect A ServicesContract is used to model an agreement between two or more parties and may constrain the expected real world effects of a service.

A fulfillment,2 : something that inevitably follows an

antecedent (as a cause or agent)

Request (port stereotype) A Request represents a feature of a Participant that is the consumption of a service by one participant provided by others using well-defined terms, conditions and interfaces. A Request designates ports that define the connection point through which a Participant meets its needs through the consumption of services provided by others.

A request port is a “conjugate” port. This means that the provided and required interfaces of the port type are inverted; this creates a port that uses the port type rather than implementing the port type.

2 : something asked for <granted her request>

SoAML Initial Key Terms for DM2 Data Dictionary

From References and Research\SOAML\SoaML-defns

Capability A Capability is the ability to act and produce an outcome that achieves a result. It can. Specify a general capability of a participant as well as the specific ability to provide a service.

3 : the facility or potential for an indicated use or deployment <the capability of a metal to be fused> <nuclear capability>

Service A Service represents a feature of a Participant that is the offer of a service by one participant to others using well defined terms, conditions and interfaces. A Service designates a Port that defines the connection point through which a Participant offers its capabilities and provides a service to clients

2 a : the work performed by one that serves <good service>

ServiceContract A ServiceContract is the formalization of a binding exchange of information, goods, or obligations between parties defining a service.

Contract: 1 a : a binding agreement between two or more persons or parties; especially : one legally enforceable b : a business arrangement for the supply of goods or services at a fixed price <make parts on contract> c : the act of marriage or an agreement to marry2 : a document describing the terms of a contract

Service Interface Provides the definition of a service. Defines the specification of a service interaction as the type of a «Service» or «Request» port.

Interface:2 a : the place at which independent and often unrelated systems meet and act on or communicate with each other <the man-machine interface> b : the means by which interaction or communication is achieved at an interface

ServiceChannel A communication path between Services and Requests within an architecture.

Channel: d : a means of communication or expression: as (1) : a path along which information (as data or music) in the form of an electrical signal passes

SoAML Initial Key Terms for DM2 Data Dictionary

From References and Research\SOAML\SoaML-defns

Services Architecture The high-level view of a Service Oriented Architecture that defines how a set of participants works together, forming a community, for some purpose by providing and using services.

Consumer Consumer models the type of a service consumer. A consumer is then used as the type of a role in a service contract and the type of a port on a participant.

: one that consumesConsume: 5 : to utilize as a customer

Port Extends UML Port with a means to indicate whether a Connection is required on this Port or not 2 a : a harbor town or city where ships may take on or discharge cargo

provider Provider models the type of a service provider in a consumer/provider relationship. A provider is then used as the type of a role in a service contract and the type of a port on a participant.

: one that providesProvide:2 a : to supply or make available

08 Jan 2010 DM2 WG Agenda

• News – – SoAML – Dave/Greg get Fatma defs in list and also an AI for WG– DM2 PES Exemplars – Dave send Brad Cox the email copies example;

related to spatio-temporality of agreements, rules, specs, etc.– Others –

• headsup new ASRG version coming out• SoAML passed final adopted stage at OMG

• New References – none• Review planned 2.01 Action Items that made cutoff• DM2 PES XML Examples Work Update• Measures and rules example – Dryer example from NCEM project• Others -- TBD

Training and Education• T&E against actual persons issue• Rqmt –

– JCIDS FSA / AoA – looks like it’s the types of skills and qualifications required by a particular JCIDS alternative solution

• Certification – qualification – skill– Ops Planning – OPPLANs and COMMPLANs

• Related to DoDAF team AI• CONOPS – Capabilities

18 December DM2 TWG Agenda

• News – – DoDAF CM– Others SoAML Monday

• New References – M3 1.2 in M3 folder• Continue review planned 2.01 Action Items in

preparation for technical cutoff• DM2 PES XML Examples Work Update• Others

– measures and rules example – Dryer example from NCEM project – next TWG

Dave to take to Mike (#326)• Where to put DM2 PES Examples

– Journal – pro-easy to change; con-buried– MDR – pro-like CoT; – PES document (former Vol III) – part of alt 2 but not in .doc form– All of the above – pro-hits everybody; con-need sync’d– Others?

• What is the release plan schedule detail for 2.01?

Capability States or Model Metadata • Capability temporal parts

– Current– Next year– 10 years from now

• ArchitecturalDescriptions– Capability model (CV’s) that

are ArchitecturalDescriptions named “Current”

– Capability model that is “next year”

– Capability model that is “10 years from now”

Events (#330)• Declaration of completion• Causes reaction• Typically unsolicited or unexpected• Natural events• Recognition of the effect of the activity• Sufficiency to proceed• Use – OV-3 (trigger), OV-6bc, SV-6 (trigger), SV-10bc

– Activity1 causes activity2

342 Desired Effect in SoAIDEAS Capability

IndividualTypeCapability

IndividualType

Condition

IndividualType

Activity

Performer

Property

Measure

+ numericValue: string

WholePartTypeactivityPartOfCapabil ity

overlapTypeactivityPerformedByPerformer

WholePartTypedesiredEffectOfCapabili ty

BeforeAfterTypeactivityChangesResource

propertyOfTypecapabilityOfPerformer

overlapTypeactivityPerformableUnderCondition

Capability

WORKING DRAFT

WORKING DRAFT

measureOfTypemeasureOfTypeActivityPartOfCapability

measureOfTypemeasureOfTypeActivityPerformedByPerformer

measureOfTypemeasureOfTypeActivityChangesResource

measureOfTypemeasureOfTypeActivityPerformableUnderCondition

measureOfTypemeasureOfTypeCondition

IndividualType

Resource

IAN:

Capability can't be a powertype unless you tell me what it's a powertype of. Changed it to Type

Mapped Skill and Capability under dispositional property

Renamed capabil ityPerformerManifestation to capabili tyOfPerformer

renamed DesiredEffect to Effect

MeasureOfEffectmeasureOfType

effectMeasure

overlapTypedesiredEffect

MeasureOfDesire

I question whether a measure of the desire is part of JCIDS. I think a JCA, JCD, ... just says, this here Effect (effects measures on resource states) is desired.

Type

CapabilityType

desiredFutureResourceState

whole

desirer

supertype

desiredFutureResourceState

howMuchDesired

supertype

subtype

subtype

Example XML docs• Initial Source Material

– UPDM SAR example– TISP/ISP examples– NCES, other examples

• Tutorial• Guidance• Validation

326 Issue: include whole-parts, super-subs, overlaps, …

Org a Org bInfo A

Part-of info A

Part-of info A

Part-of Org aPart-of Org a

Act 1Act 2

Act 3Act 4

Info A is-a-type of some higher-level category

19 Mar 2010 DM2 WG Agenda1. News:

– 2.01 DoDAF web page status– Integrated EA Conference– UPDM Meeting in London – superclass association rules – similar to issues in

programming when crossing class inheritance boundaries• put Hotel Room Service System in ppt & screen cap the MD (Dave Mc)• Len Levine rescue example• Willingness factors and policies (Ellis)

– IDEAS, M3, and NAF – – FOSE (Federal Office Supply Expo) – Artisan / UPDM, DoDAF track

2. New References: • Tutorials and Briefings

• DM2-IDEAS 2010-02-27.ppt• DoDAF2_Plenary 2010-02-26.ppt• PES Examples\UPDM SAR – send Matthew DoDAF Team markups of UPDM 1 diagrams (Dave)

3. DM2 2.01 SQL Script• update for XML generation and storage and for cascading keys and also some example

data – DB and XML (Greg)• Issue that generated XML doesn’t match XSD, e.g., Activity in DM2 PES, service does

Activity ID’s differently, more specific tagging, via WSDL. Feedback to see if can be accommodated. Benfield to send example for WG to look at.

4. DoDAF CM5. Review new Action Items (“unassigned”)6. Others:

– In queue but probably won’t have time to get to tomorrow:• 20 SoAML terms to compare to DM2 data dictionary• Prioritization of 2.02 AI’s – in reverse order!• http://www.w3.org/2007/eGov/IG/wiki/Main_Page

– TBS by WG