검수요청.png검수요청.png

EAI

위키원
Asadal (토론 | 기여)님의 2021년 8월 7일 (토) 02:36 판
이동: 둘러보기, 검색

EAI(이에이아이)는 Enterprise Application Integration의 약자로서, 전사적 응용 프로그램 통합이라고 한다. 기업, 기관, 단체 등에서 사용하는 모든 응용 프로그램을 상호 연계하여 통합하는 것을 말한다. 여러 응용 프로그램을 1:1로 직접 연결하는 포인트투포인트(Point-to-Point) 방식과 중간에 단일 접점인 허브를 두고 1:N 구조로 연결하는 허브앤스포크(Hub and Spoke) 방식이 있다.

EAI

개요

EAI는 기업 내 컴퓨터와 연관된 모든(서로 다른 응용 소프트웨어 네트워크 프로토콜,운영체계와 상관없이) 애플리케이션을 유기적으로 연동하여 필요한 정보를 중앙 집중적으로 통합, 관리, 사용할 수 있는 환경을 구현하는 것이다. e-비즈니스를 위한 기본 인프라, 기본의 점 대 점 인터페이스(Point-to-Point Interface)에서는 애플리케이션 수의 실질적 한계와 유지보수의 어려움 및 애플리케이션 추가 시 방대한 비용 및 시간 손실이 있었으나 EAI를 도입한 인터페이스에서는 새로운 애플리케이션 도입 시 어댑터(Adapter)만 필요한 손쉬운 확장성이 보장된다. EAI는 전사적자원관리(ERP), 고객 관계관리(CRM), 공급망계획(SCP) 시스템, 인트라넷, 각종 데이터 등을 통합, 동일한 플랫폼(인터넷)을 통해 기존 애플리케이션의 변화 없이 통신을 가능케 한다.[1]

목적

EAI는 다음의 목적을 위해 사용될 수 있다.

  • 정보의 통합 : EAI는 일관성 있는 여러 시스템들의 정보를 보증하며, 기업 정보 통합(EII)를 의미한다.
  • 프로세스 통합 : 응용프로그램 간 비즈니스 프로세스를 연결한다.
  • 벤더에 대해 독립 : 응용 프로그램으로부터 업무의 정책과 규칙을 추출하고, EAI시스템에 구현하여 비즈니스 응용프로그램 중 하나가 다른 벤더에 의해 수정된다고 해도, 비즈니스의 규칙은 다시 만들어질 필요가 없다.

EAI의 구성요소

  1. EAI 플랫폼:데이터의 전송을 보장하는 메시지 큐와 트랜잭션 미들웨어 기능 수행한다.
  2. Adapter:다양한 패키지 애플리케이션 및 기업 자체 개발 애플리케이션을 재사용 가능 지원한다.
  3. 데이터 브로커:시스템 상호 간 데이터가 전송될 때, 데이터 포맷과 코드 변환이 가능하다.
  4. Workflow:미리 정의된 비즈니스 Workflow에 따라 업무 처리가 가능하다.
  5. Message Queue:프로세스가 송신을 기다리고 있는 온라인 시스템의 대기 행렬이 있다.

EAI의 유형

통합범위

  1. Data-Level:서비스 연결 간 Data 내용을 바탕으로 애플리케이션 간 전달이 가능하다.
  2. Object-Level:애플리케이션 간의 트랜잭션 및 연관 데이터 통합이 가능하다.
  3. Process-Level:다단계 프로세스에 대한 중앙집중적인 프로세스 제어 관리가 가능하다.

데이터 전송 모델

  1. Hub&Spoke:단일 접점인 허브 시스템을 통해 데이터를 전송하는 중앙 집중방식이 가능하다.
  2. Message Bus:애플리케이션과 미들웨어 간 웹서비스 인터페이스를 통해 전송이 가능하다.
  3. Point to Point:1:1 방식으로 애플리케이션 통합수행으로 이용된다.
  4. Hybrid:Hud&Spoke와 Message Bus와 혼합이다.[2]

EAI 전송방식

  • Hub&Spoke : 단일 접점으로 주변의 여러 애플리케이션과의 연계 업무를 담당하는 일종의 중앙집중 방식으로 모든 데이터가 허브 시스템에 저장됐다가 전달되는 구조이다. 이 방식은 관리가 쉽고 유지보수가 용이하다는 장점이 있으나 데이터가 한곳에 집중됨으로써 병목현상과 실시간 처리가 어려운 게 단점이다.
  • Message Bus : 전송로인 버스를 통해 데이터가 통합 서버 또는 애플리케이션으로 전달되도록 하는 방식으로 버스에서 특정 데이터를 지정한 목표지점에 안전하고 효율적으로 보내는 역활을 함으로써 애플리케이션 간 통합을 이루어낸다. 확장성이 뛰어나고 대용량 데이터처리가 용이하다는 장점이 있으나 관리가 용이 하지 않고 불필요한 호출에 모든 시스템이 응대를 해야 하므로 네트워크 부담이 커질 수 있다.
  • Hybrid : 이 방식은 Hub&Spoke 방식과 Message Bus 방식의 장점을 통합한 방식으로, 필요할 경우 어느 한 방향으로 EAI 시스템을 구축할 수 있다. 유연하게 통합할 수 있다는 장점이 있으나 아직 성능이나 관리에 있어서 검증되지 않았다는 지적이 있다.
  • peer To peer : Hub, Bus와 같은 미들웨어를 두지 않고 포인트 투 포인트 방식으로 각각의 애플리케이션을 연결하는 방식이다. 기존 방식보다 저렴한 비용으로 통합 작업을 수행할 수 있다는 장점을 갖고 있으나 데이터를 변환하면서 일괄성과 무결성을 유지하는 여타의 EAI 솔루션과 달리 단순히 애플리케이션 인터페이스만 해결할 뿐이다. 따라서 '통합'관점이 아닌 '연계' 관점으로 보는 시각이 있다.[3]

통합패턴

EAI 시스템을 구현하기 위한 유형으로는 '중개'와 '연합' 두 가지가 있다. 두 가지 유형은 때로는 동시에 일어나기도 하며, 같은 EAI 시스템은 다중 중계 시스템으로 유지될 수 있고, 게다가 외부 사용자의 요청에 대해 연합으로 서비스를 제공할 수 있다. 구체적으로는 다음과 같다.

  • 중개: EAI 시스템은 여러 응용프로그램 사이에서 중개자 또는 브로커의 역활을 수행한다. 응용 프로그램에서 어떠한 상황이 발생하게 되면, EAI 시스템의 통합 모듈에게 통보하게끔 설계되어있다. 해당 모듈은 다른 관련된 응용 프로그램들에게 전파하게끔 되어있다.
  • 연합 : EAI시스템은 모든 응용프로그램들의 최상위에 위치하게 된다. 모든 외부로부터의 접속은 EAI를 통해 이루어진다. EAI 시스템은 외부로 적절한 정보와 인터페이스를 제공하기 위해 구성되고, 요청자의 의한 응용 프로그램과 서로 작업을 수행하게 된다.

EAI 도입 단계

  • 계획(Strategy) : 고객의 현행 비즈니스 전략과 IT 전략에 따라 비즈니스 프로세스를 파악하는 단계로서 EAI 적용 초기 전략을 수립하는 단계
  • 판단(Assessment) : 파악된 고객의 전략을 분석해 하이 레벨 EAI 애플리케이션 아키텍처를 수립하고, 인프라스트럭처 차이의 분석을 통한 EAI 솔루션을 수립 단계
  • 구성(Architecture) : EAI 기능적 요건 및 인터페이스 요건을 도출하고, 시스템 성능 및 관리 등에 필요한 요건을 정립하여 EAI 아키텍처를 수립하는 단계
  • 선택(Selection) : 수립된 EAI 아키텍처에 맞는 최적의 EAI 제품을 선정하는 단계로서, 어댑터, 브로커링, 프로세스 관리 및 시스템 관리를 위한 구현 틀의 선정 단계
  • 도안(Design & Prototyping) : 선정된 제품의 구현을 위해 상세 설계 및 초기 프로토타입을 개발하는 단계
  • 구축(Building) : 상세 설계 및 초기 프로토타입의 결과에 따라 각 구성 요소별로 제품의 구성 및 필요한 인터페이스 프로그램 작성
  • 보완(Depolyment) : 구현된 제품군의 고객 인도 준비 및 유지보수 계획의 수립 단계
  • 운영(Run) : EAI 솔루션의 운영 및 유지관리 단계[3]

EAI 개발 프로세스

분석 단계

분석단계에서는 기업 내에서 EAI가 무엇을 할 것인가? 를 정의한다.

  1. 인터페이스 타입 정의:인터페이스 타입 정의란, 어떤 업무 시스템과 연동을 할 것인지, 그리고 해당 시스템의 기술적인 인터페이스 타입은 무엇인지 (Tuxedo,EJB,Socket,WebServioe,MQ etc)를 조사하고 서로 협의한다.
  2. 메시지 패턴 정의:인터페이스를 할 시스템들이 정의되었으면 어떤 방식으로 인터페이스를 할지를 정의한다. 이를 MEP라고 한다. SYNC 방식인지, 1:N으로 분할 거래를 할 것인지, ASYNC 방식, 디퍼드인지 각 업무별로 연계하는 방식에 대해 정의한다.
  3. 인터페이스 전문 정의:어떤 업무 시스템과 어떤 방법으로 연계할지가 정해지면 실제로 왔다 갔다 하는 메시지에 대한 포맷을 정의한다. XML로 할 것인지, TEXT로 할 것인지 헤어에는 어떤 데이터에 들어갈 것인지, 메시지 ID는 어떻게 정의할 것인지 등에 대해 정의를 한다.

분석단계가 끝나면 EAI 시스템이 갖추어야 할 모양과 어떤 업무 시스템 간을 어떻게 연동할 것인지가 정의된다.

디자인 단계

EAI 시스템의 요구 사항이 나오면 지자인 단계에서는 실제 인터페이스별로 아키텍처 디자인을 수행한다.

  1. 프로토타입 제작:EAI는 시스템 특성상 기능적인 면 (시스템 간 연계)보다 중요한 것이 비기능적인 요건이다. 시스템 간의 연계를 주요 목적으로 하다 보니, 거래 데이터의 전달 보장과 장애시 거래 유실을 방지하는 아키텍처가 필요하다. 이를 위해서 디자인 초기에 요건이 나온 인터페이스 연계 타입에 대해서 프로토타입 구현을 해서 정상적으로 작동하는지 다른 RISK 요인은 없는지 검증을 하고 현업과 연동을 해봄으로써 현업과 연계 시나리오에 대한 동일한 VIEW를 가지도록 한다.
  2. 프로토 타입 검증:프로토타입이 완성되면 해당 프로도 타입에 대해 검증을 한다. 대부분 Micro Benchmark 테스트 형식으로, 시스템 장애에 대한 장애 발견, 원인분석, 복구가능함을 검증하고, 장기간 거래에 대한 안정성 성능을 측정하여 시스템에 대한 기초 데이터를 마련한다.
  3. IF 리스트 수집:프로토타입에 의해서 검증된 아키텍처를 기반으로 현업에서부터 실제 연계 IF 목록을 수집하고 개발 일정을 수립한다. 현업의 시스템 개발과 연계 일정에 대해 의존성을 가지기 때문에, 이 과정에서 자세한 인터페이스 방식과 스케줄을 정의한다.

디자인 단계에서 가장 중요한 것은 주요 인터페이스 패턴별로 프로토타입을 개발하고 검증하는 것이다. 검증된 프로토타입을 가지고 실제 구현단계에서는 붕어빵 찍어내듯이 같은 패턴으로 정해진 스케줄에 따라 인터페이스를 구현해주게 된다.

구현 단계

구현단계에서는 실제 스케줄에 맞춰서 인터페이스를 연계하고, 이를 개발이나 STAGING 환경으로 이행하면서 연계에 있어서 오류가 있는 부분을 수정한다.

  1. 인터페이스 연계: 구현 단계에서는 일정에 맞춰서 인터페이스를 연계한다. 이때 필히 테스트 환경을 구축하여 인터페이스 구축 시마다 인터페이스에 대한 테스트를 수행해야 한다.
  2. 단계적 이행: EAI 개발 시스템에서 개발된 인터페이스는 EAI의 STAGING 시스템으로 개발된다. EAISTAGING 시스템에는 업무 시스템에 대한 개발 시스템이 연동되어 있는데, EAI 개발 시스템에 연동하지 않는 이유는 개발 시스템에서 잦은 RESTART와 디버깅 등이 개발팀에서 이루어지기 때문에 이에 대한 영향을 타 업무 개발팀에 끼치지 않도록 하기 위함이다. STAGING로 이행을 할 때는 정해진 인터페이스 개발 스케줄에 맞춰서 이행하여 업무 개발팀이 원활하게 업무 개발을 할 수 있도록 한다.
  3. 모니터링 및 수정: EAI 프로젝트에서 인터페이스를 연계해놓고 나면 문제가 예상하지 못했던 인터페이스 에러나, 요건 수정이 발생한다. STAGING 시스템에서 이를 모니터링해서 에러를 수정하고 이에 대한 보강 아키텍처를 수립하여 반영하는 반복적인 절차가 필요하고, 인터페이스 요건 변경에 대한 반영 역시 필요하다. 소프트웨어 개발 프로젝트의 특성상 요건에 대한 변경을 발생할 수 있으나, 거래 인터페이스 타입의 변경(대상 시스템 타입이 바뀌거나, MEP 자체가 변경되는)은 발생해서는 안 되며, 피치못하게 발생했을 경우 변경된 요건에 대한 아키텍처 영향도를 분석(프로토 타입핑을 통해서) 후에 결정을 해야 완성된 EAI 시스템의 안정성에도 문제가 없게 된다.[4]

EAI 레퍼런스 아키텍처

많은 상용 EAI 솔루션들이 있지만 이러한 솔루션들은 프레임 위만 제공할 뿐 실제 연계 아키텍처는 그 프레임워크를 기반으로 따로 설계해야 하는 경우가 보편적이다. 여기서는 EAI 시스템이 갖추어야 할 요건에 대해서 통상적인 아키텍처를 소개하고자 한다.

인터페이스

인터페이스 모듈은 EAI의 가장 기본적인 아키텍처 모듈로 송수신 시스템을 통합시키는 부분에 대한 아키텍처이다.

  • Inbound : Inbound는 송신 시스템과 연동되어 요청을 받고 응답을 송신 시스템에 보내는 역할을 한다. Inbound는 크게 두 가지의 모듈로 구성되어있다.
  1. Adapter : 어댑터는 다양한 플랫폼으로부터 메시지를 읽어드리는 Entry Point의 역할을 한다. 연동 시스템마다 각각의 아댑터가 정의되어야 한다.
  2. 메시지 변환 : 어댑터에 의해서 요청된 전문은 각 연동 시스템의 플랫폼에 따라서 각각 다르다. FML이나XML, 또는 TEXT 형태의 전문, Binary 등 여러 가지 형태가 될 수 있으나, EAI 내부에서 처리하기 위해서 이런 전문 형태를 공통적인 데이터 구조로 변환한다. 흔히 상용 솔루션에서는 메시지 처리의 유연성을 가지고 가기 위해서 XML을 사용하고, In-House 개발의 경우 성능의 최적화를 위해서 HasHT able형태의 Java POJOObject 사용하기도 한다.
  • Mediation : Mediation은 입력된 메시지를 가공하고 중계하는 EAI의 핵심적인 기능 부분이다.
  1. Routing : Routing은 입력된 메시지를 메시지의 내용에 따라서 적절한 수신 시스템으로 Routing 하는 역할을 수행한다. 이 과정은 1:1 Routing이 될 수도 있지만, N:1, 1:N 등 다양한 관계로 Routing을 수행할 수 있어야 한다.
  2. Mapping : 입력된 전문을 수신 시스템에서 요구하는 형태로 맵핑하는 작업을 수행한다. 필드 간의 맵핑이나 간단한 메시지에 대한 변환을 수행한다.
  3. MEP (Message Exchange pattern) : 이 부분에서 MEP에 대한 처리도 수행한다. SYNC나 ASYNC, 디피드성 거래에 대해서 JMS와 같은 큐잉을 이용해서 MEP를 구현한다.
  • Outbound : Inbound와 마찬가지로 처리가 끝난 메시지를 수신 시스템의 플랫폼의 Natlve 메시지 형태로 변환하여 Adapter를 통해서 수신 시스템에 전달한다.[4]

통합의 장단점

통합에 있어서는 다음과 같은 장점과 단점이 발생한다.

장점

  • 여러 시스템 중 실시간 정보조회를 제공한다.
  • 능률적인 비즈니스 프로세스와 도움으로 조직의 효율이 향상하게 된다.
  • 여러 시스템 간의 정보의 통합을 이루게 된다.
  • 개별과 유지보수가 쉬워진다.

단점

  • 소규모의 비즈니스에선 필요 이상의 개발 비용이 발생할 수 있다.
  • EAI는 시간 소모가 많고 많은 자원을 필요로 한다.
  • 많은 관리자들이 설계하려 하지 않고, 투자하려고 하지도 않는 디자인 작업을 미리 해야 하고, 대부분의 EAI 프로젝트는 일반적으로 지점 간의 움직임으로 시작하고 이는 곧 관리되지 않는 다수의 응용 프로그램의 증가를 낳게 된다.

연결구조

일반적으로, 기업용 응용프로그램 통합을 위해 가장 좋은 기반 구조, 컴포넌트 모델, 표준화 구조에 대한 다양한 의견들이 존재하고 있다. 근래의 기업용 응용 프로그램의 통합구조를 위한 필수 컴포넌트는 다음과 같다.

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

EAI 관련 제품

국외

  • IBM MQ:IBM MQ는 1992년 3월 IBM이 착수한 네트워크 소프트웨어 제품의 한 계열이다.[5]
  • 웹 메소드(webMethods):webMethods.io 은ESB, 데이터 통합 시스템, API 관리 툴, B2B 게이트웨이에서 제공하는 기능을 결합한 서비스로서의 통합 플랫폼(iPaaS)이다.[6]

국내

  • 비트리아(Vitria):단일 또는 다수의 전략적인 비즈니스 프로세스를 실시간으로 표현하고 관리할 수 있도록 BPM, BAM,BVM, B2Bi의 기능이 단일화된 아키텍처로 구현된 통합 개발 환경을 지원한다.[7]
  • 팁코(Tibco):사람과 데이터와 시스템을 통합하고 비즈니스를 더욱 효과적으로 관리, 파악하여 실시간으로 의사결정을 내리고 조치를 취할 수 있도록 돕는다.[8]
  • 메타빌드:MESIM ESB 제품은 SOA(Service Oriented Architecture)를 구현하는 서비스 조합, 라우팅, 변환, 오케스트레이션 등의 핵심 기술로서 이질적인 기업환경(애플리케이션, 데이터, 플랫폼)을 통합, IT 자원을 서비스화 하여 환경변화에 민첩하게 대응하고, 개발, 통합관리 및 운영, 관제하는 제품이다.[9]

향후 계획

EAI가 점차 B2B나 e마켓플레이스 분야로 확산되면서 EAI와 B2B의 경계가 모호해지고 있다. 또한 기업내 의 내, 외부에서 운용되고 있는 다양한 패키지 애플리케이션의 도입이 점차 늘어나면서 자연스럽게 이들 상호간 연동의 필요성도 대두되고 있다. 이러한 측면에서 EAI와 B2Bi의 통합 움직임으로 새롭게 등장한 개념이 바로'eAI'이다. 기업과 기업 간 e비지니스에 필요한 각종 애플리케이션을 연동시켜주는 eAI는 기업 내 이기종 시스템을 통합해주는 EAI와 이를 기업 간으로 확대한 B2BI를 포괄하는 개념이다. 따라서 eAI는 기업 간 프로트엔드를 지원하는 백엔드를 지원하는 백엔드 중심의 솔루션을 의미한다.[3]

각주

  1. ↑ 정보통신용어사전, 〈기업 애플리케이션 통합, 企業-統合, Enterprise Application Integration, EAI〉, 《한국정보통신기술협회》
  2. ↑ 인생새옹지마, 〈EAI(Enterprise Application Integration)〉, 《기술은 사람을 챙겨야 빛이 난다.》, 2013-03-21
  3. ↑ 3.0 3.1 3.2 구름바람, 〈전사적 응용 프로그램 통합시스템EAI〉, 《늑대와 함께 춤을》, 2004-08-18
  4. ↑ 4.0 4.1 조대협, 〈EAI(Enterprise Application Integration)〉, 《네이버 블로그》, 2013-03-21
  5. ↑ IBM MQ, 〈Introduction to IBM MQ〉, 《IBM MQ》
  6. ↑ 웹 메소드, 〈webMethods〉, 《WebMethods》
  7. ↑ 비트리아, 〈Vitria〉, 《MOCOMSYS》
  8. ↑ 팁코, 〈TIBCO Software Inc.〉, 《TLBCO》
  9. ↑ 메타빌드, 〈사물,연계,통합,미들웨어〉, 《MESIM ESB》

참고자료

같이 보기


  검수요청.png검수요청.png 이 EAI 문서는 데이터에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.  

개발 : 프로그래밍, 소프트웨어, 데이터 □■⊕, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인
데이터 ACID • CRUD • CSV • DAO • DB • DBMS • DB 명령어 • DCL • DDL • DML • DTO • ERD • ETL • JDBC • LOD • MDM • ODBC • RDBMS • RDF • SQL • 가상 데이터베이스 • 관계형 데이터베이스 • 그래프 • 기본키(PK) • 내부조인 • 널 • 노드 • 다이어그램 • 대리키 • 대체키 • 데이터 • 데이터댐 • 데이터마트 • 데이터 모델링 • 데이터뱅크 • 데이터베이스(DB) • 데이터베이스 언어 • 데이터 사이언스 • 데이터 사전 • 데이터 웨어하우스 • 데이터 정의어(DDL) • 데이터 제어어(DCL) • 데이터 조작어(DML) • 데이터 클러스터 • 데이터 토큰 (문자열) • 데이터 통합 • 덱 • 디비서버 • 라이트조인 • 락 • 레코드 • 레프트조인 • 로그 • 로그파일 • 로깅 • 롤백 • 리두로그 • 릴레이션 • 마스터데이터 • 마스터데이터관리(MDM) • 마이그레이션 • 메타데이터 • 배열 • 뷰 • 빅데이터 • 서브쿼리 • 수퍼키 • 순차리스트 • 스키마 • 스택 • 슬로우쿼리 • 엔티티 • 역정규화 • 연결리스트 • 외래키(FK) • 외부조인 • 인덱스 • 인덱싱 • 인젝션 • 자료구조 • 정규화 • 정보 • 조인 • 커밋 • 쿼리 • 큐 • 키 • 타깃 • 테이블 • 튜플 • 트랜잭션 • 트리 • 트리거 • 티비마이그레이터 • 풀조인 • 프로시저 • 필드 • 해시 • 해시맵 • 해시태그 • 해시테이블 • 해시함수 • 해싱 • 후보키
데이터베이스
관리 시스템
(DBMS) 		관계형 데이터베이스 관리 시스템(RDBMS) • 노에스큐엘(NoSQL) • 데이터베이스 관리 시스템(DBMS) • 더비 • 디비투(DB2) • 레디스 • 마리아디비(MariaDB) • 마이에스큐엘(MySQL) • 몽고디비 • 빅테이블 • 사이베이스 • 선디비 • 알티베이스 • 액세스 • 에스큐엘(SQL) • 에스큐엘라이트(SQLite) • 에이치베이스 • 엠에스에스큐엘(MS-SQL) • 오라클(Oracle) • 인터베이스 • 인포믹스 • 카산드라 • 카우치디비 • 큐브리드 • 티베로 • 파이어버드 • 포스트그레스큐엘(PostgreSQL) • 하이퍼테이블
DB 명령어 alter • array • create • delete • drop • from • full join • grant • inner join • insert • join • left join • null • order by • outer join • rename • revoke • right join • select • truncate • update • where
시스템 연계 API • CGI • EAI • ESB • JPA • RSS • SOA • SOAP • SSL • SSO • web3.js • XML • 디비투디비(DB-to-DB) • 레스트풀(RESTful) • 상호운용성 • 시스템 인터페이스 • 신디케이션 API • 오픈 API • 웹 API • 웹개방성 • 윈도우 API • 자바 API • 크롤링 • 프라이빗 API
위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반
원본 주소 "http://wiki1.kr/index.php?title=EAI&oldid=488868"