맨위로가기

서비스 지향 아키텍처

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

서비스 지향 아키텍처(SOA)는 토마스 얼에 의해 조합 가능한 아키텍처로 정의되며, 비즈니스 로직과 기술 간의 느슨한 결합을 유도하는 소프트웨어 아키텍처이다. SOA는 기능을 서비스로 분리하여 개발자가 응용 프로그램을 제작할 때 이를 결합하고 재사용할 수 있도록 한다. SOA는 분산 컴퓨팅, 모듈식 프로그래밍, 매시업, SaaS, 클라우드 컴퓨팅으로 이어지는 연속체의 일부로 볼 수 있으며, 서비스 사용자, 서비스 제공자, 서비스 레지스트리로 구성된다. SOA는 서비스 안무와 오케스트레이션, 표준화된 서비스 계약을 통해 관리되며, 웹 서비스 또는 마이크로서비스로 구현될 수 있다. SOA는 웹 서비스와 혼동될 수 있으며, 메타데이터 관리, 통일된 테스트 프레임워크 부재 등의 비판을 받기도 한다. 마이크로서비스는 SOA의 현대적 해석이며, 웹 2.0과의 관계는 상호 보완적인 것으로 간주된다.

2. 정의

토마스 얼은 그의 저서 [http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788931549386&orderClick=LAG SOA 서비스 지향 아키텍처]에서 서비스 지향 아키텍처(SOA)를 다음과 같이 정의하고 있다. "최신 SOA는 공개, 기민성, 확장, 연합, 자립적 요소들로 구성된 조합가능한 아키텍처, 서비스 품질, 다양한 벤더, 상호 운영성, 서비스 발견 그리고 잠재적으로 재사용 가능한 서비스들이 웹서비스로 구현된다. SOA는 비지니스 로직과 기술을 추상화하여, 이 도메인 간에 느슨한 결합을 유도한다. SOA는 과거 플랫폼의 진화물로서, 전통적인 아키텍처의 특징들을 고스란히 가지고 있으며, 명확한 원칙을 가지고 SOE를 지원하며 서비스 지향을 촉진한다. SOA는 엔터프라이즈 환경을 이상적으로는 표준화하지만, 치밀한 사전 계획에 의한 이전 필요성과 현재도 진화하고 있는 기술에 대한 지원만이 이러한 목적을 달성할 수 있다."[9]

"Enterprise SOA(Dirk Krafzg, Karl Banke, Dirk Slama)"에서는 서비스 지향 아키텍처를 "애플리케이션 프론트엔드, 서비스, 서비스 리포지토리, 서비스 버스의 주요 개념에 바탕을 둔 소프트웨어 아키텍처이다. 서비스는 계약, 하나 이상의 인터페이스, 그에 대한 구현으로 이루어진다."라고 정의하고 있다.

W3C의 Web Service Architecture Working Group에서 활동하고 있는 Hao He 박사는 "상호 작동하는 시스템 사이를 느슨하게 연결하려는 목적을 가진 아키텍처(Service Oriented Architecture is an architectural style whose goal is to achieve loose coupling among interacting software agents)"라고 정의하고 있다.

서비스 지향과 관련된 유행어는 서비스 간의 ''느슨한 결합''을 촉진한다. SOA는 기능을 별개의 단위, 즉 서비스로 분리하며, 개발자는 사용자가 응용 프로그램을 제작할 때 이를 결합하고 재사용할 수 있도록 네트워크를 통해 접근할 수 있도록 한다. 이러한 서비스와 해당 소비자는 잘 정의되고 공유된 형식으로 데이터를 전달하거나, 둘 이상의 서비스 간의 활동을 조정하여 서로 통신한다.[10]

SOA는 분산 컴퓨팅[9][11] 및 모듈식 프로그래밍에서 SOA를 거쳐 매시업, SaaS, 클라우드 컴퓨팅(일부는 SOA의 파생물로 본다)에 이르는 연속체의 일부로 볼 수 있다.[12]

SOA에 필요한 조건은 다음과 같다.


  • 업무상 하나의 처리에 해당하는 단위로 소프트웨어가 구성되어 있을 것. SOA에서의 서비스는 그 구성 단위를 의미한다. 프로그램상의 부품이 아닌, 예를 들어 "결제한다", "재고 상황을 조회한다" 등과 같은 단위로 하나의 서비스로 구성하는 것이 요구된다. 어느 정도의 규모(입자성)로 하나의 서비스를 구성하는 것이 좋을지에 대해서는 다양한 논의가 있다.
  • 개방적이고 표준화된 기술 사양을 사용하여 서비스의 인터페이스가 정의되고, 이에 따른 호출, 응답이 가능할 것. 그 기술적 기반으로서 웹 서비스의 사용이 사실상 필수적이다(웹 서비스에 대해서는 후술).
  • 서비스를 네트워크 상에서 연계하여 시스템 전체를 신속하게 구축할 수 있을 것. 이 단계에 이르기까지 앞서 언급한 두 가지 조건이 필수적이다. 또한, 서비스를 단위로 업무 처리 흐름을 기술하는 기술과, 그 기술된 내용대로 시스템 연계를 실행하는 기술 또한 필요하다.

3. 구성 요소

SOA의 구성 요소는 다음과 같다.


  • 서비스 사용자(Service Consumer): 서비스 제공자가 제공하는 서비스를 사용한다.
  • 서비스 제공자(Service Provider): 서비스 사용자의 요청에 따라 기능을 수행하고 결과를 제공한다. 서비스 제공자는 다른 서비스 제공자의 서비스를 이용하는 서비스 사용자가 될 수도 있다.
  • 서비스 레지스트리(Service Registry): 서비스에 대한 설명을 저장한다. 서비스 제공자는 서비스를 등록하고, 서비스 사용자는 필요한 서비스를 찾아 사용한다.


각 SOA 구성 요소는 서비스 제공자, 서비스 브로커(서비스 레지스트리 또는 서비스 저장소), 서비스 요청자(소비자)의 세 가지 역할을 수행할 수 있다. 서비스 소비자와 제공자 관계는 표준화된 서비스 계약[19]에 의해 관리되며, 비즈니스, 기능, 기술 부분을 포함한다.

서비스 구성 패턴에는 안무(choreography)와 오케스트레이션(orchestration) 두 가지가 있다.

3. 1. 서비스

서비스는 명확한 기능적인 의미를 지닌 소프트웨어 컴포넌트로, 고차원의 비즈니스 개념을 캡슐화하고 있는 것을 말한다.[49] SOA의 관점에서 서비스는 인터페이스를 통해 자신이 가진 비즈니스 프로세스를 처리할 수 있는 컴포넌트로 정의된다. 서비스는 인터페이스와 구현 부분으로 구성되며, 다음과 같은 3가지 특징을 가진다.[50]

  • 서비스의 인터페이스는 플랫폼에 독립적이다.
  • 서비스는 동적으로 검색될 수 있으며, 호출될 수 있다.
  • 서비스는 self-contained하다. 즉, 자신의 상태를 스스로 유지한다.


SOA에서 서비스는 설명 메타데이터를 사용하여 메시지를 전달하고 구문 분석하는 방법을 설명하는 프로토콜을 사용한다. 이 메타데이터는 서비스의 기능적 특성과 서비스 품질 특성을 모두 설명한다. 서비스 지향 아키텍처는 사용자가 기존 서비스만으로 구축되고 임시 방식으로 결합된 응용 프로그램을 형성하기 위해 대규모 기능 덩어리를 결합할 수 있도록 하는 것을 목표로 한다. 서비스는 블랙 박스 역할을 하며 기본 복잡성을 추상화하는 간단한 인터페이스를 요청자에게 제공한다. 또한 사용자는 내부 구현에 대한 지식 없이 이러한 독립적인 서비스에 접근할 수 있다.[8]

서비스 지향과 관련된 유행어는 서비스 간의 ''느슨한 결합''을 촉진한다. SOA는 기능을 별개의 단위, 즉 서비스로 분리하며,[9] 개발자는 사용자가 응용 프로그램을 제작할 때 이를 결합하고 재사용할 수 있도록 네트워크를 통해 접근할 수 있도록 한다. 이러한 서비스와 해당 소비자는 잘 정의되고 공유된 형식으로 데이터를 전달하거나, 둘 이상의 서비스 간의 활동을 조정하여 서로 통신한다.[10]

SOA는 분산 컴퓨팅[9][11] 및 모듈식 프로그래밍에서 SOA를 거쳐 매시업, SaaS, 클라우드 컴퓨팅 (일부는 SOA의 파생물로 본다)에 이르는 연속체의 일부로 볼 수 있다.[12]

각 SOA 구성 요소는 다음 세 가지 역할을 수행할 수 있다.

역할설명
서비스 제공자웹 서비스를 생성하고 해당 정보를 서비스 레지스트리에 제공한다. 각 제공자는 노출할 서비스, 보안 또는 쉬운 가용성 중 무엇에 더 중요성을 부여할지, 서비스 가격을 얼마로 제공할지 등 많은 사항에 대해 고민한다. 또한 제공자는 주어진 브로커 서비스에 대해 서비스가 어떤 범주에 나열되어야 하는지[18], 서비스를 사용하기 위해 어떤 종류의 거래 파트너 계약이 필요한지를 결정해야 한다.
서비스 브로커, 서비스 레지스트리 또는 서비스 저장소웹 서비스와 관련된 정보를 잠재적 요청자에게 제공하는 것이 주요 기능이다. 브로커를 구현하는 사람은 브로커의 범위를 결정한다. 공용 브로커는 어디에서나 사용할 수 있지만, 개인 브로커는 제한된 수의 사람들에게만 제공된다. UDDI는 초기에 웹 서비스 검색을 제공하려는 시도였지만 현재는 적극적으로 지원되지 않는다.
서비스 요청자/소비자다양한 찾기 작업을 사용하여 브로커 레지스트리에서 항목을 찾아 서비스 제공자에 바인딩하여 해당 웹 서비스 중 하나를 호출한다. 서비스 소비자가 필요로 하는 서비스는 브로커에 가져와 해당 서비스에 바인딩한 다음 사용해야 한다. 서비스가 여러 서비스를 제공하는 경우 여러 서비스에 액세스할 수 있다.



서비스 소비자-제공자 관계는 표준화된 서비스 계약[19]에 의해 관리되며, 여기에는 비즈니스 부분, 기능 부분 및 기술 부분이 있다.

서비스 구성 패턴에는 안무(choreography)와 오케스트레이션(orchestration) 두 가지가 있다. 특정 아키텍처 스타일에 얽매이지 않는 하위 수준의 엔터프라이즈 통합 패턴은 SOA 설계에서 계속 관련성이 있으며 유효하다.[20][21][22]

SOA에 필요한 조건은 다음과 같다.


  • 업무상 하나의 처리에 해당하는 단위로 소프트웨어가 구성되어 있을 것. SOA에서의 서비스는 그 구성 단위를 의미한다. 프로그램상의 부품이 아닌, 예를 들어 "결제한다", "재고 상황을 조회한다" 등과 같은 단위로 하나의 서비스로 구성하는 것이 요구된다. 어느 정도의 규모(입자성)로 하나의 서비스를 구성하는 것이 좋을지에 대해서는 다양한 논의가 있다.
  • 개방적이고 표준화된 기술 사양을 사용하여 서비스의 인터페이스가 정의되고, 이에 따른 호출, 응답이 가능할 것. 그 기술적 기반으로서 웹 서비스의 사용이 사실상 필수적이다(웹 서비스에 대해서는 후술).
  • 서비스를 네트워크 상에서 연계하여 시스템 전체를 신속하게 구축할 수 있을 것. 이 단계에 이르기까지 앞서 언급한 두 가지 조건이 필수적이다. 또한, 서비스를 단위로 업무 처리 흐름을 기술하는 기술과, 그 기술된 내용대로 시스템 연계를 실행하는 기술 또한 필요하다.


SOA로 이어지는 생각과 기술은 오래전부터 존재해 왔다. 객체 지향과 컴포넌트 지향은 정해진 인터페이스에 따라 소프트웨어의 일부분을 캡슐화하고 부품화하여 그것들을 조합하여 전체를 구성한다는 생각을 기본으로 한다. 또한 분산 객체, 메시징, EAI (전사적 애플리케이션 통합) 등의 기술을 사용하여 네트워크를 통해 소프트웨어를 연계(느슨한 결합)시키는 것은 대규모 시스템에서는 이미 어느 정도 실시되고 있다.

하지만 객체 지향이나 컴포넌트 지향에서는 주로 프로그램상의 부품을 소프트웨어의 구성 단위로 하고 있어, 업무 처리의 변화를 시스템의 변경에 빠르게 반영하고 싶다는 관점에서는 단위가 너무 작다고 여겨진다.

또한 기존의 시스템 연계 기술은 특정 소프트웨어 기반의 사용을 전제로 하거나, 연계하기 위해 필요한 작업이나 절차가 복잡하다. 이러한 이유로 시스템 연계의 속도와 비용에 대한 문제점이 지적되었다. 이러한 문제를 해결하기 위한 기술 또는 개념으로서 2000년경부터 웹 서비스가 제창되었다.

하지만 초기의 웹 서비스는 현재의 SOA와 유사한 구상이 이미 제창되었음에도 불구하고, 구현 기술로는 웹을 통한 소프트웨어의 연계 자체에 주안점이 놓여 있었다. 또한 연계하는 개별 소프트웨어(서비스)를 시스템 전체에서 어떻게 위치시킬 것인가(서비스의 세분성의 기준을 무엇으로 할 것인가), 다수의 서비스를 연계시키는 복잡한 트랜잭션 처리를 어떻게 설계하고 구현할 것인가와 같은 사항들이 과제로 남아 있었다. 그 후, 웹 서비스의 개념과 기술의 확장에 따라 2004년경부터 "웹 서비스"를 대신하여 "SOA"가 키워드로 주목받게 되었다.

이러한 과제에 대한 대책으로서 포틀릿 프레임워크가 주목받고 있다. 객체 지향과 컴포넌트 지향은 기본적인 IT 부품의 재사용을 고려하는 경우가 많다. 포틀릿 프레임워크의 경우에는 최종 사용자가 직접 이용하는 웹 페이지상의 기능의 재사용을 목표로 하고 있다. 또한 객체나 컴포넌트를 최종 사용자가 이용하는 경우에는 별도의 프로그램이 필요했기 때문에, 사용자와 개발자의 생각에 차이가 있는 경우가 있었다. 포틀릿 프레임워크의 경우에는, 사용자가 요구하는 기능마다 플러그인으로 구현한다. 플러그인에는 웹 페이지에 배치할 수 있는 복수의 포틀릿을 포함할 수 있다.

객체 및 컴포넌트와 달리 플러그인마다 애플리케이션 서버에 추가/변경/삭제할 수 있다. 또한, 설치된 플러그인에 포함된 포틀릿을 최종 사용자가 드래그 앤 드롭 처리로 웹 페이지에 배치할 수 있다. 즉, 최종 사용자가 이용하는 비즈니스 기능을 웹 페이지에 배치하여 이용할 수 있다.

또한, 포틀릿마다 표시, 엔티티 인터페이스, 비즈니스 로직이 포함되어 있다. 따라서 기술에 의해 비의존적이다. 예를 들어, JSF로 작성된 포틀릿과 SpringFramework로 작성된 포틀릿을 하나의 웹 페이지에 배치하는 것도 가능하다. 또한, PHP로 작성된 포틀릿과 유사한 기능을 가진 Java의 포틀릿으로 대체하는 것도 가능하다.

포틀릿 간 통신은 Java API, Java RMI, Web Service, JSON 등으로 할 수 있다. 이러한 프로토콜용 API는 포틀릿 프레임워크가 동일한 기능을 제공한다.

오픈 소스 포틀릿 프레임워크의 예로 Liferay가 있다.

3. 2. 메시지

SOA에서 메시지는 중요한 개념이다. 서비스 제공자와 사용자는 메시지를 통해 서로 통신한다. 서비스 제공자는 서비스 명세를 통해 자신의 서비스 인터페이스를 공개하며, 이 명세에는 서비스 기능과 사용자와 주고받아야 하는 메시지 형식이 정의되어 있다. SOA에서 서비스는 플랫폼 독립적이어야 하므로, 메시지 또한 특정 기술에 독립적이어야 한다.[50]

SOA에서 서비스는 메타데이터를 사용하여 메시지를 전달하고 구문 분석하는 방법을 설명하는 프로토콜을 사용한다. 이 메타데이터는 서비스의 기능 및 품질 특성을 모두 설명한다. SOA는 사용자가 기존 서비스만으로 구축되고 임시 결합된 응용 프로그램을 형성하기 위해 대규모 기능을 결합할 수 있도록 한다. 서비스는 블랙 박스 역할을 하여 기본 복잡성을 추상화하는 간단한 인터페이스를 제공하며, 사용자는 내부 구현을 알 필요 없이 이러한 독립적인 서비스에 접근할 수 있다.[8]

웹 서비스에서는 다음 세 가지가 기본적인 기술 요소이며, 모두 메시지 및 정의 기술에 XML을 사용한다.

기술 요소설명
SOAP서비스 간 호출, 응답 프로토콜 (HTTP 등을 하위 프로토콜로 사용). HTTP 외 프로토콜도 사용 가능하지만, 방화벽 통과에 어려움이 있어 대부분 HTTP를 기본으로 한다.
WSDLSOAP를 이용한 서비스 호출, 응답 인터페이스 등을 정의하는 언어.
UDDIWSDL로 기술된 서비스 정보를 등록, 검색하는 기술 (UDDI 자체도 웹 서비스로 제공되며, SOAP로 호출, 응답).


4. 특징

서비스 지향 아키텍처(SOA)는 다음과 같은 특징을 갖는다.[50]


  • 동적 발견 및 바인딩: 서비스는 발견이 가능하고 동적으로 바인딩된다.
  • 모듈성: 서비스는 컴포넌트와 같이 독립된 모듈이다.
  • 상호 운용성: 서비스는 플랫폼 간 상호 운용이 가능하다.
  • 느슨한 결합: 서비스는 느슨하게 연결된다.
  • 네트워크 접근성: 서비스는 네트워크 주소로 접근 가능한 인터페이스를 갖는다.
  • 위치 투명성: 서비스는 위치 투명성을 제공한다.
  • 조립 가능성: 서비스의 조립이 가능하다.
  • 자기 치유: 서비스는 자기 치유(self-healing)를 지원한다.

5. 원칙

Service-oriented architecture|서비스 지향 아키텍처영어의 정확한 구성에 관한 산업 표준은 없지만, 많은 업계 자료에서 자체 원칙을 발표했다.[13][14][15] 이러한 원칙들은 다음과 같다.


  • '''표준화된 서비스 계약'''[16]: 서비스는 주어진 서비스 집합 내에서 하나 이상의 서비스 설명 문서에 의해 집합적으로 정의된 표준 통신 계약을 준수한다.
  • '''서비스 참조 자율성 (느슨한 결합의 한 측면)''': 서비스 간의 관계는 서비스의 존재만 인식하는 수준으로 최소화된다.
  • '''서비스 위치 투명성 (느슨한 결합의 한 측면)''': 서비스는 위치에 관계없이 네트워크 내 어디에서나 호출할 수 있다.
  • '''서비스 수명''': 서비스는 오래 지속되도록 설계되어야 한다. 가능한 경우 서비스는 소비자가 새로운 기능을 필요로 하지 않는 경우 변경하도록 강요하는 것을 피해야 하며, 오늘 서비스를 호출할 수 있다면 내일도 동일한 서비스를 호출할 수 있어야 한다.
  • '''서비스 추상화''': 서비스는 블랙 박스 역할을 한다. 즉, 내부 로직은 소비자에게 숨겨진다.
  • '''서비스 자율성''': 서비스는 설계 시간 및 런타임 관점에서 캡슐화하는 기능을 독립적으로 제어한다.
  • '''서비스 무상태성''': 서비스는 무상태적이다. 즉, 요청된 값을 반환하거나 예외를 발생시켜 리소스 사용을 최소화한다.
  • '''서비스 세분성''': 서비스가 적절한 크기와 범위를 갖도록 하는 원칙이다. 사용자에게 제공되는 서비스의 기능은 관련성이 있어야 한다.
  • '''서비스 정규화''': 서비스는 중복을 최소화하기 위해 분해되거나 통합(정규화)된다. 일부에서는 이 작업을 수행하지 않을 수 있다. 이러한 경우는 성능 최적화, 액세스 및 집계가 필요한 경우이다.[17]
  • '''서비스 구성 가능성''': 서비스를 사용하여 다른 서비스를 구성할 수 있다.
  • '''서비스 검색''': 서비스는 효과적으로 검색하고 해석할 수 있는 통신 메타 데이터로 보완된다.
  • '''서비스 재사용성''': 코드를 재사용하기 위해 로직을 다양한 서비스로 나눈다.
  • '''서비스 캡슐화''': SOA에서 처음 계획되지 않은 많은 서비스가 캡슐화되거나 SOA의 일부가 될 수 있다.

6. 구현 방식

웹 서비스 또는 마이크로서비스로 구현될 수 있다.[23] 이는 플랫폼 및 프로그래밍 언어에 독립적인 표준 인터넷 프로토콜을 통해 기능적 빌딩 블록에 접근할 수 있도록 하기 위함이다. 이러한 서비스는 새로운 애플리케이션을 나타내거나 기존 레거시 시스템을 네트워크에 사용할 수 있도록 하는 래퍼 역할을 할 수 있다.[24]

구현자는 일반적으로 웹 서비스 표준을 사용하여 SOA를 구축한다. 한 가지 예시는 SOAP이며, 2003년 W3C(World Wide Web Consortium)에서 버전 1.2를 권고한 이후 광범위한 산업적 수용을 얻었다.[25] 이러한 표준(웹 서비스 명세라고도 함)은 또한 상호 운용성을 높이고 독점적인 공급업체 소프트웨어에 묶이는 것을 일부 방지한다. 그러나 Jini, CORBA, 인터넷 통신 엔진, REST, 또는 gRPC와 같은 다른 서비스 기반 기술을 사용하여 SOA를 구현할 수도 있다.

아키텍처는 특정 기술에 독립적으로 작동할 수 있으므로 다음과 같은 광범위한 기술을 사용하여 구현할 수 있다.

기술
WSDL 및 SOAP 기반의 웹 서비스
메시징 (예: ActiveMQ, JMS, RabbitMQ)
REST가 자체 제약 기반 아키텍처 스타일을 구성하는 RESTful HTTP
DDS
OPC-UA
인터넷 통신 엔진
WCF (Microsoft의 웹 서비스 구현, WCF의 일부를 형성)
Apache Thrift
gRPC
SORCER



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

이러한 서비스는 기본 플랫폼 및 프로그래밍 언어에 독립적인 공식적인 정의(또는 계약, 예를 들어 WSDL)를 기반으로 상호 작용한다. 인터페이스 정의는 언어별 서비스의 구현을 숨긴다. 따라서 SOA 기반 시스템은 개발 기술 및 플랫폼(예: Java, .NET 등)에 독립적으로 작동할 수 있다. 예를 들어 .NET 플랫폼에서 실행되는 C#으로 작성된 서비스와 Java EE 플랫폼에서 실행되는 Java로 작성된 서비스는 공통 복합 애플리케이션(또는 클라이언트)에서 모두 사용할 수 있다. 두 플랫폼에서 실행되는 애플리케이션은 재사용을 용이하게 하는 웹 서비스로서 다른 플랫폼에서 실행되는 서비스도 사용할 수 있다. 관리형 환경은 또한 COBOL 레거시 시스템을 래핑하여 소프트웨어 서비스로 제공할 수 있다.[26]

고급 프로그래밍 언어인 BPEL 및 WS-CDL 및 WS-Coordination과 같은 명세는 세분화된 서비스를 보다 광범위한 비즈니스 서비스로 조정하고 지원하는 방법을 제공하여 서비스 개념을 확장하며, 아키텍트는 이를 차례로 복합 애플리케이션 또는 포털에서 구현된 워크플로우 및 비즈니스 프로세스에 통합할 수 있다.

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

7. 기술적 기반

서비스 지향 아키텍처(SOA)는 웹 서비스 또는 마이크로서비스로 구현될 수 있다.[23] 이는 플랫폼 및 프로그래밍 언어에 독립적인 표준 인터넷 프로토콜을 통해 기능적 빌딩 블록에 접근할 수 있도록 하기 위함이다. 이러한 서비스는 새로운 애플리케이션을 나타내거나 기존 레거시 시스템을 네트워크에 사용할 수 있도록 하는 래퍼 역할을 할 수 있다.[24]

구현자는 일반적으로 웹 서비스 표준을 사용하여 SOA를 구축한다. 한 가지 예시는 SOAP이며, 2003년 W3C(World Wide Web Consortium)에서 버전 1.2를 권고한 이후 광범위한 산업적 수용을 얻었다.[25] 이러한 표준(웹 서비스 명세라고도 함)은 또한 상호 운용성을 높이고 독점적인 공급업체 소프트웨어에 묶이는 것을 일부 방지한다. 그러나 Jini, CORBA, 인터넷 통신 엔진, RESTful, 또는 gRPC와 같은 다른 서비스 기반 기술을 사용하여 SOA를 구현할 수도 있다.

아키텍처는 특정 기술에 독립적으로 작동할 수 있으므로 다음과 같은 광범위한 기술을 사용하여 구현할 수 있다.

기술 종류세부 기술
웹 서비스WSDL 및 SOAP 기반의 웹 서비스
메시징ActiveMQ, JMS, RabbitMQ
RESTful HTTPREST가 자체 제약 기반 아키텍처 스타일을 구성
기타DDS, OPC-UA, 인터넷 통신 엔진, WCF, Apache Thrift, gRPC, SORCER



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

이러한 서비스는 기본 플랫폼 및 프로그래밍 언어에 독립적인 공식적인 정의(또는 계약, 예를 들어 WSDL)를 기반으로 상호 작용한다. 인터페이스 정의는 언어별 서비스의 구현을 숨긴다. 따라서 SOA 기반 시스템은 개발 기술 및 플랫폼(예: Java, .NET 등)에 독립적으로 작동할 수 있다. 예를 들어 .NET 플랫폼에서 실행되는 C#으로 작성된 서비스와 Java EE 플랫폼에서 실행되는 Java로 작성된 서비스는 공통 복합 애플리케이션(또는 클라이언트)에서 모두 사용할 수 있다. 두 플랫폼에서 실행되는 애플리케이션은 재사용을 용이하게 하는 웹 서비스로서 다른 플랫폼에서 실행되는 서비스도 사용할 수 있다. 관리형 환경은 또한 COBOL 레거시 시스템을 래핑하여 소프트웨어 서비스로 제공할 수 있다.[26]

고급 프로그래밍 언어인 BPEL 및 WS-CDL 및 WS-Coordination과 같은 명세는 세분화된 서비스를 보다 광범위한 비즈니스 서비스로 조정하고 지원하는 방법을 제공하여 서비스 개념을 확장하며, 아키텍트는 이를 차례로 복합 애플리케이션 또는 포털에서 구현된 워크플로우 및 비즈니스 프로세스에 통합할 수 있다.

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

SOA에 필요한 조건은 다음과 같다.


  • 업무상 하나의 처리에 해당하는 단위로 소프트웨어가 구성되어 있을 것. SOA에서의 서비스는 그 구성 단위를 의미한다. 프로그램상의 부품이 아닌, 예를 들어 "결제한다", "재고 상황을 조회한다" 등과 같은 단위로 하나의 서비스로 구성하는 것이 요구된다.
  • 개방적이고 표준화된 기술 사양을 사용하여 서비스의 인터페이스가 정의되고, 이에 따른 호출, 응답이 가능할 것. 그 기술적 기반으로서 웹 서비스의 사용이 사실상 필수적이다.
  • 서비스를 네트워크 상에서 연계하여 시스템 전체를 신속하게 구축할 수 있을 것.


SOA로 이어지는 생각과 기술은 오래전부터 존재해 왔다. 객체 지향과 컴포넌트 지향은 정해진 인터페이스에 따라 소프트웨어의 일부분을 캡슐화하고 부품화하여 그것들을 조합하여 전체를 구성한다는 생각을 기본으로 한다. 또한 분산 객체, 메시징, EAI (전사적 애플리케이션 통합) 등의 기술을 사용하여 네트워크를 통해 소프트웨어를 연계(느슨한 결합)시키는 것은 대규모 시스템에서는 이미 어느 정도 실시되고 있다.

하지만 객체 지향이나 컴포넌트 지향에서는 주로 프로그램상의 부품을 소프트웨어의 구성 단위로 하고 있어, 업무 처리의 변화를 시스템의 변경에 빠르게 반영하고 싶다는 관점에서는 단위가 너무 작다고 여겨진다.

또한 기존의 시스템 연계 기술은 특정 소프트웨어 기반의 사용을 전제로 하거나, 연계하기 위해 필요한 작업이나 절차가 복잡하다. 이러한 이유로 시스템 연계의 속도와 비용에 대한 문제점이 지적되었다. 이러한 문제를 해결하기 위한 기술 또는 개념으로서 2000년경부터 웹 서비스가 제창되었다.

하지만 초기의 웹 서비스는 현재의 SOA와 유사한 구상이 이미 제창되었음에도 불구하고, 구현 기술로는 웹을 통한 소프트웨어의 연계 자체에 주안점이 놓여 있었다. 또한 연계하는 개별 소프트웨어(서비스)를 시스템 전체에서 어떻게 위치시킬 것인가(서비스의 세분성의 기준을 무엇으로 할 것인가), 다수의 서비스를 연계시키는 복잡한 트랜잭션 처리를 어떻게 설계하고 구현할 것인가와 같은 사항들이 과제로 남아 있었다. 그 후, 웹 서비스의 개념과 기술의 확장에 따라 2004년경부터 "웹 서비스"를 대신하여 "SOA"가 키워드로 주목받게 되었다.

이러한 과제에 대한 대책으로서 포틀릿 프레임워크가 주목받고 있다. 객체 지향과 컴포넌트 지향은 기본적인 IT 부품의 재사용을 고려하는 경우가 많다. 포틀릿 프레임워크의 경우에는 최종 사용자가 직접 이용하는 웹 페이지상의 기능의 재사용을 목표로 하고 있다. 또한 객체나 컴포넌트를 최종 사용자가 이용하는 경우에는 별도의 프로그램이 필요했기 때문에, 사용자와 개발자의 생각에 차이가 있는 경우가 있었다. 포틀릿 프레임워크의 경우에는, 사용자가 요구하는 기능마다 플러그인으로 구현한다. 플러그인에는 웹 페이지에 배치할 수 있는 복수의 포틀릿을 포함할 수 있다.

객체 및 컴포넌트와 달리 플러그인마다 애플리케이션 서버에 추가/변경/삭제할 수 있다. 또한, 설치된 플러그인에 포함된 포틀릿을 최종 사용자가 드래그 앤 드롭 처리로 웹 페이지에 배치할 수 있다. 즉, 최종 사용자가 이용하는 비즈니스 기능을 웹 페이지에 배치하여 이용할 수 있다.

또한, 포틀릿마다 표시, 엔티티 인터페이스, 비즈니스 로직이 포함되어 있다. 따라서 기술에 의해 비의존적이다. 예를 들어, JSF로 작성된 포틀릿과 SpringFramework로 작성된 포틀릿을 하나의 웹 페이지에 배치하는 것도 가능하다. 또한, PHP로 작성된 포틀릿과 유사한 기능을 가진 Java의 포틀릿으로 대체하는 것도 가능하다.

포틀릿 간 통신은 Java API, Java RMI, Web Service, JSON 등으로 할 수 있다. 이러한 프로토콜용 API는 포틀릿 프레임워크가 동일한 기능을 제공한다.

오픈 소스 포틀릿 프레임워크의 예로 Liferay가 있다.

현재 제안된 SOA가 전제로 하는 시스템 연동을 위한 기술적 기반은 대부분의 경우 웹 서비스이다. 웹 서비스는 XML(Extensible Markup Language)이나 HTTP(Hypertext Transfer Protocol) 등 인터넷 표준 기술을 기반으로 하며, SOA 구현에 필요한 사항을 기술적으로 지원한다. 순수한 개념적 논의를 하자면, SOA를 구현하는 기술을 웹 서비스에 한정할 필요는 없다. 그러나 ESB와 같은 기술을 사용하지 않고, SOA 구현에 필요한 인터페이스의 표준화나 제품 구현이 진전되지 않은 업계 동향을 고려해 볼 때, 웹 서비스의 사용이 사실상 필수적인 상황이다. 다만, 웹 서비스는 단지 SOA의 기술적인 한 요소일 뿐이다. 웹 서비스를 사용했다고 해서 SOA라고 할 수는 없다.

웹 서비스에서는 다음 세 가지가 기본적인 기술 요소로 여겨진다. 이들은 모두 메시지 및 정의를 기술하는 데 XML을 사용한다.

  • SOAP(Simple Object Access Protocol): 서비스 간 호출, 응답 프로토콜
  • WSDL(Web Services Description Language): SOAP를 이용한 서비스 호출, 응답의 인터페이스 등을 정의하는 언어.
  • UDDI(Universal Description, Discovery, and Integration): WSDL로 기술된 서비스의 정보를 등록, 검색 가능하게 하는 기술


이 외에도 다수의 서비스 간 복잡한 연동을 설계하기 위한 기술 사양으로 BPEL(Business Process Execution Language) 및 BPMN(Business Process Modeling Notation)이 등장했다. 또한, 설계된 서비스 연동을 실행하기 위한 기술로 ESB(Enterprise Service Bus)가 등장했다.

BPEL은 업무 처리 프로세스(서비스를 연동하는 순서 및 규칙)를 기술하는 언어이다. 서비스의 연동에 대해 기술하는 동시에 개별 서비스의 인터페이스를 기술한 WSDL 형식의 데이터도 지정한다. BPEL과 WSDL을 통해 서비스 연동의 기술과 개별 서비스를 분리하여 유연하고 용이한 느슨한 결합이 가능해진다.

BPMN은 업무 처리 프로세스(서비스를 연동하는 순서 및 규칙)를 그림으로 기술하기 위한 시각화 표기법이다. BPMN을 사용하여 작성한 그림은 BPEL 형식의 기술로 변환할 수 있다.

ESB는 서비스 간을 연결하는 중계 버스 역할을 담당하는 기술 또는 그 구현 제품을 의미하는 단어이다. 서비스를 1:1로 직접 P2P 연결하는 경우에 비해 ESB를 사용하면 다수의 서비스 간 연결을 집중적으로 관리, 감시할 수 있게 된다.

개별 서비스(소프트웨어)의 구현에는 임의의 기술을 사용할 수 있다. 다만, 웹 서비스 또는 SOA의 제품 구현에서는 Java 또는 .NET의 사용이 우선시된다. 기존 기술(예: 메인프레임 계열 기술)을 사용하고 있는 시스템을 서비스로 활용하는 경우, 해당 인터페이스를 생성하는 데 Java 등을 사용하는 것이 일반적이다.

8. 비판

SOA는 웹 서비스와 혼동되어 왔다.[32] 그러나 웹 서비스는 SOA 스타일을 구성하는 패턴을 구현하는 한 가지 옵션일 뿐이다. 기본 또는 바이너리 형태의 원격 프로시저 호출(RPC)이 없는 경우, 애플리케이션은 더 느리게 실행될 수 있고 더 많은 처리 능력을 필요로 하여 비용이 증가할 수 있다. 대부분의 구현은 이러한 오버헤드를 발생시키지만, SOA는 자바 비즈니스 통합(JBI), 윈도우 커뮤니케이션 파운데이션(WCF), 데이터 배포 서비스(DDS)와 같이 원격 프로시저 호출이나 XML 또는 JSON을 통한 변환에 의존하지 않는 기술을 사용하여 구현할 수 있다. 동시에, VTD-XML과 같은 새롭게 등장하는 오픈 소스 XML 파싱 기술과 다양한 XML 호환 바이너리 형식은 SOA 성능을 크게 향상시킬 것을 약속한다.[33][34][35]

상태 유지 서비스는 소비자별 컨텍스트를 소비자와 제공자 모두 공유해야 하며, 이는 제공자와 소비자 간에 교환되는 메시지에 포함되거나 참조된다. 이 제약은 서비스 제공자가 각 소비자에 대해 공유 컨텍스트를 유지해야 하는 경우 서비스 제공자의 전체 확장성을 감소시킬 수 있다는 단점이 있다. 또한 서비스 제공자와 소비자 간의 결합도를 증가시키고 서비스 제공자 전환을 더 어렵게 만든다.[36] 궁극적으로 일부 비평가들은 SOA 서비스가 여전히 표현하는 애플리케이션에 의해 너무 제약받는다고 생각한다.[37]

서비스 지향 아키텍처가 직면한 주요 과제는 메타데이터 관리이다. SOA 기반 환경은 작업을 수행하기 위해 서로 통신하는 많은 서비스를 포함한다. 설계가 여러 서비스가 함께 작동하는 것을 포함할 수 있다는 사실 때문에 애플리케이션은 수백만 개의 메시지를 생성할 수 있다. 또한 서비스는 서로 다른 조직이나 경쟁 회사에 속할 수 있으며, 이는 거대한 신뢰 문제를 야기한다. 따라서 SOA 거버넌스가 이 계획에 포함된다.[38]

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

어려움의 주요 원인
솔루션의 이질성과 복잡성
자율 서비스 통합으로 인한 방대한 테스트 조합
서로 다른 경쟁 벤더의 서비스 포함
플랫폼은 새로운 기능과 서비스의 가용성으로 인해 지속적으로 변경되고 있음


9. 확장 및 변형

팀 오라일리는 빠르게 성장하는 웹 기반 애플리케이션 집합을 설명하기 위해 "웹 2.0"이라는 용어를 만들었다.[40] 웹 2.0과 서비스 지향 아키텍처(SOA) 간의 관계는 광범위하게 다루어진 주제이다.

SOA는 균일하게 정의된 인터페이스를 가진 서비스로 애플리케이션 로직을 캡슐화하고 검색 메커니즘을 통해 이를 공개적으로 사용할 수 있도록 하는 철학이다. 복잡성 숨기기, 재사용, 서비스의 느슨한 결합이라는 개념은 연구자들이 SOA와 웹 2.0이라는 두 철학 간의 유사점과 각 애플리케이션에 대해 자세히 설명하도록 영감을 주었다. 일부는 웹 2.0과 SOA가 상당히 다른 요소를 가지고 있으므로 "병렬 철학"으로 간주될 수 없다고 주장하는 반면, 다른 사람들은 두 개념을 상호 보완적인 것으로 간주하고 웹 2.0을 글로벌 SOA로 간주한다.[41]

웹 2.0과 SOA의 철학은 서로 다른 사용자 요구를 충족하므로 설계 측면과 실제 애플리케이션에서 사용되는 기술 측면에서 차이점을 보인다. 하지만, 2008년 기준으로 사용 사례는 웹 2.0과 SOA의 기술과 원리를 결합할 수 있는 잠재력을 보여주었다.[41]

마이크로서비스는 분산 컴퓨팅 시스템을 구축하는 데 사용되는 서비스 지향 아키텍처의 현대적 해석이다. 마이크로서비스 아키텍처의 서비스[42]는 목표를 달성하기 위해 컴퓨터 네트워크를 통해 서로 통신하는 프로세스 (컴퓨팅)이다. 이러한 서비스는 기술에 구애받지 않는 통신 프로토콜을 사용[43]하며, 이는 언어 및 프레임워크 선택을 캡슐화하는 데 도움이 되어 선택을 서비스 내부 문제로 만듭니다. 마이크로서비스는 2014년 이후 (및 DevOps 도입 이후) 인기를 얻었으며 지속적인 배포 및 기타 애자일 방식을 강조하는 SOA에 대한 새로운 실현 및 구현 접근 방식이다.[44]

마이크로서비스에 대한 단일하고 일반적으로 합의된 정의는 없다. 문헌에서 다음 특성과 원칙을 찾을 수 있다.


  • 세분화된 인터페이스 (독립적으로 배포 가능한 서비스)
  • 비즈니스 중심 개발 (예: 도메인 주도 설계)
  • 이상적인 클라우드 애플리케이션 아키텍처
  • 다중 언어 프로그래밍 및 영속성
  • 경량 컨테이너 배포
  • 분산된 지속적 전달
  • 전체론적 서비스 모니터링을 통한 DevOps


실시간 응답 시간을 요구하는 대화형 애플리케이션, 예를 들어 짧은 지연 시간의 대화형 3D 애플리케이션은 이러한 종류의 애플리케이션의 특정 요구 사항을 해결하는 특정 서비스 지향 아키텍처를 사용하고 있다. 여기에는 짧은 지연 시간에 최적화된 분산 컴퓨팅 및 통신뿐만 아니라 리소스 및 인스턴스 관리 등이 포함된다.[45][46][47]

10. 관련 도서

참조

[1] 웹사이트 SOA Source Book - What Is SOA? https://collaboratio[...] 2021-03-30
[2] 서적 Fundamentals of Software Architecture: An Engineering Approach O'Reilly Media
[3] 웹사이트 Chapter 1: Service Oriented Architecture (SOA) https://msdn.microso[...] 2016-09-21
[4] 웹사이트 Service-Oriented Architecture Standards - The Open Group https://publications[...]
[5] 웹사이트 What Is SOA? http://www.opengroup[...] 2016-09-21
[6] 서적 Cloud Computing: A Practical Approach McGraw Hill
[7] 서적 Fundamentals of Software Architecture: An Engineering Approach O'Reilly Media
[8] 웹사이트 Migrating to a service-oriented architecture, Part 1 http://www-128.ibm.c[...] 2008-12-09
[9] 서적 Service-Oriented Modeling: Service Analysis, Design, and Architecture https://archive.org/[...] Wiley & Sons
[10] 서적 SOA Modeling Patterns for Service-Oriented Discovery and Analysis https://archive.org/[...] Wiley & Sons
[11] 문서 About the Principles 2005-06
[12] 웹사이트 Application Platform Strategies Blog: SOA is Dead; Long Live Services http://apsblog.burto[...] Apsblog.burtongroup.com 2009-01-05
[13] 뉴스 Improve your SOA project plans http://www-128.ibm.c[...] IBM 2004-07-16
[14] 웹사이트 Principles of Service Oriented Design http://msdn.microsof[...] 2012-09-03
[15] 문서 eight specific service-orientation principles http://soaprinciples[...]
[16] 웹사이트 4.4 Guidelines for Using Web Service Contract Technologies - Anatomy of a Web Service Contract http://www.informit.[...] 2021-06-11
[17] 서적 IEEE International Conference on Services Computing, 2004. (SCC 2004). Proceedings. 2004
[18] 서적 2014 IEEE International Conference on Web Services IEEE
[19] 서적 2012 13th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing IEEE
[20] 간행물 A Decade of Enterprise Integration Patterns
[21] 서적 SOA Patterns Manning Publications
[22] 간행물 Compliance by design – Bridging the chasm between auditors and IT architects http://soadecisions.[...]
[23] 문서 Web Services-Oriented Architecture in Production in the Finance Industry Springer-Verlag 2004-02
[24] 웹사이트 www.ibm.com http://www.ibm.com/s[...] 2016-09-10
[25] 웹사이트 SOAP Version 1.2 の公開について (W3C 勧告) http://www.w3.org/20[...] W3.org 2003-06-24
[26] 웹사이트 . "Case Study of System Architecture that use COBOL assets" http://www.fujitsu.c[...] 2006
[27] 문서 Enterprise SOA Prentice Hall
[28] 뉴스 A New Blueprint For The Enterprise http://www.cio.com.a[...] CIO Magazine 2005-03-01
[29] 뉴스 Building a Better Process Computer User 2005-01
[30] 웹사이트 Business Benefits of SOA https://web.archive.[...] 2009-11-11
[31] 웹사이트 JSR-000089 OSS Service Activation API Specification 1.0 Final Release https://cds.sun.com/[...] 2011-07-26
[32] 웹사이트 Bray: SOA too complex; 'just vendor BS' https://www.zdnet.co[...] ZDNet
[33] 뉴스 Index XML Documents with VTD-XML http://xml.sys-con.c[...] XML Journal 2008-02-20
[34] 간행물 i-Technology Viewpoint: The Performance Woe of Binary XML http://soa.sys-con.c[...] 2008-08-05
[35] 웹사이트 Manipulate XML Content the Ximple Way http://www.devx.com/[...] devx.com 2008-01-09
[36] 웹사이트 The Reason SOA Isn't Delivering Sustainable Software http://www.jpmorgent[...] jpmorgenthal.com 2009-06-19
[37] 웹사이트 SOA services still too constrained by applications they represent https://www.zdnet.co[...] ZDNet 2009-06-27
[38] 웹사이트 Governance Layer https://web.archive.[...] 2016-09-22
[39] 웹사이트 How to Efficiently Test Service Oriented Architecture {{!}} WSO2 Inc http://wso2.com/libr[...] 2016-09-22
[40] 웹사이트 What Is Web 2.0 http://www.oreillyne[...] Tim O'Reilly 2005-09-30
[41] 학술지 Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services https://web.archive.[...] 2007
[42] 논문 Microservices: yesterday, today, and tomorrow
[43] 웹사이트 Microservices http://martinfowler.[...]
[44] 학술지 Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture http://spiral.imperi[...] 2016-05-01
[45] 서적 European Conference on Parallel Processing 2021-02-09
[46] 서적 COM.Geo '11: Proceedings of the 2nd International Conference on Computing for Geospatial Research & Applications 2021-02-09
[47] 서적 2016 IEEE Symposium on Service-Oriented System Engineering (SOSE) https://biblio.ugent[...] 2021-02-09
[48] 뉴스 SOAはクラウド・コンピューティングとどのように関連しているのか? http://www.infoq.com[...]
[49] 문서 엔터프라이즈 SOA
[50] 블로그 네이버블로그 http://blog.naver.co[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com