표준 프로토콜 패턴

Canonical protocol pattern

캐논픽 프로토콜은 서비스 재고 내에서 서비스가 이용되는 통신 프로토콜을 표준화하여 상호운용 가능하도록 [1]하는 서비스 지향 설계 패러다임 내에서 적용되는 설계 패턴이다.이를 통해 서비스가 서로 다른 통신 프로토콜을 사용할 때 통신 프로토콜을 브리징할 필요가 없어진다.[2]

이론적 근거

서로 다른 프로젝트 팀이 개발한 서비스는 서로 다른 통신 메커니즘에 기초할 수 있다.결과적으로, 서비스 재고자산은 서로 다른 프로토콜 세트를 준수하는 서로 다른 서비스 세트를 갖게 될 수 있다.통신 프로토콜이 다른 서비스를 재사용하는 것에 관해서는, 일종의 통신 브리징 메커니즘이 필요하다.예를 들어, JMS 메시징 프로토콜을 사용하여 개발된 서비스는 을 사용한 서비스와 호환되지 않는다.NET 원격 설치, 따라서 이 두 가지 유형의 서비스를 이용하기 위해서는 통신 프로토콜 격차를 해소하는 미들웨어 기술이 있어야 한다.추가 비용을 발생시키는 것 외에도, 그러한 브리징 기술의 사용은 지연 시간과 통신 오버헤드를 증가시킨다.이는 서비스를 재사용 가능한 재충원[3] 가능한 자원으로 만들고 서비스 복합성 설계 원칙의 지침에 위배된다.

모든 서비스가 서로 상호운용 가능한 서비스 재고량을 설계하여 서로 다른 솔루션으로 구성될 수 있도록 하기 위해, 캐논 프로토콜 패턴의 적용은 서비스에서 사용하는 통신 프로토콜의 표준화를 지시한다.모든 서비스가 동일한 통신 프로토콜을 사용하고 있을 때는 브리징 기술의 요건이 없어지고 서비스 간 통신이 더욱 효율화된다.[4]

사용법

Diagram A
다이어그램 A
서로 다른 통신 프로토콜을 사용하여 개발된 서비스는 서로 대화할 수 없다.
Diagram B
도표 B
동일한 통신 프로토콜을 사용하여 개발된 서비스는 서로 대화할 수 있기 때문에 여러 서비스 구성에 사용할 수 있다.

이 설계 패턴의 적용은 재고자산의 모든 서비스가 동일한 통신 프로토콜을 사용하여 서로 통신할 수 있도록 공통적인 통신 프레임워크를 제공하는 기술 아키텍처를 선택할 것을 요구한다.이는 서비스 재고자산의 서비스 이용 방법에 따라 달라진다.서비스가 특정 통신 프로토콜을 항상 사용하는 서비스 구성의 일부만 될 경우(효율성과 보안상의 이유 때문에), 해당 서비스 재고 내의 모든 서비스는 가장 널리 사용되는 프로토콜이 아니더라도 그러한 통신 프로토콜에 기초하여 구축될 수 있다.

Thomas Erl의 Canonical Protocol 패턴은 "서비스가 어떻게 프로토콜 브리징을 피할 수 있도록 설계될 수 있는가?"[5]라는 질문에 대답한다.문제는 서로 다른 통신기술을 지원하는 서비스가 상호운용성을 훼손하고, 잠재적 소비자의 양을 제한하며, 바람직하지 않은 프로토콜 브리징 조치의 필요성을 도입한다는 점이다.해결책은 단일 통신 기술을 서비스가 상호작용할 수 있는 유일한 매체 또는 주요 매체로 확립하는 아키텍처에 있다.따라서, 서비스 재고 경계 내에서 사용되는 통신 프로토콜(프로토콜 버전 포함)은 모든 서비스에 대해 표준화된다(도표 참조).

가장 성숙하고 널리 사용되는 통신 메커니즘 중 하나는 웹 서비스 프레임워크에 의해 제공된다.통신 프레임워크를 선택하는 것 외에도, 실제 메시지 프로토콜도 표준화할 필요가 있다.예를 들어 웹 서비스가 HTTP를 통해 SOAP를 사용하여 구축되는지 아니면 RESTful 서비스를 사용하여 구축되는지 여부.마찬가지로 SOAP 기반 웹 서비스에서 표준화할 때 SOAP 프로토콜의 특정 버전도 합의할 필요가 있다.SOAP v 1.1 또는 SOAP v 1.2.

고려 사항.

통신 프로토콜로 표준화하기 위해서는, 프로토콜의 특징을 보안, 효율성, 거래 지원을 포함한 서비스 상호작용 요건과 비교할 필요가 있다.예를 들어, 웹 서비스의 경우, 서비스 구성에 명시적인 트랜잭션 지원이 필요한 경우, HTTP를 통한 SOAP가 RESTful 서비스를 사용하는 것보다 더 나은 선택이 될 것이다.

어떤 경우에는, 서비스 구축에 사용되는 기술에 따라, 다른 유형의 서비스 소비자가 서비스를 이용할 수 있도록 하기 위해 두 가지 다른 프로토콜 세트를 지원하는 것이 가능할 수 있다(이중 프로토콜 설계 패턴[6]).예를 들어 WCF를 사용하면 HTTP와 TCP/IP 프로토콜을 동시에 사용하도록 동일한 서비스를 구성할 수 있다.

통신 프레임워크를 선택할 때, 머지 않아 쓸모 없게 될 프로토콜을 사용한 서비스를 구축하는 것은 그러한 서비스의 재사용 가능성에 영향을 미치고 서비스를 재설계하기 위해 상당한 시간과 노력을 필요로 할 것이기 때문에 성숙도, 확장성 및 라이센스 비용을 고려해야 한다.

참조

메모들
  1. ^ 2010년 3월 13일 웨이백 시스템에 보관된 서비스 인벤토리
  2. ^ 매튜 데일리소프트웨어 아키텍처 설계 서비스 지향 아키텍처 (Part II) 웨이백 머신[온라인]에 2011-07-24 보관.접속일: 2010년 4월 25일.
  3. ^ 2010년 3월 11일 웨이백 머신에 보관된 서비스 구성
  4. ^ 마우로 외서비스 지향적 장치 통합 - SOA 설계 패턴 분석.[온라인], pp.1-10, 2010 제43회 하와이 시스템 과학 국제 회의, 2010.접속일: 2010년 4월 30일.2010년 3월 28일 웨이백 머신에 보관
  5. ^ SOA 패턴 - 2009년 12월 14일 웨이백 머신에 보관된 표준 프로토콜
  6. ^ 이중 프로토콜 설계 패턴 2009년 12월 14일 웨이백 머신에 보관
원천
  • Thomas Erl 등, (2009년).SOA 설계 패턴.프렌티스 홀. ISBN978-0-135-613516-6.

외부 링크