서비스 지향 아키텍처 (SOA)

서비스 지향 아키텍처(Service Oriented Architecture, SOA)는 네트워크 통신 프로토콜을 통해 애플리케이션 구성요소에 의해 다른 구성요소에 서비스를 제공하는 소프트웨어 설계의 스타일이다. 서비스 지향 아키텍처의 기본 원칙은 벤더, 제품 및 기술로부터 독립적이다. 서비스는 신용 카드 명세서를 온라인으로 검색하는 것과 같이 원격으로 접속하여 독립적으로 행동하고 업데이트할 수 있는 별개의 기능 단위다. 모듈형 프로그래밍과 함께 SOA의 기본 공유인 대형 소프트웨어 애플리케이션의 기능을 제공하기 위해 다른 서비스를 함께 사용할 수 있다. 서비스 지향 아키텍처는 분산된 소프트웨어 구성요소와 별도로 유지 관리 및 배포된 소프트웨어 구성요소를 통합한다. 그것은 네트워크, 특히 IP 네트워크를 통한 요소들의 통신과 협력을 촉진하는 기술과 표준에 의해 활성화된다.

각 SOA 빌딩 블록은 다음 세 가지 역할 중 하나를 수행할 수 있다.

서비스 제공자
웹 서비스를 만들어 서비스 레지스트리에 정보를 제공한다. 각 제공자는 어떤 서비스를 노출할 것인지, 어떤 서비스를 더 중요하게 여길 것인지, 즉 보안 또는 쉬운 가용성을 제공할 것인지, 어떤 가격에 서비스를 제공할 것인지, 그 밖의 많은 것들에 대해 토론한다. 또한 제공자는 특정 브로커 서비스에 대해 어떤 범주에 서비스를 등록해야 하는지, 그리고 서비스를 이용하기 위해 어떤 종류의 거래 파트너 계약이 필요한지 결정해야 한다.

서비스 브로커, 저장소
그것의 주요 기능은 어떠한 잠재적 요청자도 웹 서비스에 관한 정보를 이용할 수 있도록 하는 것이다. 브로커를 시행하는 자는 중개인의 범위를 결정한다. 공공 브로커들은 어디서나 이용할 수 있지만, 개인 브로커는 제한된 양의 대중에게만 사용할 수 있다. UDDI는 웹 서비스 검색을 제공하려는 초기 시도였으며 더 이상 적극적으로 지원하지 않았다.

서비스 요청자/소비자
그것은 다양한 찾기 작업을 사용하여 브로커 레지스트리에 항목을 찾은 다음, 서비스 제공자에게 바인딩하여 웹 서비스 중 하나를 호출한다. 서비스 이용자가 어떤 서비스가 필요하든, 그들은 그것을 중개인에게 가져가서 각각의 서비스와 결합한 다음 그것을 이용해야 한다. 그들은 서비스가 여러 가지 서비스를 제공한다면 여러 가지 서비스에 접근할 수 있다. 서비스 소비자-공급자 관계는 사업 부분, 기능 부분 및 기술적 부분을 포함하는 표준화된 서비스 계약에 의해 관리된다. 서비스 구성 패턴은 안무와 조정이라는 두 가지의 광범위하고 높은 수준의 건축 스타일을 가지고 있다. 특정 아키텍처 스타일에 구속되지 않는 하위 레벨의 엔터프라이즈 통합 패턴은 SOA 설계에서 계속 적절하고 적격하다.


조직적 이익
SOA를 사용하면 조직이 문제를 전체적으로 살펴볼 수 있다는 생각이다. 일부 기업 설계자들은 SOA가 기업이 변화하는 시장 상황에 더 빠르고 더 비용 효율적으로 대응할 수 있도록 도울 수 있다고 믿는다. 이러한 형태의 아키텍처는 마이크로 레벨이 아닌 매크로 레벨에서 재사용을 촉진한다. 또한 기존 IT(레거시) 자산과의 상호 연결 및 사용도 단순화할 수 있다. 사업은 전반적인 통제력이 더 높다. 이론적으로 어떤 도구 세트가든 사용하는 개발자들은 많지 않을 것이다. 그러나 오히려 그들은 비즈니스 내에서 정해진 표준에 따라 코딩할 것이다. 또한 비즈니스 지향 인프라를 캡슐화하는 전사적 SOA도 개발할 수 있다. SOA는 또한 자동차 운전자들에게 효율성을 제공하는 고속도로 시스템으로 묘사되었다. 요점은 만약 모든 사람들이 차를 가지고 있지만, 어디에도 고속도로가 없다면, 어떤 시도에서든 빨리 혹은 효율적으로 어느 곳을 가려는 시도에서, 상황은 제한되고 흐트러질 것이라는 것이다. 어떤 면에서 SOA는 혁명이라기 보다는 건축적 진화로 간주될 수 있다. 그것은 이전의 소프트웨어 아키텍처의 많은 베스트 프랙티스를 포착한다. 예를 들어, 통신 시스템에서는 네트워크의 다른 장비와 대화하기 위해 진정한 정적 바인딩을 사용하는 솔루션의 개발이 거의 이루어지지 않았다. 이러한 시스템은 SOA 접근방식을 채택함으로써 잘 정의되고 상호운용성이 높은 인터페이스의 중요성을 강조할 수 있다. 서비스는 공식적으로 정의된 인터페이스를 통해서만 이용할 수 있는 독립형 기능 단위로 구성된다. SOA의 성숙한 롤아웃은 조직의 API를 효과적으로 정의한다. 서비스의 구현을 대규모 프로젝트와 별개의 프로젝트로 취급하는 이유는 다음과 같다. 분리는 서비스 제공이 조직에 공통적으로 발생하는 크고 느리게 진행되는 프로젝트로부터 신속하고 독립적으로 이루어질 수 있다는 개념을 비즈니스에 촉진한다. 기업은 서비스를 호출하는 시스템과 간소화된 사용자 인터페이스를 이해하기 시작한다. 이것은 민첩성을 옹호한다. 즉, 비즈니스 혁신을 촉진하고 시장 출시 기간을 단축한다. 분리는 서비스를 소비 프로젝트에서 분리하는 것을 촉진한다. 이것은 서비스가 소비자가 누구인지 모르게 설계되는 한 좋은 디자인을 장려한다. 서비스의 문서화 및 테스트 아티팩트는 더 큰 프로젝트의 세부사항에 포함되지 않는다. 이것은 나중에 서비스를 재사용할 필요가 있을 때 중요하다. SOA는 간접적으로 테스트를 간소화할 것을 약속한다. 서비스는 완전히 문서화된 인터페이스를 가진 독립적이고, 상태도 없으며, 구현의 상호 절단 우려와는 별개다. 조직이 적절하게 정의된 시험 데이터를 보유하는 경우, 서비스를 구축할 때 시험 데이터에 반응하는 해당 스텁이 구축된다. 서비스에 대한 회귀 테스트, 스크립트, 데이터 및 응답의 전체 세트도 캡처된다. 이 서비스는 자신이 부르는 서비스에 해당하는 기존의 스텁을 이용해 블랙박스로 시험할 수 있다. 테스트 환경은 원시 서비스와 범위를 벗어난 서비스가 스텁인 경우 구성될 수 있으며, 나머지 메쉬는 전체 서비스의 테스트 배치일 수 있다. 각 인터페이스가 자체적인 회귀 시험 문서로 완전히 문서화됨에 따라, 시험 서비스에서 문제를 식별하는 것이 간단해진다. 테스트는 테스트 서비스가 설명서대로 작동하는지 검증하는 것만으로 발전하며, 환경 내 모든 서비스의 문서화 및 테스트 사례에서 차이를 발견한다. 유휴 서비스의 데이터 상태를 관리하는 것만이 유일한 복잡성이다.