엔터프라이즈 애플리케이션 통합

엔터프라이즈 애플리케이션 통합(EAI)은 소프트웨어 및 컴퓨터 시스템의 아키텍처 원칙을 사용하여 엔터프라이즈 컴퓨터 애플리케이션 ^{[citation needed]}세트를 통합하는 것입니다.

개요

엔터프라이즈 애플리케이션 통합은 미들웨어 또는 엔터프라이즈 ^[1]전체에서 시스템과 애플리케이션을 통합할 수 있는 "미들웨어 프레임워크"를 구성하는 기술과 서비스의 집합으로 구성된 통합 프레임워크입니다.

공급망 관리 애플리케이션, ERP 시스템, 고객 관리용 CRM 애플리케이션, 비즈니스 인텔리전스 애플리케이션, 급여 및 인사 시스템 등 많은 유형의 비즈니스 소프트웨어는 일반적으로 데이터 또는 비즈니스 규칙을 공유하기 위해 서로 통신할 수 없습니다.이러한 이유로 이러한 애플리케이션을 자동화 또는 정보 사일로라고 부르기도 합니다.이러한 통신 부족으로 인해 동일한 데이터가 여러 위치에 저장되거나 간단한 프로세스를 ^{[citation needed]}자동화할 수 없는 비효율성이 발생합니다.

엔터프라이즈 애플리케이션 통합은 비즈니스 프로세스를 최대한 단순화 및 자동화하면서 동시에 기존 애플리케이션 또는 데이터 구조를 전면적으로 변경할 필요가 없도록 하기 위해 이러한 애플리케이션을 단일 조직 내에서 연결하는 프로세스입니다.애플리케이션은 API를 통해 백엔드로 링크하거나 프론트엔드(GUI)^{[citation needed]}를 통해 (셀덤) 링크할 수 있습니다.

조사기관 Gartner의 말에 따르면, [EAI는 기업 내 연결된 애플리케이션 또는 데이터 소스 간에 데이터와 비즈니스 프로세스를 제한 없이 공유하는 것입니다."^[2]

서로 연결해야 하는 다양한 시스템은 서로 다른 운영 체제에 상주하거나, 서로 다른 데이터베이스 솔루션 또는 컴퓨터 언어를 사용하거나, 날짜 및 시간 형식을 사용하거나, 시스템을 처음 만든 공급업체가 더 이상 지원하지 않는 레거시 시스템일 수 있습니다.어떤 경우에는 이러한 시스템을 "스토브파이프 시스템"이라고 부르기도 합니다.왜냐하면 이러한 시스템은 어떤 ^{[citation needed]}방식으로든 수정하기가 매우 어려운 방식으로 서로 맞물린 구성 요소로 구성되기 때문입니다.

접속성 향상

구조화된 EAI 접근방식을 따르지 않고 통합을 적용하면 조직 전체에서 포인트 투 포인트 접속이 확대됩니다.종속성은 즉석에서 추가되기 때문에 유지보수가 어려운 복잡한 구조가 됩니다.이것은 보통 스파게티라고 불리며 스파게티 코드와 동등한 프로그래밍을 암시합니다.예를 ^{[citation needed]}들어 다음과 같습니다.

완전 메쉬 포인트 투 포인트 접속에 $필요$ 한 접속의 수는 ( ${\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}$ 2) ${\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}$ ( ${\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}$ ${\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}$ 1) ${\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}$ 2 ({ $displaystyle {tbinom {n}{2$ }} $= displaytfrac {n(n-1)}{2}}$ ${\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}$ (이항 계수 참조)로 표시됩니다.따라서 10개의 애플리케이션을 포인트 투 포인트로 완전히 통합하려면 ${\tfrac {10\times 9}{2}}=45$ × ${\tfrac {10\times 9}{2}}=45$ ${\tfrac {10\times 9}{2}}=45$ $=$ ${\tfrac {10\times 9}{2}}=45$ ${\displaystyle {10\times$ 9 $}{2$ }= $45}$ 개의 포인트 ${\tfrac {10\times 9}{2}}=45$ 투 포인트 연결이 필요합니다.

그러나 조직 내 연결 수는 포인트 수의 제곱에 따라 증가하지 않습니다.일반적으로 모든 포인트에 대한 연결 수는 조직의 다른 포인트 수와 무관합니다(생각 실험: 조직에 추가 포인트가 있는 경우 해당 포인트를 알고 있습니까?관련 없는 다른 포인트의 접속 수가 증가합니까?)이것이 적용되지 않는 소수의 "수집" 포인트가 있지만, 이러한 포인트는 EAI 패턴을 관리할 필요가 없습니다.

또한 EAI는 시스템 간의 결합을 증가시켜 관리 오버헤드와 ^{[citation needed]}비용을 증가시킬 수 있습니다.

EAI는 애플리케이션 간 데이터 공유뿐만 아니라 비즈니스 데이터와 비즈니스 프로세스 공유에도 중점을 둡니다.EAI에 참여하는 미들웨어 분석가는 종종 ^{[citation needed]}시스템의 시스템을 조사합니다.

목적들

EAI는 다양한 ^{[citation needed]}용도로 사용할 수 있습니다.

데이터 통합:여러 시스템의 정보가 일관되게 유지되도록 합니다.이것은, 엔터프라이즈 정보 통합(EII)이라고도 불립니다.
벤더의 독립성: 어플리케이션에서 비즈니스 정책 또는 규칙을 추출하여 EAI 시스템에 구현합니다.그러면 비즈니스 어플리케이션 중 하나가 다른 벤더의 어플리케이션으로 대체되어도 비즈니스 규칙을 다시 구현할 필요가 없습니다.
공통 표면:EAI 시스템은 애플리케이션의 클러스터를 프런트 엔드로 하여 이러한 애플리케이션에 대한 일관된 단일 액세스 인터페이스를 제공하고 사용자가 다른 소프트웨어 패키지 사용법을 배울 필요가 없도록 보호합니다.

패턴

이 항에서는 통합, 액세스 및 라이프 타임패턴 등 EAI를 구현하기 위한 일반적인 설계 패턴에 대해 설명합니다.이것들은 추상적인 패턴이며 다양한 방법으로 구현될 수 있습니다.업계에서 일반적으로 사용되는 다른 패턴은 고급 추상 설계 패턴부터 매우 구체적인 구현 ^[3]패턴까지 다양합니다.

통합 패턴

EAI 시스템은 다음 두 ^[4]가지 패턴을 구현합니다.

중개(통신내): 여기서 EAI 시스템은 여러 애플리케이션 간의 중개자 또는 브로커 역할을 합니다.응용 프로그램에서 관심 이벤트가 발생할 때마다(예를 들어 새로운 정보가 생성되거나 새로운 트랜잭션이 완료됨), EAI 시스템의 통합 모듈에 알립니다.다음으로 모듈은 관련된 다른 응용 프로그램에 변경을 전파합니다.
페더레이션(인터커뮤니케이션): 이 경우, EAI 시스템은, 복수의 애플리케이션에 걸치는 중요한 외관으로서 기능합니다.외부로부터 애플리케이션으로의 이벤트 콜은, 모두 EAI 시스템에 의해서 프런트 엔드로 행해집니다.EAI 시스템은 기본 애플리케이션의 관련 정보 및 인터페이스만 외부에 공개하도록 구성되어 있으며 요청자를 대신하여 기본 애플리케이션과 모든 대화를 수행합니다.

두 가지 패턴이 동시에 사용되는 경우가 많습니다.같은 EAI 시스템에서는, 복수의 애플리케이션의 동기(중개)를 유지하면서, 이러한 애플리케이션(페더레이션)^{[citation needed]}에 대한 외부 유저의 요구에 대응할 수 있습니다.

액세스 패턴

EAI는 비동기(fire and forget)와 동기 액세스패턴을 모두 서포트하고 있습니다.이 패턴은 미디에이션 케이스에서 일반적인 패턴이며 페더레이션 ^{[citation needed]}케이스에서는 후자입니다.

라이프 타임 패턴

통합 운영은 단수명(예: 두 애플리케이션에 걸쳐 데이터를 동기화하는 작업을 1초 이내에 완료할 수 있음) 또는 장기수명(예: 한 단계에는 완료에 ^{[citation needed]}몇 시간 또는 며칠이 걸리는 대출 승인을 위해 인간 워크플로우 애플리케이션과 상호작용하는 EAI 시스템이 포함될 수 있음)일 수 있다.

토폴로지

크게 허브 앤 스포크와 버스의 2가지 토폴로지가 있습니다.각각 장단점이 있다.허브 앤 스포크 모델에서는 EAI 시스템이 중심(허브)에 있으며 스포크를 통해 애플리케이션과 대화합니다.버스 모델에서 EAI 시스템은 버스입니다(또는 이미 존재하는 메시지버스 또는 메시지 지향 ^{[citation needed]}미들웨어에서 상주 모듈로 구현됩니다).

대부분의 대기업은 존 네트워크를 사용하여 네트워크 지향 위협에 대한 계층형 방어 기능을 구축합니다.예를 들어 기업에는 일반적으로 신용카드 처리(PCI 준거) 존, 비PCI 존, 데이터 존, 외부 사용자 접근을 프록시하는 DMZ 존 및 내부 사용자 접근을 프록시하는 IWZ 존이 있습니다.애플리케이션은 여러 영역에 걸쳐 통합되어야 합니다.이 ^{[citation needed]}경우 허브 앤 스포크 모델이 더 잘 작동합니다.

테크놀로지

EAI 시스템의 ^{[citation needed]}각 컴포넌트 구현에는 다음과 같은 여러 기술이 사용됩니다.

버스/허브: 이는 보통 표준 미들웨어 제품(애플리케이션 서버, 메시지 버스)을 강화하거나 독립 실행형 프로그램(즉, 미들웨어를 사용하지 않음)으로 구현하여 자체 미들웨어로 작동합니다.
응용 프로그램 연결: 버스/허브는 어댑터 세트(커넥터라고도 함)를 통해 애플리케이션에 연결됩니다.이러한 프로그램은 기본 비즈니스 애플리케이션과 상호 작용하는 방법을 알고 있습니다.어댑터는 단방향 통신(단방향)을 실행하여 애플리케이션에 대한 허브로부터의 요구를 실행하고 응용 프로그램에 대한 관심 이벤트(새로운 레코드 삽입, 트랜잭션 완료 등) 발생 시 허브에 알립니다.어댑터는 특정 애플리케이션(예를 들어 애플리케이션 벤더의 클라이언트 라이브러리에 대해 구축됨) 또는 특정 애플리케이션 클래스(예를 들어 SOAP, SMTP 또는 액션 메시지 형식(AMF) 등의 표준 통신 프로토콜을 통해 모든 애플리케이션과 상호 작용할 수 있습니다.어댑터는 버스/허브와 같은 프로세스 공간에 상주하거나 원격 위치에서 실행하거나 메시지 큐, 웹 서비스 또는 독점 프로토콜과 같은 업계 표준 프로토콜을 통해 허브/버스와 상호 작용할 수 있습니다.Java 세계에서는 JCA 등의 표준으로 벤더 중립적인 방법으로 어댑터를 작성할 수 있습니다.
데이터 형식 및 변환: 모든 어댑터가 다른 모든 응용 프로그램의 포맷으로 데이터를 변환하지 않도록 하기 위해 EAI 시스템은 일반적으로 응용 프로그램에 의존하지 않는(또는 공통) 데이터 포맷을 규정합니다.EAI 시스템은 일반적으로 데이터 변환 서비스를 제공하여 애플리케이션별 형식과 일반 형식 간의 변환을 지원합니다.이것은 2단계로 이루어집니다.어댑터는 애플리케이션 포맷의 정보를 버스의 공통 포맷으로 변환합니다.그런 다음 여기에 의미 변환이 적용됩니다(우편 번호를 도시 이름으로 변환, 한 응용 프로그램의 개체를 다른 응용 프로그램의 개체로 분할/머지하는 등).
통합 모듈: EAI 시스템은 임의의 시간에 여러 통합 작업에 참여할 수 있으며, 각 통합 유형은 다른 통합 모듈에 의해 처리됩니다.통합 모듈은 특정 유형의 이벤트와 이러한 이벤트가 발생했을 때 수신되는 프로세스 알림을 서브스크라이브합니다.이러한 모듈은 다양한 방법으로 구현될 수 있습니다. Java 기반 EAI 시스템에서는 웹 애플리케이션, EJB 또는 심지어 EAI 시스템의 사양을 준수하는 POJO일 수 있습니다.
트랜잭션 지원: 프로세스 통합에 사용할 경우 EAI 시스템은 단일 분산 트랜잭션(2단계 커밋 프로토콜 또는 보상 트랜잭션 사용)에서 모든 애플리케이션에 걸쳐 모든 통합 작업을 실행함으로써 애플리케이션 간의 트랜잭션 일관성을 제공합니다.

커뮤니케이션 아키텍처

현재 엔터프라이즈 애플리케이션 통합에 가장 적합한 인프라스트럭처, 컴포넌트 모델 및 표준 구조를 구성하는 것은 무엇인지에 대해 여러 가지 생각이 있습니다.현대적 엔터프라이즈 애플리케이션 ^{[citation needed]}통합 아키텍처에 필수적인 4가지 구성요소는 다음과 같습니다.

보안, 액세스 및 통신을 처리하는 중앙 집중식 브로커입니다.이는 통합 서버(SIF(School Interoperability Framework) 존 통합 서버 등) 또는 서비스 매니저로서 기능하는 엔터프라이즈서비스 버스(ESB) 모델과 같은 소프트웨어를 통해 실행할 수 있습니다.
표준 데이터 구조를 기반으로 하는 독립 데이터 모델. 표준 데이터 모델이라고도 합니다.XML과 XML 스타일시트의 사용은 이 통일된 비즈니스 언어의 사실상의 표준이 되고 있는 것 같습니다.
각 벤더, 애플리케이션 또는 인터페이스가 해당 애플리케이션과 네이티브하게 대화하고 중앙 집중형 브로커와 통신할 수 있는 단일 구성 요소를 구축할 수 있는 커넥터 또는 에이전트 모델입니다.
컴포넌트가 표준화된 방법으로 접속할 수 있도록 시스템에 대한 API, 데이터 흐름 및 계약 규칙을 정의하는 시스템 모델입니다.

데이터베이스 또는 사용자 인터페이스 수준에서 연결하는 등의 다른 접근법이 검토되었지만 확장하거나 조정할 수 있는 방법은 발견되지 않았습니다.개별 응용 프로그램은 중앙 집중식 브로커에 메시지를 게시하고 해당 브로커로부터 특정 메시지를 수신하도록 구독할 수 있습니다.각 응용 프로그램은 브로커에 대한 연결을 하나만 필요로 합니다.이 중앙 제어 접근법은 매우 확장 가능하고 ^{[citation needed]}진화가 가능합니다.

엔터프라이즈 애플리케이션 통합은 메시지 지향 미들웨어(MOM)와 같은 미들웨어 기술과 XML 또는 JSON과 같은 데이터 표현 기술과 관련이 있습니다.다른 EAI 테크놀로지에서는 통합 수단으로 서비스 지향 아키텍처의 일부로 웹 서비스를 사용하는 것이 포함됩니다.엔터프라이즈 애플리케이션 통합은 데이터 중심적인 경향이 있습니다.가까운 장래에, 컨텐츠의 통합과 비즈니스 ^{[citation needed]}프로세스가 포함될 것입니다.

구현의 함정

2003년에는 모든 EAI 프로젝트의 70%가 실패했다고 보고되었습니다.이러한 장애의 대부분은 소프트웨어 자체나 기술적인 문제가 아니라 관리상의 문제로 인해 발생합니다.통합 컨소시엄 유럽 회장 Steve Craggs는 EAI 시스템을 사용하는 기업이 직면한 7가지 주요 함정에 대해 설명하고 이러한 ^[5]문제에 대한 해결책을 설명합니다.

지속적인 변화:EAI의 본질은 동적이기 때문에, 동적인 프로젝트 매니저가 실장을 관리할 필요가 있습니다.
EAI 전문가 부족: EAI는 많은 문제와 기술적 측면에 대한 지식이 필요합니다.
경쟁 규격:EAI 분야에서는 EAI 표준 자체가 보편적이지 않다는 것이 역설이다.
EAI는 도구 패러다임입니다. EAI는 도구가 아니라 시스템이기 때문에 구현해야 합니다.
인터페이스 구축은 기술입니다.솔루션을 엔지니어링하는 것만으로는 불충분합니다.최종 결과에 대해 공통의 합의에 이르려면 사용자 부문과 솔루션을 협상해야 합니다.인터페이스 설계에 대한 합의가 부족하면 다양한 시스템의 데이터 요건을 매핑하기 위한 과도한 노력이 발생합니다.
상세 손실:초기 단계에서는 중요하지 않아 보였던 정보가 나중에 중요해질 수 있습니다.
설명 책임:많은 부서가 상충되는 요건을 가지고 있기 때문에 시스템의 최종 구조에 대한 명확한 설명 책임이 있을 것입니다.

다음 ^{[citation needed]}영역에서 기타 잠재적인 문제가 발생할 수 있습니다.

EAI 작업의 ^[6]중앙 집중식 조정의 결여.
새로운 요건: EAI의 실장은 장래의 변경에 대비해 확장성이 높고 모듈러형이어야 합니다.
보호주의:데이터를 통합하고 있는 애플리케이션은 기술, 문화, 정치적인 이유로 다른 부서와 데이터를 공유하고 싶지 않은 경우가 많습니다.

「」를 참조해 주세요.

이니셔티브 및 조직

레퍼런스

^ Linthicum, David S. (2000). Enterprise Application Integration. Addison-Wesley Professional. ISBN 978-0-201-61583-8.
^ AIIM International의 2001년 4월 보고서에서는 "엔터프라이즈 애플리케이션:E-Business and Document Technologies 채택, 2000-2001: Worldwide Industry Study(세계 산업 연구)에 따르면 EAI는 "엔터프라이즈에서 연결된 애플리케이션 및 데이터 소스 간에 데이터와 비즈니스 프로세스를 제한 없이 공유하는 것"이라고 정의되어 있습니다.
Gable, Julie (March–April 2002). "Enterprise application integration" (PDF). Information Management Journal. Retrieved 2008-01-22.
^ Hohpe, Gregor; Woolf, Bobby (2015). "Messaging Patterns Overview". Enterpriseintergationpatterns.com and Addison-Wesley. Retrieved 2016-05-19.
^ MSquare 시스템(2014-05-21)"EAI 유형"2014년 5월 21일 https://web.archive.org/web/20140521124430/http://www.msquaresystems.com/enterprise-application-2/eai에 보관됩니다.2014년 5월 28일에 http://www.msquaresystems.com/enterprise-application-2/eai에서 MSquare 시스템을 검색했습니다.
^ Trotta, Gian (2003-12-15). "Dancing Around EAI 'Bear Traps'". Retrieved 2006-06-27.
^ Toivanen, Antti (2013-10-25). "Avoiding Pitfalls of Integration Competency Centers". Archived from the original on 2017-07-30. Retrieved 2013-10-26.

[1] Linthicum, David S. (2000). Enterprise Application Integration. Addison-Wesley Professional. ISBN 978-0-201-61583-8.

[2] AIIM International의 2001년 4월 보고서에서는 "엔터프라이즈 애플리케이션:E-Business and Document Technologies 채택, 2000-2001: Worldwide Industry Study(세계 산업 연구)에 따르면 EAI는 "엔터프라이즈에서 연결된 애플리케이션 및 데이터 소스 간에 데이터와 비즈니스 프로세스를 제한 없이 공유하는 것"이라고 정의되어 있습니다.
Gable, Julie (March–April 2002). "Enterprise application integration" (PDF). Information Management Journal. Retrieved 2008-01-22.

[Enterprise_Integration_Patterns-3] Hohpe, Gregor; Woolf, Bobby (2015). "Messaging Patterns Overview". Enterpriseintergationpatterns.com and Addison-Wesley. Retrieved 2016-05-19.

[4] MSquare 시스템(2014-05-21)"EAI 유형"2014년 5월 21일 https://web.archive.org/web/20140521124430/http://www.msquaresystems.com/enterprise-application-2/eai에 보관됩니다.2014년 5월 28일에 http://www.msquaresystems.com/enterprise-application-2/eai에서 MSquare 시스템을 검색했습니다.

[5] Trotta, Gian (2003-12-15). "Dancing Around EAI 'Bear Traps'". Retrieved 2006-06-27.

[6] Toivanen, Antti (2013-10-25). "Avoiding Pitfalls of Integration Competency Centers". Archived from the original on 2017-07-30. Retrieved 2013-10-26.

[1]

[2]

[3]

[4]

[5]

[6]

Search

엔터프라이즈 애플리케이션 통합

네임스페이스

더

목차

개요

접속성 향상

목적들

패턴

통합 패턴

액세스 패턴

라이프 타임 패턴

토폴로지

테크놀로지

커뮤니케이션 아키텍처

구현의 함정

「」를 참조해 주세요.

이니셔티브 및 조직

레퍼런스

Search

엔터프라이즈 애플리케이션 통합

개요

접속성 향상

목적들

패턴

통합 패턴

액세스 패턴

라이프 타임 패턴

토폴로지

테크놀로지

커뮤니케이션 아키텍처

구현의 함정

「 」를 참조해 주세요.

이니셔티브 및 조직

레퍼런스

「」를 참조해 주세요.