Canonical Message Model Version Mapping in SOA

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Enterprises face challenges in supporting multiple versions of a canonical message model within a service-oriented architecture, as existing solutions fail to seamlessly manage and integrate changes over time, leading to increased complexity and inefficiency in messaging infrastructure.

Innovation Solution

A method is introduced to determine and map differences between various versions of a canonical message model, providing this mapping to a message access service, allowing seamless support and updating of these versions within a service-oriented architecture industry model repository.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Stability of the object's composition

If an enterprise standardizes on a single version of the canonical message model, then the messaging infrastructure achieves simplicity and stability, but the system cannot compensate for different versions of the message model over time

Engineering Contradiction:

Improvemessage model stabilityVSAvoidmessage model version adaptability

Core Design Contradiction:

Stability of the object's compositionVSAdaptability or versatility

Solution Approach 1:

The patent implements a dynamic version management system that allows the canonical message model to evolve over time while maintaining backward compatibility. The system dynamically tracks differences between versions and provides mappings that enable runtime instantiation to handle multiple versions seamlessly, resolving the contradiction between stability and adaptability.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The patent introduces an intermediary layer (version mapping mechanism) that mediates between different message model versions. This intermediary tracks deltas between versions and provides translation mappings, allowing the system to support multiple versions without compromising the stability of the standardized model.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Adaptability or versatility

If the message model is updated with new features, then the system achieves enhanced functionality and scalability, but the existing infrastructure requires modification or redeployment

Engineering Contradiction:

Improvemessage model functionalityVSAvoidinfrastructure modification effort

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The patent performs preliminary actions by pre-computing and storing version mappings that track differences between message model versions. This allows the infrastructure to be updated with new features while existing mappings enable runtime instantiation to handle both old and new versions without requiring infrastructure modification or redeployment.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent creates copies of the message model infrastructure that can handle different versions. By maintaining versioned copies with their respective mappings, the system can add new features to the latest version while preserving the ability to process older versions through the copied infrastructure, eliminating the need for complete infrastructure redeployment.

Inventive Principle:

Principle #26Copying

3Adaptability or versatility

If the enterprise supports multiple versions of the message model, then the system achieves version flexibility and backward compatibility, but the complexity of the messaging infrastructure increases

Engineering Contradiction:

Improveversion support capabilityVSAvoidmessaging infrastructure complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the version management complexity by separating it into distinct components: version tracking, difference mapping, and runtime instantiation. This segmentation allows the system to support multiple versions while containing complexity within isolated modules rather than distributing it throughout the entire messaging infrastructure.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent implements self-service mechanisms where the version mapping system automatically tracks and manages differences between versions without requiring manual intervention. The runtime instantiation self-determines which version mapping to apply, reducing the operational complexity of managing multiple versions while maintaining full version support capability.

Inventive Principle:

Principle #25Self-service

Data Source

PatentUS8631071B2Recognition of and support for multiple versions of an enterprise canonical message model

Publication Date: 2014.01.14 SERVICENOW INC

AI summary

A method of recognizing and supporting multiple versions of a canonical message model in a service oriented architecture industry model repository comprising determining differences between at least one first version of a message model and at least one other version of the message model; mapping the differences between the different versions of the message models to the SOA IMR; and providing the mapping of the differences between the message models to a message access service, mapping of differences between the message models are applied and updated to the later of the message models to support the versions of the canonical message models seamlessly.