OASIS SOA 참조 모델

OASIS SOA Reference Model

SOA-RM(OASIS Reference Model for Service Oriented[1] Architecture)은 서비스 지향 환경 내에서 중요한 엔티티와 엔티티 간의 관계를 이해하고 해당 환경을 지원하는 일관된 표준 또는 사양을 개발하기 위한 추상적인 프레임워크입니다.SOA의 통일된 개념을 기반으로 하며, 특정 서비스 지향 아키텍처를 개발하거나 SOA를 교육하고 설명하는 설계자가 사용할 수 있습니다.

이러한 맥락에서 참조 모델은 서로 다른 SOA 구현 간에 모호하지 않게 사용될 수 있는 공통의 의미론을 제공하는 장소로 간주됩니다.참조 모델과 특정 아키텍처, 기술 및 SOA의 다른 측면 간의 관계는 아래 명세서에서 설명합니다.

묘사

역사

OASIS SOA 참조 모델은 OASIS SOA 참조 모델(SOA-RM) 기술 위원회(TC)[2]의 제품입니다.이 이니셔티브 이전에는 SOA의 표준 정의가 존재하지 않았습니다.SOA-RM TC는 2005년 2월에 특정 서비스 지향 아키텍처의 생성을 안내 및 촉진하는 핵심 참조 모델을 개발하고,[3] 참조 모델을 기반으로 하는 하나 이상의 참조 아키텍처뿐만 아니라 SOA를 위한 참조 모델을 발행하기 위해 인가되었습니다.레퍼런스 모델은 2006년 [4]10월에 OASIS 멤버에 의해 OASIS 표준으로 승인되었습니다.

OASIS SOA-RM TC는 레퍼런스 모델의 최종 승인 기간 동안 동반 레퍼런스 아키텍처에 대한 작업을 시작했으며, 2012년 12월 서비스 지향 아키텍처를 위한 OASIS 레퍼런스 아키텍처 재단(SOA-RAF)[5]이 OASIS 위원회 사양으로 승인되었습니다.

반면 OASIS서비스 지향 아키텍처 참조 모델 일부 quarters,[6] 수많은 다른 서비스 지향 아키텍처 규격 efforts[7][8]에서 환영 받는 경우는 SOA-RAF 개발되고 있는 또한 기간 동안. 협조적인 노력이 개인의 노력“일치”에 OASIS, 오픈 그룹과 함께 했으며, 객체 관리 그룹 뒤(OMG)시작되어 논의되고 있었다.반지는2008~2009년 기간논의에서 명백한 공통점을 발견했지만, 그 당시에는 조화가 불가능했으며, 최종 결과물은 2009년 7월에 발간된 "건축을 둘러싼 SOA 개방형 표준 환경 탐색(Navigating the SOA Open Standards Lastance Around[9] Architecture)"이라는 공동 논문이었습니다.또한 SOA-RAF의 부록 C에는 다른 SOA 표준화 노력에 대한 요약이 포함되어 있습니다.논의는 현재까지 계속되고 있다.아래(그리고 SOA-RM 자체)에서는 단일 참조 모델에서 여러 참조 아키텍처를 도출하는 방법에 대해 설명합니다.

현황

SOA-RM TC는 활성 상태를 유지하고 서비스 및 인터페이스 세분화와 같은 주제에 대한 논의를 계속합니다.이러한 논의에서 추가적인 위원회 메모가 나올 수 있습니다.

주요 개념

SOA에 대한 OASIS 정의

SOA-RM 규격에 따르면, SOA는 서로 다른 소유권 도메인의 통제 하에 있을 수 있는 분산된 기능을 구성하고 활용하기 위한 패러다임입니다.측정 가능한 전제 조건 및 기대와 일관되게 원하는 효과를 낼 수 있는 기능을 제공, 발견, 상호작용 및 사용할 수 있는 통일된 수단을 제공합니다.SOA-RM 규격은 SOA에 대한 정의를 "요구 및 기능"이라는 개념에 기초하고 있으며, 여기서 SOA는 서비스 소비자의 요구를 서비스 제공업체가 제공하는 기능과 일치시키는 메커니즘을 제공합니다.

서비스

참조 모델의 중심 개념은 서비스 개념이며, 참조 모델은 이를 다음과 같이 정의합니다.1개 이상의 기능에 대한 접근을 가능하게 하는 메커니즘.여기서 액세스는 소정의 인터페이스를 사용하여 제공되며 서비스 개요에 의해 지정된 제약 및 정책과 일관되게 실행된다.

다음은 참조 모델이 서비스에 대해 정의하는 주요 개념입니다.가시성, 상호작용 및 실제 효과는 서비스의 동적 측면(서비스와의 상호작용)에 대처하고 나머지 개념은 정적 측면에 대처합니다.

  • 서비스 개요:서비스를 사용하거나 사용을 검토하기 위해 필요한 정보입니다.이 설명의 목적은 서비스 상호작용의 참가자 간의 상호작용과 가시성을 촉진하는 것입니다.특히 참가자가 다른 소유권 영역에 있는 경우에는 더욱 그렇습니다.
  • 가시성:니즈가 있는 사람과 능력이 있는 사람이 서로 상호작용할 수 있는 능력.가시성에는 용역이 존재할 뿐만 아니라 제공자에 대한 충분한 소비자 지식 및 제공자에 대한 소비자에 대한 충분한 지식이 있어 당사자들 간에 상호작용을 시작하거나 지속할 의지가 확립되어 있는 것이 포함된다.이는 일반적으로 기능 및 기술요건, 관련 제약조건 및 정책, 접근 또는 응답 메커니즘 등의 측면에 대한 설명을 제공함으로써 이루어집니다.
  • 상호 작용:서비스 프로바이더와 소비자 간의 상호작용을 말합니다.일반적으로 메시지 교환에 의해 조정되는 상호작용은 일련의 정보 교환과 호출된 액션을 통해 진행됩니다.상호작용의 결과는 현실세계의 효과입니다.
  • 실제 효과:서비스를 사용한 실제 결과입니다.이는 정보의 반환 또는 상호 작용에 관여하는 엔티티(알고 있거나 알려지지 않은) 상태의 변화일 수 있습니다.
  • 실행 컨텍스트:요구가 있는 요소와 능력이 있는 요소 사이에 경로를 형성하고 서비스 프로바이더와 소비자가 상호작용할 수 있는 조건을 확립하는 일련의 기술 및 비즈니스 요소.모든 상호작용은 특정 실행 컨텍스트에 근거합니다.이것에 의해, 서비스 프로바이더와 소비자가 상호작용할 수 있게 되어, 유효한 정책이나 계약의 결정점이 됩니다.
  • 계약 및 정책:정책은 참여자가 정의한 소유기업의 사용, 배치 또는 설명에 대한 일부 제약이나 조건을 나타내며, 계약은 둘 이상의 당사자의 합의를 나타낸다.참조 모델은 주로 서비스에 적용되는 정책 및 계약의 개념에 초점을 맞추고 있습니다.

SOA의 예시

다음 예는 SOA-RM 규격에서 따온 것이며 위에서 설명한 주요 개념과 참조 모델이 정의하는 다른 개념을 괄호 및 기울임꼴로 포함합니다.

  • 전력회사는 전기를 생성하고 분배할 수 있는 능력(기본 능력)을 가지고 있다.전기회사 배전망(서비스)으로부터의 배선은 주택의 일반적인 사용(서비스 기능)을 지원하기 위한 전력 공급 수단을 제공하며, 소비자는 월 콘센트(서비스 인터페이스)를 통해 발전된 전력(서비스 호출 출력)에 액세스한다.
  • 전기를 사용하기 위해 소비자는 사용하는 플러그 유형, 전원 전압 및 가능한 부하 한계를 이해해야 합니다. 유틸리티는 고객이 제공된 전압과 호환되는 장치 및 지원되는 부하만 연결하는 것으로 가정합니다. 또한 소비자는 호환되는 소비자 개발을 가정합니다.얼음은 손상이나 손상 없이 연결할 수 있습니다(서비스 기술 전제 조건).
  • 거주자 또는 기업 사용자는 공급(서비스 제약)을 사용하기 위해 유틸리티 계정을 개설해야 하며, 유틸리티는 사용량을 측정하고 소비자가 규정된 요금(서비스 정책)으로 사용료를 지불할 것으로 예상합니다.소비자와 전력회사가 제약조건과 정책(서비스 계약)에 합의할 때, 소비자는 배전망과 주택 연결이 그대로 유지되는 한(예: 폭풍으로 인해 배전선이 파괴될 수 있음) 서비스를 사용하여 전기를 공급받을 수 있으며, 소비자는 지불을 받을 수 있다(예: 우편으로 수표).또는 전자 자금이체)를 유틸리티(도달 가능성)로 전송합니다.
  • 다른 사람(예: 다른 사람의 집을 방문하는 사람)은 초기 서비스 제약 조건을 충족하기 위해 유틸리티 또는 요건 없이 계약된 공급을 사용할 수 있지만(예: 도달 가능성은 온전한 배전만 필요로 한다) 그럼에도 불구하고 서비스 인터페이스와 호환될 것으로 예상된다.
  • 특정 상황(예: 과도한 수요)에서 유틸리티는 공급을 제한하거나 롤링 블랙아웃(서비스 정책)을 실행할 수 있습니다.이러한 일이 자주 발생하는 경우(소비자의 묵시적 정책) 소비자는 공식적인 불만을 제기할 수 있다.
  • 유틸리티가 모든 디바이스를 장치에 유선 연결해야 하는 경우 기본 기능은 그대로 유지되지만 이는 매우 다른 서비스이며 매우 다른 서비스 인터페이스를 가집니다.

SOA 및 프로세스

참조 모델은 프로세스 모델 개념을 통해 프로세스의 개념을 포함하지만 참조 모델의 이 측면의 범위는 의도적으로 완전히 정의되지 않습니다.예를 들어, 조정 및 안무는 프로세스 모델의 일부일 수 있지만 참조 모델은 여러 서비스의 조정을 다루지 않습니다.이는 레퍼런스 모델의 초점은 서비스 모델링과 서비스 모델링과 관련된 주요 관계 모델링에 맞춰져 있기 때문입니다.그 작업의 출처는 아직 정해지지 않았지만, 이 분야에 장래의 작업이 있을 것으로 예상된다.

세컨더리 개념

OASIS 레퍼런스 모델의 정의

SOA-RM 규격에 따르면 참조 모델은 일부 환경의 주체 간의 중요한 관계를 이해하기 위한 추상적인 프레임워크입니다.또한 해당 환경을 지원하는 일관된 표준 또는 사양을 사용하여 특정 참조 또는 구체적인 아키텍처를 개발할 수 있습니다.참조 모델은 특정 문제 영역 내에서 통일된 개념, 공리 및 관계의 최소 집합으로 구성되며 특정 표준, 기술, 구현 또는 기타 구체적인 세부사항과는 독립적입니다.따라서 SOA를 위한 참조 모델은 SOA 주체 간의 중요한 관계를 이해하기 위한 추상적인 프레임워크입니다.

레퍼런스 모델과레퍼런스 아키텍처

SOA-RM 규격은 참조 모델과 참조 아키텍처를 명확하게 구분하고 이들 간의 관계를 설명합니다.참조 아키텍처는 추상적인 일련의 메커니즘과 관계가 미리 결정된 일련의 요구사항을 실현하는 방법을 나타내는 아키텍처 설계 패턴입니다.하나 이상의 참조 아키텍처는 공통 참조 모델에서 파생되어 참조 모델이 대상이 될 수 있는 다양한 목적/용도를 다룰 수 있습니다.SOA-RM 규격은 참조 모델과 참조 아키텍처 간의 관계뿐만 아니라 참조 아키텍처가 구체적인 아키텍처를 도출하기 위해 어떻게 사용될 수 있는지를 설명하기 위해 주택 설계를 포함하는 유사점을 제공합니다.


레퍼런스

  1. ^ "OASIS Reference Model for Service Oriented Architecture 1.0, Official OASIS Standard (Normative PDF), Oct. 12, 2006" (PDF).
  2. ^ "OASIS SOA Reference Model TC". OASIS. Retrieved February 5, 2015.
  3. ^ Nickull, Duane (January 4, 2006). "Why we need the OASIS SOA Reference Model". Loosely Coupled. Retrieved February 5, 2015.
  4. ^ "OASIS Members Approve SOA Reference Model". Grid Today. October 30, 2006. Archived from the original on 27 September 2007.
  5. ^ "OASIS Reference Architecture Foundation for Service Oriented Architecture Version 1.0, Committee Specification 01 (Authoritative PDF), 04 December 2012" (PDF).
  6. ^ SOA 참조 모델 제1부, SOA 참조 모델 제2부
  7. ^ Linthicum, Dave (February 4, 2007). "Open Group debates SOA Reference Architecture..." Infoworld. Archived from the original on June 7, 2007.
  8. ^ Little, Mark (February 21, 2007). "Psst ... got a SOA Reference Model? Want another one?". InfoQ. Retrieved February 5, 2015.
  9. ^ "Navigating the SOA Open Standards Landscape Around Architecture, Joint Paper by The Open Group, OASIS, and OMG, July 2009" (PDF).