시스템 통합은 어떻게 하시나요?

Question

다양한 사람들이 시스템 통합을 어떻게 해결하는지 궁금합니다.나는 지난 몇 년 동안 시스템 통합에 점점 더 많은 작업이 이루어졌고 이러한 종류의 작업 요구도 증가할 것이라고 생각합니다.

자체적으로 작은 서비스를 개발해 연결한 뒤 해결하시는지, 아니면 일종의 제품(WebSphere, BizTalk, 노새 등).또한 이러한 종류의 솔루션이 어떻게 관리 및 유지 관리되는지(보안, 계측 등을 어떻게 해결하는지), 솔루션에서 어떤 종류의 문제를 경험했는지 등을 아는 것도 흥미로울 것이라고 생각합니다.

Answer 1

와우 - 알았어 - 이것에 대한 게시물을 받게 되지만 규모가 커질 것입니다.

통합은 비즈니스의 이점에 대한 큰 이해를 바탕으로 뒷받침되어야 합니다. 운영 모델을 정리하십시오. 비즈니스는 통합 대신 표준화해야 할 수도 있고 비용이 많이 들 수 있으므로 대부분의 SOA가 실패하는 이유입니다! 엔터프라이즈 아키텍처:IT 저자의 비즈니스 혜택을 주도합니다.잔느 W.로스

통합이 필요한 경우 통합 유형을 결정해야 합니다.

속도 및 성능 지표는 무엇입니까?

우리는 BizTalk 2006과 LOB(Line of Business) 응용 프로그램이 포함된 웹 서비스를 사용하는 복합 응용 프로그램이 포함된 .NET SOA를 보유하고 있습니다.복합 엔드(소비)에서의 애플리케이션 성능 - 업무용 애플리케이션의 웹 서비스(및 해당 구현) 속도로 제한됩니다!결과에 대한 3초 미만의 결과 반환(사례 목록)이 필요합니다.웹 서비스에서는 달성할 수 없으므로 초기 검색을 위해 데이터베이스로 직접 이동해야 합니다.그런 다음 웹 서비스를 통해 사례 생성을 수행합니다.여기서는 비용 영향과 유지 관리가 문제가 됩니다.

여기서 요점은 사양 및 비즈니스 요구 사항의 성능 기준을 살펴보는 것입니다. 이는 웹 서비스(HTTP), 파일 삭제/EDI 등 수행해야 하는 통합 유형을 살펴보는 데 도움이 됩니다.

기능적으로 통합을 위해서는 제안된 아키텍처에서 실패 지점을 살펴봐야 합니다. 이는 SLA/OLA에서 일련의 책임으로 이어지기 때문입니다.통합/실패 지점을 제어하는 ​​항목으로 래퍼해야 할 수도 있습니다.

LOB(Line of Business)와의 통합과 관련해 비슷한 점은 통합하기 전에 다른 제품에 대해 얼마나 알아야 합니까?예, 웹 서비스는 계약에 따라 설계되어야 하지만 구현이 누출되는 경우가 많으며 무슨 일이 일어나고 있는지에 대해 많이 이해해야 합니다. 웹 서비스가 있어도 추상화를 제어할 수 없는 제품인 경우 BizTalk라는 통합 기술로 누출됩니다.

이 두 가지 점을 함께 결합하면 가장 좋은 조언은 BizTalk와 같은 통합 허브 유형을 얻는 것입니다. 즉, 생성한 웹 서비스에 LOB(Line of Business) 응용 프로그램을 래퍼하여 BizTalk 측에서 추상화 누출이 발생하지 않도록 하고 실패 지점도 줄일 수 있습니다. 통합 허브에서 비즈니스 애플리케이션 라인을 분리하고 오류 지점을 오케스트레이션 내부가 아닌 단일 소스로 분리했습니다.

SOA 및 통합 프로젝트의 계측 및 진단은 달성하기 어렵습니다!- 어떤 멋진 판매원도 당신에게 다르게 말하려고 하지 마세요!응 MOM Ent와 MOM이 할 수 있어 UniCenter도 할 수 있어 ㅋㅋ

주요 문제는 인터게이션에서 트림 오류가 무엇을 의미하는지와 이를 복구하는 방법을 이해하는 것입니다.결국 메시지가 중단되고 이것이 해당 비즈니스 프로세스에 어떤 의미인지 이해해야 합니다.프로세서는 100% Ram이고 100% 오케스트레이션은 실패했지만 실제 의미는 없다는 경고를 받을 수 있습니다.처음부터 솔루션에 이 항목을 엔지니어링해야 하며, 실패 지점까지 고려하도록 설계해야 합니다.

통합 패턴의 유형과 이를 수행하는 방법도 고려해야 합니다.

위는 LIVE 구현에서 BizTalk를 사용하는 .NET SOA의 실제 세계관입니다.그러나 이는 또한 이것의 아키텍처적 한계 때문이기도 합니다. BizTalk는 주로 HUB 및 SPOKE 패턴입니다.

확인해 보세요 Martin Fowler의 엔터프라이즈 애플리케이션 패턴

작업을 스킨화하는 방법에는 여러 가지가 있습니다!

기타 고려사항...플랫폼/개발자 언어 등

우리에게 가장 큰 요인 중 하나는 이 일을 시작하는 데 필요한 기술이었습니다.Java와 C#을 이해하는 OO 개발자가 있었지만 주로 C#을 사용했습니다.그래서 우리는 MS 스택을 선택했습니다.그러나 통합 유형과 이를 관리할 제품을 선택하면 해당 기술을 이해하는 데 더 많은 기술이 필요합니다.하지만 이건 우리 개발자들에게는 정상적인 일이죠?경험에 관계없이 많은 개발자가 BizTalk와 같은 문제를 풀 수 있습니다!패러다임의 큰 변화 - 이는 부분적으로 코드보다는 메시징 변화로 인한 것입니다.

마지막으로 최고의 비트!

통합에서 직면하게 될 거래의 수는 아마도 이 모든 것에서 가장 큰 단일 요인일 것입니다.이는 그러한 것들에 대한 패턴, 실패 지점 및 관용을 안내할 것입니다.

예상되는 볼륨에서 가장 적합한 볼륨을 선택해야 합니다.확장하고 확장할 수 있는 것!우리는 다른 제품보다 더 잘 이해하고 올바르게 확장 및 확장할 수 있는 BizTalk를 선택했습니다.

볼륨이 없으면 관리할 항목이 없는지 살펴보고 관리가 없는 웹 서비스 유형 스타일로 웹 서비스를 선택하세요. 성능 및 오류 이해를 코딩해야 합니다.

.net 3을 사용하는 Windows 플랫폼에서 WWF/WCF를 살펴보세요. 웹 서비스에서 웹 서비스로의 전환에 도움이 될 수 있습니다. 이제 BizTalk 및 기타 오버헤드 없이 이러한 모든 문제에 대해 실제 플랫폼에서 훨씬 더 많은 문제를 해결할 수 있습니다.

도움이 되었기를 바랍니다.

Answer 2

내 경험에 따르면 어떤 종류의 문제를 다루고 있는지에 따라 다릅니다.

내 경험에 따르면 BizTalk 2006 R2를 가격 대비 성능 면에서 이기는 것은 어렵지만 Microsoft 기술 스택을 사용한다는 의미는 아닙니다.

Websphere MQ는 대기업에 더 쉽게 판매되는 것으로 보이며 엔터프라이즈 수준에서 더 많이 사용되는 것으로 보입니다.

둘 다 좋은 도구를 제공하지만 고객의 요구 사항에 맞게 이를 사용자 정의하는 것은 개발자의 몫입니다.

어떤 경우에는 맞춤형 솔루션이 비용을 절감하는 데 가장 적합하거나 MSMQ와 같은 기술을 활용하는 것임을 발견했습니다.

Answer 3

WebSphere, BizTalk, Mule을 언급하셨습니다.각각의 장점과 단점은 매우 다른 특징을 가지고 있습니다.통합만 원하신다면 Mule을 추천하겠습니다.나는 그것에 대해 매우 좋은 경험을 가지고 있었고 더 중요한 것은 설계자가 비침습적이므로 언제든지 다른 ESB 또는 다른 버즈 단어 불만 솔루션으로 마이그레이션할 수 있다는 것입니다.Mule의 장점 중 하나는 애플리케이션에 내장할 수 있고 최종 아티팩트를 Webshpere, WLS, Glassfish 등에 배포할 수 있다는 것입니다.ESB 내장을 보여주지도 않고요.그러면 이 ESB는 모든 통합 배관(연결 유형 및 프로토콜 관리)을 수행할 수 있습니다.반면 일부 엔드포인트는 귀하가 언급한 다른 통합 솔루션일 수 있습니다.

Answer 4

우리는 한동안 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)

Answer 5

우리는 오라클 계약을 맺었습니다.그래서 우리는 Oracle Stack을 사용하고 있습니다.SOA 스위트 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 솔루션입니다.;)

그럼 이런 정보를 등록할 수 있는 좋은 제품을 아시는 분 계시나요?