2012년 3월 14일 수요일

Integration Framework Comparison

Java code Geeks에 가장 많이 사용하는 Integration Framework 3가지 “Spring Integration”, “Mule ESB”, “Apache Camel”에 대해서 비교 분석한 Post가 올라와 있어서 간략히 정리해 보도록 하겠습니다. 원문은 아래 링크를 따라 가시기 바랍니다.

원문 보기

현재도 그렇지만 앞으로는 더욱더 회사 간 또는 어플리케이션 간에 데이터 교환이 더 빈번히 많아지고 그 필요성도 커지는 건 당연한 일입니다. 이런 일을 위해서 Enterprise Integration Patters(EIP)가 발표되었고 이를 충실히 구현한 Open source EIP Framework이 위에서 언급한 3가지 입니다.

Spring Integration

  • Spring project을 기반으로 개발되어 있어, Spring Project에 쉽게 추가.
  • Spring을 잘 안다면 쉽게 사용 가능.
  • 기본적인 Connector만 지원(File, FTP, JMS, TCP, HTTP, JDBC,WebService)
  • 기존 Spring project에 EI 기능을 추가한다면 적극 추천.

MULE ESB
  • EI 기능외에 Full ESB 기능이 포함되어 있음.
  • SAP, Tibco Rendevous, Oracle Siebel CRM, Paypal, IBM’s CICS Transactioin Gateway와 같은 특화된 Connector을 제공.
  • 특화된 Connector가 필요하다면 추천.

Apache CAMEL
  • Mule ESB 만큼 많은 Connector 제공.
  • IDE 툴은 “FuseSource”, “Talend”에서 따로 제공하나 많은 양의 Boilerpalte code을 발생시킴. 
3 가지 중 승자는 없는 것 같습니다. 개인적인 판단에 따라 사용하시길. 


원문 저자는 개인적으로 Apache Camel을 선호한다고 합니다. Spring Project는 싫고(전 Post에서 언급되지만 원저자는 Spring을 싫어 합니다), 특별한 Connector도 필요 없기 때문에.

2012년 3월 12일 월요일

Why I will use Java EE instead of Spring in new Enterprise Java Projects in 2012

Java Code Geeks에 포스팅 된 글입니다.
이 글의 필자는 JEE(J2EE가 아닙니다.)가 보다 활성화 되었으면 하는 의도에서 이 글을 작성 한 것 같습니다.
또 한 필자는 Enterprise Java Project에서 표준 기술인 JEE 보다 Spring(이는 비 표준 기술입니다.)의 역할이 크고 사람들이 열광 하는 것에 못 마땅하게 생각하고 있음을 알 수 있습니다.  그리고 언급하고 있는 이야기를 요약하면 다음과 같습니다.

  1. 과거 J2EE는 무겁고, 크고, 불편했다. 이를 해결해준 것이 Spring이다. Spring이 Enterprise Java 환경에 미친 영향은 실로 막대하다.
  2. 우리가 흔히 말하는 J2EE는 이미 죽었다. 지금은 JEE(Java Enterprise 5 이후) 시대이며 JEE는 Spring과 다른 Framework으로 부터 장점만을 훔쳐서(“STOLE”) 훌륭하게 발전 되었다.
  3. JEE는 “Standard specification”이다. 이는 Vendor Independent을 가지게 한다.
  4. 앞으로는 JEE기반의 Enterprise Java Project가 많아 질 것이다.
필자가 너무 JEE을 옹호하는 발언을 하므로 몇몇 개발자들의 원성도 사고 있군요. 하지만 중요한 사실은 JEE는 이제 Spring을 대적할 수 있을 만큼 안정적이고, 빠르고, 편리해 졌다는 것입니다.

원문보기

2012년 3월 5일 월요일

I don't know, what is GlassFish?

Why the name GlassFish?
개발자 중 한명인 Eduardo가 말한 “transparent development”(투명한 개발), 다른 개발자가 “비쳐 보인다”라고 말하므로서 개발의 투명성을 묘사하는 GlassFish라 명해졌습니다.

GlassFish는 Java EE을 지원하는 Open source Application server 입니다.
GlassFish(현재 3.1.2)는 Java EE 6의 모든 기능을 완벽히 구현하였습니다.

GlassFish vs Tomcat
GlassFish는 Java EE Container에 속해 있는 반면, Tomcat은 Servelt과 JSP만 지원하는 Servlet Container 이다.

Tomcat 상에서 구동되는 어플리케이션은 GlassFish에서도 그대로 사용이 가능.

두드러진 차이점

  • GlassFish를 이용하면 EJB, JPA, JMS 등의 이점을 확실하게 누릴 수 있다. 반면에 Tomcat의 경우 상기의 기술을 개별적으로 추가해 줘야 하는 번거로움이 있으며, 개발자는 그 기능을 일일이 확인해야 한다. 
  • GlassFish가 제공하는 클러스터링과 정교한 고가용성 기능은 어플리케이션이 엄격한 엔터프라이즈급 SLA를 충족 할 수 있도록 설계되었다. 
  • GlassFish는 관리자 콘솔과 Command Line Interface를 이용한 중앙식 관리 방식을 지원하고 있고, Callflow Monitoring 기능은 어플리케이션 개발자 또는 서버 관리자가 어플리케이션 개발자 또는 서버 관리자가 어플리케이션이 가장 많이 사용되는 영역을 파악할 수 있도록 도와줍니다. 
  • GlassFish는 Ruby/JRuby, Python/Jython, Groovy, PHP, JavaScript/Phobos, Scala 같은 다양한 스크립팅 언어를 지원합니다. 
  • GlassFish는 어플리케이션 재배포시 세션을 유지시킬 수 있어 개발자가 단기간에 Java 웹 어플리케니션을 개발할 수 있도록 도와 줍니다. 
  • GlassFish는 서버를 재시작 하지 않고 가상 서버와 HTTP Listener를 동적으로 재구성할 수 있게 해줍니다. 
  • GlassFish 하위 웹 티어는 Grizzly Framework을 통해 구현되었는데, Java로 제작된 이 프레임워크는 NIO API의 이점을 최대한 활용함으로써 높은 확장성 뿐 아니라 고도의 커스터마이징 능력까지 제공합니다.

Sun에서는 Tomcat의 NIO Connector와 GlassFish를 비교했습니다. 이 테스트에서는 컨테이너에서의 시간 소모를 최소화하기 위해 단순한 Servlet이 이용되었고, 사용자 증가와 관련해서 각 종 컨테이너가 지원할 수 있는 능력(작업/초)이 측정 되었습니다. 16,000명의 사용자가 접속했을 경우의 결과는 다음과 같습니다.

성능상 비교

GlassFishTomcat
작업/초6988.96615.3
평균 응답 시간0.2420.358
최대 응답 시간1.5193.693
90% 응답시간0.60.75

ETL 솔루션 환경

ETL 솔루션 환경 하둡은 대용량 데이터를 값싸고 빠르게 분석할 수 있는 길을 만들어줬다. 통계분석 엔진인 “R”역시 하둡 못지 않게 관심을 받고 있다. 빅데이터 역시 데이터라는 점을 볼때 분산처리와 분석 그 이전에 데이터 품질 등 데이...