Preface

The Problem

Nowadays we use general purpose applications or libraries to communicate with each other. For example, we often use an HTTP client library to retrieve information from a web server and to invoke a remote procedure call via web services.

However, a general purpose protocol or its implementation sometimes does not scale very well. It is like we don't use a general purpose HTTP server to exchange huge files, e-mail messages, and near-realtime messages such as financial information and multiplayer game data. What's required is a highly optimized protocol implementation which is dedicated to a special purpose. For example, you might want to implement an HTTP server which is optimized for AJAX-based chat application, media streaming, or large file transfer. You could even want to design and implement a whole new protocol which is precisely tailored to your need.

The Solution

The Aradon framework & Platform is a clean alternative to bloated Enterprise Java stacks. It focuses on developer productivity and targets RESTful architectures. Aradon is a perfect companion to agile software development.

Aradon is a pure Java framework and allows you to keep your preferred development tools and libraries. If you already use Java as a development platform you don’t need to switch to another language, another IDE and other libraries. Just switch to a more productive Java environment!

Why not Servlet

• 장점 : 가장 많이 알려진 웹서비스 개발 규약이다. 관련 지원 프로젝트가 많다.(Struts, Spring)
• 단점 :
• 동적인 웹 페이지를 만들기 위해 나온 Servlet, JSP spec의 태생적인 한계 ` - Arch Model : State Model, Disconnected Web, - 서블릿이 하기 어려운 도전적인 문제들 : connected web, streaming, distribute & split not cluster, ByteObject 전송
  • Mobile Device 에 따른 변화된 시장환경
    • required high scalability
    • quick & easy deploy
  • 분산에 취약
  • 디플로이와 테스트 곤란
    • Servlet Model은 Test 친화적이지 않다. View와 너무 밀접하게 연관되어 있다.
  • 배보다 배꼽이 커진 프레임워크들
    • MODULE 내에서조차 그리고 모듈간의 의존성이 증가할수록 설계를 파악하는 데 따르는 어려움이 가파르게 높아진다. 이런 overload는 개발자가 다룰 수 있는 설계의 복잡도를 제한한다.
    • 서비스 모델의 제약조건은 명시적으로 분리되었을때 설계에 대한 개선과 활용도가 높아진다. - Filter
    • 자바의 복잡성은 문화적인 것이지 강제된 것은 아니다. ( Much of the java Complexity is cultural and not imposed G.bort -Play Framework Arch) `

---

WHY ?

Aradon은 누군가의 RFP(Request for Proposal)를 받아 만드는게 아니라, 여러가지 서비스와 서버를 만든후에 좀 더 나은 방식으로 만들 수 없을까를 고민하며 만들게 된 미들웨어 프로젝트이다.

밀레니엄 전의 간단한 사이트 전용 페이지를 만들었을때는 How는 중요한 문제가 아니었다. MVC를 강조한 Struts가 뜨고 다시 Spring이 나타나고 조금씩 무엇인가가 변했지만, 그냥 그냥 적당한 프레임워크를 사용해서 적당하게 만들면 됐다. 그 때 프로그래머에게 중요했던건 효율적인 DB 설계와 SQL이었지 Framework가 무었인지 미들웨어가 무었인지는 작은 고려사항 일뿐이었다. 그보다는 Table이 몇개인가가 더 중요했고, 테이블당 MaxRow는 기껏(?)해야 1억건 안팎이었다.

어느 순간 환경이 변했다. HTTP는 가장 성공한 프로토콜이 되었고 사람들은 기존의 전통적인 CS 환경이 아닌 HTTP를 이용해 더 많은 것을 해냈고 더 많은 걸 해내길 원했다. 사람들은 문서를 작성하기 위해 워드를 설치하고, 게임이나 이메일 클라이언트를 까는대신 - 워드 서비스를 사용해서 글을 작성하고, 게임 서비스를 사용해서 게임을 하고 메일 서비스를 사용해서 메일을 주고 받기 시작했다. 이제 브라우저는 단순히 HTML Parser가 아니라 사용자 Platform이 되었다.

20년 전에 ASP(Application Service Provider)는 죽었지만 완전히 무덤에 봉인된 것은 아니었다. 때맞춰 HTML5와 Mobile 디바이스의 발달은 HTTP로 할 수 있는 것의 영역을 더 넓혔다. 이제 사람들은 HTTP로 단순히 HTML만을 보는데 사용하지 않는다. (물론 그 자신은 모를지라도) 사람들은 익숙하게 Google Doc와 Gmail을 사용하며 브라우저로 게임도 할 수 있다고 여기게 됐다. NAS나 별도의 프로그램을 통해 파일을 공유하기 보다는 HTTP 기반의 Repository Service를 사용하며 ATM이나 은행보다는 인터넷 뱅킹을 더 많이 사용하며 SNS 서비스를 사용해서 안부를 주고 받으며, 이미지 서비스를 사용해서 자신들의 사진들을 관리한다.

이제 서비스 개발자는 새로운 도전에 직면하게 됐다. 이전에는 고작 동시에 몇십명정도나 호스트에 접근했으나 이제는 한번에 수백만명이 사용할 수 있는 방법을 고민해야 한다. 몇억건은 이제 더이상 대용량 데이타라고 불리지 않으며 직접적인 브라우저를 통한 접근이 아니라 다른 서비스와의 상호 운영성, 안정성 등의 비 기능적 요구사항이 중요한 이슈가 되었다. Gmail이나 FaceBook은 단순히 기능이 복잡해서 구현하기 어려운게 아니라 이전의 상식을 뛰어넘는 막대한 Request와 Data 양 때문에 구현하기 어렵다.

최근의 Business Apps의 트렌드는 변하고 있다.

• Separation of Data From Application
• Dynamic Feature Provisioning
• Elastic Feature Level Scalability
• Apps as a Service
• It's a Mathup - No More Function Point Apps

Servlet과 Tomcat은 어항속의 물이었다. 어항에 있을때에는 물을 보지 못했다. 어항을 나오자 그제서야 물이 보였다.

비슷한 목적의 잘 알려진 프로젝트

• Paly
• Node.js
• Vert.x
• BASS.io