1 / 23

Towards a Model-Based Characterization of Data and Services Integration

Towards a Model-Based Characterization of Data and Services Integration. Paul C. Brown Principal Software Architect. Context: Interacting Systems. Overlapping Information Views. Multiple Schemas. Domain Model: Conceptual Abstraction. Concepts, relationships, key attributes.

swain
Download Presentation

Towards a Model-Based Characterization of Data and Services Integration

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Towards a Model-Based Characterization of Data and Services Integration Paul C. BrownPrincipal Software Architect

  2. Context: Interacting Systems

  3. Overlapping Information Views

  4. Multiple Schemas

  5. Domain Model: Conceptual Abstraction • Concepts, relationships, key attributes

  6. Mapping Concepts to Representational Schema • Concepts, relationships, key attributes

  7. Concepts are not Uniform: Mapping is Required

  8. Representational Mappings Derived from Concepts

  9. Conceptual Mappings Derived from Abstractions

  10. Information has an Inherent Network Structure

  11. Communication Schemas Tend To Be Tree Structured

  12. Information Realities • Canonical data model myth • One 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 issue

  13. Data-Related Model Requirements • Network- 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 vocabulary • One concept  many terms • One term  many concepts • Versions of representations and mappings • Mappings whose expression requires some form of computation

  14. Service Realities • Many operations are not pure functions • Operate 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 important

  15. Service-Related Model Requirements • Representation 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 operations • Versions and mappings between versions • Abstracted concepts related to services operations • Mappings between concepts and concrete service models • Flexible vocabulary • Mappings whose expression requires some form of computation

  16. Process (Service Utilization) Context

  17. Process (Service Utilization) Realities • Services 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 transactions

  18. Process (Service Utilization) Model Requirements • Observable behavior of the service as viewed through its interfaces • Service 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 versions

  19. UML Can Satisfy Many Modeling Requirements • UML can represent concrete things • Data structure schema • Services, operations, state machines • UML can represent abstractions • Concepts and Relationships How do we model mappings and multiple vocabularies?

  20. Semantics of Business Vocabulary and Rules (SBVR)

  21. Semantics of Business Vocabulary and Rules (SBVR) Abstract concepts and relationships Concrete schema and other representations

  22. SBVR Can Complete the Modeling Picture • SBVR can represent mappings (simple and complex) • SBVR handles multiple vocabularies for concepts • SBVR can be used to relate multiple UML representations

  23. What We Need • Uniform approach to modeling • Abstract 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 versions • Tooling • Schema Concrete model + schema-model mapping • Concrete mappings  schema mappings (e.g. XSLT) • Abstract mappings  concrete mappings UML and SBVR seem to have the required building blocks!

More Related