기업 서비스 버스(ESB)를 사용한 정보 시스템 통합
복잡한 정보 시스템을 통합하기 위한 모범 사례 중에는 논리적 데이터 마트의 구축과 MDM 시스템 및 기업 서비스 버스(ESB, Enterprise Service Bus)를 사용한 중앙 집중식 데이터 교환 인프라 구축이 있습니다. ArchiGraph.MDM 시스템을 포함한 당사의 솔루션은 운영 체제의 일부로 사용하기에 적합합니다. 특수 목적 Astra Linux Special Edition 및 Alt Linux.
통합 버스가 필요한 이유는 무엇입니까?
겹치는 정보 집합으로 작동하는 두 개 이상의 소프트웨어 제품을 사용하는 모든 회사는 그들 사이에서 통신하지 않을 때의 대가를 알고 있습니다. ERP, CRM 및 기타 기업 애플리케이션 간의 동기화되지 않은 고객 목록 또는 제품 범위 및 기타 정보는 시간, 자원, 회사 평판의 지속적인 손실을 초래합니다. 이 문제에 대한 유일한 올바른 솔루션은 MDM(마스터 데이터 관리) 시스템과 함께 ESB(엔터프라이즈 서비스 버스)를 구현하는 것입니다.
정보의 정기적인 업로드 및 변환(ETL), 서비스 지향 아키텍처(SOA)를 기반으로 하는 솔루션은 이러한 문제에 대한 임시 솔루션만 제공하고 많은 단점이 있으며 IT 인프라의 성장을 제한합니다.
통합 버스의 구현
통합 버스를 도입할 때 서로 다른 정보 시스템에 존재하는 동일한 객체에 대한 정보 구조를 매핑(비교)하는 작업이 발생합니다. 각각의 애플리케이션과 관련하여 공통, 중립성을 생성하여 이 문제를 해결하는 것이 필요하며, 정보 모델. 이러한 모델은 시맨틱 기술을 사용하여 가장 효과적으로 구현될 수 있습니다. 최적의 구현 결과를 위해서는 전문 데이터 설계자가 모델을 개발해야 합니다.
구현 프로젝트의 중요한 부분은 데이터 교환과 관련된 모든 응용 프로그램에 대한 커넥터(프로그래밍 인터페이스)의 구현입니다. 당사의 전문가는 다양한 플랫폼에서 광범위한 소프트웨어용 커넥터를 개발하고 연결한 경험이 있습니다.
IBM WebSphere MQ, Integration Service Bus, WSO2 Message Broker, Apache Synapse 및 Business Semantics 버스 솔루션을 기반으로 파트너와 함께 통합 프로젝트를 수행합니다.
종종 통합 버스를 구현하는 프로젝트는 엔터프라이즈 정보 아키텍처의 일반적인 재설계의 일부로 수행됩니다.
2005년
Enterprise Service Bus - 통합 문제 해결을 위한 "예산" 접근 방식
작성 : 해외 사이트 자료를 바탕으로
번역: Intersoft Lab
독자들에게 통합에 대한 다양한 접근 방식을 계속해서 알리기 위해 우리는 비교적 새롭고 매우 매력적인 기술인 기업 서비스 버스(Enterprise Service Bus, 약어 ESB)에 집중하기로 결정했습니다.
Enterprise Service Bus란 무엇이며 DWH, OLAP 및 XML Connoisseurs Club Magazine의 이전 호에서 논의된 EAI(Enterprise Application Integration)와 어떻게 비교됩니까? 확립된 전통에 따라, 우리는 먼저 이 분야의 전문가들에게 플로어를 제공할 것입니다.
Gartner 분석가는 ESB를 통합된 새로운 유형의 미들웨어로 정의합니다. 기능이미 다른 사람들 기존 유형중간 지원. Enterprise Service Bus는 SOAP(Simple Object Access Protocol) 프로토콜을 구현하고 WSDL(Web Services Description Language) 언어와 UDDI(Universal Description, Discovery and Integration) 사양을 사용하여 웹 서비스를 지원합니다. 많은 엔터프라이즈 서비스 버스는 보장된 전달, 게시 및 구독을 비롯한 다른 통신 스타일도 지원합니다. 이러한 버스가 제공하는 서비스는 경량 메시징 미들웨어에 없는 "부가 가치"를 가지고 있습니다. 메시지 검사, 변환, 콘텐츠 기반 라우팅, 보안, 서비스 지향 아키텍처를 위한 서비스 검색, 로드 밸런싱 및 등록을 제공합니다. 일부 서비스는 버스 기반에 구축되고 다른 서비스는 플러그인에서 실행됩니다. 또한 버스는 XML 및 기타 메시지 형식을 지원합니다.
기업 서비스 버스가 매력적인 이유는 무엇입니까? 우선, 상대적으로 저렴합니다. ESB 제품은 일반적으로 저렴하거나 "예산" 솔루션으로 포지셔닝됩니다.
실제로 오늘날 통합 기술에 대한 수요가 증가하고 있습니다. 그리고 초기에는 EAI 제품의 배치가 전략적 목표의 달성과 연관되어 장기적으로 성과를 거두었지만, 이 순간기업이 직면해야 하는 것은 본질적으로 전술적이며 새로운 접근 방식이 필요합니다. "현대 비즈니스 현실"은 EAI 벤더가 전통적으로 취약했던 영역인 변환, 개발자 중심 프로그래밍(예: Java) 및 외부 기술과의 통합에 주목했습니다. 이 모든 "비옥한 땅"은 새로운 범주의 제품인 ESB의 출현을 위한 것입니다.
엔터프라이즈 서비스 버스의 장점에 대해 이야기하면서 Gartner의 부사장이자 연구 부서 구성원인 Roy Schulte의 말을 인용할 가치가 있습니다. 소프트웨어중간 계층은 더 이상 서비스 지향(Service Oriented Architecture, 약어 SOA) 및 이벤트 중심 아키텍처(Event Driven Architecture, 약어 EDA), 웹 서비스 및 비즈니스 프로세스 관리를 사용하는 새로운 애플리케이션을 지원할 수 없습니다. 이것이 정보 시스템 설계자와 관리자가 기업 정보 인프라를 ESB와 함께 활용해야 하는 주된 이유입니다.”
Gartner 수석 분석가는 ESB 공급업체 그룹을 강조합니다. 그는 복합 애플리케이션 및 SOA를 지원하는 데 가장 적합한 "예산" 통합 솔루션으로 포지셔닝된 ESB 제품의 첫 번째 그룹을 언급합니다. 두 번째 그룹은 웹 서비스 시장을 겨냥한 제품이며 마지막으로 마지막 그룹은 소프트웨어, EDA 지원을 제공합니다. Roy Schulte에 따르면 ESB 시장은 웹 서비스, 다중 프로토콜 및 이벤트 중심 솔루션에 대한 수요 증가로 인해 향후 몇 년 동안 밀도가 높아질 것이라고 합니다.
흥미롭게도 많은 회사에서 ESB는 제품 범주가 아니라 아키텍처로 취급됩니다. 예를 들어, IBM에서 엔터프라이즈 서비스 버스는 "아키텍처 패턴"으로 간주됩니다.
따라서 ESB가 무엇인지에 대한 명확한 정의가 아직 없다고 말할 수 있습니다. 실제로 토론은 두 가지 질문을 중심으로 이루어집니다.
- ESB 아키텍처(표준화할 필요조차 없는 아키텍처), "일방적 접근" 또는 독립형 제품입니다.
현재 기성 솔루션이 없는 많은 공급업체가 Enterprise Service Bus를 아키텍처로 이야기하는 것이 도움이 되지만 현재 상황에서는 고객이 ESB 기능을 제공하는 제품이 필요합니다. 따라서 향후 2년 동안 ESB 기능을 제공하는 공급업체의 수가 증가할 것으로 예상해야 합니다.
- ESB 제품의 위치와 미래는 무엇입니까? 즉, 엔터프라이즈 서비스 버스는 라우팅 및 메시징뿐만 아니라 간단한 XML 변환을 제공하는 고급 메시지 대기열 시스템입니다. 아니면 애플리케이션 어댑터, 자동화 및 비즈니스 프로세스 모델링을 사용하여 ESB는 EAI를 성공적으로 대체합니다.
현재로서는 이러한 질문에 대한 확실한 답이 없습니다.
그러나 Enterprise Service Bus에 대한 명확성은 없지만 ESB의 개방형 표준 접근 방식이 구매 및 구현 비용을 크게 줄일 수 있다는 점은 강조할 가치가 있습니다.
"기업 서비스 버스"라는 용어에서 "서비스"라는 단어가 중심이라는 점에 유의하십시오. 따라서 Forrester Research 분석가는 ESB를 "기본(재사용 가능한) 비즈니스 서비스 세트에 액세스할 수 있는 미들웨어 계층"으로 간주합니다. SOA는 입력 및 출력 데이터를 XML 형식이러한 서비스에서 받았습니다.
ESB 및 XML
XML의 특별한 역할을 강조하지 않는다면 불공평할 것입니다. XML은 통합의 기초입니다. XML이 단순한 언어가 아닌 "알파벳"에 가깝다는 사실을 받아들이면 통합을 완전히 구현하려면 비즈니스 프로세스를 조정하고 XML 변환을 관리하며 조직 전체에 XML 메시지의 유효성을 검사하고 전달해야 한다는 것이 분명해집니다. 이러한 모든 기능은 Enterprise Service Bus의 기초를 형성합니다.
XML은 데이터 집합의 포괄적인 표현을 제공할 수 있습니다. 이 언어의 인기는 높은 유연성과 확장성에 기인할 수 있습니다. 실제로 XML 구문을 사용하면 다양한 데이터를 처리하기 위한 특수 XML 스키마를 현대화하고 개발할 수 있습니다.
동시에 전송할 데이터의 양의 급격한 증가는 기업 정보 구조의 기능에 심각한 어려움을 초래합니다. 따라서 XML의 기능을 사용한 최초의 통합 프로젝트는 이 언어의 약속에 대한 "살아있는" 증거였지만 이제 XML 문서의 수, 크기 및 복잡성이 증가하는 특정 문제가 있습니다. 기존 어려움(확장성 부족)의 주요 원인은 다음과 같습니다.
- 전체 문서 구문 분석: 일반적으로 라우팅 및 필터링을 위해 일부만 추출해야 하는 경우에도 전체 문서를 구문 분석하려고 합니다. 문서가 커지면 대기 시간이 늘어납니다.
- 다시 스캔합니다. 문서는 종종 재분석됩니다. 즉, 비즈니스 프로세스의 각 단계에서 동일한 문서를 여러 번 스캔할 수 있습니다. 이 방법은 리소스 집약적이기 때문에 성능과 처리량이 저하됩니다.
- 단일 가닥 실행. 이 경우 현재 단계가 완료될 때까지 다음 처리 단계를 시작할 수 없습니다. 결과적으로 전체 프로세스가 가장 느린 단계에 의존하기 때문에 대기 시간이 증가합니다.
불충분한 확장성 문제를 극복하기 위해 다음 기능을 지원하는 처리 아키텍처를 사용하는 것이 좋습니다.
- 문서 스트리밍 - 각 요소가 도착할 때 XML 문서가 처리되도록 합니다. 낮은 대기 시간을 보장합니다. 이 접근 방식을 사용하면 큰 메시지를 작은 메시지만큼 생산적으로 처리할 수 있습니다.
- 전체 XML 문서가 아닌 관련 단편만 처리하여 매우 중요한 성능 향상을 달성하는 선택적 처리.
- 다중 스레드 처리: 프로세서가 채널 전체의 단계 정렬, 개별 단계의 병렬 실행 및 여러 XML 조각을 처리할 때 동일한 단계의 로드 밸런싱을 관리합니다.
- 처음부터 동일한 문서의 구조를 여러 번 반복적으로 읽는 대신에 필요한 모든 조각을 한 번의 전송으로 추출하는 유일한 스캔입니다.
위의 기능은 특별한 코딩 및 구성 없이 Enterprise Service Bus를 사용하여 구현할 수 있습니다.
엔터프라이즈 서비스 버스(ESB)와 메시지 브로커(예: RabbitMQ)의 차이점은 무엇입니까?
그 결과, 불만족스러운 성능의 문제가 해결될 수 있다.
결론
외국 인터넷 출판물에 실린 출판물과 주요 리서치 회사의 분석가가 추정한 바에 따르면 기업 서비스 버스는 더 이상 단순한 서비스가 아닙니다. 새로운 기술큰 잠재력과 함께. 실제로 Gartner는 2005년에 대부분의 대기업이 ESB를 사용할 것으로 예측합니다. IDC는 기업 서비스 버스가 "혁명"해야 한다고 믿습니다. 정보 기술유연하고 확장 가능한 분산 처리를 가능하게 합니다.
실제로 개방형 표준(특히 XML)에 대한 지원은 저렴하지만 효과적인 솔루션을 제공하고 빠른 투자 수익을 보장합니다. 높은 비율 ROI. 통합 컨소시엄의 부사장인 Steve Craggs는 "ESB는 통합의 기초이며 통합 프로젝트를 효율적이고 성공적이며 체계적으로 구현할 수 있는 유연하고 사용자 정의 가능한 환경을 제공합니다."라고 말했습니다.
그러나 '기업 서비스 버스'라는 용어의 모호성으로 인한 불확실성은 여전히 남아 있습니다. 오늘날 ESB는 SOA를 구현하는 데 필요한 모든 기술을 나타냅니다. 이것이 바로 서비스 지향 아키텍처의 개발 및 적용을 전문으로 하는 회사인 ZapThink의 관점입니다. 이와 관련하여 ZapThink 분석가는 엔터프라이즈 서비스 버스에 대한 실제적이고 구체적인 정의가 2005년에 개발되지 않으면 ESB라는 용어가 "SOA 사전에서 영원히 사라질 것"이라고 경고합니다. SOA 자체에 대해서는 다음 기사에서 논의될 것입니다.
간행물
- Beth Gold-Bernstein은 ESB가 당신의 미래에 중요합니까?
- Nigel Thomas와 Warren Buckley ESB의 부상.
- 통합 컨소시엄 웹사이트에 게시된 자료.
ESB와 SOA란 무엇인가¶
System-of-Systems 사고에 대한 훌륭한 설명
Nick Coghlan, 핵심 Python 개발자
에서도 사용 가능 카탈라, 독일어, 영어, 프랑세즈, 이탈리아노, 네덜란드, 포르투갈어, 터키어그리고 中文 .
약어 ESB 및 관련 SOA는 혼동의 원인이 될 수 있습니다. ESB는 엔터프라이즈 서비스 버스를 의미합니다. SOA - 서비스 지향 아키텍처.
이 이름은 의미가 거의 없으므로 다음이 더 많습니다. 전체 정보과도한 기업용어 없이 평범한 언어로.
모든 진실¶
은행의 프런트 엔드 애플리케이션에 로그인할 때 어떤 일이 발생하는지 상상해 봅시다.
- 당신의 이름이 표시됩니다
- 계정 잔액이 표시됩니다.
- 신용 카드 및 직불 카드 표시
- 귀하의 뮤추얼 펀드 목록이있을 수 있습니다
- 또한 관심이 있을 수 있는 사전 계산된 대출 목록을 받습니다.
높은 확률로 우리는 이 모든 정보가 다음에 속한다고 말할 수 있습니다. 다른 시스템일부 인터페이스(HTTP, JSON, AMQP, XML, SOAP, FTP, CSV 또는 기타)를 통해 데이터를 제공하는 애플리케이션:
- Linux 및 Oracle을 실행하는 CRM에서
- z/OS 메인프레임에서 실행되는 COBOL 시스템에서
- 그들은 이 정보가 메인프레임 시스템에서 왔다고 말하지만 이 사람들은 너무 조용해서 다른 모든 것보다 CSV를 선호한다는 말 외에는 아무 말도 하지 않습니다.
- Windows에서 실행되는 PHP와 Ruby의 혼합에서
- Linux 및 Solaris에서 실행되는 PostgreSQL, Python 및 Java에서
문제는 프론트엔드 애플리케이션이 시스템 1-5와 통신하도록 하는 방법입니다. 글쎄, 안돼.
이는 이러한 환경이 여러 시스템을 넘어 확장할 수 있도록 하는 기본 사항입니다. 당신은 그들이 서로 직접 통신하도록 강요하지 않습니다.
아래 다이어그램에서 다른 시스템에서 제공하는 서비스에 대한 각 호출은 굵기와 스타일이 다른 선으로 표시됩니다.
상위 레벨 프로세스도 표시하지 않았습니다(App1은 App6의 이전 응답이 성공적인지 여부에 따라 App2를 호출하고 App3 또는 App5를 호출하므로 App4는 나중에 App2에서 생성된 데이터를 가져올 수 있지만 App1이 App1 등을 금지하지 않습니다.)
또한 서버에 대해 이야기하는 것이 아닙니다. 각 시스템은 10개의 물리적 서버에서 실행될 수 있으므로 최소 60개의 물리적 구성 요소가 서로 통신합니다.
그러나 몇 가지 문제가 분명해집니다.
인터페이스를 분리하는 방법? 다운로드를 예약하는 방법은 무엇입니까? 각 애플리케이션이 서로 다른 개발 팀, 공급업체 또는 부서에서 관리되고 원래 개발자의 절반이 이미 회사를 떠났을 때 업데이트 또는 예정된 다운타임을 어떻게 조정합니까?
6개의 앱을 관리할 수 있다고 생각한다면 30개는 어떻습니까?
당신은 400을 처리할 수 있습니까? 그리고 2000년부터? 각 응용 프로그램은 고유한 에코시스템이 될 수 있으며 실행하려면 12개의 서버 또는 기타 장치가 필요하므로 모든 종류의 기술 및 문화적 경계가 있는 대륙에 걸쳐 20,000개의 움직이는 부품이 있습니다. 그리고 이 모든 부분은 중단 없이 끊임없이 메시지를 교환하기를 원합니다. (스키마는 생략하겠습니다.)
이 상황에 대한 훌륭한 이름이 있습니다. 엉망입니다.
상황을 어떻게 고칠 수 있습니까?¶
첫 번째 단계는 상황이 통제 불능 상태임을 인식하는 것입니다. 이렇게 하면 강한 죄책감을 느끼지 않고 해결책을 찾을 수 있습니다. 글쎄, 당신은 그것을 더 잘하는 방법을 몰랐지만이 모든 것이 고칠 수 있는 기회가 있습니다.
이것은 우리가 IT에 접근하는 방식에 조직적 변화를 가져올 수 있지만, 또 다른 단계는 시스템과 애플리케이션이 단순히 데이터를 공유하는 것이 아니라는 점을 기억하는 것입니다. 은행, 오디오 녹음, 레이더 장치 등 비즈니스 자체에 관계없이 비즈니스 프로세스를 지원하도록 설계되었습니다.
이 두 가지 점을 명확하게 정의하면 서비스를 중심으로 시스템을 설계하거나 재설계할 수 있습니다.
서비스는 흥미롭고 재사용 가능하며 원자적이며 한 시스템에서 이를 사용하려는 다른 응용 프로그램에 제공하지만 서비스는 일대일로 직접 노출되지 않습니다. 이것은 가능한 모든 것 중에서 가장 짧고 의미 있는 설명입니다.
주어진 시스템 기능이 다음 세 가지 요구 사항을 충족하는 경우:
- 나흥미로운 (흥미로운)
- 아르 자형재사용할 수 있는(재사용 가능한)
- ㅏ tomic (원자)
그러면 시스템이 다른 시스템에 서비스로 노출될 수 있고 노출되어야 하지만 직접 연결되지 않을 가능성이 높습니다.
몇 가지 예를 들어 IRA 접근 방식에 대해 논의해 보겠습니다.
| 변하기 쉬운 | 메모 |
|---|---|
| 환경 | 전기회사 CRM 시스템 |
| 기능 | 2012년 3분기에 셀프 서비스 포털에서 활성 상태였던 고객 목록을 반환합니다. |
| 흥미로운데요? | 네, 충분히 흥미롭습니다. 이것은 모든 종류의 유용한 보고서 및 통계를 생성하는 데 사용할 수 있습니다. |
| 있을 수있다 | 아니, 별로. 이것은 당신이 만들 수 있지만 |
| 자꾸 | 전체 연도에 대한 통계와 같은 상위 수준 구성, |
| 사용? | 2018년에는 이것이 필요하지 않을 것이 분명합니다. |
| 원자인가요? | 아마 그렇습니다. 다른 분기에 이미 유사한 서비스가 있는 경우 전체 연도를 볼 수 있습니다. |
| 이것으로 IRA를 만드는 방법은 무엇입니까? |
|
| 변하기 쉬운 | 메모 |
|---|---|
| 환경 | 전자상거래 사이트 |
| 기능 | 지정된 사용자에 대해 수집된 모든 정보를 반환합니다. |
| 흥미로운데요? | 일반적으로 그렇습니다. 전체에 액세스할 수 있는 경우 항상 필요한 것을 선택할 수 있습니다. |
| 있을 수있다 | 이상하게도 실제로는 그렇지 않습니다. 소수만 있을 것이다 |
| 자꾸 | 관심이 있는 지원서(있는 경우) |
| 사용? | 모든 정보를 절대적으로 사용하십시오. |
| 원자인가요? | 절대 아니다. 이 괴물 같은 기능은 논리적으로 수십 개의 작은 부품으로 구성될 예정입니다. |
| 이것으로 IRA를 만드는 방법은 무엇입니까? |
|
| 변하기 쉬운 | 메모 |
|---|---|
| 환경 | 어디서나 모든 CRM 시스템 |
| 기능 | 누군가 계정을 만든 후 C_NAZ_AJ 테이블의 CUST_AR_ZN 열 업데이트 |
| 흥미로운데요? | 전혀 흥미롭지 않습니다. 이것은 CRM 시스템의 내부 기능입니다. 제정신이 아닌 사람은 그러한 낮은 수준의 기능을 처리하고 싶어하지 않습니다. |
| 있을 수있다 | 예, 아마도. 계정를 통해 생성할 수 있습니다. |
| 자꾸 | 여러 채널이 있으므로 여러 가지 |
| 사용? | 사용된. |
| 원자인가요? | 예인 것 같습니다. 이것은 테이블의 한 열에 대한 간단한 업데이트입니다. |
| 확인하는 방법 | |
| 이 IRA? | 그것으로 서비스를 만들려고 하지도 마십시오. 흥미롭지 않다. 아무도 한 시스템의 특정 열과 테이블에 대해 생각하고 싶어하지 않습니다. 이것은 CRM 시스템의 까다로운 부분이며 재사용 가능하고 원자적이지만 서비스를 구축할 가치가 없습니다. 그것은 당신과 CRM의 것입니다. 그것에 대해 생각하는 것은 당신의 책임입니다. 다른 사람들도 그것을 감당하도록 강요하지 마십시오. |
| 변하기 쉬운 | 메모 |
|---|---|
| 환경 | 이동통신사 |
| 기능 | 과금 시 선불통신카드 충전 |
| 흥미로운데요? | 극도로. 문자 메시지, IVR, IM, 포털, 기프트 카드등. |
| 있을 수있다 | 예. 그것은 많은 높은 수준에 참여할 수 있습니다 |
| 자꾸 | 프로세스. |
| 사용? | |
| 원자인가요? | 예, 통화 응용 프로그램의 관점에서 카드를 충전하거나 충전하지 않을 수 있습니다. 결제가 일련의 단계를 통해 이를 구현한다는 사실은 중요하지 않습니다. 비즈니스 관점에서 이것은 원자적이며 과금에 의해 제공되는 분리할 수 없는 서비스입니다. |
| 확인하는 방법 | 이미 IRA입니다. |
| 이 IRA? |
지난 50년 동안 프로그래밍을 조금이라도 해봤다면 서비스를 제공하는 것이 다른 코드를 위해 한 코드에서 API를 제공하는 것과 같다는 것이 분명해질 것입니다. 유일한 차이점은 한 시스템의 하위 모듈을 다루는 것이 아니라 개별 시스템의 전체 환경 수준에서 작업한다는 것입니다.
ESB 및 SOA의 서비스 가용성¶
이제 시스템이 직접 통신하지 않는다는 것을 알고 서비스가 무엇인지 이해했으므로 ESB를 효과적으로 사용할 수 있습니다.
이제 통합 시스템 서비스를 제공하고 호출하는 것이 ESB의 역할입니다. 따라서 대부분의 경우 하나의 액세스 방법만 각 시스템과 ESB 사이에 하나의 인터페이스를 정의해야 합니다.
따라서 위의 다이어그램과 같이 8개의 시스템이 있는 경우 생성, 유지 관리, 관리 및 프로비저닝할 수 있는 16개의 인터페이스(각 방향에 하나씩)가 있습니다.
ESB가 없으면 생성하고 관리할 56개의 인터페이스가 있습니다(각 시스템이 서로 통신한다고 가정).
추가로 40개의 인터페이스가 없기 때문에 낭비되는 시간이 줄어들고 비용이 더 많이 절약됩니다. 이것이 금요일이 스트레스를 덜 받는 이유 중 하나입니다.
이 사실만으로도 ESB 구현을 고려해야 합니다.
시스템 중 하나가 재작성되고 다른 소유자에게 이전되고 부서 또는 공급업체로 분할되면 ESB 담당자가 적절한 변경을 수행해야 합니다. ESB와의 인터페이스가 그대로 유지되기 때문에 다른 시스템 중 어느 것도 이를 알아차리지 못할 것입니다.
IRA 서비스를 정기적으로 호흡하기 시작하면 복합 서비스에 대해 생각할 수 있습니다.
위의 "이 클라이언트에 대해 할 수 있는 것은 무엇이든 제공" 서비스를 기억하십니까?
하나를 만드는 것은 좋은 생각이 아니었지만 때때로 정보를 집계해야 하는 클라이언트 응용 프로그램을 실행하게 됩니다. ESB 담당자가 이를 담당할 것이며 특정 복합 데이터 세트를 필요로 하는 특정 클라이언트 시스템에 대한 복합 서비스를 구축하기 위해 최상의 원자성 서비스를 선택하는 것이 그들의 작업이 될 것입니다.
시간이 지남에 따라 전체 조직은 더 이상 데이터베이스 테이블, 파일, 패키지, 기능, 서브루틴 또는 레코드에 관한 것이 아님을 깨닫기 시작할 것입니다. 이제 우리는 ESB 애플리케이션이 제공하는 흥미롭고 재사용 가능한 원자적 서비스를 중심으로 한 아키텍처에 대해 이야기하고 있습니다.
사람들은 더 이상 애플리케이션과 시스템이 서로에게 메시지를 보내고 있다고 생각하지 않을 것입니다. 그들은 ESB를 자신의 시스템이 사용할 수 있는 흥미로운 서비스에 대한 원스톱 게이트웨이로 볼 것입니다. 그리고 그들은 누가 무엇을 제공하는지조차 확인하지 않고 그들의 시스템은 ESB만 다룰 것입니다.
시간, 인내, 조정된 노력이 필요하지만 가능합니다.
하지만 조심하세요...¶
대부분 가장 좋은 방법 SOA의 전체 개념을 파괴합니다. ESB를 배포하고 문제가 저절로 해결될 것으로 예상합니다. 좋은 생각이지만 불행히도 ESB를 배포하는 것만으로는 충분하지 않습니다.
기껏해야 아래 다이어그램과 같이 카펫 아래에 무언가를 숨기려고 해도 아무 소용이 없습니다.
IT 담당자는 시스템을 싫어할 것이고 관리자는 처음에는 ESB를 새로운 솔루션으로 용인하지만 결국에는 웃음거리가 될 것입니다. "뭐야, 똑같은 새 은색 총알이야? 하하하.”
ESB가 더 큰 개발 계획의 일부가 아닌 경우 이러한 결과는 불가피합니다.
그렇다면 ESB는 은행 등을 위한 것입니까?¶
전혀. 그것 좋은 결정흥미로운 결과를 얻기 위해 여러 데이터 소스와 여러 액세스 방법의 조정된 작업이 필요한 모든 상황에서.
예를 들어 최신 온도 판독값을 수집하여 이메일 알림 및 iPhone 앱과 같은 여러 채널에 게시하는 작업은 통합 플랫폼에 적합합니다.
중요 애플리케이션의 모든 인스턴스의 작동을 주기적으로 확인 및 모니터링하고, 모두 실행되지 않는 경우 구성된 스크립트를 실행하고 관리자에게 문자 메시지를 보내는 것도 좋습니다.
명확하고 잘 정의된 환경에 통합되어야 하는 모든 것이 ESB 서비스에 적합합니다. 그러나 항상 그렇듯이 어떤 것이 통합에 정말 적합한지 여부는 경험에 따라 결정됩니다.
기업 서비스 버스
물론 Zato 팀이 도울 수 있습니다.
하지만 SOA는 XML, SOAP 및 웹 서비스라고 들었습니다¶
예, 어떤 사람들은 당신이 그것을 믿기를 바랍니다.
함께 작업한 사람이나 공급업체가 BASE64로 인코딩된 CSV 파일을 SAML2로 보호되는 SOAP 메시지로 보냈다면 왜 그런 인상을 받았는지 이해할 수 있습니다.
XML, SOAP 및 웹 서비스에는 사용 사례가 있지만 다른 모든 것과 마찬가지로 오용될 수 있습니다.
SOA는 이해하기 쉽고 관리하기 쉬운 아키텍처에 관한 것입니다. 서비스가 SOAP를 사용할 수 있는지 여부는 실질적으로 관련이 없습니다. 아키텍처 접근 방식으로서의 SOA는 SOAP 서비스가 전혀 사용되지 않더라도 여전히 유효합니다.
건축가가 아름다운 건물을 디자인한다면 인테리어 색상에 너무 많은 영향을 줄 수 없습니다.
따라서 SOA는 XML, SOAP 및 웹 서비스가 아닙니다. 그것들은 사용될 수 있지만 기초가 아니라 부분일 뿐입니다.
잃어버린 동료가 SOA가 무엇인지 이해할 수 있도록 이 기사를 참조할 수 있습니다.
뿐만 아니라¶
이 장은 아주 기본적인 것만 다루지만 그럼에도 불구하고 ESB와 SOA가 어떤 모습이어야 하고 성공하기 위해 필요한 것은 무엇인지에 대한 확실한 이해를 제공해야 합니다.
여기에서 다루지 않은 다른 주제는 다음과 같습니다(단, 이에 국한되지 않음).
- ESB 도입을 위해 관리자의 지원을 받는 방법
- SOA 설계자와 분석 팀을 구성하는 방법
- 조직에서 표준 데이터 모델(CDM) 표현
- 핵심 성과 지표(KPI) - 이제 시스템 간에 서비스를 제공하는 공통적이고 통합된 방법이 있으므로 실제로 제공되는 서비스를 관찰하고 분석해야 합니다.
- 비즈니스 프로세스 관리(BPM) - 서비스 관리를 위한 BPM 플랫폼을 선택하는 방법과 시기
- API가 없는 시스템은 어떻게 해야 합니까? 예를 들어, ESB가 데이터베이스에 직접 액세스해야 하는 경우(대답은 다르며 황금률은 없습니다)
자토는 무엇입니까?¶
Zato는 Python으로 작성된 ESB 및 애플리케이션 서버이며 미들웨어 및 백엔드 시스템을 구축하는 데 사용할 수 있습니다. 이 소프트웨어는 열려 있습니다 소스 코드상업 및 지역 사회 지원. 그리고 Python은 단순성과 효율성으로 유명한 프로그래밍 언어입니다.
Python과 Zato를 사용하면 생산성을 높이고 시간 낭비를 줄일 수 있습니다.
자토를 썼다 실용주의자를 위한 실용주의자. 이것은 ESB/SOA 과대 광고에 뒤이어 공급업체가 성급하게 구축한 또 다른 시스템이 아닙니다.
실제로 Zato는 이러한 시스템으로 인한 "소화"에 대한 실제 경험에서 구축되었습니다. 실제로 Zato의 저자는 그러한 환경과 싸우는 데 너무 많은 시간을 투자하여 거의 모든 화재에 면역이 되었습니다.
이것은 Zato가 세상에 나온 단조이므로 다른 유사한 솔루션에서는 볼 수 없는 성능과 사용 편의성을 제공할 수 있습니다.
에서 만나요 여기!
(Enterprise Service Bus)는 기업의 분산 정보 환경을 구축하도록 설계되었습니다. 소프트웨어하나의 센터에서 모든 통합 애플리케이션의 상호 작용을 보장하고 기존 정보 소스를 결합하고 서로 다른 사이에서 중앙 집중식 데이터 교환을 제공합니다. 정보 시스템.
엔터프라이즈 서비스 데이터 버스 DATAREON ESB정보 교환의 안정성과 완전성을 보장하고 정보 시스템의 전반적인 성능을 높이며 관리 인건비를 줄이는 효과적인 수단입니다.
엔터프라이즈 서비스 버스
소프트웨어 데이터리온 ESB전자에 대한 러시아 프로그램의 통합 등록부에 공식적으로 포함됨 컴퓨터주 및 시립 기관에서 구입할 수 있는 데이터베이스(https://reestr.minsvyaz.ru/).
소규모 회사에서 2-3개의 정보 시스템을 통합하기 위해 DATAREON은 DATAREON ESB - DATAREON MQ를 기반으로 하는 소프트웨어 제품을 제공합니다.
DATAREON ESB의 기능
기업 서비스 데이터 버스를 사용하여 해결된 작업
- 데이터 전송서로 다른 정보 시스템 간(라우팅 또는 지점 간)
- 단일 정보 공간 형성이기종 환경에서
- 이벤트 모델 기반 분산 시스템 구축다음 옵션에서:
- 이벤트 모델을 기반으로 한 종단 간 비즈니스 프로세스로 응용 프로그램 구축
- 다양한 정보 시스템에서 비즈니스 애플리케이션의 동기화를 통한 시스템 구축
- 영수증 확장 가능한 제어 아키텍처기업/지주 수준
- 전개 데이터 교환 시스템전송 계층 및 비즈니스 논리 수준에서
- 정보 흐름 구축 작업 위임분석 부서
- 통합 체계의 전반적인 복잡성 감소에 대한 요구 사항을 줄이고 대역폭채널
- 전반적인 안정성 증가데이터 전송 계층
- 거래 비용 절감다른 부서 간에 데이터를 교환할 때
- 전체 비용 절감정보 시스템의 유지 관리 및 지원.
DATAREON ESB Enterprise Service Bus의 이점
- 빠른 통합
- 높은 신뢰성
- 자원을 재사용할 수 있는 능력
)(이전에는 Axelot Datareon ESB로 알려짐)는 분산된 엔터프라이즈 정보 환경을 구축하도록 설계되었습니다. 소프트웨어 제품은 기존 정보 소스를 결합하고 서로 다른 정보 시스템 간에 중앙 집중식 데이터 교환을 제공하여 하나의 센터에서 모든 통합 응용 프로그램의 상호 작용을 보장합니다.
Datareon ESB Enterprise Data Service Bus는 정보 교환의 안정성과 완전성을 보장하고 정보 시스템의 전반적인 성능을 높이며 관리 인건비를 줄이는 수단입니다.
Datareon ESB 소프트웨어 제품은 공식적으로 주 및 시립 기관에서 구입할 수 있는 전자 컴퓨터 및 데이터베이스용 러시아 프로그램의 통합 등록부에 포함되어 있습니다.
기능
- 다양한 표준 및 통합 시나리오 지원
- Eclipse 에코시스템을 통한 통합 환경의 중앙 집중식 관리
- 데이터 변환(다양한 조건을 제어하는 다단계 데이터 변환 알고리즘)
- 모든 크기의 데이터 전송(수직 및 수평 확장)
- 1C:Enterprise 8 플랫폼 기반 제품과의 손쉬운 통합
- 안전한 데이터 전송 보장
- 전체 데이터 네트워크 상태의 진단 및 모니터링
해결해야 할 과제
- 서로 다른 정보 시스템 간의 데이터 전송(라우팅 또는 지점 간)
- 이기종 환경에서 단일 정보 공간 형성
- 다음 옵션에서 이벤트 모델을 기반으로 분산 시스템 구축:
- 이벤트 모델을 기반으로 한 종단 간 비즈니스 프로세스로 응용 프로그램 구축
- 다양한 정보 시스템에서 비즈니스 애플리케이션의 동기화를 통한 시스템 구축
- 확장 가능한 엔터프라이즈/홀딩 레벨 관리 아키텍처 확보
- 전송 수준 및 비즈니스 논리 수준에서 데이터 교환 시스템 배포
- 정보 흐름 구축 작업을 분석 부서에 위임
- 통합 체계의 전반적인 복잡성을 줄이고 채널 대역폭 요구 사항을 줄입니다.
- 데이터 전송 계층의 전반적인 안정성 향상
- 부서간 데이터 교환 시 거래 비용 절감
2017
액슬롯 데이터레온 ESB 2.1.0.0
AXELOT Datareon ESB 솔루션은 Gold Application Development Competency list에 포함되었으며 이는 제품의 높은 품질과 Microsoft 제품과의 호환성을 확인시켜 줍니다.
AXELOT Datareon ESB는 기업에 여러 가지 주요 이점을 제공합니다.
- 통합 가능성;
- 리소스의 신뢰성 및 재사용성
- 확장 가능한 엔터프라이즈/홀딩 레벨 관리 아키텍처 확보
- 정보 흐름 구축 작업을 분석 부서에 위임합니다.
- 통합 체계의 전반적인 복잡성을 줄이고 채널 대역폭에 대한 요구 사항을 줄입니다.
- 데이터 전송의 전송 계층의 전반적인 안정성을 높입니다.
- 부서 간 데이터 교환 시 거래 비용 절감
- 정보 시스템을 유지 관리하는 전체 비용을 줄입니다.
시스템의 주요 기능:
- 많은 수의 커넥터 다양한 시스템: 1С:Enterprise 8, SOAP 서비스, REST 서비스, MS SQL, IBM DB2, Oracle DB, PostgreSQL, SharePoint, OData, TCP, Siemens TeamCenter 및 기타
- 커넥터의 독립적인 개발을 위한 플러그인 메커니즘;
- 상호 작용 시나리오 개발 시 다양한 프로그래밍 언어 및 기술 지원: 1C:Enterprise 8, JavaScript, T-SQL;
- 시각적 매핑 메커니즘 및 임의의 XSLT 변환을 사용하여 다단계 데이터 변환 시나리오 설정
- 작업 다양한 형식데이터(XML, JSON, XLS, DBF, CSV, Base64 등);
- 정보 패킷의 정적 및 동적 라우팅
- 고속 상호 작용 및 내결함성: 네트워크 대역폭, 로드 밸런싱, 정보 도메인 격리에 대한 요구 사항 감소, 통합 노드 상태 모니터링 기능
- 이벤트 모델 지원, 동기 및 비동기 호출, 배달 보장;
- 중단할 필요 없이 "핫" 모드에서 가입자 시스템(언로딩/로딩, 변환 및 라우팅을 위한 메커니즘)의 통합 시나리오 변경(1C:Enterprise 8 플랫폼의 구성 포함)
- 모든 통합 프로세스의 진단 및 모니터링, 정보 패키지 디버깅 및 추적.
1C:Enterprise 8 플랫폼에서 애플리케이션 통합에 특히 주의를 기울입니다. 1C:Enterprise 8 플랫폼의 모든 표준 구성에 내장된 특수 하위 시스템이 포함되어 있으며 빠르고 편리한 통합 설정 및 관리에 필요한 모든 메커니즘을 제공합니다. AXELOT: ESB Service Data Bus는 SOAP 및 REST 서비스를 통해 1C:Enterprise 8 플랫폼의 구성과 상호 작용합니다.
서버 구성 요소 "AXELOT: ESB Service Data Bus"는 C++로 개발되었습니다. "AXELOT: ESB Service Data Bus"의 관리 및 구성은 Eclipse 개발 환경에서 수행되며 "1C: Enterprise Development Tools"의 "1C: Enterprise 8" 플랫폼에서 시스템 개발과 함께 수행할 수 있습니다. "AXELOT: ESB Service Data Bus"는 다중 플랫폼이며 다음을 지원합니다. 운영체제 MS 윈도우와 리눅스.
AXELOT Datareon ESB는 완전히 러시아 개발이며 전자 컴퓨터 및 데이터베이스용 러시아 프로그램의 통합 등록부에 포함되는 과정에 있으며, 특정 문제를 해결하기 위해 주 및 시 기관에서 구입할 수 있습니다.
제 생각에는 엔터프라이즈 통합 버스를 구축하는 데에는 두 가지 접근 방식이 있습니다.
- "통합 가능한 시스템에서";
- "구현된 프로세스에서".
"통합 가능한 시스템에서" 접근
이 경우 통합 버스는 메시징 프로토콜의 라우팅 및 협상을 수행하는 일종의 전송으로 간주됩니다. 모든 메시지는 소스 시스템 어댑터의 입력 채널 -> 라우터 -> 수신기 시스템의 출력 채널 체인을 통과합니다. 이러한 구성 요소와 특정 기술 간의 통신 유형은 하나의 소스 시스템에서 오는 메시지가 여러 대상 시스템을 가질 수 있는지 여부, 데이터 무결성을 보장하기 위한 예상 로드 및 접근 방식(모든 소스 시스템에 대해 공통 트랜잭션 사용 또는 데이터가 트랜잭션의 각 소스 시스템).- 메시지 유형이 아닌 시스템에 대한 종속성. 일반적으로 통합 시스템의 수는 전송되는 메시지 유형의 수보다 몇 배 적습니다.
- 새로운 수신기 시스템의 연결 용이성: 새로운 수신기 시스템을 연결하려면 라우팅 테이블에 데이터를 입력하는 것으로 충분합니다.
- 통합 솔루션의 모니터링 시스템 구현 용이성: 모니터링 시스템용 데이터는 라우터에서 한 곳에서 생성 가능(단, 이 지점은 어댑터에서만 생성되는 데이터가 있기 때문에 예약을 통해서만 허용 가능 통합 시스템).
- 지원 솔루션의 용이성. 모든 메시지가 단일 라우터를 통과하기 때문에 메시지 전달의 모든 논리와 메시지 간의 종속성 추적은 이 라우터에서 한 곳에서 구현될 수 있습니다.
- 개발자 간의 시스템 공유. 시스템 코어와 모든 어댑터는 서로 독립적이므로(통신은 전용 및 설명된 인터페이스를 통해서만 제공됨) 개발 작업을 프로그래머 간에 분할할 수 있으므로 통합 솔루션을 만들고 구현하는 프로세스를 병렬화할 수 있습니다.
- 이 솔루션은 통합 메시지 전달 논리의 구현에만 적용할 수 있습니다. 모든 또는 대부분의 메시지에 공통적인 종속성 및 변환을 추적하기 위한 규칙이 있는 경우. 만약에 다른 유형메시지는 완전히 다른 종속성 추적 및 교환 관리 논리를 갖기 때문에 어댑터로 이동해야 하므로 이점 4가 제거되거나 구현이 전혀 불가능합니다.
- 이 체계는 비동기 교환을 구현하는 데 적합합니다. 동기 또는 혼합 교환의 경우 구현의 복잡성 이 접근법크게 증가합니다.
- 솔루션 성능 저하가 발생할 수 있습니다. 예를 들어 메시지가 별도의 트랜잭션으로 각 수신자 시스템에 전송되어야 하는 경우 큐에 의한 소스 시스템, 커널 및 수신자 시스템의 분리가 필요합니다. 이러한 대기열은 시스템의 병목 현상이 될 수 있습니다.
"구현된 프로세스에서" 접근
이 경우 각 비즈니스 프로세스는 별도로 고려되며 여러 시스템 간의 데이터 교환이 필요합니다. 버스 도구 이 교환. 교환 프로세스를 시작하는 이벤트는 소스 시스템에서 메시지를 수신하는 것입니다. 소스 시스템에서 수신된 메시지는 하나 또는 여러 수신자 시스템으로 전송되며 전송 기능이 구현될 뿐만 아니라 메시지 처리 결과도 모니터링되고 전송된 메시지는 다른 것과 상관됩니다.이 접근 방식에는 다음과 같은 이점이 있습니다.
- 유연성. 이 접근 방식을 사용하면 각 메시지 유형에 대해 고유한 별도의 교환 논리를 구현할 수 있습니다. 이 논리는 사소하지 않을 수 있습니다.
- 비동기 및 동기 교환 구현의 복잡성은 거의 동일합니다.
- 스레드의 독립성, 더 정확하게는 이 경우 프로세스에 대해 이야기하는 것이 더 정확합니다. 한 교환 프로세스를 구현하는 동안 내린 기술적 결정은 다른 교환 프로세스의 복잡성에 영향을 미치지 않습니다.
이 접근 방식에는 다음과 같은 단점이 있습니다.
- 메시지 유형에 대한 종속성. 일반적으로 메시지 유형의 수는 통합 시스템의 수보다 몇 배 더 많습니다. 새로운 소스 시스템을 버스에 연결할 때 유형별로 메시지를 라우팅하고 메시지 유형별로 별도의 교환 프로세스를 구현해야 합니다.
- 여러 유형의 메시지에 대해 동일한 교환 논리를 구현해야 하는 경우 코드 및/또는 버스 설정의 복제가 가능합니다.
- 메시지 전달 프로세스는 시스템 어댑터에 따라 달라지며 서로는 물론 서비스 프로세스에도 종속될 수 있습니다. 이러한 종속성의 존재는 통합 솔루션을 개발하고 구현하는 프로세스의 병렬화 정도를 감소시킵니다. 일부 구성 요소의 개발자는 통합 솔루션의 다른 구성 요소 개발자의 작업 결과에 따라 다릅니다.
접근 방식의 선택은 다음 알고리즘에 따라 수행됩니다.
- 분석가로부터 통합 시스템 및 메시지 유형의 목록과 설명을 얻습니다.
- 통합이 필요한 시스템과 관련된 비즈니스 프로세스의 목록과 설명을 분석가로부터 얻습니다.
- 프로세스가 간단하고 메시지 유형보다 훨씬 적은 시스템이 있고 교환이 주로 비동기식이며 하나의 메시지를 여러 시스템으로 전송해야 하는 경우 첫 번째 접근 방식을 선택합니다. 거래 관리 정책을 결정합니다.
- 프로세스가 주로 동기식 교환을 의미하지만 프로세스가 복잡한 경우, 즉 메시지의 통과는 수신자 시스템에서의 처리 결과에 따라 달라지며 두 번째 접근 방식을 선택합니다. 이 접근 방식을 지지하는 또 다른 주장은 메시지 유형의 수가 통합 시스템의 수와 비슷하다는 사실입니다.
이러한 구현 방법은 도그마가 아니며 첫 번째 접근 방식만 선택하거나 두 번째 접근 방식만 선택할 필요가 없다는 점을 분명히 이해해야 합니다. 항상 결합할 수 있는 최신 엔터프라이즈 서비스 타이어( ESB) 그렇게 할 수 있습니다.
게시물을 좋아했습니다 -
이 글을 통해 이 제품의 개발 맥락에서 IBM WebSphere ESB(이하 ESB라고 함) 전용 주기를 열고자 합니다. 그리고 우선, 이러한 종류의 기술에 익숙해져야 합니다.
엔터프라이즈 서비스 버스(Enterprise Service Bus)는 서비스 지향 아키텍처의 원칙을 기반으로 다양한 정보 시스템 간에 중앙 집중식 및 통합 이벤트 지향 메시징을 제공하는 미들웨어입니다.
물론 특별한 소프트웨어 없이(어쩌면 여전히 일반적인 것이 개발되어야 할 수도 있음) 이 접근 방식을 기반으로 기업 시스템을 구축하는 것은 가능하며 결과적으로 발생하는 일은 서비스 버스라고 할 수 있습니다. 그러나 IBM의 제품에는 중앙 집중식 메시징 및 이 프로세스 제어를 위한 기성 장치뿐만 아니라 풀세트특히 ESB를 위한 유연한 서비스 지향 애플리케이션을 개발할 수 있는 기회. 요약하면 IBM WebSphere ESB의 다음 기능과 이점을 강조할 수 있습니다.
- 건축적 관계의 질서와 획일성
- 중앙 집중식 관리
- 서버 측 애플리케이션 구성
- 서비스 지향 아키텍처 원칙의 정신에 서비스 구성 요소 아키텍처(SCA) 기술 구현
- 개발된 프로그램 코드의 프로토콜 독립성
- 광범위한 버스 및 애플리케이션 구성 옵션
클래식 ESB 어셈블리 토폴로지는 수평 확장성과 내결함성을 제공하는 클러스터입니다. 공식 권장 사항에 따르면 클러스터 구성원 수를 늘리면 독립 실행형 토폴로지에서 서버 용량을 늘리는 것보다 성능이 더 효율적으로 향상됩니다. 또한 서비스를 중지하지 않고 클러스터를 재부팅(또는 일부가 실패할 수 있음)할 수 있습니다.
ESB는 일반적으로 IBM BPM에서 서비스 계층으로 사용되지만 상호 작용 모델을 구축하는 데 주도적인 역할을 할 수 있습니다. 기업 시스템강력한 통합 장치(IBM WebSphere Application Server에 대한 애드온으로서의 ESB를 의미).
이것은 실제로 "서비스 수집 지점"이기 때문에 ESB에서 필요합니다. 다른 서비스(아마도 외부)와 함께 작동하는 서비스가 필요한 경우 이러한 서비스 간의 통합은 ESB에서 가장 논리적으로 수행됩니다. . 외부 또는 이기종 서비스의 경우 "래퍼"를 ESB 서비스로 만들 수 있습니다. 서비스에 "단일 주택"을 사용하는 편리함을 조금 설명하겠습니다.
주문하다
시스템이 클수록 더 중요한 질서와 획일성이 있습니다. 우리가 대기업의 복잡한 시스템에 대해 이야기하고 있다면 확실히 대규모 시스템이라고 할 수 있습니다. 물론 머리 속에 수백 대의 서버 상호 작용에 대한 다이어그램이나 각각에 대한 관련 없는 많은 문서가 있는 관리자를 항상 찾을 수 있습니다. 소프트웨어 모듈, 무엇과 상호 작용하는지 설명합니다. 
그러나 모든 상호 작용을 자체적으로 수행할 수 있는 서비스(ESB)를 갖는 것이 훨씬 쉽습니다. 이 접근 방식을 사용하면 모든 하위 시스템에서 상호 작용 아키텍처의 일부가 이미 명확해집니다. 시스템, 서버 및 애플리케이션 간의 통신에 혼란이 없습니다. 모든 것이 ESB에 연결되고 ESB가 모든 것에 연결됩니다. 
중앙 집중식 관리
구성, 서버 재배치에 대한 적응, 내결함성, 로드 밸런싱, 오류 처리 또는 모니터링 및 분석 등 시스템을 중앙에서 구성하는 것이 항상 더 편리합니다. 
예를 들어, 데이터베이스 서버를 이동할 때 기존의 모든 애플리케이션 서버의 구성, 특히 특정 애플리케이션의 설정으로 들어갈 필요가 없습니다. ESB에 데이터베이스를 지정하는 하나의 환경 변수만 있으면 충분합니다. 주소를 입력한 다음 한 지점에서 변경해야 합니다.
또는 외부 시스템 중 하나를 오랫동안 사용할 수 없었고 이에 대한 단일 요청이 손실되어서는 안 되는 경우, 편리한 시간에 배달되지 않은 메시지를 "투입"하기 위해 실패한 이벤트 처리 서비스를 사용할 수 있습니다.
시스템에 대한 동시 요청 수를 조절하거나 이러한 요청을 모니터링해야 하는 경우 부하를 분석하고 병목 현상을 찾아 ESB 서버 콘솔로 이동해야 합니다(메시징 제어 센터로 이동해야 함).
서버 측 구성
구성 측면에서 서비스를 위한 "단일 주택"을 사용하면 몇 가지 유용한 목표를 달성할 수 있습니다. 첫 번째는 구성 재사용(SOA에서 매우 유용한 코드 및 모듈 재사용과 유사)입니다. 다른 모듈애플리케이션은 동일한 데이터베이스 연결 매개변수, 자원, 인증 매개변수, 환경 변수 등을 사용할 수 있습니다. 
둘째, 서버 측에서 구성할 때 크게 영향을 줄 수 있는 것은 응용 프로그램 환경입니다. 이를 통해 응용 프로그램을 변경하지 않고도 서로 다른 회로(테스트 및 프로덕션) 간에 응용 프로그램을 전송하고 조정하고 버그를 수정할 수 있습니다.
이러한 모든 이점을 사용하면 응용 프로그램은 진정한 카멜레온의 기능을 갖게 됩니다. 응용 프로그램은 매우 유연하여 작업 환경의 일부가 되는 동시에 중요한 기능을 제공합니다.
그러나 IBM WebSphere ESB에서 애플리케이션의 유연성은 애플리케이션이 실행되는 환경에 국한되지 않습니다. 개발 능력이 이에 크게 기여합니다. 시스템에는 실행할 장소가 있어야 할 뿐만 아니라 개발 및 완료되어야 하므로 다음과 같은 흥미로운 점을 놓쳐서는 안 됩니다.
SCA
이 아키텍처는 구성 요소가 다른 구성 요소에서 사용할 수 있는 서비스로 기능을 노출한다는 원칙을 기반으로 합니다. 하나의 모듈 내에서 구성 요소는 해당 인터페이스에서 설명하는 일부 기능을 완전히 구현하는 프로그램 블록(자바 코드)입니다. 구성 요소의 실행 논리는 인터페이스 및 참조(파트너 참조)를 통해 구성 요소를 구조에 연결하여 구현됩니다.
이러한 모듈 구조를 개발, 확인, 개발, 변경 및 유지하는 것은 매우 편리합니다. 구성 요소에 구현된 기능의 원자성은 코드 수준으로 내려가지 않고 구성 요소 전체에서 작업할 수 있도록 합니다. 반면에 트랜잭션 컨텍스트에서 구성 요소 구현을 실행하기 때문에 논리적으로 필요합니다.
각 구성 요소에는 구현을 제공하는 인터페이스가 있습니다. 따라서 구성 요소를 함께 연결하면 구성 요소를 알 필요가 없습니다. 내부 기능– 필요한 인터페이스를 구현하는 것으로 충분합니다.
이 아키텍처를 통해 "수동" 흐름 제어 없이 병렬 작업이 필요한 모든 작업을 해결할 수도 있습니다(예: 지연된 응답으로 여러 구성 요소에 대한 비동기식 호출 가능).
내보내기 및 가져오기 유형과 같은 비 Java 구성 요소를 사용하면 다음을 위한 서비스를 제공할 수 있습니다. 외부 사용또는 그에 따라 외부 서비스를 사용합니다. 중재 흐름 구성 요소는 다른 구성 요소 간에 교환되는 메시지에 대한 낮은 수준의 액세스를 제공하고 이기종 인터페이스로 작업할 때 다양한 변환을 허용합니다.
인터페이스 외에도 IBM 비즈니스 오브젝트 프레임워크는 매우 유용한 기능을 제공합니다. xsd 스키마로 표시되는 BO(비즈니스 개체)는 구성 요소 간 및 모듈 간 통신 모두에서 인터페이스의 데이터 전송을 위한 개체로 사용됩니다. 예를 들어 웹 서비스를 설명하기 위해 wsdl 스키마에 직접 통합됩니다. 즉, 예를 들어 모듈 "A"가 웹 서비스로서의 기능을 제공하는 경우 이를 사용하려면 모듈 "B"가 인터페이스와 기성품 BO를 연결하는 것으로 충분하며 완전히 작동할 수 있습니다. 데이터 전송을 위한 추가 java 객체를 생성하지 않고 이러한 서비스를 제공합니다. BO는 또한 이 데이터가 다른 구성 요소에서 사용되는 경우 데이터베이스와 데이터를 교환할 때 사용하는 것이 편리합니다(이는 물론 DAO 패턴에 위배되지만 불필요한 Java 개체 및 데이터 재작성 작업을 앞뒤로 제거합니다).
프로그램 코드의 프로토콜 독립성
보시다시피, 코드의 프로토콜 독립성은 내보내기 및 가져오기 구성 요소를 사용하여 달성됩니다. 이러한 구성 요소와의 통신은 인터페이스 및 참조를 통해 이루어지기 때문에 프로그래밍 코드상호 작용에 사용되는 프로토콜과 완전히 독립적입니다. 동일한 기능을 지원되는 모든 프로토콜에서 쉽게 사용할 수 있습니다. 올바른 인터페이스. 다음 그림은 이미 인터페이스를 HTTP, JMS 및 웹 서비스로 노출하는 빈에 SCA 바인딩을 사용하여 내보내기를 추가하는 방법을 보여줍니다. 
이점은 분명합니다. 유연성, 다용성, 코드 재사용, 개발 및 수정 속도입니다.
그건 그렇고, SCA 바인딩은 특수 프로토콜을 사용하며 동일한 서버/클러스터 내의 모듈 간의 통신을 위한 것입니다. 이 바인딩을 통한 통신은 다른 프로토콜보다 리소스 집약적이며 빠릅니다.
구성
서버 및 애플리케이션 구성은 서버의 IBM 콘솔을 통해 수행됩니다.
일반적으로 IBM WebSphere와 마찬가지로 ESB에는 몇 가지 특정 기능과 아티팩트가 있습니다. 예를 들어 동일한 가져오기 및 내보내기를 사용할 때 해당 서비스의 끝점을 즉석에서 구성할 수 있습니다. 서비스 호출의 경우 다양한 규칙으로 정책 세트를 구성할 수 있습니다(예: 클라이언트가 작동하는 동일한 트랜잭션에서 웹 서비스를 호출할 수 있도록 하는 WS-AT 메커니즘에 대한 지원을 설치할 수 있지만 트랜잭션성은 이미 전체 기사 주제), 인증 매개변수 설정, 인증서 연결 등.
구성을 통해 예외적인 상황에 대한 자동 응답 메커니즘(예: 오류 발생 시 구성 요소 실행 자동 반복)을 설정할 수 있습니다. 구성 요소 추적을 즉시 설정하거나 로깅 수준을 변경할 수 있습니다. 대량 오류 처리를 위해 의도적으로 사용할 수 있는 오류 이벤트 관리 서비스도 사용할 수 있습니다.
그리고 물론 IBM Application Server에서 때로는 매우 엄격하게 구현되는 Java2EE 사양에 따라 다른 많은 것들을 구성할 수 있습니다.
위의 모든 사항은 ESB가 항상 배우기 쉽지는 않지만 편리하고 강력하며 유연한 통합 장치임을 확인시켜줍니다. 앞으로는 사용법만 배우면 됩니다.
기사에는 다음 이미지가 사용되었습니다.
저는 개인적으로 10년 동안 SOA에 대해 잘 알고 있었고 이 기간 동안 명확한 연관 체인을 개발했습니다. SOA의 기본은 데이터 버스입니다. 데이터 버스 이후로 통합 프로젝트에 대해 이야기하고 있습니다.
나는 역사를 휘젓지 않을 것입니다. 우리 모두는 그 시대에 통합이 어떻게 발전했는지 기억합니다. 즉, 포인트-투-포인트 개념에서 통합 계층의 전용 데이터 모델이 있는 버스로 가는 길고 고통스러운 경로입니다. 오늘 우리는 이미 Neoflex Integra 통합 제품에 대해 이야기하고 있습니다. 러시아 시장아직 은행 자동화가 없기 때문에 분석의 초기 단계를 크게 줄일 수 있음과 동시에 향후 통합 프로젝트의 결과를 즉시 평가할 수 있습니다.
Neoflex Integra는 450번째 이후, 또는 은행에서 수행된 455번째 통합 프로젝트 이후에도 나타났습니다. 정확히 지적하기 어렵습니다. 그러나 직원들이 통합 실습에 투입한 공수를 계산해 보니 약 137년이 되었습니다. 통합은 항상 Neoflex 작업의 주요 영역 중 하나였으므로 이러한 수치에 놀라지 마십시오. 이 기간 동안 우리는 두 가지를 이해할 수 있었습니다. 첫째, 대출 기관의 풍경은 분류할 수 있습니다. 둘째, 적어도 분석 단계에서는 통합 프로젝트 간에 공통점이 많습니다. 우리는 금융 조직의 활동 영역에서 원자 서비스를 비즈니스 프로세스에 결합하여 응용 프로그램 개체와 이들 간의 관계를 포함하는 일반적인 표준 모델의 형태로 기초를 선별했습니다. 환상적으로 보이지만 이제 우리는 기성품 "세부 사항" 세트를 가지고 은행에 와서 미래 통합 모델을 형성하는 데 사용할 수 있습니다. 네오플렉스 인테그라는 리테일 파이낸스 3월호에서 발표한 신제품입니다. 그러나 오늘날 우리는 이미 통합 프로젝트 기간을 약 1/4로 줄일 수 있다고 말할 수 있습니다. 또한 은행은 더 이상 이전과 같이 "포켓에 돼지"를 사지 않으며 매우 많은 비용을 지불합니다. 확실한 결과. 그러나 SOA로 돌아가서 통합 제품에 대한 주제에 관심이 있는 분들을 위해 11월 20일에 열리는 "New Neoflex Integra 제품: 프로젝트 경험의 정수" 웨비나에 여러분을 초대합니다.
따라서 다음에는 어떤 일이 벌어질지, SOA는 어떻게 발전할 것이며, 데이터 버스는 계속 유지될 것이며, 현재 신용 환경에서와 같은 영광의 자리를 차지할 것입니까? 신용기관? 나는 멀리서, 일반적으로 SOA에 대해, 은행 산업에서 이 개념의 운명에 대해 시작할 것입니다. 실제로 은행에 적합한 IT 아키텍처는 비즈니스 요구 사항을 충족할 수 있는 아키텍처입니다. 은행이 클수록 요청이 많아집니다. 러시아에는 여러 지점이 있고 지리적으로 분산된 구조로 인해 충분한 규모의 은행이 있지만, 그 은행들조차 고품질 SOA 환경을 항상 감당할 수는 없으며 비용이 많이 들 뿐만 아니라 위험도가 크기 때문입니다. SOA 프로젝트가 항상 좋게 끝나는 것은 아닙니다. 우리 제품을 통해 위험을 줄이는 동시에 SOA 진입의 문턱을 줄일 계획입니다.
SOA 환경이 파이프 비즈니스라고 생각하지 마십시오. Neoflex 프로젝트는 통합할 수 없는 시스템이 없음을 보여줍니다. 은행은 보통 자신에게 가장 중요한 영역부터 시작하여 조금씩 새로운 지형을 만들기 시작하지만 최근에는 이전에 볼 수 없었던 규모를 접하게 되었습니다. 그것은 VTB24 은행의 프로젝트에서 일어났습니다. 회사는 Oracle SOA Suite를 기반으로 하는 Universal Banking Services Layer를 만들기 위해 그곳에서 일했습니다. 이 솔루션에는 은행이 모든 통신 채널을 통해 모든 고객과 작업할 수 있도록 하는 600개 이상의 서비스가 포함되어 있습니다. Oracle의 동료에 따르면 이러한 크고 복잡한 결정은 러시아에서 기억하지 못할 것입니다. 그리고 그것이 성공한다면 다른 프로젝트는 순전히 기술적으로 실현 가능합니다.
단일 논리적 계층을 형성하고 IT 공간을 최적화해야 하는 필요성은 많은 소매 프로젝트를 실행하는 은행에서 가장 많이 경험합니다. 여기서 고객 서비스의 속도는 매우 중요하며 SOA 실행에 사용되는 기술은 더 빠른 데이터 흐름으로 인해 속도를 크게 높일 수 있습니다. 따라서 VTB24, Probusinessbank( 라이프 그룹), 우리도 함께 작업하고 있으며 얼마 전에 장기 SOA 전환 프로그램을 채택했습니다. 소규모 조직이 그들의 모범을 따를지 여부는 말하기 어렵습니다. 위기는 결국입니다. 그러나 순전히 실용적인 고려 사항은 다음과 같습니다. SOA가 필요한 사람과 간단한 해결책으로 버틸 수 있는 사람 사이에 조건부 경계를 긋고자 한다면, 이 경계는 시장 침체가 시작되기 전에 대략 상위 400개 은행을 통과했습니다.
은행 자동화의 다른 영역에서는 이미 만들어진 기능의 사용을 극대화하는 개념 또는 제품 개념이 시스템이 구성 요소화 된 후 성공적으로 뿌리를 내렸습니다. SOA도 예외가 되어서는 안 된다고 생각합니다. 그러나 이것은 미래의 문제입니다. 그 동안 많은 은행이 완전히 다른 현실에 살고 있으며 그들의 의제는 어떤 통합 제품을 사용할 것이 아니라 어떤 버스를 구현할 것인가입니다. 하늘에서 땅으로 내려갑시다.
IBM WebSphere ESB로 무엇을 해야 합니까?
의심할 여지 없이 IBM WebSphere ESB는 프로젝트 수와 구현 수 면에서 통합 버스 시장의 선두 주자입니다. 10개의 통합 프로젝트 중 8개가 IBM WebSphere ESB에서 수행됩니다. 그리고 불과 2년 만에 상황이 조금씩 바뀌기 시작했고, 다른 주요 글로벌 벤더들의 움직임이 시장에 나타나기 시작했다. 나는이 기사의 틀 내에서 비교하고 싶지 않습니다. 왜냐하면 그것 없이는이 주제에 대한 충분한 수의 비교 및 분석 연구가 있기 때문입니다. 내 기사는 한때 SOA를 향한 발걸음을 내디뎠고 IBM WebSphere ESB와 함께 한 사람들을 대상으로 합니다. 그리고 그들은 진지하게 고민해야 했습니다. 갑자기 작년에 IBM이 2014년부터 통합 소프트웨어의 제품군을 변경했으며 IBM Web Sphere ESB가 더 이상 개발되지 않을 것이라는 작년 소식과 이에 대한 지원이 눈에 눈이 내리는 것처럼 단지는 최근에야 2018년 4월까지 연장되었습니다. 기존에는 2014년 완공 예정이었다.
이와 관련하여 이 통합 플랫폼을 사용하는 점점 더 많은 고객이 자신을 기다리고 있는 것에 대해 질문하기 시작했습니다.
기적은 일어나지 않으며 나는 마술사가 아니지만 두 가지 방법을 제안하고 싶습니다.
1. IBM이 미래에 내기를 걸고 있는 또 다른 플랫폼인 Integration Bus(이전 Message Broker) 사용에 대해 생각하십시오.
IBM WebSphere ESB에 비해 성능과 안정성이라는 명백한 이점이 있습니다. 이 플랫폼에는 충분한 프로젝트와 구현이 있으며 처음부터 누군가가 이를 통합 버스로 선택했습니다.
주요 기술 기능은 메시지 전달을 보장하고 결과적으로 안정성을 제공하는 전송으로 메시지 큐(MQ)를 내부적으로 사용한다는 것입니다.
2. 이미 IBM WebSphere ESB에서 통합 솔루션을 개발할 때 구현 수준을 분리하여 새 코드 IBM WebSphere ESB가 아니라 통합 솔루션에서 사용하는 다른 구성 요소가 추가 진화 전략에 해당합니다. IBM의 적합한 제품은 많지 않고 2-3개뿐입니다. 내 생각에 그 중 가장 유망한 것은 고성능 및 인증된 보안을 제공하는 통합 작업을 해결하기 위한 하드웨어 및 소프트웨어 시스템인 IBM WebSphere Data Power입니다. 이 제품의 장점은 동급 최고의 성능과 외부 및 내부의 광범위한 보안 작업을 해결할 수 있는 능력입니다.
현재까지 Renaissance Credit Bank에서 완료된 IBM Data Power의 파일럿 프로젝트 중 하나에서 인상적인 결과를 얻었습니다. 초당 40개의 요청이 5,000개의 동시 연결로 처리되고 1개의 요청에 대한 처리 시간이 1ms 미만입니다. 테스트 중 CPU 로드가 5% 수준이라는 점은 주목할 가치가 있습니다!
IBM Data Power를 사용하면 IBM WebSphere ESB와 IBM DataPower 간의 통합 솔루션 계층을 분리하는 데 도움이 되므로 IBM WebSphere ESB를 새 통합 버스(예: IBM Integration Bus)로 교체할 때 해당 부분을 다시 실행할 필요가 없습니다. IBM 데이터파워.
이 하이브리드 버스 접근 방식은 다른 공급업체의 제품을 기반으로 구현할 수도 있습니다. IBM 뿐만이 아니다. 많은 벤더의 제품 개발이 같은 방향으로 진행되는 경우가 많기 때문에 이는 별도의 논의 주제입니다.
가까운 미래에 통합 데이터 버스는 어떤 모습이어야 합니까?
여기서 저는 제가 설명한 제안이 미래에 일어날 타이어 아이디어와 매우 잘 일치한다는 사실을 알려드리고 싶습니다. "하이브리드" 버스의 개념을 도입하고 기술을 결합하여 다양한 통합 문제에 대한 솔루션을 달성하고 있습니다. 게다가, 우리는 소프트웨어를 결합하고 소프트웨어 및 하드웨어 시스템의 도움으로 "순수한" 소프트웨어를 희석하는 것에 대해 이야기하고 있습니다.
오늘날에는 하나의 제품으로 비즈니스의 모든 요구 사항을 충족하기가 매우 어렵습니다. 따라서 오래되고 검증된 "동종 최고의" 원칙이 통합 타이어에 완벽하게 적용됩니다.
여러 제품을 가져와 하나의 공통 작업으로 결합하고 구성 요소를 분리하고 공통 통합 데이터 모델에 "심기"하면 다기능 솔루션을 얻을 수 있을 뿐만 아니라 "제품 중독"으로부터 자신을 보호할 수 있습니다.
그래서 우리는 두 가지를 찾았습니다. 간단한 솔루션, 각각 고유한 장점이 있습니다.
· IBM Integration Bus와 결합된 IBM WebSphere ESB는 SOA 플랫폼을 구축하고 복잡한 애플리케이션과 IT 환경을 통합하는 데 사용됩니다.
고성능 IBM 제품간편한 구성이 특징인 DataPower는 간단한 요청을 처리하고 다기능 보안을 제공하는 데 사용됩니다.
의심할 여지 없이 하이브리드 버스는 클라우드에 데이터 버스가 없는 한 미래가 될 것입니다. 지금은 불가능해 보이더라도 말입니다. 우리는 1~2년 후에 이 문제로 돌아올 것입니다. 동의하십니까?
BPM 시스템 블록은 여기에서 의도적으로 고려되지 않았습니다. 이것은 별도의 광범위한 주제입니다.