NServiceBus 에 대한 이야기를 들었지만 그것이 무엇인지 실제로 이해하지 못했습니다. 그들은 ".net을위한 가장 인기있는 오픈 소스 서비스 버스"라고 주장합니다.
그래서; "서비스 버스"란 무엇이며 언제 필요합니까?
NServiceBus 에 대한 이야기를 들었지만 그것이 무엇인지 실제로 이해하지 못했습니다. 그들은 ".net을위한 가장 인기있는 오픈 소스 서비스 버스"라고 주장합니다.
그래서; "서비스 버스"란 무엇이며 언제 필요합니까?
답변:
서비스 버스는 SOA의 이더넷으로 생각할 수 있습니다.
무엇보다도 이더넷의 IP 주소와 같이 사물을 식별하는 언어를 도입합니다. 이 이름은 본질적으로 물리적 인 것이 아닙니다.
다음으로, 세미 연결 통신을 지원하는 버스의 경우 대기열이나 은유의 이더넷 카드와 같이 각 노드에 물리적으로 관련된 것이 있습니다.
물리적 인 것 외에도 이더넷 용 OSI 스택과 같은 통신의 "프로토콜"부분이 있습니다. 버스에서 이것은 애플리케이션 코드에서 사용하는 클라이언트 라이브러리입니다.
궁극적으로 서비스 버스는 분산 시스템 구축을위한 한 단계 높은 추상화 수준을 제공하는 것으로 볼 수 있습니다. 클라이언트-서버 통신에도이를 사용하여 내구성있는 단방향 메시징을 제공하고 서버가 알림을 다시 클라이언트로 푸시 할 수 있습니다.
특히, RabbitMQ, MSMQ, Regular SQL Tables, Amazon SQS, Azure Storage Queues 및 Azure Service Bus 중에서 선택한 큐잉 기술을 사용하면 NServiceBus가 매우 가볍고 사용하기 쉽습니다.
엔터프라이즈 서비스 버스에 대한 Wikipedia 기사를 확인하십시오 .
Service Bus는 좋은 서비스 지향 아키텍처를 구현하기위한 끝없는 탐구에서 또 다른 추상화 계층 역할을합니다. 서비스 버스는 메시징, 라우팅 및 서비스 조정과 같은 우수한 서비스 지향 아키텍처 뒤에있는 무거운 작업을 처리 할 수 있습니다.
왜 그런 것을 원하는지 잘 모르겠다면 좋은 서비스 지향 아키텍처를 만드는 이유를 읽어 보는 것이 좋습니다. 내 눈을 뜨고 웹 서비스를 갖는 것과 진정한 서비스 지향 아키텍처를 갖는 것의 차이점을 증명 한 책은 Thomas Erl의 서비스 지향 아키텍처 : 개념, 기술 및 디자인 이었습니다 .
이 용어는 EAI 의 후계자 인 SOA 와 함께 도입되었습니다 .
필요할 때? 그건 좋은 질문이야. 그것은 많은 복잡성을 동반합니다.
경험의 법칙은 원인보다 더 많은 문제를 해결할 수 있습니다.
이기종 환경이 있고 (다른 기술을 사용하는) 응용 프로그램을 비즈니스 프로세스에 맞추려는 경우 심각합니다. 그런 다음 오케스트레이션 및 안무에 BPEL 을 사용하는 것이 도움이 될 수 있습니다 (그러나 마이그레이션으로 인해 문제가 발생 함).
편집 : wikipedia에없는 것은 연습입니다. ESB는 상호 운용성을 의미하는 Corba 또는 Java Enterprise와 함께 사용하기 위해 특수 커넥터, 이전 터미널 응용 프로그램을 사용하여 적응할 수 있습니다. 단점은 SOAP에 대한 100 개가 넘는 '표준'이 엄청난 노력 없이는 협력하지 않는다는 것입니다.
두 개의 대형 보증 회사가 합병 된 후 6 개월 이내에 IT 시스템을 상호 연결해야하는 경우 반드시 필요합니다.