라이브러리 대신 서비스 (REST / SOAP)를 사용하는 이유는 무엇입니까?


22

응용 프로그램을 서비스로 분할하려고한다고 가정 해 봅시다. SOA 접근 방식을 채택해야하는 이유와 필요한 애플리케이션이로드 할 수있는 라이브러리 API를 작성하는 이유가 있습니까?


6
이봐 네이트, Stevey의 Google Platforms Rant를 읽고 , 플랫폼 (서비스)과 제품 (라이브러리) 질문에 대한 통찰력을 제공합니다.
yannis

답변:


11

둘 사이의 차이는 미묘 할 수 있습니다. 예를 들어 .NET 세계에서는 최종 사용자에게 단일체처럼 느껴지고 동일한 컴퓨터에서 작동하지만 내부에서 여러 WCF 서비스로 분리되는 응용 프로그램이있을 수 있습니다. 라이브러리가 강력하게 연결되어 있지 않거나 (애드 인 / 플러그인) 서로 대화 할 때 프로토콜을 따르는 아키텍처도있을 수 있습니다.

이러한 중개 사례에 대해 이야기하지 않고 강력하게 연결된 API 라이브러리와 별도의 REST 서비스 만 처리하는 경우 다음 사항을 고려할 수 있습니다.

  1. 라이브러리 API는 동일한 머신에서 호출됩니다. 어디서나 서비스를 호스팅하고 어디에서나 호출 할 수 있습니다. 성능 / 확장 성 / 보안상의 이유로 여러 컴퓨터에서 응용 프로그램을 호스팅하는 경우 서비스를 사용해야 할 가능성이 있습니다.

  2. 여러 컴퓨터에 배포 된 응용 프로그램에서 하나의 서비스를 사용하는 경우와 비슷한 상황입니다. 예를 들어 은행에서 일부 재무 계산을 수행하는 응용 프로그램을 수행하는 경우 한 가지 방법은 전체 응용 프로그램을 모든 데스크톱에 배포하고 매번 모든 클라이언트에 대해 대규모 업데이트를 수행하는 것입니다. 또 다른 방법은 서버에서 계산 부분을 호스팅하고 UI와 해당 서버에 대한 많은 호출로 가벼운 앱만 데스크톱에 배포하는 것입니다.

  3. REST 서비스를 호스팅하는 경우 누구나 Mac 사용자, Linux를 사용하는 사람 등이 사용할 수 있습니다. Visual Studio로 C # 라이브러리를 작성하고 DLL로 배포 한 경우 사용자 (고객)를 잊어 버리십시오. ?) Windows가없는 사람.


9

서비스의 또 다른 장점은 서비스를 업데이트 할 때 서비스의 모든 소비자에게 즉시 배포된다는 것입니다. 따라서 버그 또는 성능 문제를 해결 한 경우 사람들이 무시하도록 선택할 수있는 업데이트를 배포하지 않고 업데이트 된 서비스가 시작되는 즉시 모든 사람이 혜택을 누릴 수 있습니다.


물론 이것은 단점이기도합니다. 여러 응용 프로그램이 의존하는 서비스를 변경하면 해당 응용 프로그램 중 하나 이상에서 기능이 예기치 않게 중단 될 수 있습니다. 이는 서비스에서 다른 사람을 놀라게하는 것이 아니라 서비스를 변경할 때마다 서비스의 모든 소비자가 계속 작동하도록해야한다는 점에 유의하십시오. 레거시 서비스 메소드를 배치 한 후에는 그대로두고 구현을 변경해야 할 때 새 메소드를 작성하는 것이 더 좋습니다.
Lews Therin

8

도서관 장점 :

  • 통화 당 오버 헤드 감소 (점프 만 또는 심지어 인라인 ) = 성능 향상
  • 가능한 가장 간단한 것
  • 중앙 집중식 서비스가 중단되고 모든 소비자에게 영향을 줄 위험이 없습니다.

서비스 장점 :

  • 버전이 지정된 API가 제공되지 않는 한 모든 사람이 즉시 투명하게 업그레이드됩니다.
  • 소비자는 코드를 디 컴파일 할 수 없습니다
  • 서비스 하드웨어를 개별적으로 확장 가능
  • 기술 불가지론. 공유 라이브러리를 사용하면 소비자는 호환되는 기술을 사용해야합니다.
  • 더 안전합니다. UI 계층은 DB에 직접 액세스하는 대신 방화벽 뒤에있는 서비스를 호출 할 수 있습니다.

"네이티브 코드"는 여기서 의미가 없습니다. a) 서비스가 "네이티브 코드"도 사용할 수 있으며 b) 적시 컴파일은 종종 네이티브 코드와 동일한 성능을 제공합니다.
sleske

요점을 알았어. "네이티브 코드"라고 말할 때 내가 말하는 것은 라이브러리가 "진행 중"호출이라는 것입니다. 어떤 서비스 계층의 오버 헤드가 없습니다 (예 : HTTP 웹 API 호출을 만드는 경우)
코리 하우스

예, 통화 오버 헤드는 실제로 낮아야합니다. "네이티브 코드"에 대한 언급을 "더 낮은 호출 오버 헤드"로 대체하기 위해 답을 자유롭게 편집 할 수있었습니다. :-)에 동의하지 않으면 언제든지 다시 편집하십시오.
sleske

내가 추가하고 싶은 것은 트랜잭션 사용법입니다 . 일반적으로 공유 라이브러리보다 서비스 경계에서 트랜잭션 작업을 수행하는 것이 훨씬 어렵습니다.
c_mart

2

SOA 접근 방식을 통해 다양한 서비스를 별도로 호스팅하고 유지 관리 할 수 ​​있습니다. 코드 외에도 특정 서비스를 배포하려면 많은 특수 구성 (암호, 포트, 인증서 등)이 필요할 수 있습니다. REST 서비스를 사용하면 명확하게 문서화되고 쉽게 이해할 수있는 유한 한 양의 복잡성이 있습니다. 또한 DB 또는 기타 리소스에 대한 액세스 권한을 클라이언트에 부여 할 필요가 없기 때문에 더욱 안전합니다.


1

SOA 서비스가 변경되면 해당 SOA 서비스를 다시 개발, 테스트 및 재배치해야합니다. 해당 서비스를 사용하는 모든 응용 프로그램은 계속 그렇게 할 수 있습니다. DLL에서 라이브러리를 변경하면 해당 라이브러리의 모든 소비자가 해당 DLL을 참조하도록 재개발해야하고, 모두 다시 테스트해야하고, 모두 재배치해야합니다. 이 문제가 제대로 발생하지 않을 위험이 있으며 응용 프로그램마다 DLL 버전이 다릅니다. 때로는이 문제가되지 않을 수도 있습니다 - 아마도 모든 시스템 구축시에 존재 라이브러리의 버전을 가져야한다 (당신은 도움이되는 새로운 기능을 가지고 로깅 시스템을 업데이트 한 수 - 당신이 정말모든 시스템을 업데이트해야합니까?)이 경우 라이브러리가 좋습니다. 그러나 세율 계산 서비스가 있고 세법이 변경되었다고 가정하십시오. 이 변경 사항을 통합하기 위해 모든 시스템을 업데이트하지 않아도되므로 한 곳에서 수행하는 것이 좋습니다. 이 경우 서비스가 더 나은 옵션입니다.


0

몇 가지 좋은 답변이 있지만 주어진 답변에 더 많은 것을 추가하고 싶습니다.

API 라이브러리 메소드는 가능한 적은 오버 헤드로 사물과 상호 작용할 때 매우 유용합니다. 결과적으로 API와 API를 사용하는 응용 프로그램간에 더 높은 결합이 있습니다. 때로는 응용 프로그램에 적합하지만 필요한 경우도 있지만, 매우 분산 된 시스템이 있거나 상호 운용성이 큰 문제라고 생각하는 경우 추상화 후자를 한 단계 업그레이드하고 다른 통신 방법을 사용해야합니다. 특히, 분산 시스템을 원한다면 SOAP는 SOA의 다음 단계이지만, 서로 간의 절차를 알아야하기 때문에 단위 간의 종속성이 남아 있습니다. REST는 머신이 다른 서비스의 컨텐츠에 대해 통합 된 방식으로 무언가를 학습 할 수 있도록하여 새로운 차원으로 나아가고 있습니다.

귀하의 경우, 응용 프로그램이 배포되지 않은 경우 응용 프로그램을 SOA로 변환 할 이유가 없습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.