다른 사람들이 시스템 통합을 어떻게 해결하는지 궁금합니다. 지난 몇 년 동안 점점 더 많은 작업이 통합 시스템에 도입되었고 이런 종류의 작업 필요성 또한 증가 할 것이라는 느낌이 들었습니다.시스템 통합은 어떻게합니까?
나는 당신이 그때 당신이 일종의 제품 (WebSphere, BizTalk, Mule 등)을 사용하는 경우 자신의 작은 서비스를 개발하거나 해결하는 경우 궁금해. 또한 이러한 종류의 솔루션을 관리하고 유지 관리하는 방법 (보안, 계측기 등을 어떻게 해결할 것인가), 솔루션에서 어떤 종류의 문제를 경험했는지 등은 흥미로울 것입니다.
와우 - 좋아 -이 게시물을 얻을 것이지만 큰 것입니다.
통합에 대한 비즈니스의 이해를 바탕으로 통합을 수행해야합니다. 비용이 많이 소요될 수 있으므로 비즈니스가 통합을 위해 표준화해야 할 수도 있으므로 운영 모델을 분류해야합니다. 실패! Enterprise Architecture: Driving Business Benefits from IT Author(s): Jeanne W. Ross
통합이 필요한 경우 통합 유형을 결정해야합니다.
속도 및 성능 메트릭이란 무엇입니까?
BizTalk 2006 및 웹 서비스를 Line Of Business 응용 프로그램과 함께 사용하는 복합 응용 프로그램이 포함 된 .NET SOA가 있습니다. 복합 엔드 (소비)에서 애플리케이션의 성능은 비즈니스 애플리케이션 라인에서 웹 서비스 (및 구현)의 속도로 제한됩니다! 서브 < 결과 3 초 반환 - 사례 목록. webservices에서 확인할 수 없으므로 초기 검색을 위해 데이터베이스로 직접 이동해야합니다. 그런 다음 사례 생성을위한 웹 서비스를 통해. 비용의 영향과 보전이 문제가됩니다. 웹 서비스 (HTTP), 드롭/EDI 등
파일 - 여기
요점은 당신이해야 할이 통합의 유형 봐에 도움이 될 것입니다 사양 및 비즈니스 요구 사항에 성능 기준을 살펴 보는 것입니다 기능적으로 통합을 위해서는 SLA/OLA에서 일련의 응답으로 이어질 수 있으므로 제안 된 아키텍처의 실패 지점을 살펴볼 필요가 있습니다. 통합/소멸 포인트를 귀하가 통제하는 것에 래핑 (wrapper)해야 할 수도 있습니다.
Line of Business와의 통합에 관해서도 통합하기 전에 다른 제품에 대해 얼마나 알고 있어야합니까? 예 Webservices는 계약에 의한 설계로되어 있지만 구현은 종종 새어 나가며 어떤 일이 일어나고 있는지에 대해 많은 것을 이해해야합니다. 그리고 이것이 웹 서비스로 추상화를 제어하지 못하는 제품이라면 BizTalk라는 통합 기술로 새어 나옵니다.
이 두 가지 사항을 함께하면 BizTalk와 같은 통합 허브 유형을 얻는 것이 좋습니다. 작성한 웹 서비스에서 비즈니스 응용 프로그램의 줄을 래핑하십시오. 그러면 BizTalk 측면에서 새어 나오는 추상화가 없어 질 수 있습니다. 귀하가 비즈니스 어플리케이션을 통합 허브 및 장애 지점에서 오케스트레이션 내부가 아닌 단일 소스로 분리 할 때 실패한 지점.
SOA와 계측의 계측 및 진단 Porjects는 습득하기가 어렵습니다! - 어떤 번쩍 거리는 판매원이 당신을 다르게 시도하도록 내버려 두지 마십시오! MOM Ent를 가진 MOM이 할 수 있습니다. UniCenter는 어쩌면 할 수 있습니다.
주된 문제는 intergation mean에서 오류라고 일컬어지는 것과 그걸 복구하는 방법을 이해하는 것입니다. 메시지가 갇히게되고 결국 그 프로세스가 의미하는 바를 이해해야합니다.당신은 말할 수있는 경고를받을 수 있습니다 - 가공업자는 100 % 램 100 % 오케스트레이션이 실패했지만 실제 의미는 없습니다. 당신은 처음부터 솔루션에이 물건을 넣어야합니다. 그리고 잘하면 실패 지점에 들어가야합니다.
통합 패턴의 유형과이를 수행하는 방법도 고려해야합니다.
위는 LIVE 구현에서 BizTalk가 포함 된 .NET SOA의 실제보기입니다. 그러나 BizTalk는 주로 HUB 및 SPOKE 패턴입니다.
체크 아웃 Enterprise Application Patterns by Martin Fowler
는 작업을 피부하는 방법에는 여러 가지가 있습니다!
기타 고려 사항 ... 플랫폼/개발자 언어 등 우리에게 큰 요인
하나는이 물건을 시작하는 데 필요한 기술이었다. 우리는 Java와 C#을 이해하는 개발자가 있었지만 주로 C#을 사용했습니다. 그래서 우리는 MS 스택에갔습니다. 그러나이를 관리하기 위해 통합 유형과 제품을 선택하면 해당 기술을 이해하는 데 더 많은 기술이 필요합니다. 하지만 이건 우리를위한 정상입니다 Devs 맞죠? Expereince와 상관없이 많은 개발자들이 BizTalk와 같은 문제를 해결할 수 있습니다! 패러다임의 큰 변화 - 부분적으로는 코드가 아닌 메시징 이동 때문입니다.
최강 비트!
통합에 직면 할 가능성이있는 트랜잭션의 수는이 모든 측면에서 가장 큰 요인 일 수 있습니다. 이것이 어떤 패턴, 실패 지점 및 그러한 것들에 대한 경고를 안내 할 것이기 때문입니다.
오른쪽 볼륨에 가장 적합한 볼륨을 선택해야합니다. 스케일 업 및 스케일 아웃 할 수있는 것! BizTalk는 확장 및 확장이 가능하고 다른 일부보다 더 잘 이해할 수 있기 때문에 BizTalk를 선택했습니다.
볼륨이 없으면 관리 할 항목이없고 관리가없는 webservice 유형 스타일로 이동해야합니다. 성능 및 실패에 대한 이해가 필요합니다.
.net 3을 사용하는 Windows 플랫폼에서 WWF/WCF를 살펴보면 BizTalk 및 기타의 오버 헤드없이 이러한 모든 문제에 대해 이제 acutal 플랫폼에서 훨씬 더 많은 웹 서비스에 도움이 될 수 있습니다.
희망이 도움이됩니다.
내 경험에 따르면 어떤 유형의 문제를 붙잡고 있는지에 따라 다릅니다.
내 경험에 따르면 BizTalk 2006 R2를 능가하기는 어렵지만 Microsoft 기술 스택 사용을 암시합니다.
Websphere MQ는 대기업에게 더 쉽게 팔리는 것처럼 보이며 엔터프라이즈 급에서 더 많은 사용을 보았을 것입니다.
둘 다 좋은 도구를 제공하지만 고객의 요구 사항에 맞게이 기능을 사용자 정의하는 것은 개발자의 몫입니다.
경우에 따라 맞춤식 솔루션이 비용을 낮추는 데 가장 적합하거나 활용 기술인 MSMQ 인 것으로 나타났습니다.
WebSphere, BizTalk, Mule에 대해 언급했습니다. 각각은 좋은 점과 나쁜 점과 매우 다른 특징을 가지고 있습니다. 통합 만하면 Mule을 추천합니다. 저는이 프로그램에 대해 매우 좋은 경험을했고 건축가는 비 침습성 이었기 때문에 항상 다른 ESB 또는 기타 버즈 단어 불만 사항 솔루션으로 마이그레이션 할 수있었습니다. Mule의 달콤한 점 중 하나는 응용 프로그램에 임베디드 될 수 있으며 최종 삽화를 Webshpere, WLS, Glassfish 등에 배포 할 수 있다는 것입니다. 그런 다음이 ESB는 모든 통합 배관 (연결 유형 및 프로토콜 관리)을 수행 할 수 있습니다. 일부 종단점은 언급 한 다른 통합 솔루션 일 수 있습니다.
우리는 Mule을 잠시 사용하고 있습니다 (현재 1.4에서 2.1.x 버전으로의 마이그레이션을 조사하고 있습니다).
글쎄, 라이브 커뮤니티와 빠른 반응으로 공급 업체 측에서 최고의 ESB 중 하나이지만, IMO 버전 2.1.x는 아직 원시 상태가 아닙니다 (또는 우리는 CXF 웹 호출 용으로 만 사용하는 회사입니다 :) 자세한 내용은 내 게시물 http://www.nabble.com/Migration-from-XFire-to-CXF:-Is-Web-Service-Client-in-Mule-2.x-broken--to19969320.html#a19969320)
오라클 계약이 있습니다. 따라서 우리는 Oracle Stack을 사용하고 있습니다. SOA Suite 10.1.3.4. 대부분 BPEL 솔루션이며 간단한 변환을 위해 ESB를 사용하려고합니다.
ESB에는 잘못된 결함 처리 메커니즘이 있습니다. BPEL의 경우 오류를 처리 할 수있는 여러 가지 방법이 있습니다. 우리는 SOA Suite에 연결하는 Java 웹 서비스를 개발하려고 노력하고 있으며, 주요 시스템은 Oracle EBS 시스템입니다. SOA Suite와 함께 제공되는 기본 EBS 어댑터를 통해 레거시 시스템 또는 다른 EBS 환경과 통신합니다.
우리가 직면 한 문제는 EBS 어댑터에 대한 지식 부족입니다. 우리는 EBS 시스템으로부터 정보를받은 BPEL 솔루션에 몇 가지 문제를 야기했습니다. 솔루션 제작을 준비하는 것은 지옥이었습니다.
우리 웹 서비스를 보호하는 것이 큰 문제는 아닙니다. Oracle 스택에는 Oracle Web Service Manager가 있습니다. 이를 통해 우리는 모든 웹 서비스를 안전하게 할 수 있습니다.
우리가 직면 한 가장 큰 문제는 우리 자신의 기준이 없다는 것입니다. 비즈니스에 SOA 솔루션을 구축 할 수 있다고 생각하게합니다. SOA 솔루션으로 얻을 수있는 이점을 설명 할 수는 없습니다. 빨리? 아니 ! 싼거야? 안돼! 더 쉬운 솔루션? 재사용이 가능한 좋은 서비스를 얻었을 때 ... 그 쉬운 부분은 문제가 있습니다. 재사용 가능한 웹 서비스를 사용하는 응용 프로그램을 어떻게 알 수 있습니까?
우리는 이러한 종류의 정보를 표시 할 수있는 레지스터가 필요합니다. 좋은 오픈 소스 솔루션을 찾을 수 없기 때문에 자체 레지스터를 만들려고합니다. Oracle 스택의 간단한 APEX 솔루션. ;)
누군가 이런 종류의 정보를 등록하는 좋은 제품을 알고 있습니까?