2012-08-23 2 views
0

우리는 데이터를 전송하는 데 필요한 약 6 개의 시스템 (모든 내부 시스템)을 보유하고 있습니다. 현재 우리는 일관된 방법이 없습니다. 우리는BizTalk 올바른 솔루션입니까?

우리의 목표는 .. 직접 등 데이터베이스, 텍스트 파일을 업데이트하기 위해 직접 데이터베이스를 업데이트 할 수 ODBC 연결을 SSIS, SQL Server에 연결된 서버 (Linked Server)를 사용

1) 응용 프로그램을 연결하는 일관된 방법이있다.
2) 응용 프로그램 간의 연결을 모니터링하고 로깅하는 중앙 집중식 방법이 있습니다.
3) 웹 서비스를 제공하는 응용 프로그램의 경우 은 데이터베이스 대신 과 직접 연결하여 사용하기를 원합니다.

웹 서비스, 데이터베이스, 플랫 파일에 연결할 수 있어야하며 TCP 연결을 통해 데이터를 받아 들일 수 있어야합니다.

BizTalk는이 문제에 대한 좋은 해결책입니까 아니면 과도한 것입니까?

+1

BizTalk는 원하는 모든 것을 쉽게 처리합니다. 주요 관심사는 비용 대 다른 기술을 해결할 것입니다. 라이센스만으로도 비쌉니다 (서버 당 2.5k 달러가 가장 저렴합니다). 그런 후에도 BizTalk 특정 기술을 많이 필요로하는 솔루션을 개발해야합니다. 또한 당신이 얻는 모니터링은 (2010 년에 개선되었을 수도 있습니다 - 광범위하게 사용하지는 않았습니다) 완전히 새로운 것은 아닙니다 - 구성하고 올바르게 사용하기 위해서는 전문 기술이 필요합니다. 최선의 방법은 무료 개발 버전을 구해서 어떻게 적용되는지 확인하는 것입니다. –

답변

2

정말 다릅니다. 당신이 묘사하고있는 아키텍처를 위해서는 적합 할 것입니다. 그러나 통합하려는 시스템과의 커뮤니케이션이 유효한지 검증해야합니다. 예를 들어; 이러한 시스템이 웹 서비스, 메시지 대기열 또는 파일 기반 통신을 사용할 때 적합 할 수 있습니다.

biztalk로 시작하면 하드웨어, 소프트웨어 등에 투자해야하며 대부분의 경우이를 사용하는 법을 배우기 위해 기꺼이 투자해야합니다. 이 시스템 커넥터 제대로 2) 예,에 BizTalk BAM 3이 지원을 캡슐화해야합니다 경우 1) 예) 네, 당신이 어떤에서 완벽하게

1

을 일치합니다 '당신의 점에 관한

(6 시스템)에서 설명했듯이, 통합에 대한보다 형식화 된 접근법을 조사하는 좋은시기이기도합니다. 포인트 투 포인트/직접 통합 방식에서 많은 수의 순열/스파게티가 발생할 것으로 예상됩니다. 각각의 새로운 시스템이 추가됩니다.

BizTalk는 모두 hub and spoke, and bus type topologies (ESB 도구 키트 포함)을 지원하며 둘 중 하나는 시스템 간의 상호 연결 수를 줄입니다.

는 oɔɯǝɹ에 추가하려면

  1. 예 - 궁극적으로 BizTalk는 내부적으로 XML에 이르기까지 모든 변환하면 메시지 유형 사이에 변환하는 영상지도 또는 XSLT 중 하나를 사용합니다.
  2. 예. 상자 밖에도 WMI 및 Perfmon 카운터를 많이 사용할 수 있으며 BizTalk에는 BizTalk의 상태를 모니터링하는 SCOM 관리 팩이 있습니다. 당신에게 애플 리케이션을 위해, BAM (간단한 모니터링을위한 TPE, BAM API를 사용하여 좀 더 진보 된 것들을 할 수 있습니다).
  3. 예 - BizTalk는 모든 일반적인 WCF 바인딩 유형과 기본 SOAP 웹 서비스를 지원합니다. BizTalk의 메시지 상자는 다른 프로세스를 나중에 메시지에 '연결할'수있는 게시/하위 엔진으로 사용할 수 있습니다.

몇 가지주의 사항 :

. BizTalk는 메시지 (예 :조직 전체의 전자 문서). 대량 데이터 동기화에는 적합하지 않습니다. SSIS는 실제로 대규모 데이터 전송/데이터 마이그레이션/데이터 동기화 패턴에 더 나은 선택입니다.

. 데이빗이 지적한 것처럼 BizTalk에 대한 학습 곡선은 가파르고 도구 자체는 무료가 아니며 (SQL과 BizTalk 라이센스가 필요하며 일반적으로 SCOM과 같은 모니터링 도구를 사용하기를 원할 것입니다.) 이를 빠르게 추적하려면 BizTalk 교육에 대한 개발자를 보내거나 BizTalk 컨설턴트를 불러 들여야합니다.

. Microsoft는 Azure Service Bus에 초점을 맞추고있는 중이며 앞으로 BizTalk가 Azure Service Bus로 병합 될 speculation이 있습니다. 엔터프라이즈 전략이 전적으로 Microsoft가 아닌 경우 ESB에 NServiceBus 및 FUSE과 같은 제품을 고려할 수도 있습니다.

1

문제는 일반적인 엔터프라이즈 문제입니다. 기업은 HR, 웹, 공급망, 재고 관리, 고객 관리 등과 같은 격리 된 응용 프로그램을 몇 년 동안 구축하기 시작하고 이러한 응용 프로그램이 혼자 살 수는 없으며 서로 이야기해야 할 필요가있을 때 일반적으로 몇 가지 해킹 된 솔루션을 시작합니다. 데이터베이스 수준에서의 데이터 마이그레이션과 유사합니다.

하지만 곧 그들은 명확한 가시성, 관리 불량, 표준 등의 문제를 깨닫지 못하고 진짜 스파게티를 만듭니다. 가장 큰 위협은 애플리케이션이 서로 의존하게되고 무엇이든 변경할 수있는 민첩성을 잃게된다는 것입니다. 시스템을 변경하면 중량 테스트 및 긴 릴리스주기가 필요합니다.

이것은 BizTalk Server와 같은 미들웨어 플랫폼이 해결할 수있는 종류의 문제입니다. 스레드에서 많은 응답이 BizTalk 서버의 비용에 집중되었습니다 (언급 된 비용 중 일부는 올바른 BTW가 아닙니다). 저렴한 제품은 아니지만 모든 애플리케이션을 함께 연결하는 중앙 미들웨어 플랫폼으로서의 조직에서 수행하는 역할과 비 기능적 이점의 수를 살펴보면 대부분의 타사 제품에 대한 어댑터와 같이 상자 밖에서 쉽게 사용할 수 있습니다 오라클, FTP, FILE, 웹 서비스 등과 같이 플랫폼을 쉽게 확장하고, 성능, 장기 실행 워크 플로우, 내구성, 장기 실행 워크 플로우를위한 보상 로직, 환경을 조절하는 기능 등이 포함됩니다.

새로운 Microsoft Office 제품을 사용하려는 경우 BizTalk를 사용하는 것이 좋습니다. 그들은 자신의 상황을 찾아 분석 할 수있는 의사를 도울 수 있습니다.

관련 문제