ModelBased Characterization of Data and Services Integration Paul C Brown Principal Software Architect Context Interacting Systems Overlapping Information Views Multiple Schemas Domain ID: 338018
Download Presentation The PPT/PDF document "Towards a" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Towards a Model-Based Characterization of Data and Services Integration
Paul C. Brown
Principal Software ArchitectSlide2
Context: Interacting SystemsSlide3
Overlapping Information ViewsSlide4
Multiple SchemasSlide5
Domain Model: Conceptual AbstractionConcepts, relationships, key attributesSlide6
Mapping Concepts to Representational SchemaConcepts, relationships, key attributesSlide7
Concepts are not Uniform: Mapping is RequiredSlide8
Representational Mappings Derived from ConceptsSlide9
Conceptual Mappings Derived from AbstractionsSlide10
Information has an Inherent Network StructureSlide11
Communication Schemas Tend To Be Tree StructuredSlide12
Information RealitiesCanonical data model mythOne size does not fit all: complete concept vs. reference
Vocabularies vary
Think about the multiple meanings of “attribute”
“Procedure” to a physician vs. health insurance company
Information evolves
Medical procedure code change ICD-9
ICD-10
Versioning is important
Information is replicated
Consistency is an issueSlide13
Data-Related Model RequirementsNetwork- and tree-structured
representational schema (e.g
. database schema, XSDs,
JSON, record formats)
Mappings
between
representational schema
Abstracted models
of concepts and
relationships
Independent of representational schema
Mappings
between the abstracted
concepts and representational schema
Flexible vocabularyOne concept many termsOne term many concepts Versions of representations and mappings Mappings whose expression requires some form of computationSlide14
Service RealitiesMany operations are not pure functionsOperate on persistent state (information) managed by the service
Operations are not independent
Sequencing constraints, business rules
Services often house cached data
Cache update protocols and timing
Impact on service operations
Vocabulary (terminology) varies and overloaded
Particularly between organizations
Services evolve
Versioning is importantSlide15
Service-Related Model RequirementsRepresentation of:
Services
and their interfaces
Service
operations and their data structures
State
and state instances
Relationship
between service
operations and
service
state
Dependencies between
service operationsVersions and mappings between versions
Abstracted concepts related to services operationsMappings between concepts and concrete service modelsFlexible vocabularyMappings whose expression requires some form of computationSlide16
Process (Service Utilization) ContextSlide17
Process (Service Utilization) RealitiesServices may be involved in multiple processes Protocol semantics must be understood
REST, SOAP, XML over JMS, HTTP, file transfer, etc.
Coordination must be understood
Fire and forget to distributed transactionsSlide18
Process (Service Utilization) Model RequirementsObservable behavior of the service as viewed through its interfacesService usage scenarios
Sequencing and dependency constraints between service operations
Coordination of activities between components
Versions of observable behavior, usage scenarios, sequencing, and coordination
Mappings between versionsSlide19
UML Can Satisfy Many Modeling RequirementsUML can represent concrete thingsData structure schema
Services, operations, state machines
UML can represent abstractions
Concepts and Relationships
How do we model mappings and multiple vocabularies?Slide20
Semantics of Business Vocabulary and Rules (SBVR)Slide21
Semantics of Business Vocabulary and Rules (SBVR)
Abstract concepts and relationships
Concrete schema and other representationsSlide22
SBVR Can Complete the Modeling PictureSBVR can represent mappings (simple and complex)SBVR handles multiple vocabularies for concepts
SBVR can be used to relate multiple UML representationsSlide23
What We NeedUniform approach to modelingAbstract and concrete concepts and relationships
Multiple domains with relationships
Bi-directional Mappings
Abstract
concrete models
Concrete
concrete models
Concrete models
actual schema
Schema
schema mappings Versioning at all levels + mappings between versionsToolingSchema Concrete model + schema-model mappingConcrete mappings schema mappings (e.g. XSLT)Abstract mappings concrete mappings
UML and SBVR seem to have the required building blocks!