표준 스키마 패턴

Canonical schema pattern

소프트웨어 엔지니어링에서 Canonical Schema는 서비스 지향 설계 패러다임 내에서 적용되는 설계 패턴으로, 서비스에서 동일한 데이터 [3]모델을 참조하는 메시지를 교환할 때 데이터[1][2] 모델 변환을 수행할 필요성을 줄이는 것을 목표로 합니다.

근거

서비스 간의 상호 작용에는 비즈니스 문서를 교환해야 하는 경우가 많습니다.서비스 소비자가 데이터(예: 구매 주문과 같은 특정 사업체와 관련된)를 전송하기 위해서는 데이터 구조(예: 데이터 모델)를 알아야 한다.이를 위해 서비스 공급자는 서비스 소비자로부터의 착신 메시지 내에서 예상되는 데이터 구조를 공개합니다.서비스가 웹 [4]서비스로 구현되는 경우 XML 스키마 문서입니다.서비스 소비자는 필요한 데이터 모델을 알게 되면 그에 따라 데이터를 구성할 수 있습니다.그러나, 어떤 상황에서는 서비스 소비자가 이미 특정 비즈니스 문서와 관련된 필수 데이터를 보유하고 있을 수 있지만, 그 데이터가 서비스 제공자가 명시한 데이터 모델에 부합하지 않을 수 있습니다.데이터 모델 간의 이러한 차이 때문에 데이터 모델 변환이 요구되므로 서비스 프로바이더의 지시에 따라 메시지가 필수 구조로 변환됩니다.상기의 예에 근거해, 서비스 프로바이더는, 수신한 비즈니스 문서를 처리한 후에, 서비스 소비자에게 반송하는 것을 충분히 생각할 수 있다.서비스 소비자는 다시 데이터 모델 변환을 실시해, 처리한 비즈니스 문서를 자사 로지내에서 사용하는 데이터 모델로 변환한다.c 비즈니스 문서를 나타냅니다.
이 런타임 데이터 모델 변환은 처리 오버헤드를 증가시키고 서비스 [5]구성 설계를 복잡하게 만듭니다.데이터 모델 변환의 필요성을 피하기 위해 Canical Schema 패턴은 서비스 [6][7]인벤토리의 서비스에서 일반적으로 처리되는 비즈니스 문서에 표준화된 데이터 모델을 사용하도록 지시합니다.

사용.

Diagram A
그림 A
서비스 A는 동일한 비즈니스 문서에 대해 서비스 B와 다른 데이터 모델을 사용하고 있습니다.메시지 교환 시 런타임 데이터 모델 변환을 수행해야 합니다.
Diagram B
그림 B
두 서비스 모두 특정 비즈니스 문서를 나타내기 위해 동일한 데이터 모델을 사용합니다.따라서 메시지를 교환할 때 데이터 모델을 변환할 필요가 없습니다.

이 설계 패턴은 표준화된 서비스 계약 설계 원칙을 적용함으로써 완전히 지원됩니다.표준화된 서비스 계약의 설계 원칙은 서비스 계약이 표준화된 데이터 모델을 기반으로 한다고 주장합니다.이는 서비스 인벤토리[8] Blueprint 분석을 수행하여 서비스 간에 교환되는 일반적으로 발생하는 비즈니스 문서를 찾아냄으로써 실현됩니다.그런 다음 이러한 비즈니스 문서를 표준화된 방식으로 모델링합니다.예를 들어 웹 서비스의 경우 비즈니스 문서는 XML 스키마로 모델링됩니다.표준화된 데이터 표현 레이어가 서비스 인벤토리에 존재하면 동일한 비즈니스 문서를 교환해야 하는 경우 서로 다른 서비스 계약에서 동일한 데이터 모델을 사용할 수 있습니다.이를 통해 데이터 모델 변환이 불필요해지고 데이터 모델 변환과 관련된 처리 오버헤드가 줄어듭니다.또한 커스텀 데이터 모델 변환 로직 없이 서비스를 사용할 수 있으므로 서비스의 재사용 가능성이 높아집니다.어떤 면에서 Canical Schema 패턴을 적용하면 데이터 모델 변환[9] 설계 패턴을 적용할 필요성이 줄어듭니다.

고려 사항.

이 설계 패턴의 적용에는 표준화된 데이터 모델의 사용을 의무화하는 설계[10] 표준이 필요합니다. 데이터 모델의 작성만으로 데이터 모델의 [11]사용이 보장되지 않기 때문입니다.원칙적으로는 단순하지만 표준화된 데이터 모델을 수용하는 솔루션 설계 측면에서 각 팀의 추가 노력이 필요할 수 있는 다른 프로젝트 팀의 약속이 필요하기 때문에 시행하기가 어렵습니다.
조직의 규모나 기업의 다른 세그먼트로부터의 반발로 인해 도메인인벤토리 설계 [7]패턴의 적용에 의해 작성된 특정 도메인인벤토리 내에서 Canonical Schema 설계 패턴을 적용해야 하는 경우가 있습니다.
스키마는 서비스 계약 설계와는 별도로 설계해야 합니다.[11]이것에 의존하지 않습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ 예를 들어 데이터베이스의 데이터 구조는 테이블에 포함된 데이터의 구조를 테이블 스키마로 나타냅니다.XML 기반 문서의 경우, 해당 XML 스키마 문서는 XML 문서의 구조를 포함합니다.
  2. ^ "Services". Archived from the original on 2012-05-01. Retrieved 2010-03-17.
  3. ^ 마우로 등서비스 지향 장치 통합 - SOA 설계 패턴 분석.2010년 3월 28일 Wayback Machine [Online], 페이지 1-10, 2010년 제43회 하와이 국제 시스템 과학 컨퍼런스, 2010년.접속일 : 2010년 4월 30일
  4. ^ 서비스 오리엔테이션 가이드라인에 준거하고 있는 한, 어떠한 테크놀로지라도 사용해 서비스를 실장할 수 있습니다.
  5. ^ "Service Compositions". Archived from the original on 2010-03-11. Retrieved 2010-03-17.
  6. ^ "service inventory". Archived from the original on 2010-03-13. Retrieved 2010-03-17.
  7. ^ a b 토마스 얼, 허브요른 빌헬름센입니다표준 스키마 설계 패턴[온라인]입니다.액세스 날짜:2010년 4월 8일
  8. ^ "Service Inventory Blueprint". Archived from the original on 2010-05-11. Retrieved 2010-03-17.
  9. ^ "Data Model Transformation". Archived from the original on 2010-02-13. Retrieved 2010-03-17.
  10. ^ "design standards". Archived from the original on 2010-03-17. Retrieved 2010-03-17.
  11. ^ a b 에벤 휴이트.Java SOA 쿡북[permanent dead link][온라인]페이지 50.접속일: 2010년 4월 25일

외부 링크