SC4 Future Architecture Workshop
Download
1 / 25

SC4 Future Architecture Workshop - PowerPoint PPT Presentation


  • 127 Views
  • Uploaded on

SC4 Future Architecture Workshop. Second PWI Workshop London, UK October 18-19, 2009 David Price David Leal Co-Chairs. Agenda. Day 1 Welcome and Introductions Walkthrough of Overview Presentation Day 2 Input to/Review of IT Framework Components

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' SC4 Future Architecture Workshop' - bikita


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

SC4 Future Architecture Workshop

Second PWI Workshop

London, UK

October 18-19, 2009

David Price

David Leal

Co-Chairs


Agenda
Agenda

  • Day 1

    • Welcome and Introductions

    • Walkthrough of Overview Presentation

  • Day 2

    • Input to/Review of IT Framework Components

    • Input to/Review of SC4 Methods and Guidelines

    • Input to/Review of Examples

    • Plan for Rotterdam


SC4 Future Architecture Introduction

A Brief Introduction to the Proposed SC4 Future Architecture

October 2009

David Price


Background

  • For several years participants from ISO TC184 SC4 “STEP” have been migrating to OMG, OASIS and other standards bodies

  • For several years various SC4 people have made presentations on why … basically that SC4 is stuck in the mid-1990s and the rest of the world has moved on

  • 2009 NIST funded a “STEP for Engineering Enterprise Integration”


NIST “Future STEP” Project Goals

  • To enable enterprise integration based on inter-related data exchange, ontology and service specifications

  • To enable the selective harvesting of ISO 10303 (aka STEP) standards into ontologies and other widespread modeling languages via OMG Model Driven Architecture ™ approach

    • ISO TC184 SC4 STEP community has been creating data exchange information models for 20 years – lots of knowledge, lessons learned and capability there

    • With possibility of ISO STEP harvesting improvements made in OMG and W3C back into its standards

    • May lead ISO STEP to adopt OMG & W3C technology


Near-Term Goal - Harvesting STEP

Industry

OMG

Future STEP

Project

ISO

OMG

EXPRESS

STEP

EXPRESS

Schemas

ODM/OWL

Reasoner

Harvesting

Process, Specs

& Tools

OWL

Reference

Data

UML Profile

for EXPRESS

STEP as UML

UML 2 Tool &

Executable UML

Data

APIs

& Services

Inter-related

suite of stds

Software Systems

Integration

XML

Schema


End Goal – New ISO STEP Approach

Industry Extensions

Reasoning

SOA

Standardized

Core Ontologies

And Mapping

Data

Exchange

Processes


SC4 Future Arch PWI

  • In May 2009 SC4 initiated a project to propose an SC4 future architecture

  • Deliverables

    • A proposed architecture for SC4 standards

    • An example done using the proposed architecture

    • A paper/report on making SC4 standard content freely available

  • Deadline : November 2009


Today s choice of technology

resource parts

Today’s choice of technology

OED, normative scientific and engineering references

terms and definitions for people

constrained

exchange

subsets

web service definitions

domain extensions

XML schema + schematron

OWL + named graphs

OWL + SWRL

CL, and other dictionary languages

WSDL


Project goals

  • Better

    • Put SC4 standards on a sound, formal, semantic foundation

    • Enable wider coverage of SC4 customer information and communication technology needs

  • Faster and cheaper

    • Use widespread technologies, methodologies and approaches

    • Maintain/extend reuse/modularity

    • Support lightweight usage scenarios

  • Legacy

    • Provide migration/mapping for existing SC4 standards


Approach

  • Enable a suite of SC4 standards taking a knowledge-based approach with formal, semantic models at its core

    • A “green field” approach to the architecture and standards

      • Not just re-implementing STEP architecture using UML tools

    • ISO 10303, ISO 15926, etc. can continue to be extended if industry so chooses

      • i.e. Not “the only” architecture used in SC4, instead it's “the new and improved” additional architecture

    • Evolve and grow over time, do not have to migrate every thing in SC4 at once (or ever, for that matter)


The SC4 Architecture Elements

  • An SC4 IT Framework in which to create standards

  • SC4 Methods and Procedures that specify how to populate the SC4 IT Framework

  • An SC4 Framework of Concepts that is the basis of the formal models


IT Framework Components

  • Library of Natural Language Dictionaries

  • Formal models of general and discipline-specific concepts

  • Process models and implementation bindings

  • Data models and implementation bindings

  • Service models and implementation bindings

  • Mapping and Traces between elements within and across components


Library of Natural Language Dictionaries

  • Libraries of dictionaries, largely sources published elsewhere, augmented by SC4 as required (e.g IEC IEV)

  • Terms and related definitions for human consumption

    • Not definitions of specific model elements

    • Relationships between terms

  • Usages and users of terms in the dictionary

    • Analysts deciding if an SC4 standard covers their scenario

    • Guides, reports, presentations, etc. explaining SC4 standards

    • Use cases, Activity models, concept maps, etc. used to scope, introduce or overview SC4 standards

    • Referenced as a 'source' from the major elements in the standard models


Logic-based Models

  • Specified using languages with formal semantics

  • Concepts and their relationships which begin at a generic level with a series of levels of increasing specificity

  • Specializations and extensions to general models to support discipline-specific requirements

    • Can address some industry use cases directly

      • e.g. Semantic Web-style uses, data aggregation or federation, reasoning

      • Need not be decidable (e.g. OWL Full)

  • The SC4 Conceptual Model Framework

    • With lessons learned from 10303,15926, etc. applied

    • Example : A quantities and units ontology


Process Models and Bindings

  • Models of the processes that act on the world (e.g. create or consume data)

    • Not models of services like SOA

  • Two main purposes

    • scoping and providing context for data-related standards

    • standardizing processes, or adding detail to standard processes from other organizations

      • These may be directly executable via bindings to execution engines (e.g. BPMN → BPEL)

      • Using process to record provenance


Data Models/Bindings

  • Logical data models (e.g. EXPRESS, UML)

  • Data models (e.g. XML Schema)

  • Purpose is to support interchange, integration, archiving and preservation, content of services, databases, etc.

  • ISO 10303 is an example

  • Typically scoped using a process model

  • Bindings are to text files, XML files, etc., including from logical data models

  • ‘Closing world’; Adding constraints about data shall be recorded


Service Models and Bindings

  • Models of services and their relationships such as choreography or orchestration

    • Service Oriented Architecture

    • Web Oriented Architecture

    • Resource Oriented Architecture

  • Bindings are to Web services, SOAP, WSDL, REST, etc.

  • Often support a process model and have a formal model or data model defining their content


Mappings and Traces

  • 'Mapping' was too strong a name as the relationship semantics may only be human-interpretable, so now ‘Mapping and Trace’

  • Specifications of the relationships between

    • model elements in different IT architecture components (e.g. data model element represents formal model element)

    • model elements within an IT architecture component (e.g. data model element A can be transformed to data model element B or can be represented by XML binding for A)

    • references to terms, dependencies, etc.

  • May be formal or informal, but always computer navigable

    • Example of formal : EXPRESS-X, QVT, XSLT, SQL, STEP Mapping Tables, Graph Transformation Languages

      • E.g. MEXICO stuff is example (EXPRESS->UML)

      • Profiles of UML (e.g. SOAML, SysML)

    • Examples of informal : 'source' or 'seeAlso' annotations


Technologies

  • Approach is to be “inclusive” with respect to technologies, particularly for implementation

    • Need to allow elements to be glued together as required for mapping, migration, source, etc.

    • OMG MDA identified as strong candidate, particularly for the more detailed components

  • The core Dictionary and Formal Model technologies are the first priority as the more detailed components will likely require a support for a wide variety of technologies


Initial Candidate technologies

  • Dictionary : Natural language, SKOS, Concept Maps, Topic Maps, Controlled Natural Language, ISO 11179 Metadata Registry, ISO 22745

  • Formal models : OWL, ODM, Common Logic, Controlled Natural Language

  • Data models : EXPRESS, UML, E/R, MOF DSL, ORM

  • Serialization bindings : XML Schema, XML, P21, JSON, YAML, HDF5, RDFa, SQL

  • Process models/bindings : UML, BPMN, UPDM, BPEL

  • Service models/bindings : UML, SOAML, WSDL, REST

  • Mapping : Controlled Natural Language, EXPRESS-X, QVT, TGG, XSLT, OWL


Initial it recommendations
Initial IT Recommendations

  • List for initial report, not final SC4 suite of IT

  • Library – Decision not final

  • Formal Models – OWL and ISO Common Logic

  • Data Models – UML, XML-related languages and EXPRESS

  • Service Models – UML, and perhaps soaml

  • Process Models – UML, and perhaps BPMN

  • Mapping and Trace

    • Trace – Specific technology for each component that can be processed into a common form for navigation and query (e.g Dublin Core, SKOS, SAWSDL)


Concluding questions

  • Are we missing any architecture components?

  • Are we missing good candidate technologies for use in any architecture components?

  • What criteria should we use to evaluate candidate technologies?

    • e.g. maturity, cost, tool availability

  • How does SC4 publish standards for various components now? Is the model as the standard sufficient?

    • For example, is OWL with annotation properties enough or must we also publish a document?


Contacts
Contacts

  • Public Future Architecture Wiki

  • http://FutureArch.wikispaces.com

  • SC4 Sharepoint

  • http://sp.tc184-sc4.org/SC4Projects/FutureSC4Arch/default.aspx

  • SC4 Email Exploder:

  • [email protected]


ad