기업 응용프로그램 통합

위키백과 ― 우리 모두의 백과사전.

아래의 내용은 한국어로 번역되지 않은 내용이 담겨 있습니다. 일주일 내 번역되지 않으면 삭제될 수 있습니다. This article needs translation into Korean. If the article is not rewritten in Korean within a week it will be listed for deletion.

아래의 내용은 외국어가 번역되지 않고 그대로 옮겨진 내용이 숨겨져 있습니다.

이 문서는 편집 지침에 맞춰 다듬어야 합니다. 이 문서를 정리해 주세요.

기업 응용프로그램 통합 또는 기업 애플리케이션 통합은 Enterprise Application Integration (EAI)의 번역 용어로, 기업용 응용프로그램의 구조적 통합 방법을 말한다.

목차 1 개관 2 구조 개선(Improving connectivity) 3 목적(Purposes of EAI) 4 EAI 패턴(EAI patterns) 4.1 통합 형태(Integration patterns) 4.2 접근 형태(Access patterns) 4.3 수명 형태(Lifetime patterns) 5 EAI의 의미(EAI topologies) 6 기술요소(Technologies) 7 연결 구조(Communication architectures) 8 EAI 구현의 함정(EAI implementation pitfalls) 9 장/단점(Advantages and Disadvantages) 10 미래의 EAI(The Future of EAI) 11 External links 12 References

[편집] 개관

공급망 관리(Supply chain management, SCM, 재고와 선적(수송) 관리 목적) 응용프로그램과, 고객 관계 관리(customer relationship management, CRM, 현재의 고객과 잠재고객 관리 목적) 응용프로그램, 경영 정보학(business intelligence, BI) 업무로 부터 발생하는 데이터를 통해 일정 양상(pattern)을 찾아 내기 위한 응용프로그램, 인적 자원(en:human resources), 의료 관리, 조직내 모든 의사소통, 기타 여러가지의 데이터를 관리 하기 위한 응용프로그램들은 일반적으로 서로의 정보 공유나, 업무의 이해를 돕기 위한 의견 교환을 할 수 없다. 이런 이유로, 위의 응용프로그램들은 이따금 en:islands of automation 또는 en:information silo로 불린다. 이런 상호교류의 부족은 동일한 정보(Data)를 여러 곳에 저장하거나, 간단한 업무를 자동화하지 못하는 것과 같은 비효율을 야기 한다.

EAI(Enterprise application integration, 기업 응용프로그램 통합)는 단일 조직 내부에서의 업무 프로세스를 최대한 단순화및 자동화 하기 위한 응용프로그램들의 연결을 의미 한다. 게다가 이미 존재하는 응용프로그램과 데이터구조에 대한 전면적인 수정 작업을 하지 않도록 도와 준다.

가트너(Gartner Group)의 인용에 따르면, "EAI 는 기업환경에서 연결되어 있는 어떠한 응용프로그램과 어떠한 원천 데이터 간에도 이뤄지는 구속 없는 공유"라고 정의 한다. ^[1]

EAI가 가지는 큰 의미는 서로다른 다양한 시스템간의 연결에 있다. 다른 운영체제(operating system)를 운영 중일 경우 그리고 다른 데이터베이스(database, DBMS)와 프로그래밍 언어(programming language)를 사용 중 이거나, 더 이상의 고객지원을 받을 수 없는 기존의 레거시 시스템(legacy system)간의 통합이 그것이다. 이런 경우, 시스템은 수정하기 힘들정도록 강하게 뭉쳐 있기 때문에, en:stovepipe system(강 종속시스템)이라 불린다.

[편집] 구조 개선(Improving connectivity)

만약, 조직화된 EAI구조 없이 시스템통합을 진행하게 된다면, point-to-point connections(연결)은 교차 형태로 이뤄지게 된다. 즉흥적인 원칙으로 인한 종속성과, 관리하기 어려워져버린 뒤죽박죽 결과물이 증가하게 된다. 이런 현상을 스파케티의 형상에서 차용하여, 스파게티 코드(spaghetti code)라 한다.

예를 들어:

n개의 커넥션은 에서와 같이 지점간에 완전히 맞물려야 한다. 따라서, 10개의 응용프로그램은 완전한 통합을 위해 개의 지점간 연결이 필요하게 된다.

그러나, EAI는 응용프로그램간 데이터에 대한 공유만을 의미하지 않고, 서로간의 비지니스 데이터와 프로세스의 공유에 초첨이 맞춰져 있다. EAI의 적용은 둘 이상의 학문 분야에 걸치는 복합적인 큰 문제와 이질성(en:heterogeneous), networks에 내포된 다양한 계층의 분산 시스템(distributed systems)등을 내포하고 있는 en:system of systems과 대한 주시가 요구된다.

[편집] 목적(Purposes of EAI)

EAI 는 다음의 목적들로 사용 되어 질 수 있다.

• 정보의 통합.
  • EAI는 일관성 있는 여러 시스템들의 정보를 보증하며, 이미 알려져 있는 기업 정보 통합(EII, Enterprise Information Integration)를 의미 한다.

• 프로세스 통합.
  • 응용프로그램간 비지니스 프로세스를 연결 한다.

• Vendor에 대해 독립.
  • 응용프로그램으로 부터 업무의 정책과 규칙을 추출하고, EAI 시스템에 구현하여 비지니스 응용프로그램 중 하나가 다른 vendor에 의해 수정된다고 해도, 비지니스의 규칙(rule)은 다시 만들어질 필요가 없다.

• 일반적 견해.
  • EAI 시스템은 응용프로그램 단위의 전위 처리 시스템 될 수 있다.
  • 일관성이 유지된 접점(access interface)의 제공 한다.
  • 다른 소프트웨어 패키지를 새로 익혀야하는 번거로움으로부터 벗어나게 해 준다.

[편집] EAI 패턴(EAI patterns)

[편집] 통합 형태(Integration patterns)

EAI 시스템을 구현하기 위한 두 가지 유형.

Mediation(중개)

EAI 시스템은 여러 응용프로그램 사이에서 중개자 또는 브로커의 역할을 수행한다. 응용프로그램에서 어떠한 상황이 발생하게 되면, EAI 시스템의 통합 모듈에게 통보된다. 해당 모듈은 다른 관련된 응용프로그램들에게 전파하게 된다.

Federation(연합)

이런경우, EAI 시스템은 모든 응용프로그램들의 최상위에 위치하게 된다. 모든 외부로부터의 접속은 EAI를 통해 이뤄지게 된다. EAI 시스템은 외부로 적절한 정보와 인터페이스를 제공하기 위해 구성되어 지고, 요청자의 위한 응용프로그램과 서로 작업을 수행하게 된다.

두 가지 유형은 때로는 동시에 일어나기도 한다. 같은 EAI 시스템은 다중 중계 시스템으로 유지 될 수 있고, 게다가 외부 사용자의 요청에 대해 연합으로 서비스를 제공할 수 있다.

[편집] 접근 형태(Access patterns)

EAI 는 동기와 비동기 접근을 모두 지원하며, 전자는 전형적인 중개의 경우이고, 후자는 연합을 경우를 의미 한다.

[편집] 수명 형태(Lifetime patterns)

통합된 수행(operation)은 짧은 수명(예를 들어, 동기방식으로 연결된 두 가지의 응용프로그램은 완벽한 보완책이 될 수 있다. )을 가지거나 또는 지속적 수명(예를 들어, 하나의 절차 단계는, 사람이 하는 대출 기간에 대한 승인 업무 흐름과 상호 연관되는 EAI시스템을 포함할 수 있다. )을 가질 수 있다.

[편집] EAI의 의미(EAI topologies)

다음과 같은 두 가지의 중요한 의미적 위치를 가지고 각 hub-and-spoke(터미널 집중) 방식과 bus 방식이 그것 이다. 각각은 장점과 단점이 있고, hub-and-spoke model은 중앙에 EAI 시스템이 존재하고(HUB구조), 연관된 응용프로그램들은 연결대를 통해 상호 교류 한다. the bus model은 EAI 시스템이 bus가 된다. 또는 이미 구현되어 있는 메시지 버스에 내재되어 운영된다. 또는 메시지 지향 미들웨어(message-oriented middleware)라고 한다.

[편집] 기술요소(Technologies)

여러 기술들이 EAI 시스템의 구성요소들을 구현하기 위해 사용되고, 각 아래와 같다.

Bus/hub

Bus/hub는 보통 진보적인 표준 미들웨어(application server, message bus)에 의해 구현된다. 또는 미들웨어는 아니지만, 미들웨어처럼 동작을 하는 단일 프로그램에 의해 구현된다.

Application connectivity

bus/hub 는 adapters(또는 connectors라고 불린다.)의 셋을 통해 연결되고, adapters는 어떻게 비지니스 어플리케이션과 연동되어야 하는지 알고 있다. adapters는 두 가지의 방법으로 연결되어 지고, 응용프로그램으로부터 들어오는 요청을 이행한다. 그리고 새로운 정보가 추가 되거나, 단위 작업이 완료되는 등의 상황이 감지되었을 때, hub에게 알려준다. Adapters는 vendor의 client-library를 이용하여 만들어지는 등, 명시적으로 응용프로그램이 될 수 있다. 또는 응용프로그램의 class 가 될 수 있다. 표준 프로토콜인 SOAP 이나 SMTP를 이용하여 어떠한 응용프로그램과도 상호연동할 수 있는 class 가 그 예 이다. adapter는 같은 프로세스 영역 bus/hub로 위치할 수 있고, 또는 원격에서 실행하고 산업표준 메시지 큐나 웹서비스 또는 독점적인 프로토콜을 사용해서라도 hub/bus와 서로 영향을 미칠 수 있다. Java에서 JCA와같은 표준은 adapter가 venor 에 중립적으로 생성될 수 있도록 해준다.

Data format and transformation

모든 adapter와 응용프로그램간에 별도의 데이터 변환을 하지 않기 위해, 일반적으로 EAI시스템은 응용프로그램의 공통적으로 사용할 수 있는 데이터 포멧(형)을 요구한다. 일반적으로 EAI시스템은 응용프로그램의 고유의 데이터 포멧에서 공통의 데이터 포멧으로 변환시켜 주는 서비스를 제공한다. 여기에는 두 가지의 단계가 있는데, 첫 번째로 adapter는 응용프로그램의 데이터 포멧을 bus의 공통적인 포멧으로 변환하고, 그 후 우편번호를 도시의 이름으로 변환하는 것과 같은 의미에 맞는 변환이 적용된다.( 또는 하나의 응용프로그램의 객체를 다른 응용프로그램의 객체로 분열 또는 병합하는 것을 의미 한다.)

Integration modules

EAI 시스템은 언제라도 다중 병렬처리 시스템에 참여 되어 질수 있고, 병렬처리 시스템의 통합 유형에 따라 다른 통합모듈이 처리된다. 통합모듈은 지정된 일련의 event에 대해 구독을 하고, 이런 event가 발생하여 전단되는 통지(notification)를 이행/처리하게 된다. 이런 모듈은 다음의 여러 방법으로 구현이 가능하다. 그 첫 번째로 Java에 기반한 EAI 시스템이 있다. 이런 시스템은 EAI 시스템 정의에 따라 웹 애플리케이션(web application), EJB 또는 POJO가 될 수 있다.

Support for transactions

통합된 프로세스를 사용하려 할 때, 관련한 모든 통합연산의 실행에 의해 EAI시스템은 업무처리에서의 일관성을 제공한다. 통합연산은 en:two-phase commit또는 en:compensating transaction를 이용하는 최상위의 단일 분산트랜잭션이 가지는 모든 응용프로그램과 연관되어 있다.

[편집] 연결 구조(Communication architectures)

일반적으로, 기업용 응용프로그램 통합을 위해 가장 좋은 기반구조(infrastructure), component model, 표준화 구조(standards structure)에 대한 다양한 의견들이 존재하고 있다. 최근의 기업용 응용프로그램의 통합구조를 위한 필수 컴포넌트는 아래의 네 가지와 같다.

1. 보안, 접근, communication을 관장하는 중앙 집중 형 broker의 운영. broker는 서버의 통합으로 또는 SOAP-기반의 서비스 관리기능을 하는 엔터프라이즈 서비스 버스(Enterprise service bus, ESB)와 유사한 통합관리 서버를 통해 완성된다.
2. 표준 데이터구조에 기반한 비 종속적 테이터 모델. 이 모델은 De facto(사실적이고) De jure(적법한) 표준인 XML과 XML style sheets 으로 표현 된다.
3. connector 또는 vendor의 agent model, 응용프로그램 또는 외부 접점(interface) 은 하나의 컴포넌트로 생성 만들어 질 수 있고, 그것은 중앙 집중 형 브로커와 통신 할 수 는 전통적 응용프로그램이라 할 수 있다.
4. API와 데이터 흐름, 위의 컴포넌트와 연동 대한 규칙을 정의 하는 system model은 표준화에 따라 생성된다.비록 database나 user-interface과의 연결과 같은 접근방법이 이미 개발되어 져지만, 그것들은 규격을 찾기 어렵고, 새로운 작업을 통해 수정되어져야 한다. 개개의 응용프로그램들은 중앙의 broker에게 메시지를 전달하고, broker로부터 전달되는 메시지를 받기 위해 대기 한다. 이 때 각 응용프로그램과 broker는 단일 커넥션을 유지 한다. 이런 중앙관리형 접근 방법은 높은 발전 가능성과 일관성을 가지고 있다.

기업용 응용프로그램의 통합은 메시지 지향 미들웨어(Message Oriented Middleware, MOM)나 데이터에 대한 표현 기술인 XML과 같은 미들웨어(middleware) 기술과 관련이 있다. 다른 EAI 기술요소들은은 통합적 의미에서 서비스 지향 아키텍처(service-oriented architecture)의 일부분인 웹 서비스(web services)와 관련이 있다. 기업용 통합응용프로그램 환경은 데이터 중심으로 변화하고 있다. 가까운 미래에 content integration(데이터 통합)과 en:business processes(BP)도 모두 포함될 것 으로 예상한다.

[편집] EAI 구현의 함정(EAI implementation pitfalls)

2003년에 진행된 프로젝트 중 70%는 실패 하였다. 이런 실패의 대부분은 소프트웨어 자체의 결함이거나 어려운 기술로 인한 것은 아니었다. 대 부부은 관리적인 면에서의 실패로 인한 문제 였다. 유럽통합회의 의장 Steve Craggs는 EAI시스템을 사용함에 기업에서 인식해야 할 7가지 주요 위험요소와 문제를 해결할 방법을 제시 하고 있다.

Constant change

EAI의 특징은 동적인 아주 역동적이고, EAI를 적용하기 위해 그에 상응하는 관리자를 요한다.

Lack of EAI experts

EAI는 기술 기반의 다른 많은 지식들을 필요로 한다.

Competing standards

여전히 전세계적으로 EAI 의 표준이 정해지지 않았다.

EAI is a tool paradigm

EAI는 도구가 아니며, 오히려 구현되어질 시스템 이다.

Building interfaces is an art

공학적 해결 방법은 충분치 못 하기 때문에, 해결 방안으로 최종 결과를 도출 하기 위한 협의가 필요하다. 디자인에대한 협의의 부족으로 다양한 시스템 데이터 요구사항을 상세히 그려내기 위한 많은 노력이 필요로 하게 됐다.

Loss of detail

초기에 중대하지 않게 취급되던 정보는 후에 대단한 중대한 요소로 대두 될 것인다.

Accountability

많은 지식활동 분야에서 다량의 대립된 요구사항을 소유하고 있기 때문에, 시스템의 최종구조에 대한 의무가 해결되어 질 것이다.

다른 암시적 문제들은 다음과 같은 부분에서 대두 될 것이다:

Emerging Requirements

EAI의 확장성있고, 규격화된 단위 모듈화로 인해 미래가 바뀔 것이다.

Protectionism

기술과 문화, 그리고 다른 단체와 정보를 공유하지 않기를 원하는 정치적인 문제를 안고 있는 조직간에도 데이와 응용프로그램은 통합하게 될 것이다.

이 문단은 기계 번역되었다는 의심을 받고 있습니다. 한국어 어법에 알맞게 다듬어 주시기 바랍니다.

---

[편집] 장/단점(Advantages and Disadvantages)

• Advantages(장점)
  • 여러 시스템중 실시간 정보 조회 제공.
  • 능률적인 비지니스 프로세스와 도움으로 조직의 효율이 증가하게 된다.
  • 여러 시스템간 정보의 통합을 이루게 된다.
  • 개발과 유지보수가 쉬워진다.
• Disadvantages(단점)
  • 작은규모의 비지니스(small and mid-sized businesses_SMBs)에선 필요이상의 개발 비용이 발생할 수 있다.
  • EAI는 시간 소모가 많고 많은 자원을 필요로 한다.
  • 많은 관리자들이 설계하려 하지 않고, 투자하려고 하지도 않는 디자인 작업을 미리 해야 하고, 대부분의 EAI프로젝트는 일반적으로 지점 간의 움직임(운동)으로 시작 하고 아는 곧 관리되지 않는 다수의 응용프로그램이 증가를 낳게 된다.

[편집] 미래의 EAI(The Future of EAI)

EAI 기술은 여전히 개선되고 있고, 여전히 접근 방법이나, 기업에서 참고 할 수 있는 적절한 기술 단체도 없다. 다른 단체의 기술을 이용 또는, 확장하여 사용하고자 하나, vendor lock-in(벤더 독점)적으로 개발 되었다.

[편집] External links

• Integration Consortium

[편집] References

1. ↑ 2001년 4월, report for AIIM International, "Enterprise Applications: Adoption of E-Business and Document Technologies, 2000-2001: Worldwide Industry Study," Gartner defines EAI as "the unrestricted sharing of data and business processes among any connected applications and data sources in the enterprise."
   Gable, Julie (March/April 2002). Enterprise application integration. Information Management Journal. 2008년 1월 22일에 확인.