개념: 서비스 지향 아키텍처(SOA)
이 개념은 서비스 지향 아키텍처(SOA) 특성을 여러 차원으로 규정합니다(기술 하부 구조, 디자인 개념 프레임워크, 비즈니스와 IT 간 브릿지, 컴포넌트 기반 및 OO 기법 전개).
관계
기본 설명

소개

엔터프라이즈 규모 소프트웨어 솔루션을 빌드하는 데 따른 어려움은 다음과 같은 네 가지 이상의 기본 도전 과제 소스에서 비롯됩니다.

  1. 복잡한 비즈니스 도메인을 이해합니다.
  2. 비즈니스 요구를 충족시킬 수 있는 가장 효율적인 IT 자원 사용을 평가합니다.
  3. 수개월에 걸쳐 진행되는 여러 프로젝트 단게에서 대규모 엔지니어 팀이 관여하는 개발 노력을 관리합니다.
  4. 몇 년 동안에 걸쳐 전개된 하부 구조 기술의 복잡한 환경에 솔루션을 배치합니다. 이러한 환경은 여러 벤더로부터 확보한 다양한 미들웨어 소프트웨어로 구성되며, 다양한 품질과 문서화 내용이 충분하지 않은 통합 노력을 통해 어셈블됩니다.

이 컨텍스트에서 솔루션을 개발하려면 설계자가 유연한 방식으로 해당 솔루션을 전개하고, 대상 하부 구조가 전개될 때에도 비즈니스 기능성을 빠르게 구현하는 새 기능 컨텍스트에서 기존 노력을 재사용할 수 있도록 도와주는 소프트웨어 아키텍처에 대한 접근 방식이 필요합니다. 이러한 요구 처리를 돕기 위해 많은 조직이 정보 자원을 본래부터 유연한 환경을 작성하는 독립적이고 재사용가능한 기능으로 재구성할 수 있는 방법을 모색하고 있습니다. 공개된 표준 프로토콜을 사용하여 이러한 재사용가능한 기능을 설명함으로써 조직이 기본 기술에 관계 없이 사용할 수 있는 자체 설명 서비스를 작성할 수 있습니다. 이러한 기술 독립성을 통해 다른 컨텍스트에서 서비스를 사용함으로써 비즈니스 프로세스, 규칙 및 정책의 표준화를 달성할 수 있습니다. IT 시스템에 대한 이러한 접근 방식은 서비스 지향 아키텍처(SOA)라고도 하며 비즈니스 및 IT 조직의 응답성을 빠르게 개선할 수 있는 잠재력을 갖고 있는 것으로 널리 인식되고 있습니다.

SOA로의 이동은 조직에게 많은 도전 과제를 제공합니다. 예를 들어, 서비스 지향 개념은 새 용어 및 모델을 사용하며 상호운용성 및 프로세스 통합을 장려합니다. 또한 SOA를 구성하는 많은 기본 기술 계층을 통합하는 작업은 매우 복잡한 타스크입니다. IT 조직은 일반적으로 접근 방식을 변경하고 스킬 세트를 업그레이드해야 하며 개발 환경에도 새 기능을 사용해야 하고 솔루션-디자인 프로세스도 변경됩니다. SOA 개념은 이러한 문제를 조정하기 위한 최신 경향이며 해당 특성은 지속적으로 발전하고 있습니다. 그러나 SOA의 개념과, 엔터프라이즈 소프트웨어 솔루션을 빌드하는 데 있어 주요 관심사항을 처리하기 위한 SOA 역할에 대한 몇 가지 명확한 관점도 있습니다.

기술 하부 구조로서의 SOA

시스템은 해당 서비스 인터페이스를 통해 정의되는 오퍼레이션을 호출하는 서비스 콜렉션으로 구성됩니다. 이제 많은 조직은 해당 솔루션을 서비스 및 상호 연결 관점에서 표현합니다. SOA를 채택하는 궁극적인 목적은 비즈니스와 IT 내부에 유연성을 제공하기 위해서입니다. 특히 여러 시스템에 서비스를 분배하고 인터넷 또는 인트라넷을 통해 해당 서비스를 연결하는 경우, SOA 접근 방식을 지원하기 위한 여러 가지 중요 기술이 정의되었습니다. 이러한 웹 서비스 접근 방식은 SOAP와 같은 서비스 간 통신 프로토콜에 의존합니다. 또한 웹 서비스 인터페이스(WSDL(Web Services Definition Language)로 표현)를 공용 디렉토리에 등록하여 UDDI(Universal Description, Discovery and Integration) 저장소에서 검색할 수 있으며 XML로 정의되고 표준 스키마로 설명하는 문서에서 정보를 공유합니다. 또한 정책, 보안, 신뢰성, 발견 등의 추가 영역을 다루는 표준이 개발됩니다. 이 표준 계열은 일반적으로 "WS-* 계열"이라고 합니다.

그러나 객체 지향이 단순히 클래스 계층 구조 세트가 아닌 것처럼 SOA도 단순히 표준 및 서비스 설명 세트가 아닙니다. 실제로, 웹 서비스 기술을 사용하지 않는 SOA를 작성할 수 있으며 서비스 지향 이외의 방식으로 웹 서비스 기술을 사용할 수 있습니다. 서비스 지향 시점이 비즈니스에 가치를 추가하는 이유와 서비스 지향 솔루션의 디자인, 구현, 배치 및 관리 방법을 이해하려면 보다 많은 연구가 필요합니다. [또한 SOA는 WS와 다릅니다.]

디자인 개념 프레임워크로서의 SOA

SOA용 솔루션을 작성한다는 것은 현재 빌드 중인 시스템의 유형을 다시 생각하고 조직의 스킬을 다시 고려하며 팀 구성원이 협업하는 방식을 재정의하는 것을 의미합니다. 보다 중요한 것은 솔루션 개발을 위해 서비스 지향 방식을 채택하려면 솔루션 디자인 방법, 개별 서비스로부터의 서비스를 어셈블하는 의미, 배치된 서비스 지향 솔루션을 관리 및 전개하는 방법에 대한 영향을 포괄적으로 검토해야 합니다.

이러한 이동에 따른 주요 변경사항 중의 하나는 "응용프로그램"이라는 용어 문제가 발생한다는 것입니다. 즉, 기존에는 응용프로그램이 모든 프로젝트의 중심이었지만 비즈니스가 의존하는 서비스 포트폴리오로 그 중심이 이동하게 됩니다. 이러한 측면에서 볼 때 응용프로그램 지향 프로젝트에서 서비스 지향 프로젝트로의 이동은 응용프로그램을 작성하는 컴포넌트의 수직 통합 세트 디자인에서 수평 서비스 세트 디자인으로의 이동으로 볼 수 있습니다. 향후에는 응용프로그램이 많은 가치를 제공하는 비즈니스 및 하부 구조 서비스 세트를 구성하는 사용자 상호작용 서비스와 유사한 특정 비즈니스 로직의 소규모 계층에 대한 설명과 관련이 있습니다.

Gartner에서는 이처럼 광범위한 서비스 지향 컨텍스트를 서비스 지향 응용프로그램 개발(SODA)이라고 합니다. Gartner는 SODA의 다섯 가지 핵심 개념으로 컴포지션, 조정 프로세스 관리, 서비스 기반 상호운용성 및 통합, 발견 및 설명과, 신속한 응용프로그램 유지보수를 제시합니다. 도구 벤더 관점에서 볼 때 이러한 영역은 다음 세 가지 영역에서 제공되는 기술 지원과 관련이 있습니다.

SOA 라이프사이클. "발견 및 설명"과 "신속한 응용프로그램 유지보수" 개념은 서비스 라이프사이클과 서비스를 찾고 적용하며 전개하고 유지보수하는 방법을 나타냅니다. 도구 벤더는 서비스를 저장, 카탈로그화, 검색 및 조회할 수 있는 방법을 계속 제공하고 있습니다. 지속적인 서비스 전개에 대한 지원은 이 영역의 중요 측면으로서, 결과적으로 여러 서비스 버전이 생성됩니다.

SOA 플랫폼 및 프로그래밍 모델. 서비스 기반 상호운용성 및 통합 개념은 특정 런타임 플랫폼에서 서비스를 연결, 배치 및 관리할 수 있는 방법을 나타냅니다. 주요 플랫폼 벤더는 서비스 지향 기능을 미들웨어 런타임의 일부로 직접 지원하며 해당 런타임 프로그래밍 모델을 첫 번째 클래스 요소로서 표면 서비스 개념으로 전개합니다. 결과적으로, 단일 서비스 기반 관점에서 솔루션을 고안, 디자인, 구현 및 관리할 수 있습니다.

SOA 사례 및 도구. 컴포지션 및 조정 프로세스 관리 개념은 변화하는 비즈니스 요구의 해결 관점에서 서비스를 작성하고 어셈블하는 방법을 나타냅니다. 도구 벤더는 기존 응용프로그램 마이닝을 통한 잠재적 서비스 발견, 해당 기능을 서비스로서 액세스할 수 있도록 하기 위한 기존 기능성 랩핑 및 해당 인터페이스를 통한 동작 연결로 서비스 연결을 지원합니다. 이 영역의 기본 원칙은 서비스 지향 솔루션을 반복적이고 예측 가능한 방식으로 설계하기 위한 명확한 안내와 우수 사례를 제공한다는 것입니다.

서비스 지향 솔루션 개발의 성공을 위해서는 이 세 가지 영역이 모두 중요합니다. 즉, 비즈니스 목적에 보다 부합하는 유연한 솔루션을 효율적으로 작성해야 하는 조직의 요구를 충족시키려면 이 영역을 모두 다루어야 합니다.

비즈니스와 IT를 연결하는 솔루션에 대한 전체적인 접근 방식으로서의 SOA

엔터프라이즈 규모 솔루션을 개발하는 데 있어 해결해야 할 기본 과제 중 하나는 비즈니스 분석가가 제시하는 도메인 특정 요구사항과 IT 조직이 디자인하는 기술 특정 솔루션을 연결하는 것입니다. 일반적으로, 서로 다른 이 두 가지 영역의 연결은 올바른 방법이 아닙니다. 즉, 두 커뮤니티는 서로 다른 스킬을 갖고 있으며 다른 모델링 개념(있는 경우)을 사용하며 해당 개념 간 맵핑을 거의 이해하지 못합니다. 서비스 지향 접근 방식을 사용하는 이유는 비즈니스 분석가와 현업 전문가 및 IT 전문가(예: 설계자, 시스템 분석가, 통합자, 디자이너 및 개발자) 간의 이러한 차이를 보완하기 위해서입니다. 특히 핵심 서비스 세트와 관련한 프로세스, 자산, 인도물의 통합은 이처럼 서로 다른 두 가지 시스템 측면을 분명하고 정확하게 연결하기 위한 것입니다.

SOA의 서비스 중심 보기를 통해 극복할 수 있는 과제는 다음과 같습니다.

비즈니스와 IT 간의 차이 보완. 활동 및 프로세스의 비즈니스 보기와 이러한 활동 파트를 실현하기 위해 사용되는 기술을 조정해야 합니다. 이러한 조정에는 비즈니스 모델로 다운스트림 개발을 수행하고 비즈니스 모델과 IT 솔루션을 조합하여 전개할 수 있는 기능이 포함됩니다. 이 조정에는 또한 서비스 개념이 중요합니다. 서비스 및 서비스 기반 사고는 비즈니스 분석가, IT 설계자, 통합자 및 개발자를 함께 묶는 공통 기반을 형성합니다. 실제 서비스 특성, 세분성 레벨 및 서비스 캡슐화 레벨을 통해 비즈니스를 운영하는 비즈니스 프로세스 모델과 서비스의 보다 밀접한 관계를 구축할 수 있습니다. 또한 공통 디자인 사례를 통해 이처럼 다른 관점에서 개념, 중간 산출물 및 타스크를 동기화할 수 있습니다. 마지막으로, 비즈니스 의도를 나타내는 모델을 효율적인 구현 기반으로 효율적으로 변환할 수 있는 도구가 비즈니스와 IT 간의 차이를 보완하는 데 매우 중요합니다.

IT 조직의 역할 변화 지원. 서비스 중심 사고로의 이동은 조직 내 팀 구성 및 스킬의 변화를 가져옵니다. 또한 개발 작업은 서비스 레벨 계약(SLA) 및 서비스 간 프로토콜을 강조하는 아키텍처 설명으로 서비스를 찾고 정의하며 관리 및 어셈블하는 데 초점을 맞춥니다. 도구 기능을 현재의 제품 구성으로 작업분류하는 기존의 방법은 이 접근 방식에 적합하지 않습니다. IT 조직의 구성원에 따라 다른 기능 구성이 필요합니다. 예를 들어, 소프트웨어 설계자와 같은 기존 역할에서 필요한 스킬은 다양한 서비스 제공자 세트에서 서비스 어셈블리 및 관리를 보다 강조하도록 변경되고 있습니다. 마찬가지로, 통합 전문가와 같은 새 역할이 대두되고 조직의 핵심 비즈니스 목적을 지원하는 서비스 기반의 가치 체인을 어셈블하는 데 초점을 맞춥니다.

자산 및 재사용 강조. 시스템 디자인에서 서비스를 핵심 자산으로 간주함에 따라 이러한 서비스 재사용의 가치에 대한 조직의 관점도 변경됩니다. 앞에서, 응용프로그램 컴포넌트 세트의 수직 개발에서 수평 컴포넌트 통합으로의 이동에 대해 설명했습니다. 이러한 이동에 따른 중요 측면 중 하나는 서비스의 재사용 가능성이 높아진다는 것입니다. 실제로, 서비스와 새 기능의 결합 및 새 기능의 새 서비스 구성은 근본적인 변경 구동 요인입니다. 많은 비즈니스에 있어, SOA의 이러한 재사용 가능성은 서비스 포트폴리오의 디자인 및 개발과 연관된 비용을 상쇄시킬 수 있습니다. 결과적으로, 자산의 관리 및 통제를 위한 기술 및 기법과, 자산 결합을 위한 반복적인 패턴 캡처 방식이 보다 중요해집니다. 자산 기반 개발 접근 방식에 있어 이러한 자산은 조직에 중요한 가치를 제공하므로 주의깊게 관리 및 운영해야 합니다. 자산 관리를 위한 팀 하부 구조는 이 접근 방식에 있어 중요한 역할을 담당합니다.

종사자(practitioner) 역할 간 협업 레벨 증가. 엔터프라이즈 응용프로그램 개발에서는 항상 소프트웨어 개발 시 구성원이 협력하여 전체 라이프사이클에서 공유 자산, 중간 산출물 추적성 및 공유 사례와 프로세스를 관리하는 데 초점을 맞추어야 합니다. 소프트웨어 개발의 이러한 협업 특성은 조직의 지리적 분포가 확대되고 팀 내 구성원 간의 실시간 커뮤니케이션이 강화되며 소프트웨어가 보다 광범위한 시스템 개발 노력의 일부로 포함됨에 따라 점점 더 강조되고 있습니다. 또한 소프트웨어 개발 하부 구조의 역할을 팀 간의 서비스 공유 및 재사용을 장려하는 소프트웨어 종사자(practitioner)의 협업 개발 환경으로 인식하는 경향이 증가하고 있습니다.

컴포넌트 기반 및 객체 지향 기법의 발전으로서의 SOA

소프트웨어 엔지니어링과 관련된 모든 새 환경에서는 이전 프로젝트에서 사용한 것과 동일한 기법 및 도구를 적용할 수 있습니다. 이전 솔루션으로 새로운 문제점을 해결하려는 이러한 경향은 새로운 경향이 아닙니다. 마찬가지로, 개발자가 컴포넌트 기반 응용프로그램을 작성할 때는 객체 지향 개발과 관련된 경험을 사용하여 문제점을 해결하려고 시도했습니다. 경험이 풍부할수록 객체 지향 기술 및 언어를 사용하여 컴포넌트를 효과적으로 구현할 수 있음을 알 수 있습니다. 그러나 결정 및 구현에 대한 절충도 이해해야 합니다. 이러한 절충은 다형 동작 또는 클래스 라이브러리 재디자인을 구현함으로써 단일 C++ 응용프로그램에 대한 기반이 아닌 컴포넌트 세트를 사용할 수 있는 상속 대 집계에 대한 절충입니다.

마찬가지로, 컴포넌트는 가장 효과적인 서비스 구현 수단이며 이 경우 올바른 컴포넌트 기반 응용프로그램이 반드시 올바른 SOA를 작성하는 것은 아님을 이해해야 합니다. 응용프로그램 아키텍처의 서비스가 수행하는 역할을 이해하면 회사의 컴포넌트 개발자 및 기존 컴포넌트를 효과적으로 이용할 수 있습니다. 이러한 전이를 위해서는 서비스 지향 접근 방식이 추가 응용프로그램 아키텍처 계층을 의미함을 이해해야 합니다. 아래 그림은 솔루션 이용자 관점에서 응용프로그램 아키텍처에 기술 계층을 적용하여 보다 덜 세분화된 구현을 제공하는 방법을 보여줍니다. 이 시스템 파트를 의미하는 용어가 "응용프로그램 에지"이며 서비스를 통해 전통적인 컴포넌트 디자인을 사용한 내부 재사용 및 컴포지션으로 시스템의 외부 보기를 효과적으로 제공할 수 있음을 나타냅니다. 오브젝트, 컴포넌트 및 서비스 간 차이를 확인하는 방법 중 하나는 해당 구현과 결합되는 방식입니다. 예를 들어, 오브젝트가 프로그래밍 언어에 결합되고 컴포넌트는 일부 런타임 및 플랫폼(COM, CORBA, J2EE 등)에 결합되는 반면 서비스는 해당 스펙을 설명하는 데 사용되는 표준 세트에만 결합됩니다.

다이어그램은 텍스트 컨텐츠에서 설명합니다.

일반적으로 객체 지향 사고에서 컴포넌트 기반 사고로 이동하려면 개발자가 이 신기술 및 해당 요구사항에 대해 학습하는 데 6 - 18개월의 시간이 소요됩니다. 그러나 서비스 지향 솔루션으로의 이동 시간을 단축시킬 수도 있습니다. 이를 위해서는 개발자가 서비스 지향 솔루션을 지원하고 컴포넌트 개발 및 재사용을 허용하는 도전 과제, 절충 및 디자인 결정사항을 이해해야 합니다.