서비스 지향 설계 원칙

Service-orientation design principles

서비스 지향 설계 원칙은 서비스 지향 아키텍처(SOA)[1][2][3] 내에서 서비스의 솔루션 로직을 개발하기 위해 제안된 원칙입니다.

개요

특정 설계 패러다임을 기반으로 한 소프트웨어 개발의 성공 여부는 결코 장담할 수 없습니다.서비스 지향 설계 패러다임 하에서 개발된 소프트웨어는 훨씬 더 큰 위험을 수반합니다.이는 서비스 지향 아키텍처가 일반적으로 여러 비즈니스 영역에 걸쳐 있고 상당한 초기 분석이 필요하기 때문입니다.따라서, 구체적인 지침 없이 개발된 SOA는 [4]실패할 가능성이 매우 높습니다.서비스 지향으로의 이행이 약속된 이익을 실현하는 긍정적인 변화임을 확실히 하기 위해 일련의 [5]규칙을 채택하는 것이 도움이 됩니다.

서비스 지향 설계 원칙은 Thomas Erl의 SOA 서비스 [6][7][8]설계 원칙에 따라 크게 다음과 같이 분류할 수 있습니다.

이러한 설계 원칙의 적용은 기술에 의존하지 않는 서비스를 창출하여 장기적으로 [9]상호 운용성을 제공합니다.이러한 설계 원칙은 서비스를 [2]식별하기 위한 가이드라인 역할을 합니다.

전략적 목표

이러한 원칙의 적용은 애당초 서비스 지향의 채택과 관련된 근본적인 목표를 달성하는 데 도움이 됩니다.이러한 목표는 장기적으로 전략적이며 조직의 당면한[10] 요구를 넘어서는 것입니다.이러한 전략적 목표는 다음과 같은 7가지 목표와 [11][12]이점으로 요약할 수 있습니다.

  • 내장 상호 운용성 향상
  • 페더레이션의 강화
  • 벤더 다양화 옵션 확대
  • 비즈니스와 테크놀로지의 연계성 향상
  • ROI 향상
  • 조직의 민첩성 향상
  • IT 부담 경감

상기의 목표와 메리트는, 항상 변화하는 시장 상황에 신속히 대응해, 노력과 시간을 단축할 수 있는 민첩한 조직을[13] 구축하는 데 직접 도움이 됩니다.

특성.

서비스 지향 설계 원칙은 명확한 설계[14] 특성을 촉진함으로써 서비스 지향 솔루션을 기존 객체 지향 솔루션과 구별하는 데 도움이 됩니다.서비스 지향 솔루션에 이러한 특성이 존재하면 앞서 말한 목표와 이점을 실현할 가능성이 크게 높아집니다.Erl은 다음과 같은 [15]4가지 서비스 지향 특성을 식별했습니다.

  • 벤더 중립
  • 비즈니스 주도의
  • 기업 중심
  • 구성 중심

벤더 중립적인 서비스 지향 솔루션은 끊임없이 변화하는 비즈니스 요구사항에 대응하여 기본 기술 아키텍처를 발전시키는 데 도움이 됩니다.특정 벤더에 의존하지 않기 때문에 솔루션 전체를 처음부터 재설계할 필요 없이 노후화된 인프라스트럭처를 보다 효율적인 테크놀로지로 대체할 수 있습니다.또, 특정의 테크놀로지에 의해서 특정의 비즈니스 자동화 요건이 충족되는 이기종 테크놀로지 환경을 구축하는 데도 도움이 됩니다.

SOA 내에서 솔루션 로직의 개발은 비즈니스의 요구에 따라 이루어지며 비즈니스의 장기적인 요구사항에 초점을 맞춰 설계되었습니다.그 결과, 테크놀로지 아키텍처는 비즈니스 요구에 보다 부합합니다.

기존의 사일로 기반 애플리케이션 개발과는 달리, SOA는 기업 전체 또는 기업 중 적어도 일부의 요구사항을 고려합니다.그 결과, 개발된 서비스는 기업의 다양한 세그먼트에서 상호 운용이 가능하고 재사용이 가능합니다.

서비스 지향 솔루션은 기존 서비스를 활용하여 새로운 요구사항과 변화하는 요구사항을 단기간에 처리할 수 있도록 지원합니다.서비스는 재합성할 수 있도록 설계되어 있습니다.즉, 다른 솔루션의 일부가 됩니다.

어플

서비스 지향 설계 원칙은 서비스 지향 분석 및 설계 프로세스 중에 적용됩니다.각 원칙을 적용할 수 있는 정도는 항상 상대적이며 조직의 전체적인 목표와 목표 및 시간 제약에 대해 저울질해야 합니다.유의해야 할 중요한 요소 중 하나는 이러한 설계 원칙의 적용만이 아니라 서비스 지향 설계 목표의 실현을 보장하는 일관된 적용이라는 것입니다.이는 서비스가 엔터프라이즈 리소스이기 때문입니다.즉, 특정 표준에 준거하여 여러 솔루션 내에서 재사용할 수 있다는 확신을 주기 때문입니다.따라서 이러한 리소스를 유지하기 위해서는 일관성 없는 애플리케이션이 서비스를 제공하게 되므로 이러한 원칙이 일관되게 적용된 프로세스에서 벗어나야 합니다.상호 호환성이 없기 때문에 기본적인 서비스 지향 설계 특성이 상실됩니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ 2012년 5월 1일 Wayback Machine에서 아카이브된 서비스
  2. ^ a b Hubbers; et al. "Ten Ways to Identify Services". CiteSeerX 10.1.1.94.5879. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  3. ^ 보이치에치 셀러리, 세르지우시 스트리코스키입니다클라우드 컴퓨팅과 서비스 지향 아키텍처를 기반으로 하는 전자 정부.접속일 : 2010년 4월 11일
  4. ^ 존 브로드킨입니다SOA 실패는 사람, 프로세스 문제로 추적됩니다.접속일 : 2010년4월 8일2012년 10월 13일 Wayback Machine에서 아카이브 완료
  5. ^ 게로 베르마스상위 10개의 SOA 함정.접속일 : 2010년4월 8일2012년 2월 23일 Wayback Machine에서 아카이브 완료
  6. ^ a b Thomas Erl (2008)SOA 서비스 설계의 원칙"을 참조하십시오.프렌티스 홀.ISBN 978-0-13-234482-1
  7. ^ Hoijin Yoon. "A Convergence of Context-Awareness and Service-Orientation in Ubiquitous Computing". CiteSeerX 10.1.1.114.1823. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  8. ^ Michael Poulin 서비스 오리엔테이션 원칙의 진화, 파트 1접속일 : 2010년 4월 12일2012년 2월 25일 Wayback Machine에서 아카이브 완료
  9. ^ 데이비드 웨버입니다웹 서비스로서의 서비스: "아직 도착하지 않았습니까?"웹 서비스 기술 스택만으로는 SOA의 목표를 달성할 수 없습니다.접속일 : 2010년 4월 11일
  10. ^ 당장 필요한 것은 특정 비즈니스 프로세스 자동화(예: 청구서 처리)와 연계된 것입니다.장기적인 요건은 현재의 요건을 넘어서는 것으로, 통상은 복수의 비즈니스 프로세스에 분산되어 있습니다.
  11. ^ 2012년 10월 19일 웨이백 머신에 보관된 SOA 목표 및 이점
  12. ^ 사디 멜부시서비스 지향 아키텍처를 제공하는 방법론.접속일 : 2010년 4월 10일2012년 3월 5일 Wayback Machine에서 아카이브 완료
  13. ^ IT 환경 내에서 민첩한 조직은 기존 리소스의 대부분을 사용하면서 비즈니스 요구사항에 신속하게 대응할 수 있는 조직입니다.
  14. ^ 서비스 지향 설계 패러다임을 기반으로 서비스로 구성된 솔루션.
  15. ^ Erl et al, (2009)SOA 설계 패턴"을 참조하십시오.프렌티스 홀.ISBN 978-0-13-613516-6

추가 정보