Framework/Another Lore2009. 3. 6. 05:47

스팸 필터, Validation, Database 에 이어 4번째 Framework AL 개요

AL은 프로젝트 명 Another Lore의 약자로 일명 알-ㅅ-로 이름을 지었다. Validation과 Database가 System Framework인 반면에 AL은 도메인 Domain Framework 이다.

시스템 프레임워크는 프로젝트 종류와 상관없이 해당 시스템 인프라에 밀접한 관련이 있다. 이를테면 DB를 사용한다면 그게 게임이든 웹서비스든 혹은 임베딩 서비스라도 상관이 없다. 그런면에서 시스템 프레임워크는 문제를 단순화 시킬수 있다. 인프라 그 자체는 한정적이고 단순하기 때문에 집중의 장점을 충분히 활용할 수 있고 재 활용도가 높다.

반면에 도메인 프레임워크는 특정 도메인을 가정한 프레임워크이므로 해당 도메인에서 유용한 프레임워크이다. 첫 시도는 4년전쯤의 그리스 창조의 신 이름을 딴 Odin 이라는 프로젝트였다. (공식 명칭은 CAFE -Contetnt Application Framework & Engine) 사용자가 다루는 모든 엔티티를 Node와 Property라는 이름으로 추상화 시켜서 모든 컨텐트를 하나의 구조로 볼 수 있게 하겠다는 시도였다.

이를테면 사원과 부서라는 엔티티를 보자. 이를 다루기 위해서는 Employee 객체와 Dept 객체를 만들고 아마도 DB 겠지만 저장할때는 사원과 부서 테이블을 만들어 저장한다. 이제 로켓을 타고 지상 10000미터쯤에서 Employee객체와 Dept 객체를 바라보자. 아주 콩알만하게 보이기 때문에 우리는 이 두 객체의 차이점을 명확히 볼 수없다. 10000미터 상공에서는 Employee객체나 Dept 객체나 별 차이가 없다. Employee 객체는 empNo, ename, hireDate, sal 이라는 Property가 있고 Dept 객체는 deptNo, dname, loc 라는 Property가 있지만 아주 작은 차이다. (라고 생각하자-ㅅ-) 아주 작은 차이이기 때문에 더이상 굳이 Employee와 Dept로 인터페이스 하지 않아도 되고 최상위 객체로 Node로 인터페이스 처리를 하자. 라는 게 기본적인 아이디어 이다.

처음에는 JSR-170 에서 시작하였다. JSR-170은 Content Repository API를 의미하는데, 각종 컨텐트를 보관, 검색, 버저닝(versioning)하는 방법을 표준화하려는 시도이다. 오픈 소스 구현으로는 Apache Jackrabbit이 있고 현제는 JSR283으로 Extend 2.0 API가 있다.  (http://www.jcp.org/en/jsr/detail?id=170, http://www.jcp.org/en/jsr/detail?id=283) Odin는 소정의 결과도 있었지만 당시의 나는 아직 DB 관점에서 세상을 보는 단점이 있었기 때문에 충분히 성숙한 프레임워크를 만들지 못했다. (라고 나중에 생각했다.)

AL은 간단히 말하면 분산 컨텐트 서비스로 이전의 경험들도 좀더 발전적인 개념을 가지게 되었다. 그전에 AL 따위를 만들어서 무슨 장점이 있는지 부터 살펴보자. 그 자체로 장점을 가지는 시스템 프레임워크와는 달리 도메인 프레임워크는 좀더 제한적이기 때문에 신중히 접근해야 한다.

단기적으로는 Content Service API의 재활용에 있다. 예를들어 대부분의 프로젝트은 로그인 모듈이 필요하지만 그 때마다 로그인 모듈을 만드는건 그닥 좋아 보이지 않는다. 그래서 Open ID라는 게 생겼다. 이전의 Single Sign On 서비스와 비슷하지만 좀더 추상화되었고 MS의 패스포트 서비스와 달리 벤더 종속이 아닌 Open API이고 Open된 표준 규약이 존재한다. 이 OpenID라는 서비스를 사용하면 사용자는 여러군데 동시 가입하지 않아도 여러개의 서비스를 사용할 수 있으며 프로바이더 입장에서는 별도의 로그인 모듈 없이도 인증 서비스를 할 수 있다는 장점이 있다.

물론 정치적인 단점이 없는건 아니지만 그와 비슷한 관점에서 생각해 보면 대부분의 컨텐트 서비스는 컨텐트의 CRUDS(Create, Retrieve, Update, Delete, Search)말고도  
 - Versioning
 - Authorization(Security & ACL)
 - monitoring
 - exception handling
 - filtering 
등과 같은 기능을 공통적으로 사용한다. 그리고 비기능적 요구사항을 infra quality와 application quality(improve productivity, chain service)를 요구한다.  

일종의 메타 서비스(서비스를 만드는 서비스) 같은 것으로 서비스의 공통 부분을 제공해주는 서비스이다. 이런 메타 서비스를 통해 생산성을 향상시킬 수 있는 단기적인 장점이 있고 장기적으로는 AL Framework를 묶은 서비스끼리 chain으로 연결해서 거대한 하나의 Lore를 만들수 있으리라는 기대가 있다.

먼저 도메인에서 사용하는 용어 정의를 하자.
  • Node(노드) : 정보의 최소단위
    * 독립성과 관계성을 가져야 한다.
    * 0개 이상의 Property와 1개 이상의 Link를 가져야 한다.(
    * 한개의 parentNode를 가져야 하며 하나의 nodeType을 가져야 한다. 
    * 자신의 Global Unique하게 인식할 수 있는 한개의 UUID를 가지고 있다.
    * 노드를 인식하고자 할때에는 nodePath를 사용하거나 uuid를 사용한다. (name을 바꿀수 있어야 하나?)
  • Property(속성)
    * PropertyType과는 Class와 instance의 관계이다.
  • PropertyType(속성타입) :  
    * Type[String, Clob, Binary, Long, Double, Boolean, Date, Reference, Undefined] : defines integer constants for the available property types as well as for their standardized type names (used in serialization) and two methods for converting back and forth between name and integer value:
  • Property Constraint
    * Property가 가져야 할 Constraint. 이를테면 RequiredConstraint는 DB의 Not Null 과 비슷
  • NodeType(노드타입) :
    * An important feature of many repositories is the ability to distinguish the entities stored in the repository by type.
    * Supertypes: A node type may extend another node type (or more than one node type, if the implementation supports multiple inheritance.)
  • Property Definitions(속성정의) :
    * A node type contains a set of definitions specifying the properties that nodes of this node type are allowed (or required) to have and the characteristics of those properties.
    * 대소문자 구분하지 않음
  • Link(링크)
    * Node와 Node의 관계
    * Link는 label(name)을 가지며 이 label이 LinkType이다.
    * LinkType과는 Class와 instance의 관계이다.
    * Link는 ... 양방향?
  • LinkType(링크타입)
    * preDefined LinkType : parent-child, member
    * MemberType : A node type contains another memberNodeType specifying the member nodes that nodes of this node type are allowed (or required) to have and the characteristics of those child nodes (including, in turn, their node types)
  • Property Value-Constraint[Validation],
  • Value-Object[Static Value, Reference Value] :
    * Value : this represents the value of a property. The methods of the Value interface are:
  • UserSession,
  • UUID
    * Node Global Unique ID이다.
    * 전 세계에 같은 UUID를 가지는 노드는 있을 수 없다.(같은 UUID는 수학적으로 발생할 수 없는 확률이다.)
    * UUID represents a Universally Unique Identifier per IETF Draft specification

 

NodeType과 Node의 관계는 자바의 클래스와 인스턴스와 관계와 비슷하다. NodeType은 하위로 PropertyType을 가지고 Node는 하위로 Property를 가진다. 예컨데 employee 인스턴스 하나를 만들기 전에 먼저 Employee NodeType을 정의하고 각각의 PropertyType을 선언한 뒤 해당 Value의 Property를 가지는 empNode를 만든다. 이렇게 만들어진 empNode와 deptNode는 다양한 LinkType의 link를 가진다.

... 물리학의 대통합 이론이 떠오를 정도로 정보를 극단적으로 추상화시켰다. 좀더 이해하기 쉽게 말하자면 Database를 Wrapping한 Repository Service이다. 왜 Database를 Wrapping해서 Repository Service 개념으로 접근하는 장점은 무엇일까? 대부분의 프로그래밍은 Model - Process - View 단계를 거친다. 상대적으로 앞에 있을수록 좀더 단단하며 변하기 어렵다. 그래서 테이블 재설계등의 Model의 변동은 프로젝트 전반에 영향을 미치고 그 만큼 파괴력도 크다. AL은 Model의 뒷부분을 숨기고 유연하게 모델을 언제든 재설계를 할 수 있게 하고 오히려 모델 재설계에 장점을 가진다.

마땅한 Tool이 없어서 Class Diagram으로 말하자면




bleujin은 EmployeeNodeType을 인스턴스한 하나의 Node이다.
dev는 DeptNodeType을 인스턴스한 하나의 Node이다. bleujin과 dev는 부서관계라는 link을 가지고 있다.

어찌보면 객체디비나 EJB3모델과 세계관은 비슷하지만 AL은 자체가 서비스인 메타 서비스이므로 좀더 도메인에 치중되어 있다.




'Framework > Another Lore' 카테고리의 다른 글

와~~~  (0) 2009.04.09
AL - Extreme  (0) 2009.04.04
AL - Code Example  (0) 2009.03.20
AL - Abstraction & Model  (0) 2009.03.13
AL - 배경  (0) 2009.03.07
Posted by bleujin