Listen to this article

서비스 지향 아키텍처

Service-oriented architecture

소프트웨어 엔지니어링에서 서비스 지향 아키텍처(SOA)는 단일 설계 [1]대신 개별 서비스에 초점을 맞춘 아키텍처 스타일입니다.결과적으로, 그것은 애플리케이션 구성요소에 의해, 네트워크를 통한 통신 프로토콜을 통해 다른 구성요소에 서비스가 제공되는 소프트웨어 설계 분야에도 적용된다.서비스는 원격으로 액세스하여 온라인으로 신용 카드 명세서를 검색하는 등 독립적으로 작동 및 업데이트할 수 있는 개별적인 기능 단위입니다.또한 SOA는 벤더, 제품 [2]및 기술로부터 독립되도록 의도되어 있습니다.

서비스 오리엔테이션은 서비스, 서비스 기반 개발 및 [1]서비스 결과에 대한 사고방식입니다.

서비스에는 [3]SOA의 여러 정의 중 하나에 따라 네 가지 속성이 있습니다.

  1. 이는 논리적으로 반복 가능한 비즈니스 활동을 나타내며 지정된 결과를 제공합니다.
  2. 그것은 자급자족이다.
  3. 소비자를 위한 블랙박스입니다. 즉, 소비자는 서비스의 내부 작동을 의식할 필요가 없습니다.
  4. 다른 [4]서비스로 구성될 수 있습니다.

다양한 서비스를 서비스 메시로 결합하여 모듈식 프로그래밍과 SOA가 공유하는 주요 소프트웨어 애플리케이션의 [5]기능을 제공할 수 있습니다.서비스 지향 아키텍처는 분산된 소프트웨어 컴포넌트, 개별적으로 유지보수된 소프트웨어 컴포넌트를 통합합니다.네트워크, 특히 IP 네트워크를 통한 컴포넌트의 통신과 협력을 촉진하는 테크놀로지 및 표준에 의해 실현됩니다.

SOA는 소프트웨어의 구현과 유지보수를 단순화하기 위한 컴퓨터 프로그램의 서로 다른 부분 간의 인터페이스 또는 통신 프로토콜인 API(애플리케이션 프로그래밍 인터페이스)의 아이디어와 관련이 있습니다.API는 서비스로, SOA는 서비스가 작동할 수 있도록 하는 아키텍처로 생각할 수 있습니다.

개요

SOA에서 서비스는 설명 메타데이터를 사용하여 메시지를 전달하고 구문 분석하는 방법을 설명하는 프로토콜을 사용합니다.이 메타데이터는 서비스의 기능적 특성과 서비스 품질 특성을 모두 설명합니다.서비스 지향 아키텍처는 사용자가 단순히 기존 서비스에서 구축한 애플리케이션을 형성하기 위해 대규모 기능 청크를 조합하여 애드혹 방식으로 결합할 수 있도록 하는 것을 목적으로 합니다.서비스는 블랙박스 역할을 하는 기본적인 복잡성을 추상화하는 단순한 인터페이스를 요청자에게 제공합니다.또한 사용자는 내부 [6]구현에 대한 지식 없이도 이러한 독립적인 서비스에 액세스할 수 있습니다.

개념의 정의

서비스 오리엔테이션이 추진하는 관련 유행어는 서비스 간의 느슨한 결합입니다.SOA는 사용자가 애플리케이션을 제작할 [7]때 기능을 결합하고 재사용할 수 있도록 개발자가 네트워크를 통해 액세스할 수 있도록 하는 개별 단위 또는 서비스로 구분합니다.이러한 서비스와 이에 대응하는 소비자는 명확하게 정의된 공유 형식으로 데이터를 전달하거나 둘 이상의 [8]서비스 간에 활동을 조정함으로써 서로 통신합니다.

2009년 10월에 서비스 지향 아키텍처에 관한 매니페스토가 발표되었습니다.여기에는 다음과 [9]같은 6개의 핵심값이 있습니다.

  1. 비즈니스 가치는 기술 전략보다 더 중요합니다.
  2. 전략적 목표는 프로젝트 고유의 이점보다 더 중요합니다.
  3. 고유의 상호 운용성은 커스텀 통합보다 중요합니다.
  4. 공유 서비스는 특정 목적의 구현보다 더 중요합니다.
  5. 최적화보다 유연성이 더 중요합니다.
  6. 진화적 정교함은 초기 완벽의 추구보다 더 중요하다.

SOA는 분산 컴퓨팅[7][10] 및 모듈식 프로그래밍의 오래된 개념에서 SOA를 통해 매시업, SaaS 및 클라우드 컴퓨팅(일부에서는 SOA의 [11]산물로 간주)에 이르기까지 다양한 연속체의 일부로 볼 수 있습니다.

원칙

서비스 지향 아키텍처의 정확한 구성과 관련된 업계 표준은 없지만, 많은 업계 소식통이 자체 원칙을 발표했습니다.그[12][13][14] 중 몇 가지는 다음과 같습니다.

표준화된 서비스 계약[15]
서비스는 표준 통신 계약에 준거합니다.이것은, 특정의 서비스 세트내의 1개 이상의 서비스 개요 문서에 의해서 일괄적으로 정의되고 있습니다.
서비스 참조 자율성(루즈 커플링의 한 측면)
서비스 간의 관계는 서비스 존재만 인식할 수 있는 수준으로 최소화됩니다.
서비스 로케이션의 투과성(루즈 커플링의 한 측면)
서비스는 존재하는 장소에 관계없이 네트워크 내의 임의의 장소에서 호출할 수 있습니다.
서비스 수명
서비스는 오래 사용할 수 있도록 설계되어야 합니다.가능한 한 새로운 기능이 필요하지 않은 경우 서비스를 통해 사용자에게 변경을 강요하지 않도록 해야 합니다.지금 바로 서비스를 호출하면 내일 동일한 서비스를 호출할 수 있습니다.
서비스 추상화
이 서비스는 블랙박스 역할을 하며, 이는 소비자로부터 숨겨진 내부 논리다.
서비스 자율성
서비스는 독립적이며 디자인 타임 및 런타임 관점에서 캡슐화된 기능을 제어합니다.
서비스 스테이트리스
서비스는 상태 비저장입니다. 즉, 요청된 값을 반환하거나 예외를 제공하여 리소스 사용을 최소화합니다.
서비스의 세분화
서비스의 규모와 범위가 적절한 것을 보증하는 원칙.서비스가 사용자에게 제공하는 기능은 관련이 있어야 합니다.
서비스 정규화
용장성을 최소화하기 위해 서비스를 분해 또는 통합(정규화)합니다.경우에 따라서는, 이것이 행해지지 않는 경우가 있습니다.퍼포먼스 최적화, 액세스 및 집약이 필요한 경우입니다.[16]
서비스 컴포넌트
서비스를 사용하여 다른 서비스를 구성할 수 있습니다.
서비스 검출
서비스는 효과적으로 검출 및 해석할 수 있는 통신 메타 데이터로 보완됩니다.
서비스 재사용 가능성
로직은 코드 재사용을 촉진하기 위해 다양한 서비스로 나뉩니다.
서비스 캡슐화
SOA에 따라 초기에 계획되지 않은 많은 서비스가 캡슐화되거나 SOA의 일부가 될 수 있습니다.

패턴

각 SOA 구성 요소는 다음 세 가지 역할 중 하나를 수행할 수 있습니다.

서비스 프로바이더
웹 서비스를 생성하여 서비스 레지스트리에 정보를 제공합니다.각 프로바이더는 보안 또는 용이한 가용성, 서비스 제공 가격 등 어떤 서비스를 공개해야 하는지, 어떤 서비스를 공개해야 하는지 등 다양한 방법과 이유에 대해 논의합니다.프로바이더는 또한 특정[17] 브로커 서비스에 대해 어떤 카테고리에 서비스를 나열해야 하는지, 그리고 서비스를 사용하려면 어떤 종류의 거래 파트너 계약을 체결해야 하는지 결정해야 합니다.
서비스 브로커, 서비스 레지스트리 또는 서비스 저장소
주요 기능은 잠재적인 요청자가 웹 서비스에 대한 정보를 이용할 수 있도록 하는 것입니다.브로커를 시행하는 자가 브로커의 범위를 결정한다.공공 브로커는 어디서나 이용할 수 있지만 민간 브로커는 제한된 수의 공공만이 이용할 수 있습니다.UDDI는 웹 서비스 디스커버리 제공을 적극적으로 지원하지 않는 초기 시도였습니다.
서비스 요청자/소비자
다양한 검색 작업을 사용하여 브로커 레지스트리에서 엔트리를 찾은 후 서비스 공급자에 바인드하여 웹 서비스 중 하나를 호출합니다.서비스 소비자가 필요로 하는 서비스는 브로커에게 전달하여 각 서비스와 결합하고 사용해야 합니다.서비스가 여러 서비스를 제공하는 경우 여러 서비스에 액세스할 수 있습니다.

서비스 소비자-공급자 관계는 비즈니스 부분,[18] 기능 부분 및 기술 부분으로 구성된 표준화된 서비스 계약에 의해 관리됩니다.

서비스 구성 패턴에는 안무와 오케스트레이션이라는 두 가지 광범위한 고급 아키텍처 스타일이 있습니다.특정 아키텍처 스타일에 얽매이지 않는 낮은 수준의 엔터프라이즈 통합 패턴은 SOA [19][20][21]설계에서 계속 적절하고 적격입니다.

구현 접근법

서비스 지향 아키텍처는 웹 서비스 또는 마이크로 [22]서비스를 사용하여 구현할 수 있습니다.이는 플랫폼 및 프로그래밍 언어에 독립적인 표준 인터넷 프로토콜을 통해 기능 구성요소에 액세스할 수 있도록 하기 위해 수행됩니다.이러한 서비스는, 새로운 애플리케이션을 나타내거나, 기존의 레거시 시스템을 랩핑 [23]해 네트워크 대응으로 하거나 할 수 있습니다.

구현자들은 일반적으로 웹 서비스 표준을 사용하여 SOA를 구축합니다.2003년 W3C[24](World Wide Web Consortium)에서 버전 1.2를 추천한 후 업계에서 널리 받아들여지고 있는 SOAP가 그 예입니다.이러한 표준(Web 서비스 사양이라고도 함)은 상호 운용성을 향상시키고, 록인으로부터 독자적인 벤더 소프트웨어에의 보호를 어느 정도 제공합니다.그러나 Jini, CORBA, Internet Communications Engine, REST 또는 gRPC와 같은 다른 서비스 기반 기술을 사용하여 SOA를 구현할 수도 있습니다.

아키텍처는 특정 테크놀로지에 의존하지 않고 운용할 수 있기 때문에 다음과 같은 다양한 테크놀로지를 사용하여 구현할 수 있습니다.

구현에서는 이러한 프로토콜 중 하나 이상을 사용할 수 있으며, 예를 들어 SOA 개념을 준수하는 프로세스 간에 정의된 인터페이스 사양에 따라 파일 시스템 메커니즘을 사용하여 데이터를 통신할 수 있습니다.중요한 것은 정의된 인터페이스를 사용하여 호출할 수 있는 독립형 서비스입니다.이러한 서비스는 호출된 어플리케이션에 대한 사전 지식이 없는 서비스나 실제로 서비스가 어떻게 작업을 수행하는지에 대한 지식이 필요한 애플리케이션 없이 표준적인 방법으로 작업을 표준 방식으로 작업을 수행할 수 있습니다.SOA를 통해 느슨하게 결합되고 상호 운용 가능한 서비스를 결합하여 구축된 애플리케이션을 개발할 수 있습니다.

이러한 서비스는 기반이 되는 플랫폼 및 프로그래밍 언어에 의존하지 않는 정식 정의(또는 WSDL 등)에 따라 상호 운용됩니다.인터페이스 정의에서는 언어 고유의 서비스 구현을 숨깁니다.따라서 SOA 기반 시스템은 개발 기술 및 플랫폼(예: Java )과 독립적으로 작동할 수 있습니다.NET 등).에서 실행되는 C#으로 기술된 서비스.예를 들어 Java EE 플랫폼에서 실행되는 Java로 작성된 NET 플랫폼 및 서비스는 공통 복합 애플리케이션(또는 클라이언트)에서 모두 사용할 수 있습니다.어느 플랫폼에서 실행되는 애플리케이션은 다른 플랫폼에서 실행되는 서비스를 재사용을 촉진하는 웹 서비스로 사용할 수도 있습니다.또한 관리 환경에서는 COBOL 레거시 시스템을 랩하여 소프트웨어 .[25]서비스로 제공할 수 있습니다.

BPEL과 같은 고급 프로그래밍 언어 및 WS-CDL 및 WS-Coordination과 같은 사양은 세분화된 서비스를 보다 세분화된 비즈니스 서비스로 정의 및 지원하는 방법을 제공함으로써 서비스 개념을 확장합니다. 설계자는 이를 워크플로우 및 구현된 비즈니스 프로세스에 통합할 수 있습니다.컴포지트 애플리케이션 또는 포털에서 사용할 수 있습니다.

서비스 지향 모델링은 SOA 실무자가 서비스 지향 자산을 개념화, 분석, 설계 및 설계하도록 안내하는 다양한 분야를 식별하는 SOA 프레임워크입니다.서비스 지향 모델링 프레임워크(SOMF)는 성공적인 서비스 지향 모델링 접근방식에 기여하는 다양한 구성요소를 나타내는 모델링 언어 및 작업 구조 또는 "지도"를 제공합니다.서비스 개발 계획의 "할 일" 측면을 식별하는 주요 요소를 설명합니다.이 모델을 통해 실무자는 프로젝트 계획을 수립하고 서비스 지향 이니셔티브의 이정표를 식별할 수 있습니다.또한 SOMF는 비즈니스 조직과 IT 조직 간의 조정을 다루기 위한 공통 모델링 표기법을 제공합니다.

Dirk Krafzig, Karl Banke 및 Dirk Slama의 SOA[26] 요소
SOA 메타 모델, The Linthicum Group, 2007

조직의 이점

일부 엔터프라이즈 설계자는 SOA가 기업이 변화하는 시장 상황에 [27]보다 신속하고 비용 효율적으로 대응할 수 있도록 지원할 수 있다고 믿고 있습니다.이러한 아키텍처 스타일은 마이크로(클래스) 레벨이 아닌 매크로(서비스) 레벨에서 재사용을 촉진합니다.또한 기존 IT(레거시) 자산과의 상호 연결 및 사용을 단순화할 수 있습니다.

SOA를 사용하면 조직이 문제를 전체적으로 볼 수 있습니다.기업은 전체적인 지배력을 가지고 있다.이론적으로 개발자가 원하는 툴셋을 사용하는 경우는 많지 않습니다.그러나 오히려 비즈니스 내에서 설정된 표준에 따라 코딩할 것입니다.또한 비즈니스 지향 인프라를 캡슐화하는 전사적 SOA를 개발할 수도 있습니다.SOA는 자동차 운전자에게 효율성을 제공하는 고속도로 시스템으로도 잘 알려져 있습니다.요점은 모든 사람이 차를 가지고 있지만 고속도로가 없다면, 모든 것이 제한되고 혼란스러워질 수 있다는 것입니다. 빠르고 효율적으로 어디든 가려고 시도하기 위해서입니다.IBM 웹 서비스 부사장 Michael Liebow는 SOA가 "[28]고속도로를 건설"한다고 말합니다.

어떤 면에서 SOA는 혁명이 아니라 아키텍처의 발전으로 간주될 수 있습니다.이전 소프트웨어 아키텍처의 베스트 프랙티스를 다수 소개합니다.예를 들어, 통신 시스템에서는 네트워크 내의 다른 기기와 통신하기 위해 진정한 정적 바인딩을 사용하는 솔루션의 개발이 거의 이루어지지 않았습니다.SOA 접근 방식을 채택함으로써, 이러한 시스템은 잘 정의되고 상호 운용성이 뛰어난 인터페이스의 중요성을 강조할 수 있습니다.SOA의 다른 이전 버전으로는 CORBA와 같은 원격 객체의 구성요소 기반 소프트웨어 엔지니어링과 객체 지향 분석 및 설계(OOAD)가 있습니다.

서비스는 공식적으로 정의된 인터페이스를 통해서만 사용할 수 있는 독립형 기능 유닛으로 구성됩니다.서비스는 생산과 개선이 용이한 일종의 '나노 기업'이 될 수 있다.또, 서비스는, 하위 서비스의 조정 업무로서 「메가 코퍼레이션」을 구축할 수 있다.

서비스 구현을 대규모 프로젝트와 별개의 프로젝트로 취급하는 이유는 다음과 같습니다.

  1. 분리를 통해 조직 내에서 흔히 볼 수 있는 크고 느린 프로젝트와는 별개로 신속하게 서비스를 제공할 수 있다는 개념이 비즈니스로 확산됩니다.기업은 서비스를 필요로 하는 시스템과 단순화된 사용자 인터페이스를 이해하기 시작합니다.민첩성을 추구합니다.즉, 비즈니스 혁신을 촉진하고 [29]출시 기간을 단축할 수 있습니다.
  2. 분리는 서비스와 소비 프로젝트의 분리를 촉진합니다.이는 서비스가 소비자가 누구인지 모르는 상태에서 설계된 한 좋은 디자인을 장려한다.
  3. 서비스의 문서 및 테스트 아티팩트는 대규모 프로젝트의 세부 사항 내에 포함되어 있지 않습니다.이것은 나중에 서비스를 재사용해야 할 때 중요합니다.

SOA는 테스트를 간접적으로 간소화할 것을 약속합니다.서비스는 자율적이고 스테이트리스하며 완전히 문서화된 인터페이스를 갖추고 구현의 교차 우려와는 별개입니다.조직이 적절하게 정의된 테스트 데이터를 보유하고 있는 경우 서비스 구축 시 테스트 데이터에 대응하는 스터브가 구축됩니다.서비스에 대한 회귀 테스트, 스크립트, 데이터 및 응답의 전체 세트도 캡처됩니다.이 서비스는 호출하는 서비스에 대응하는 기존 스터브를 사용하여 '블랙박스'로 테스트할 수 있습니다.테스트 환경은 기본 서비스와 범위 밖의 서비스가 스터브인 반면 메시의 나머지 부분은 완전한 서비스의 테스트 배치인 경우에 구축할 수 있습니다.각 인터페이스는 자체적인 회귀 테스트 문서 세트를 사용하여 완전히 문서화되어 있기 때문에 테스트 서비스의 문제를 쉽게 식별할 수 있습니다.테스트는 단순히 테스트 서비스가 문서에 따라 작동하는지 검증하고 환경 내 모든 서비스의 문서 및 테스트 사례에서 차이를 발견하도록 진화합니다.유휴 서비스의 데이터 상태를 관리하는 것만이 복잡합니다.

예를 들어 서비스를 유용하게 사용할 수 있는 수준으로 문서화하는 데 도움이 될 수 있습니다.Java Community Process 내의 일부 API 문서에는 좋은 예가 나와 있습니다.이것들은 완전하기 때문에, 스탭은 통상, 중요한 서브 세트만을 사용합니다.JSR-89 내의 'ossjsa.pdf' 파일이 그러한 [30]파일의 예입니다.

비판

SOA는 웹 [31]서비스와 통합되었지만, 웹 서비스는 SOA 스타일을 구성하는 패턴을 구현하는 하나의 옵션일 뿐입니다.원어민 또는 바이너리 형식의 리모트 프로시저 콜(RPC)이 없는 경우, 애플리케이션의 실행 속도가 느려지고 처리 능력이 향상되어 비용이 증가할 수 있습니다.대부분의 구현에서는 이러한 오버헤드가 발생하지만 SOA는 원격 프로시저 호출이나 XML 또는 JSON을 통한 변환에 의존하지 않는 기술(예: Java Business Integration(JBI), Windows Communication Foundation(WCF), 데이터 배포 서비스)을 사용하여 구현할 수 있습니다.동시에, 새롭게 등장한 오픈 소스 XML 구문 분석 기술(예: VTD-XML)과 다양한 XML 호환 이진 포맷은 SOA [32][33][34]성능을 크게 향상시킵니다.

스테이트풀 서비스에서는 컨슈머와 프로바이더가 모두 동일한 컨슈머 고유의 콘텍스트를 공유해야 합니다.컨슈머는 프로바이더와 컨슈머 간에 교환되는 메시지에 포함되거나 참조됩니다.이 제약에는 서비스 프로바이더가 각 사용자의 공유 컨텍스트를 유지할 필요가 있는 경우 서비스 프로바이더의 전체적인 scalability가 저하될 수 있다는 단점이 있습니다.또, 서비스 프로바이더와 소비자간의 결합을 증가시켜, 서비스 프로바이더의 전환을 더욱 [35]어렵게 합니다.궁극적으로 일부 비평가들은 SOA 서비스가 여전히 [36]SOA 서비스가 나타내는 애플리케이션에 의해 너무 제약을 받는다고 생각합니다.

서비스 지향 아키텍처가 직면한 주요 과제는 메타데이터 관리입니다.SOA 기반 환경에는 서로 통신하여 작업을 수행하는 많은 서비스가 포함됩니다.설계에는 여러 서비스가 연계되어 동작하는 경우가 있기 때문에 어플리케이션은 수백만 개의 메시지를 생성할 수 있습니다.추가 서비스는 다른 조직 또는 경쟁사에 속할 수 있으며, 이로 인해 큰 신뢰 문제가 발생할 수 있습니다.따라서 SOA 거버넌스는 사물의 [37]체계에 포함됩니다.

SOA가 직면한 또 다른 주요 문제는 통일된 테스트 프레임워크가 없다는 것입니다.서비스 지향 아키텍처에서 이러한 서비스를 테스트하는 데 필요한 기능을 제공하는 도구는 없습니다.문제의 주요 원인은 다음과 같습니다.[38]

  • 솔루션의 이질성과 복잡성.
  • Autonomous Service의 통합에 의해 대량의 테스트 조합이 실현됩니다.
  • 서로 다른 경쟁 벤더의 서비스 포함.
  • 플랫폼은 새로운 기능과 서비스의 가용성으로 인해 지속적으로 변화하고 있습니다.

확장 및 변형

이벤트 지향 아키텍처

주요 기사:이벤트 지향 아키텍처

응용 프로그램 프로그래밍 인터페이스

주요 기사:응용 프로그램 프로그래밍 인터페이스

Application Programming Interface(API; 응용 프로그램프로그래밍 인터페이스)는 개발자가 웹 응용 프로그램과 상호 작용할 수 있는 프레임워크입니다.

Web 2.0

Tim O'Reilly는 인식되고 빠르게 성장하는 웹 기반 애플리케이션 [39]세트를 설명하기 위해 "Web 2.0"이라는 용어를 만들었습니다.광범위한 커버리지를 경험한 토픽은 Web 2.0과 서비스 지향 아키텍처 [which?]간의 관계에 관한 것입니다.

SOA는 균일하게 정의된 인터페이스를 가진 서비스에 애플리케이션 로직을 캡슐화하고 이러한 로직을 발견 메커니즘을 통해 공개적으로 제공하는 철학입니다.복잡성 은폐와 재사용의 개념뿐만 아니라 느슨하게 결합된 서비스의 개념도 연구자들에게 SOA와 Web 2.0, 그리고 각각의 애플리케이션 간의 유사성에 대해 자세히 설명하도록 영감을 주었습니다.어떤 이들은 Web 2.0과 SOA가 상당히 다른 요소를 가지고 있어 "병렬 철학"으로 볼 수 없다고 주장하는 반면, 다른 이들은 두 가지 개념을 상호 보완적으로 간주하고 Web 2.0을 글로벌 [40]SOA로 간주합니다.

Web 2.0 및 SOA의 철학은 다양한 사용자 요구를 충족하므로 설계 및 실제 애플리케이션에 사용되는 기술과 관련하여 차이를 드러냅니다.그러나 2008년 현재, 사용 사례는 Web 2.0과 [40]SOA의 기술과 원칙을 결합하는 가능성을 입증했습니다.

마이크로 서비스

주요 기사:마이크로 서비스

마이크로 서비스는 분산 소프트웨어 시스템을 구축하는 데 사용되는 서비스 지향 아키텍처의 현대적인 해석입니다.마이크로 서비스[41] 아키텍처의 서비스는 목표를 달성하기 위해 네트워크를 통해 서로 통신하는 프로세스입니다.이러한 서비스에서는, 테크놀로지에 의존하지 [42]않는 프로토콜을 사용하고 있습니다.이 프로토콜은 언어 및 프레임워크의 선택을 캡슐화하는 데 도움이 되기 때문에, 서비스 내부에서 이러한 선택사항이 우려되고 있습니다.마이크로 서비스는 SOA에 대한 새로운 실현 및 구현 접근 방식으로서, 2014년(및 DevOps 도입 이후)부터 대중화되었으며 지속적인 배포와 기타 민첩한 [43]관행을 강조합니다.

일반적으로 합의된 마이크로 서비스의 정의는 없습니다.다음의 특징과 원칙은 문헌에서 찾을 수 있다.

  • 세밀한 인터페이스(독립적으로 전개 가능한 서비스를 위해),
  • 비즈니스 중심 개발(예: 도메인 중심 설계),
  • 이상적인 클라우드 애플리케이션 아키텍처,
  • 다중 언어 프로그래밍과 지속성,
  • 경량 컨테이너 전개,
  • 분산형 연속 전달 및
  • 전체적인 서비스 모니터링 기능을 갖춘 DevOps.

인터랙티브 애플리케이션을 위한 서비스 지향 아키텍처

실시간 응답 시간이 필요한 인터랙티브 애플리케이션(예: 지연 시간이 짧은 인터랙티브 3D 애플리케이션)은 이러한 종류의 애플리케이션의 특정 요구에 대응하는 특정 서비스 지향 아키텍처를 사용합니다.여기에는 예를 들어 낮은 지연 시간에 최적화된 분산 계산 및 통신, 리소스 및 인스턴스 [44][45][46]관리 등이 포함됩니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b "SOA Source Book - What Is SOA?". collaboration.opengroup.org. Retrieved March 30, 2021.
  2. ^ "Chapter 1: Service Oriented Architecture (SOA)". msdn.microsoft.com. Archived from the original on July 7, 2017. Retrieved September 21, 2016.
  3. ^ "Service-Oriented Architecture Standards - The Open Group". www.opengroup.org.
  4. ^ "What Is SOA?". www.opengroup.org. Archived from the original on August 19, 2016. Retrieved September 21, 2016.
  5. ^ Velte, Anthony T. (2010). Cloud Computing: A Practical Approach. McGraw Hill. ISBN 978-0-07-162694-1.
  6. ^ "Migrating to a service-oriented architecture, Part 1". December 9, 2008. Archived from the original on December 9, 2008. Retrieved September 21, 2016.{{cite web}}: CS1 maint: bot: 원래 URL 상태를 알 수 없습니다(링크).
  7. ^ a b Michael Bell (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. p. 3. ISBN 978-0-470-14111-3.
  8. ^ Michael Bell (2010). SOA Modeling Patterns for Service-Oriented Discovery and Analysis. Wiley & Sons. p. 390. ISBN 978-0-470-48197-4.
  9. ^ "SOA Manifesto". www.soa-manifesto.org. Retrieved September 21, 2016.
  10. ^ Thomas Erl (2005년 6월).원칙에 대해서.Serviceorientation.org
  11. ^ "Application Platform Strategies Blog: SOA is Dead; Long Live Services". Apsblog.burtongroup.com. January 5, 2009. Archived from the original on January 15, 2009. Retrieved August 13, 2012.
  12. ^ Yvonne Balzer SOA 프로젝트 계획 개선, IBM, 2004년 7월 16일
  13. ^ Microsoft Windows Communication Foundation team (2012). "Principles of Service Oriented Design". msdn.microsoft.com. Retrieved September 3, 2012.
  14. ^ SOA Systems Inc.의 Thomas Erl의 8가지 서비스 지향 원칙
  15. ^ "4.4 Guidelines for Using Web Service Contract Technologies - Anatomy of a Web Service Contract". InformIT. June 11, 2021. Retrieved September 9, 2021.
  16. ^ Tony Shan (2004). "Building a service-oriented e Banking platform". IEEE International Conference on Services Computing, 2004. (SCC 2004). Proceedings. 2004. pp. 237–244. doi:10.1109/SCC.2004.1358011. ISBN 978-0-7695-2225-8. S2CID 13156128.2004년
  17. ^ Duan, Yucong; Narendra, Nanjangud; Du, Wencai; Wang, Yongzhi; Zhou, Nianjun (2014). "Exploring Cloud Service Brokering from an Interface Perspective". 2014 IEEE International Conference on Web Services. IEEE. pp. 329–336. doi:10.1109/ICWS.2014.55. ISBN 978-1-4799-5054-6. S2CID 17957063.
  18. ^ Duan, Yucong (2012). "A Survey on Service Contract". 2012 13th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing. IEEE. pp. 805–810. doi:10.1109/SNPD.2012.22. ISBN 978-1-4673-2120-4. S2CID 1837914.
  19. ^ Olaf Zimmermann, Cesare Pautasso, Gregor Hohpe, Bobby Woolf (2016). "A Decade of Enterprise Integration Patterns". IEEE Software. 33 (1): 13–19. doi:10.1109/MS.2016.11.{{cite journal}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  20. ^ Rotem-Gal-Oz, Arnon (2012). SOA Patterns. Manning Publications. ISBN 978-1933988269.
  21. ^ Julisch, Klaus; Suter, Christophe; Woitalla, Thomas; Zimmermann, Olaf (2011). "Compliance by design – Bridging the chasm between auditors and IT architects" (PDF). Computers & Security. 30 (6–7): 410–426. CiteSeerX 10.1.1.390.3652. doi:10.1016/j.cose.2011.03.005.
  22. ^ Brandner, M., Craes, M., Oellermann, F., Zimmermann, O., Web Services-Orientive Architecture in the Financial Industry, Informatik-Spektrum 02/2004, Springer-Ver, 2004
  23. ^ "www.ibm.com". Retrieved September 10, 2016.
  24. ^ "SOAP Version 1.2 の公開について (W3C 勧告)" (in Japanese). W3.org. Retrieved August 13, 2012.
  25. ^ Okishima, Haruhiru (2006). ". "Case Study of System Architecture that use COBOL assets"" (PDF).
  26. ^ 엔터프라이즈 SOA.프렌티스 홀, 2005년
  27. ^ Christopher Koch 엔터프라이즈의 새로운 청사진, CIO Magazine, 2005년 3월 1일
  28. ^ 엘리자베스 밀라드(2005년 1월)."더 나은 프로세스 구축"컴퓨터 사용자페이지 20.
  29. ^ Brayan Zimmerli(2009년 11월 11일) SOA의 비즈니스 이점, 스위스 북서부 응용과학대학, 경영대학원
  30. ^ JSR-000089 OSS 서비스 액티베이션 API 사양 1.0 최종 릴리즈 sun.com
  31. ^ Joe McKendrick. "Bray: SOA too complex; 'just vendor BS'". ZDNet.
  32. ^ Jimmy Zhang (2008년 2월 20일) "Index XML Documents with VTD-XML" 2008년7월 4일 Wayback Machine에서 아카이브.XML 저널
  33. ^ Jimmy Zhang (2008년 8월 5일) "i-테크놀로지의 관점: 「바이너리 XML의 퍼포먼스 저하」.마이크로서비스 저널.
  34. ^ Jimmy Zhang (2008년 1월 9일) "XML 콘텐츠 Ximple Way 조작" devx.com
  35. ^ "The Reason SOA Isn't Delivering Sustainable Software". jpmorgenthal.com. June 19, 2009. Retrieved June 27, 2009.
  36. ^ "SOA services still too constrained by applications they represent". zdnet.com. June 27, 2009. Retrieved June 27, 2009.
  37. ^ "Governance Layer". www.opengroup.org. Retrieved September 22, 2016.
  38. ^ "How to Efficiently Test Service Oriented Architecture WSO2 Inc". wso2.com. Retrieved September 22, 2016.
  39. ^ "What Is Web 2.0". Tim O'Reilly. September 30, 2005. Retrieved June 10, 2008.
  40. ^ a b Christoph Schroth; Till Janner (2007). "Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services". IT Professional. 9 (3): 36–41. doi:10.1109/MITP.2007.60. S2CID 2859262. Retrieved February 23, 2008.
  41. ^ Dragoni, Nicola; Giallorenzo, Saverio; Alberto Lluch Lafuente; Mazzara, Manuel; Montesi, Fabrizio; Mustafin, Ruslan; Safina, Larisa (2016). "Microservices: yesterday, today, and tomorrow". arXiv:1606.04036v1 [cs.SE].
  42. ^ James Lewis and Martin Fowler. "Microservices".
  43. ^ Balalaie, A.; Heydarnoori, A.; Jamshidi, P. (May 1, 2016). "Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture" (PDF). IEEE Software. 33 (3): 42–52. doi:10.1109/MS.2016.64. hdl:10044/1/40557. ISSN 0740-7459. S2CID 18802650.
  44. ^ Frank Glinka; Allaithy Raed (2009). "A Service-Oriented Interface for Highly Interactive Distributed Applications". European Conference on Parallel Processing. Lecture Notes in Computer Science. 6043: 266–277. doi:10.1007/978-3-642-14122-5_31. ISBN 978-3-642-14121-8. Retrieved February 9, 2021.
  45. ^ Dieter Hildebrandt; Jan Klimke (2011). "Service-oriented interactive 3D visualization of massive 3D city models on thin clients". COM.Geo '11: Proceedings of the 2nd International Conference on Computing for Geospatial Research & Applications. COM.Geo '11: 1. doi:10.1145/1999320.1999326. ISBN 9781450306812. S2CID 53246415. Retrieved February 9, 2021.
  46. ^ Mahy Aly; Michael Franke (2016). "Service Oriented Interactive Media (SOIM) Engines Enabled by Optimized Resource Sharing". 2016 IEEE Symposium on Service-Oriented System Engineering (SOSE): 231–237. doi:10.1109/SOSE.2016.47. hdl:1854/LU-7215326. ISBN 978-1-5090-2253-3. S2CID 9511734. Retrieved February 9, 2021.
Wikimedia Commons에는 서비스 지향 아키텍처와 관련된 미디어가 있습니다.
이 기사 듣기(54분)
Spoken Wikipedia icon
이 오디오 파일은 2011년 10월 27일(2011-10-27) 본 문서의 개정판에서 작성되었으며 이후 편집 내용은 반영되지 않습니다.
(오디오 도움말, 기타 음성 기사)