블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

아두이노, ESP8266,ESP 32 성능 비교


와이 파이 통신 모듈을 사용해보니, ESP8266이나 ESP32를 MCU로 하는 보드들을 메인 보드로 사용하는 경우가 많아서, 아두이노 우노나 메가와 같은 보드 없이도 이 보드들만으로도 성능이 충분할까해서 성능 비교표를 찾아보았다. 일단 결론 부터 이야기 하면, 아두이노 시리즈는 성능이 비교가 안된다. ESP32가 가장 빠르고, ESP8266 모델만 해도 상대적으로 매우 높은 성능을 낸다.



소스 : https://hilo90mhz.com/arduino-esp32-esp8266-101-speed-test-comparison-chart/


분산 대용량 큐-Apache Kafka에 대한 검토 내용 정리


실시간 빅데이타 분석 아키텍쳐를 검토하다가 아파치 스톰을 보다보니, 실시간 데이타 스트림은 큐를 이용해서 수집하는 경우가 많은데, 데이타의 양이 많다 보니 기존의 큐 솔루션으로는 한계가 있어서 분산 대용량 큐로 아파치 카프카(Kafka)가 많이 언급된다.

그래서, 아키텍쳐를 대략 보고, 실효성에 대해서 고민을 해봤는데, 큐의 기능은 기존의 JMS나 AMQP 기반의 RabbitMQ(데이타 기반 라우팅,페데레이션 기능등)등에 비해서는 많이 부족하지만 대용량 메세지를 지원할 수 있는 것이 가장 큰 특징이다. 특히 분산 환경에서 용량 뿐 아니라, 복사본을 다른 노드에 저장함으로써 노드 장애에 대한 장애 대응 성을 가지고 있기 때문에 용량에는 확실하게 강점을 보인다.

실제로 마이크로소프트 社의 엔지니어가 쓴 논문을 보면http://research.microsoft.com/en-us/um/people/srikanth/netdb11/netdb11papers/netdb11-final12.pdf

 


카프카의 경우 10만 TPS 이상의 성능을 RabbitMQ는 2만 TPS 정도의 성능을 내는 것으로 나와 있는데, 여기서 생각해볼 문제가 큐는 비동기 처리 솔루션이다. 즉 응답 시간에 그렇게 민감 하지 않다는 것이다.

그리고 일반적인 웹 시스템의 성능이 1500~2000 TPS (엔터프라이즈 시스템의 경우) 내외인 것이 일반적이기 때문에, Rabbit MQ의 2만 TPS의 성능은 충분하다고 볼 수 있지 않을까 한다.

물론 네이버나 해외의 대형 SNS 서비스의 경우에는 충분히 저정도의 용량이 필요하겠지만, 현재로써는 일반적인 시스템에서는 카프카의 용량과 성능은 약간 오버 디자인이 아닌가 하는 생각이 든다.


Rabbit MQ is scalable and




Node.js vs Vert.x 비교


간단하게 정리해본 Node.JS Vert.x의 장단점 비교,

두 서버 모두 C10K 문제를 해결 하기 위한 Single Thread 기반의 고성능 비동기 서버이다.

C10K 문제는 대용량 (10,000개이상의 동시 커넥션을)처리 하기 위한 문제로 전통적인 Tomcat등의 WAS에서는 이 문제를 해결할 수 없다 들어온 request는 무조건 큐잉이 되었다가 뒷단의 멀티 쓰레드에 의해서 작업이 처리되는데 이 멀티 쓰레드의 수 만큼만 동시 사용자를 처리할 수 있는 개념이다.

반대로 이 두 서버들은 일단 Connection이 연결되면, 연결된 socket들을 물고 있다가, Single Thread Event Loop가 고속으로 돌면서, socket에 들어온 메세지들을 처리하고 빠지는 구조이기 때문에 하나의 Thread임에도 불구하고, 동시에 여러 사용자를 처리할 수 있는 장점을 가지고 있다.

Vert.x Node.js에 영감을 받고 만들어진 서버이기 때문에, 그 특성이 매우 비슷하지만, 장단점이 극명하게 들어난다.

 

Node.js

Vert.x

내부 엔진 기반

Google Chrome V8 자바스크립트 엔진

libuv 기반의 비동기 처리 IO

Netty 기반의 NW IO

Hazel Case 기반 클러스터링

구현언어

C

Java

사용가능 언어

Javascript(애플리케이션), C (네이티브 모듈)

Python,JavaScript,Java,Groovy,Scala

외부 모듈

40,000개 이상

100개이하

클러스터링

한 하드웨어에 여러개 node.js를 띄울 수 있음. Node.js 인스턴스간 상태 Share 불가

한 하드웨어에 여러개의 vertx를 띄울 수 있음. node간의 상태 공유 메세징 가능
(HazelCast
기반)

에코시스템

매우 풍부. 레퍼런스,서적,교육,컨설팅 기관

공식 서적 2 (2권다 100페이지 이하))
컨설팅,교육 업체 없음

성능

열세
(
node 인스턴스당 CPU 코어 1개 이상 사용이 불가함)

우세
(JVM
기반으로 하나의 vert.x인스턴스에 여러개의 verticle 인스턴스를 띄워서 CPU 사용률을 극대화 할 수 있음)

한 마디로 정리하면, Vert.xHazelCast기반의 IMDG (In memory data grid)를 가지고 있어서, 클러스터링 기능이 좋으며, JVM기반으로, 여러 개의 Verticle을 동시에 띄어서 CPU 사용률을 극대화 함에 따라 더 높은 성능을 낼 수 있으며, 여러 프로그래밍 언어를 지원한다. 기술적으로는 Vert.x가 우세적인 면이 있으나, 아직 에코 시스템이 제대로 형성되지 않아서 기술 지원이나 자료를 구하기가 어려워, 기술 습득이나 운영 유지보수에서는 Node.JS가 우세이다.

 

Selenium WebDriver와 RC 차이

ALM/Test Automation | 2013.12.24 00:20 | Posted by 조대협

How Does WebDriver ‘Drive’ the Browser Compared to Selenium-RC?

Selenium-WebDriver makes direct calls to the browser using each browser’s native support for automation. How these direct calls are made, and the features they support depends on the browser you are using. Information on each ‘browser driver’ is provided later in this chapter.

For those familiar with Selenium-RC, this is quite different from what you are used to. Selenium-RC worked the same way for each supported browser. It ‘injected’ javascript functions into the browser when the browser was loaded and then used its javascript to drive the AUT within the browser. WebDriver does not use this technique. Again, it drives the browser directly using the browser’s built in support for automation


출처 : http://docs.seleniumhq.org/docs/03_webdriver.jsp


'ALM > Test Automation' 카테고리의 다른 글

TestLink를 이용한 Test Case 관리 자동화  (2) 2013.12.31
Selenium Test Suite 수행  (0) 2013.12.29
Selenium WebDriver와 RC 차이  (0) 2013.12.24
Selenium 테스트 메모  (0) 2013.12.24
테스트 팀의 조직 구조  (1) 2012.08.21
JUnit Max  (1) 2009.05.06

 


훝어 보기
- 인터페이스
 기존의 Gmail이나, Google Docs와 상당히 유사하다. 일관된 인터페이스를 제공하는 것은 사용자 경험 관점에서 제대로 된 선택인듯
- 기능
 기능적인 차이는 크게 없다. 검색이 강화된 것과 GDocs 연동 기능이 있는 것 정도
 기본적으로 저장과 Sync 기능을 제공하고, GDocs와 연동하여 문서를 협업으로 작성할 수 있는 기능을 제공한다.
 개인 클라우드 스토리지는 이미 Box나 DropBox같이 여러 서비스들이 강력한 기능을 제공하는 레드 오션이기 때문에 기능적으로 혁신적인 차별화는 어렵고, 기존 서비스와 연동 정도 및 사용자 경험이 관건인데,
 G Drive는 아무래도 기존 서비스 연동과 함께, Android 플랫폼에 PreLoad되고, 기존 Gmail등 기존 서비스 사용자들을 Transition하면서 사용층을 급격하게 늘려 나갈 것 같다. (기능적인 차이가 아니라)

- 플랫폼 지원

PC와 안드로이드만 지원한다. 아직은... 향후 iPhone도 지원 예정이란다. WP7이나 WP8 지원 계획은 없는듯


타서비스와 비교 특징
-강화된 검색 기능

 문서 파일 뿐만 아니라 스캔된 문서 파일까지 OCR 기술을 이용하여 내용을 인지할 수 있고, 이를 기반으로 검색을 지원한다.
 타 서비스에 비해서 문서의 내용 기반으로 검색이 가능하며, 비 정형화된 스캔된 이미지까지 문서로 검색 가능하다.
-기존 서비스와 연동
 기존의 Docs와 Gmail등과 타이트하게 연동이 되어 있다. Gmail에 GDrive 저장된 파일을 Attach하거나, G-Docs를 이용하여 GDrive에 저장된 문서를 편집할 수 있으며, 이 문서가 실시간으로 공유된 사용자들에게 업데이트 된다.
-3'rd Party 연동 기능 제공
 OPEN API를 제공함으로써, 파트너나 일반 개발자들이 Google Drive를 개인 저장공간으로 사용할 수 있다.

 

단점
-단점으로 지적할 수 있는 부분은, 파일 업로드 크기 제한이 있다. 한 파일의 최대 크기를 10GB로 제한하고 있다. (Sugarsync는 무제한, 다른 클라우드 스토리지 서비스는 일반적으로 2G)
-멀티미디어 스트리밍이나 변환 기능이 없는 것은 아쉬움으로 남지만, 아마 3'rd Party 지원 기능을 통해서 다른 파트너가 만들지 않을까 싶다.

 

레퍼런스

 

구글 드라이브 소개 자료
http://googleblog.blogspot.com/2012/04/introducing-google-drive-yes-really.html

Google drive vs Sky Drive vs DropBox
http://www.geek.com/articles/geek-pick/google-drive-vs-skydrive-vs-dropbox-20120424/

Mashable Google Drive 분석
http://mashable.com/2012/04/24/google-drive-compared/

CNet Google Drive 분석

http://news.cnet.com/8301-1023_3-57419024-93/google-drive-its-slick-integrated...and-not-exactly-free/?tag=mncol;txt

Google Drive Term of Service 분석

http://www.techdirt.com/articles/20120424/17562518637/calm-down-internet-google-drives-terms-are-standard-countless-websites-including-gmail.shtml

중국은 Great Firewall로 G drive 막아주시고

http://news.cnet.com/8301-1023_3-57421540-93/google-drive-crashes-into-chinas-great-firewall/?part=rss&subj=news&tag=title

 

 

구글 드라이브에 올리면 "내 파일이 내게 아냐~~"

G Drive "Term of Services"를 분석한 글. http://www.techdirt.com/articles/20120424/17562518637/calm-down-internet-google-drives-terms-are-standard-countless-websites-including-gmail.shtml

 

 

Google Terms of License 전문 http://www.google.com/intl/en/policies/terms/

"컨텐츠 올리면 저작권들은 니꺼 맞는데... 구글에서 내부적으로 당신 컨텐츠 가지고 몰 하던지 상관하지 마시고, 다 좋은 서비스 만들기 위한거니까는 이해해라.."  이 정도 인데. republish나 public display를 허용한다. IP는 개인것이 맞는데, 재 퍼블리슁은 가능하다... 약간 애매한 조항

일단 내가 어떤 컨텐츠를 가지고 있는지, 무엇을 언제 어디서 올리고 사용하는지에 대해서는 수집이 가능하다는 말이기 때문에 구글에게 내 개인정보가 합법적으로 노출된다. 광고등에 이용하겠지만, 위치기반 서비스나 패턴 분석에 내 개인 정보가 사용될 수 있다.

 

 

요즘 일이 바뻐서 블로그 포스팅을 거의 못하고 있습니다.
많이 버는 만큼, 그동안 충전해왔던 지식이나 노하우를 주로 방전하는 느낌입니다.

어쨌거나, 클라우드의 양대 산맥인 아마존 AWS와 Microsoft Azure에 대한 이야기를 해보려고 하는데..
Azure vs AWS의 승자가 누구이냐? 인데. 결론 부터 이야기 하면 AWS의 손을 들어주고 싶습니다.
Blob Storage나 DB 서비스와 같은 액세사리성 서비스는 양쪽다 어느정도 구색을 갖춰 놨다고 했을 때, 핵심인 Compute Service가 문제인데.
기본적으로 Azure는 .NET 기반의 PaaS만 지원하지만, Amazon은 모든 플랫폼을 올릴 수 있는 IaaS 수준 서비스를 제공합니다.
이말인즉슨, 내가 필요한 소프트웨어를 마음대로 올릴 수 있다는 겁니다. 단순하게 Java냐, .Net이냐 차이가 아니라
서비스를 하다보면 NFS가 필요할 수 도 있고, 제공해주는 NoSQL 서비스의 성능 문제로, Mongo나 Cassandra를 쓰고 싶을 수 도 있고, 빌드 환경을 만들어보고 싶을 수 도 있고, 여러가지 요구 사항이 존재하는데, Azure는 그게 안되고, 그냥 딱!! .NET 개발만 해야 한다는 것인데, 단순한 웹 애플리케이션 시나리오라면 모르겠지만
요즘과 같이 빅데이타나 분산 아키텍쳐가 유행하는 시절에 이것만으로는 부족하다는 말입니다.

기술적으로 Azure가 상당히 뛰어난점도 많은데, IaaS 단으로 오픈을해서, 조금 더 선택의 폭을 넓혀 줬으면 합니다.
이상 사견이었습니다.

DB VM에 올릴 때 첫번째로 고려할 사항은 수직적 확장성이다. 수평적인 확장성은 DBMS 자체가 제공하는 클러스터 기능을 이용해야 한다. (MS SQL의 경우 수평 확장 불가, ORACLE의 경우 RAC를 이용하여 수평확장 가능). 만약에 DBMS 자체 클러스터링에 대한 확장이 불가능하다면 애플리케이션 단에서 Database Sharding등을 이용하여 확장을 하는 안을 고려할 수 있다.

수직적 확장의 경우 현재까지 Hyper-V가 최대 CPU 4 코어까지만 지원하기 때문에, 더 이상의 용량이 필요한 경우 분리된 Physical Machine을 사용하는 방법을 사용해야 한다.

 

DBMS VM에 올릴 경우 가상화에 대한 Cost로 인하여 성능이 떨어지는데, 그 중에서 성능에 가장 큰 영향을 미치는 것이 Disk에 대한 부분이다. DB VM에 배포할 때 Disk에 대해서 아래와 같이 3가지 옵션을 선택할 수 있다.

       Dynamic Size VHD : 가상 디스크의 사이즈를 동적으로 지정하여 Runtime에서 변경되도록 하는 옵션

       Fixed Size VHD : 가상 디스크의 사이즈를 정해놓고, 공유하는 방안

       Pass-through Disk : 물리적인 디스크를 직접 VM에 마운트 하는 방안

 

먼저 Fixed Size VHD Pass-through Disk (이하 PTD)의 성능 차이를 보면

 

Random IO의 경우 Read/Write 모두 큰 차이는 없고 Sequential Write 부분에서 Fixed Size Disk 가 성능이 떨어지는 것을 볼 수 있다.

일반적인 OLTP성의 트렌젝션 처리 성능을 비교해보면


 1.       Baseline: a native Windows Server 2008 environment with Hyper-V role disabled. The virtual network switch is not turned off.

2.       Root partition: a root partition in Windows Server 2008 with Hyper-V enabled.

3.       VM_PT: a guest virtual machine configured with pass-through disks, four logical processors, and 14 GB RAM.

4.       VM_VHD: guest virtual machine configured with fixed-VHD disks, four logical processors, and 14 GB RAM.

5.       Overhead is calculated by comparing with Baseline ((Baseline Batches/CPU – VM Batches/CPU)/ Baseline Batches/CPU)

위의 테스트 결과와 같이 전혀 가상화를 하지 않은 상태 (Baseline) 대비 PTD를 사용했을 때와 Fixed Size VHD의 성능을 비교하면 10~20% 정도의 차이가 나는 것을 볼 수 있고, Fixed Size VHD PTD사이의 차이는 소량의 트렌젝션에서는 PHD가 약간 우세를 나타내며, 대량의 트렌젝션에서는 큰 차이가 없는 것으로 나타난다.


다음 자료는 하나의 MS SQL 인스턴스가 독립된 PTD를 사용하고, 다른 하나는 Fixed Size VHD를 사용하는데, 해당 디스크 볼륨이 다른 VM과 공유되는 상황에 대한 비교이다.

위의 표에서와 같이 Dramatic한 성능 차이는 나지 않는다.

 

결론적으로 PTD Fixed Size VHD 사이의 성능 차이는 미미하기 때문에 성능 최적화 측면에서는 PTD를 공간 활용면에서는 Fixed Size VHD를 사용한다.

 가상화에 올린 DB Physical 서버에 직접 올린 DBMS강의 성능 차이는 약 10~20% (가상화로 인한 오버헤드)정도로 판단하고 디자인에 참고해야 하며, 가상화에 올릴 시에는 최대 4개의 코어 까지만 지원하기 때문에 4 코어 이상의 성능이 필요한 경우 가상화 환경이 아닌 분리된 DBMS 하드웨어를 사용해야 한다.

(분석 리포트 출처: http://www.microsoft.com/hosting/dynamicdatacenter/Resources.html#SQLServer_)


앞서 주로 사용자 관점의 차별점에 대해서 설명했는데, 이제 개발자 관점에서 살펴보도록 하자.

넓은 개발자 계층과, 편리한 개발 인프라

삼성 전자가 얼마전에 ‘bada’라는 이름의 모바일 플랫폼을 발표하였다. 필자가 얻은 정보에 따르면 속도도 빠르고, 기기도 좋다. 근데 문제는? 개발자 인프라가 없다. 한마디로 아직 인기가 없는 플랫폼이고, 개발에 필요한 API나, 튜토리얼, 커뮤니티등의 생태계가 생성되지 않아서 개발을 하기가 쉽지 않다.

윈폰7의 개발 인프라는 SilverLight와 .NET 그리고 XNA에 기반을 가지고 있다. 이 기술들은 윈폰7을 위해서 새롭게 개발된 기술이 아니다. 이미 윈도우 프로그래밍에 사용되고 있는 기술이다. 바꿔 말하면, 윈도우 프로그래머는 손쉽게 윈폰7개발에 참여할 수 있다는 말이고, 관련 커뮤니티들도 활성화 되어 있다. C#과 비주얼 베이직과 같은 익숙한 개발 언어를 비주얼 스튜디오라는 익숙한 개발환경에서, 개발하면 된다. 스마트폰 애플리케이션 개발에 있어서 진입 장벽이 높은 것이 쉽지 않은 일인데, MS는 이 부분에 상당히 공을 들인 듯 싶다. 안드로이드가 개발자 층이 넓은 자바를 통해서 급속하게 개발 생태계를 확보했듯이, MS는 .NET이라는 개발자층이 넓은 플랫폼 + 비주얼 스튜디오등의 안드로이드 보다 훨씬 강력한 개발환경으로 개발자층을 지원할 예정이다. 안드로이드 개발자 분들은 아시겠지만, 개발환경은 이클립스다. 이클립스는 자바 개발환경으로 참 좋은 환경이지만, 단하나 문제는 UI쪽의 레이아웃 디자인 하는 도구가 조악하다. 당연히 개발 편이성도 떨어지고 난이도도 올라간다.


<그림. 이클립스 기반의 안드로이드 UI 디자인 도구 >

근 20년간 비주얼 스튜디오라는 개발툴을 계속해서 개발하고 판매했던 MS의 관록이 느껴지는 부분이라고나 할까?


<그림. 비주얼 스튜디오 기반의 UI 디자인 환경>

클라우드 서비스

스마트폰 애플리케이션이 좀 더 나은 서비스를 하기 위해서는 백엔드에 서버가 필요하다, 일반적인 스마트폰 애플리케이션들은 인터넷 서비스 업체 (트위터,구글,페이스북등)가 제공하는 공개 API (OPEN API)를 사용한다. 그런데 좀 더 특화된 서비스를 하고 싶다면?
별도의 서버가 필요하다. 사용자의 정보를 저장하고, 서버에서 여러 트렌젝션을 처리하고, 사용자간의 정보를 처리하기 위한 서버..!! 이런 서버를 개인이 보유하기는 비용적으로 쉽지 않다.  0.99$ 짜리 애플리케이션을 만드는 개발자가 몇백만원짜리 서버를 구입하고 데이터 센터에 호스팅을 하는 것은 쉽지 않다. 더군다나 전세계를 대상으로 서비스를 할려면 속도나 법적 문제 때문에 세계 여러곳에 서비스를 설치 해야 하는데, 이건 개인이 아니라 기업도 쉽지 않은 일 이다.
이런 문제를 해결하는 방법중 하나는 클라우드 서비스를 사용하는 것이다. 클라우드 상에 서버를 임대하거나 저장 공간을 임대해서 사용하고 (Iaas – Infra as a service). 또는 OPEN API플랫폼을 구축하거나 기 구축된 것을 사용하는 것 (Paas – Platform as a service)등이 좋은 예이다.
애플의 경우 일반 사용자에게 제공하기 위한 Public 클라우드는 가지고 있지 않다. 그래서 애플리케이션들은 모두 일반 OPEN API를 사용하거나, 개개인 별로 호스팅 되는 서버를 통해서 서비스를 제공한다.
구글의 경우 클라우드 플랫폼을 제공한다. 그런데 이것이 쌩뚱맞게 Python 언어 기반이다. 근래에들어서 Java도 지원하긴 하지만, 자세히 들여다 보면 제약 사항이 많다. DB서비스나 Storage서비스도 없거나 제약 사항이 있다.


여기에 또 윈폰7의 가능성이 나오는데, MS는 메이져 클라우드 플레이어중 하나이다. CRM,MS Exchanage, SharePoint와 같은 애플리케이션 서비스를 제공하는 Saas. AppFabric과 같은 SOA 를 지원하는 프레임웍,MS-SQL서비스등과 같은 Paas 그리고 Windows Server 가상화,Storage 서비스등을 지원하는 Iaas등 클라우드의 3계층 Saas-Paas-Iaas를 모두 제공한다.  물론 다른 스마트폰 플래폼들도 이 클라우드를 쓸 수 있다. 그러나 MS의 클라우드 기술은 기본적으로 .NET 개발 환경 기반으로 되어 있고, 윈폰7역시 .NET 기반이다. 즉 아주 Smooth한 연동이 가능하다는 것이다.


 윈폰7은 단순하게 디바이스에 탑재되는 플랫폼만이 아니라 MS의 클라우드 전략과 연동해서 클라우드 서버와 연동해서 서비스를 제공할 수 있는 모델을 지원한다.

엔터프라이즈 솔루션

일반 사용자 입장이 아닌 기업 사용자의 관점에서 스마트폰 플랫폼을 보면 기업의 업무 시스템과의 연동성이 매우 중요하다. MS는 오피스,MS Exchange 서버, 계정 및 자산 관리 도구인 Active Directory 그리고 Windows Server를 기반으로 구성되는 CRM (Dynamics)등의 여러 엔터프라이즈 솔루션을 가지고 있고, 이런 솔루션들이 자연스럽게 윈폰7과 연동될 수 있는 인프라를 제공하고 있다. 기존의 아이폰이나 안드로이드는 이런 인프라가 없기 때문에 일일이 개발을 해야 하거나 써드 파티 제품을 써야 하기 때문에 기업 애플리케이션 통합이 쉽지 않다. RIM의 블랙베리 같은 경우 오랜 역사를 가지고 있고, Lotus Notes나, MS Exchange와 좋은 통합성을 가지고 있기 때문에 기업 시장에서 좋은 우위를 점유할 수 있었던 것이었는데, 이번 윈폰7이 이러한 장점 역시 같이 커버 함으로써 엔터프라이즈 모바일 스마트폰 시장에서도  높은 가능성을 보여 줄 수 있을 것이라 기대한다.

ETL vs EAI

아키텍쳐 /EAI | 2009.06.16 18:28 | Posted by 조대협

ETL과 EAI 차이점 정리

ETL은 Dataware house나 BI와 같이 좀 덜 Mission Critical한 데이타에 사용되고, Batch등의 대량 전송에 사용함. 주로 DB 위주의 접근, 송수신 인터페이스에 대한 방향성이 있음

EAI는 애플리케이션간의 Integration이고, 단건이나 수건의 데이타에 대한 실시간 조회용 분산 트렌젝션(XA)가 중요한 요건으로 작용함. 양방향성을 띰

ETL and EAI Characteristics

ETL EAI
Focus Data Integration (Data Warehousing) Application Integration (Operational Apps)
Primary Technology Database Application
Timing Batch Real-time
Data Historical Transactional
Volume Size 
>Days or weeks of data 
>Records per min (GB)
Throughput 
>Single transactions 
>Messages/second (KB)
Integration Initiation Pull, query-driven Push, pull, event-driven
Flow Control Meta-data driven, complex data flow Business-rule driven, workflow oriented
Validation Strong data profiling and cleansing capabilities Limited data validations
Transactional Limited transaction and messaging capabilities Strong transaction control and recovery. Guaranteed message delivery with two phase commit

'아키텍쳐  > EAI' 카테고리의 다른 글

Apache Camel Error Handling  (0) 2013.02.20
Apache Camel Overview  (0) 2013.02.17
EAI (Enterprise Application Integration) 추진 전략  (2) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21
TAG EAI, eTL, 비교, 차이