전사재고패턴

Enterprise inventory pattern

엔터프라이즈 인벤토리(Enterprise Inventory)는 서비스 지향 설계 패러다임의 영역에서 Thomas Erl의 설계 패턴으로, "어떻게 서비스를 제공하여 재구성을 극대화할 수 있습니까?"라는 질문에 답합니다.이 패턴을 적용하면 반복적인 서비스 [2][3]구성을 촉진하는 표준화된 전사적 서비스[1] 인벤토리가 생성됩니다.

이론적 근거

SOA 채택은 일반적으로 다양한 부서 경계에 분산된 다양한 비즈니스 프로세스 자동화의 일환으로 다양한 팀에 의해 구축되는 여러 서비스 세트를 초래합니다.각 프로젝트 팀은 팀의 단기 목표 및 요구 사항과 더 관련이 있는 서로 다른 표준 및 구현 아키텍처[3](서비스 개발용)를 따를 수 있습니다.구축된 서비스가 동일한 비즈니스 도메인 내에서 재사용 및 재구성할 수 있는 충분한 기회를 제공할 수 있지만, 서로 다른 비즈니스 도메인의 서비스를 구성할 때는 이러한 서비스 간에 일종의 브리지 또는 변환 논리가 필요한 임피던스 불일치가 발생하는 경향이 있습니다.어떤 면에서, 이러한 서비스는 서비스 지향의 기본적인 특성을 무시하는 독립형 솔루션을 초래합니다. 즉, 기업 중심적이지 않기 때문입니다.프로젝트 팀이 서로의 요구 사항을 알지 못하기 때문에 이러한 분산 서비스 제공 노력은 중복 서비스 개발로 이어지는 경우가 많습니다.

모든 서비스가 단일 표준 집합을 준수하는 환경을 조성하기 위해 서비스 지향 엔터프라이즈 아키텍처를 기반으로 하는 공통 서비스 [4]인벤토리를 생성하는 엔터프라이즈 인벤토리 설계 패턴이 적용됩니다.이를 통해 자동으로 중복성이 제거되고 서비스를 최대한 재구성할 수 있으므로 노력과 [5]시간을 줄여 새로운 솔루션을 개발할 수 있습니다.

사용.

Diagram A
다이어그램 A
서로 다른 표준을 사용하고 서로 다른 구현 아키텍처를 기반으로 구축된 서로 다른 두 조직 부서에 속하는 두 개의 개별 서비스 인벤토리.음영 처리된 서비스는 중복 서비스를 나타냅니다.
Diagram B
도표 B
공통 표준 세트를 기반으로 구축된 단일 전사적 인벤토리를 통해 최대의 재구성 기회를 제공하고 중복성을 제거합니다.

다이어그램 A에서 설명한 바와 같이, 두 개의 서로 다른 부서에 속한 서비스는 동일한 조직에 속해 있지만 중복성뿐만 아니라 아키텍처 비호환성도 포함하고 있습니다.부서 간 서비스 구성은 이러한 서비스 사이에 일종의 변환 로직이 도입되기 전까지는 가능하지 않습니다.그러나 다이어그램 B에서 엔터프라이즈 인벤토리 패턴을 적용하면 기본적으로 상호 운용 가능한 표준화된 서비스 인벤토리가 생성됩니다.

구축 중인 모든 서비스가 이 설계 패턴을 적용하는 과정에서 동일한 설계 표준을 따르도록 하려면 서비스 인벤토리[6] Blueprint를 생성해야 합니다.이러한 청사진은 후보 기능을 포함하는 후보 서비스로만 구성됩니다.이러한 서비스 인벤토리 Blueprint를 생성하여 잠재적인 전사적 서비스 인벤토리의 전체 범위를 설정합니다.이를 위해서는 대개 하향식 서비스 지향 분석을 [7]적용해야 합니다.

엔터프라이즈 인벤토리를 생성하는 것 외에도, 이 패턴을 적용하려면 현재 엔터프라이즈 아키텍처를 기반으로 하는 기술 아키텍처도 문서화하여 서비스가 해당 아키텍처의 경계 내에서 구축될 수 있도록 해야 합니다.이렇게 하면 서비스 상호 운용성과 행동 예측 가능성이 보장됩니다.

고려 사항.

엔터프라이즈 인벤토리 설계 패턴을 적용하려면 사전 분석이 필요하므로 절차와 문서가 잘 확립된 IT 시스템을 보유한 조직에 적합합니다.새로운 SOA 이니셔티브라면 전사적인 인벤토리를 만드는 것이 훨씬 쉽고 간단할 것입니다.전사적 이니셔티브이기 때문에 기존 서비스가 새로운 설계 표준에 적응하기는 다소 어려울 것이며 상당한 시간이 소요될 뿐만 아니라 재정적 부담도 발생할 것입니다.

경우에 따라 [8]조직의 규모가 너무 크기 때문에 단일 엔터프라이즈 서비스 인벤토리를 생성하는 것이 불가능할 수 있습니다.이는 또한 관리 및 유지 관리해야 하는 서비스가 너무 많기 때문에 이러한 인벤토리를 관리하고 유지 관리하는 것이 불가능해질 수 있음을 의미합니다.마지막으로, 문화적인 문제로 인해 일반적인 엔터프라이즈 서비스 재고가 채택되지 않을 수 있습니다.여기에는 프로젝트가 개발되는 방식에 대한 통제권을 포기하는 것에 대한 망설임이 포함될 수 있습니다.프로젝트의 효율적인 개발을 제한하는 설계 표준을 채택하는 것을 꺼리고 전사적 표준을 추적하고 중복을 피하기 위해 다른 프로젝트 팀이 무엇을 하고 있는지 지속적으로 확인해야 한다는 측면에서 서비스 개발자의 추가 부담을 감수해야 합니다.

레퍼런스

  1. ^ 서비스 인벤토리
  2. ^ "Service Composition". Archived from the original on 2010-03-12. Retrieved 2010-04-05.
  3. ^ a b 와지드 카탁.엔터프라이즈 인벤토리[온라인].액세스 날짜: 2010년 4월 30일.
  4. ^ 마우로 등.서비스 지향 장치 통합 - SOA 설계 패턴 분석.Wayback Machine [Online], pp.1-10, 2010년 제43회 하와이 국제 시스템 과학 컨퍼런스에서 2011-02-03 보관.액세스 날짜: 2010년 4월 5일.
  5. ^ 토마스 얼.SOA 설계 패턴[온라인] 소개.액세스 날짜: 2010년 4월 5일.
  6. ^ 서비스 인벤토리 Blueprint
  7. ^ "Top-down vs Bottom-up Deliver Approach". Archived from the original on 2010-05-09. Retrieved 2010-04-05.
  8. ^ 하워드 코헨, 조쉬 테일러.SOA in the DoD[Online].액세스 날짜: 2010년 4월 7일.

외부 링크