Life is Simple, Thinking is High

AL을 혼자서 꾸역꾸역 만들다보니 단점은

온갖 여러가지 일을 해야 한다는 점이다. 이전에 회사에 소속되어 무슨 일을 할때는 다른 누군가가 해주던 백업및 배포용 build script도 만들어야 하고 호출하는 테스트 프로그램도 직접 만들고 나중에 고생하기 싫으면 유닛 테스트도 훨씬 더 정교하게 만들어야 한다.

이렇게 혼자서 이것저것 하는 방식은 최근 5년간에는 거의 하지 않았기 때문에 이것 저것 번거럽고 귀챃지만
덕분에 훨썬 더 많은 자동화 기술을 강제적으로 사용해야 되는 동기가 되고 있다.

웬만한건 다 자동화로 처리하는데 예외중의 하나가 테스트 프로그램으로 만든 WebApplication의 테스트이다. 가능한 Jsp에 code를 최소화하긴 했지만 그럼에도 수동적인 테스트를 할때마다 10분씩을 잡아먹고 있다.

그래서 이전에 만든적이 있는 스파이더에 몇시간 동안 사이트의 링크를 따라가면서 테스트 하는 툴을 만들다가
자바 스크립트 링크를 사용하는 것에서 막혔는데..구글한테 물어보니 링크로 스크립트를 사용하는 것이 크롤링 솔류션에서도 꽤 난감한 문제이긴 한가보다.

DOM을 스크립트 엔진에 로드해서 하는 방식은 배꼽이 더 커지기 때문에 어렵고 단순히 귀찮음을 떠나서 성능 테스트를 할때도 가상 브라우저로 써야 하기때문에 더 고민하다가 정 방법이 없으면
시나리오를 저장해서 동작하는 방식으로라도 써야. -ㅅ-;


AL은 세가지 모드가 있는데.
첫번째는 프레임워크 라이브러리 형태로 호출해서 쓰는 방식이고
두번째는 StandAlone 형태로 별도의 프로세스 서비스로 동작하면 WebDav나 WS로 네트워크 콜해서 쓰는 방식이 있고
세번째는 지들끼리 서로 통신하는 분산 방식으로 구상하고 있다.

첫번째는 머 원래 만들기가 어렵지 않으니 곧 대충 대충 될것 같고.. 문제는 2번째와 3번째..

계획된 2주 예정보다 하루 일찍 드디어 AL Project - DBPersistence[Oracle]의 테스트 케이스 95개가 모두 성공하였다.


예전에 보던 룸펜스타의 별돌이의 기분과 비슷하다.

숫자 0과 1의 차이는 무한한 차이이다. 존재와 무존재의 차이니까 말이다.

그럼 1과 2의 차이는? 1과 10의 차이는? 그 차이는 앞의 0과 1의 차이보다 크지 않다. 0과 1의 차이가 질적인 차이라면 1과 10의 차이는 그냥 10의 차이일 뿐이다. 그렇다면 1과 10000의 차이는 그냥 10000의 차이일까? 그럴수도 있고 아닐수도 있다. 흥미로운건 어느 양을 초과하게 되면 단지 양의 차이가 다시 질적인 차이를 일으킨다.

갈매기의 꿈의 조나단은 얼마의 속도를 돌파하게 되자 단지 하나의 갈매기가 아니라 자유로운 갈매기가 되었다. 물은 100도에 이르는 순간 더이상 액체가 아니라 기체로 형질 변환을 일으킨다. 자동차도 시속 1000km로 달리는 순간 날수 있다. 이런 양적인 변화가 질적인 변화를 일으키는 얼마든지 있다.

AL은 유연성을 극도로 올린 프레임워크이다. 항상 시소의 양끝처럼 하나가 올라가면 하나가 내려가는 관계는 아니지만 일반적으로 하나의 특성을 올리면 다른 하나의 특성은 떨어진다. 대표적인 특성 하나가 성능이다. 유연성이 높아질수록 일반적으로 성능은 떨어진다. 그러나 성능은 유연성과 달리 극단적으로 추구한다고 해서 양적에서 질적인 변화로 바뀌기 어려운 분야이다. 더군다나 성능은 항상 한계 속도가 있다. 그것에 한없이 가까워지도록 노력할 수는 있지만 결코 돌파할 수는 없는 선(이를테면 하드웨어)이 있다. 반면에 유연성은 질적인 변화가 쉽과 한계점의 제한으로부터 더 자유롭다.

유연성을 갖춘 프레임워크는 많다. 일찌기 RAD툴이라는 말이 나오기 시작한 15년 전부터 유연성은 프레임워크의 핵심중 하나였다. 최근의 루비온 레일즈도 그러한 예이다. 그러함에도 왜 AL을 만드는가? 이유는 간단하다. 이전의 유연함을 강조하는 것들은 모두 프로세싱과 관련되어 있다. 함수가 유연해지고 구조가 유연해진다고 해서 그리 큰 성과를 거두기는 어렵다. 왜냐하면 프로세싱의 밑단계에는 모델이 깔려있기 때문이다.

데이타모델이 정적인 상황에서 프로세싱이 유연해서 달성할 수 있는 효과에는 한계가 있다. DB Table과 OR Mapping하는 프로세싱 프레임워크의 단점은 바로 이것이다. 이는 어디까지나 제한적인 유연성이며 선을 벗어나지 못하는 유연성이다. AL은 유연한 프레임워크를 강조하지만 프로세싱보다 모델에 집중하고 있고 가장 유연하지 못하는 모델을 가장 유연하게 만들려고 노력하는 프레임워크이다.

지난 1주일동안 1년반이 넘게 팽개쳐 뒀던 AL을 다시 뜯어보고 있다. 평소에도 나는 프로그래밍을 잘한다고 생각한 적이 없다. 그리고 DB도 마찬가지이다. 다만 DBA중에서는 프로그래밍을 잘하고 프로그래머 중에서는 DB를 잘 안다고 생각한다. 각기 다른 전문가의 대화를 통해서는 충분한 정보의 전달이 어렵지만 나는 다른 컨피던스 전환시에 엔트로피 손실이 거의 없기 때문에 아마도 나에게 가장 잘맞는 프레임워크라고 생각하고 있고 아마 그래서 가장 완성해 보고 싶은 프레임워크기이기도 하다.

AL의 간단한 코드 Samle을 보면 아래와 같다. 공지사항 Application을 만든다고 생각해보자. 웹이어도 상관없고 웹이 아니어도 상관없다. 가장 첫번째 해야 할일은 모델을 만드는 일이다. 이전에는 ERD를 그리고 - 종이에 그리든 마음속으로 그리든 - ERD에 맞춰 DB 테이블을 설계한다.

AL은 DB 테이블을 만들지 않고 오직 코드로 모델을 만든다. 기존의 OR-Mapping 툴과 달리 이미 존재하는 테이블과 매핑과정을 설정하는게 아니라 아예 테이블을 만들지 않는다. 실제로 구현되는 물리적 과정은 철저히 숨겨져 있다.

공지사항 그자체도 컨텐트 - 즉 Node - 이고 공지사항에 올려지는 글들도 컨텐트 이기 때문에 2가지의 타입이 필요하다.

globalPersistence.createNodeType(objectType, "notice_board", new PropertyDefinition[0]) ;
먼저 noticeBoardType(공지사항게시판타입)을 만든다.
공지사항은 특별한 속성을 가지지 않아도 상관없어서 속성타입을 정의하지 않았다. 만약 공지사항마다 인삿말이 필요하다거나 StyleSheet를 정의해야 한다면 공지사항도 속성타입을 가질 수 있지만 위 예제는 가장 간단한 예제이므로 생략한다.

noticeProperties = new PropertyDefinition[]{.... }
속성타입을 만든다. Table의 Column과 비슷한 것이라고 생각하면 된다. 5개의 속성타입을 정의했고

noticeType = globalPersistence.createNodeType(objectType, "notice", noticeProperties) ;
5가지 속성을 가진 공지사항글타입을 만든다. DB에 비교하자면 테이블 그 자체이다.

noticeType.addPropertyConstraint(BOARDNO, new NumberConstraint()) ;
공지사항글타입에 Constraint를 정의한다.

noticeBoardType.setMemberType(noticeType) ;
공지시항타입의 멤버타입으로 공지사항글타입을 지정했다. memberType은 이미 정의된 LinkType중 하나로 공지사항타입은 공지사항글타입이나 하위 타입만을 멤버로 가질수 있게 된다.

위 코드는 타입을 만드는 과정이므로 실제로는 수명중 단 한번만 실행된다. 재시작해도 재실행되지 않아야 한다.


실제 글을 등록하고 보는 과정은 간단하다. 

private void listPage(HttpServletRequest request, NoticeForm form) throws RepositoryException {
    UserSession session = getUserSession() ;
    Node noticeBoard = session.getNode("/noticeboard") ;
    request.setAttribute(LIST, noticeBoard.getChildNode()) ;
    
    form.setRowCount((int)noticeBoard.getChildNode().getSize()) ;
    }
<List>

 private void addNotice(HttpServletRequest request, NoticeForm form) throws RepositoryException{
    UserSession session = getUserSession() ;
    Node noticeBoard = session.getNode("/noticeboard") ;
    NodeType noticeType = getNodeType("notice");

    Node article = session.createNode(noticeBoard, noticeType, form.getSubject()) ;
    article.setProperty(BOARDNO, noticeBoard.getChildNode().getSize()+1) ;
    article.setProperty(SUBJECT, form.getSubject()) ;
    article.setProperty(REGUSERID, session.getUserId()) ;
    Calendar current = Calendar.getInstance() ;
    current.setTime(new Date()) ;
    article.setProperty(REGDATE, current) ;
    article.setProperty(CONTENT, form.getContent()) ;
    
    session.save() ;
    }
<Add>

private void delNotice(HttpServletRequest request, NoticeForm form) throws RepositoryException {
    Node node = getUserSession().getNodeByUUID(form.getUUID());
      node.delNode() ;
      getUserSession().save() ;
    }
<Del>

private void editNotice(HttpServletRequest request, NoticeForm form) throws RepositoryException {
    Node node = getUserSession().getNodeByUUID(form.getUUID());
    node.setProperty(SUBJECT, form.getSubject()) ;
    node.setProperty(CONTENT, form.getContent()) ;

    getUserSession().save() ;
    }
<Edit>

private void viewPage(HttpServletRequest request, NoticeForm form) throws IOException, RepositoryException {
    Node node = getUserSession().getNodeByUUID(form.getUUID());
    node.getBean().increaseViewCount() ;
    getUserSession().save() ;
    
    NodeHandler handler = new NodeHandler() ;
    handler.saveFormBean(node, form) ;
    }
<View>


AL은 EJB3나 DB매핑류 프레임워크가 별로여서 개인적인 대안으로서의 프레임워크이다. 다만 같은 문제를 고민하기보단 문제의 영역을 바꿔버렸다. AL은 그밖에도 DB에서 하지말아야 하는 모델링을 하는등 대부분의 격언을 대놓고 반대로 하고있는 Extreme 프레임워크이다. 프로그램의 변증법에서 말했듯이 이게 하나의 과정일지 결과물이 될지는 아직 알 수 없다.

Self Reflectivity
  Boot-strapping
    - 자신이 자신을 실행한다.
    - 논리학, 전산학
 
  프로그램을 만드는 프로그램
 

Meta Congnition

  Meta ?
    - Meta Content : 컨텐트에 대한 컨텐트(ICS의 ActionField)
    - ex : 1000
     <money>1000</money>
        <money unit=“won”>1000</money>

  Meta적인 관점
    - GOF Pattern의 통찰
    - 다양한 컨텍스트에서 공통의 해결책을 가진 공통의 문제

Extreme
  Extreme ?
    - XP(eXtreme Programming : Test를 과도하게, 통합을 과도하게)
    - 갈매기 조나단
    - 숫자 0과 1의 차이, 숫자 1과 2는 ?

  양적인 차이와 질적인 차이
    - 자동차와 비행기
    - 비등점의 물
    - 양적인 차이가 질적인 차이를 만든다

Abstraction

  추상화란 ?
    - 단순화와 강조(피카소, 캐리커쳐)
    - ex) 지도

  Application의 추상화
    - Model
    - Process
    - View

AL의 필요성을 인식하기 위해서는 먼저 코드보다는 배경 사상이 먼저 이해되어야 한다. 오래전에 쓴 글이지만 원본이 없는관계로 다시 쓴다 -ㅅ-

1. 컨텐트는 타입을 가져야 한다.



2. 컨텐트는 관계를 가진다.
흔히 형사 영화에서 형사들이 여러 종류의 파일을 책상위에 짝 펼쳐놓고 담배피면서 인상을 찌뿌리는 장면을 본 적이 있을 것이다. 그때의 형사가 이마의 주름살을 지며 찾는 것은 다름아닌 널려져 있는 사건 정보들간의 관계이다. 관계는 이처럼 눈에 쉽게 보이지 않지만 매우 중요하다. RDBMS에서 관계는 속성으로 취급되는데 몇년전에 이를 좀더 확대해서 관계도 컨텐트다 라는 개념으로 접근하여 코드를 작성했었는데 수개월후 여기저기 개념상의 혼란이 많이와서 관계는 관계일뿐이고 그 자체로 의미가 있다로 수정하였다. (분석단계의 한 문장이 가지는 위력을 다시한번 체감했던 기억이다. )

3. 그룹도 컨텐트다.
보통은 게시판이라는 틀이 있고 게시글이라는 내용이 들어간다고 생각한다. 즉 틀과 내용은 구분되어 있다고 생각한다. 이제 생각을 바꿔보자. 게시판틀 컨텐트와 게시글 컨텐트는 사실 include라는 관계를 맺고 있을뿐 동일한 컨텐트라고 추상화시켜보자. 그렇게 보면 무언인가를 담는 틀 따위같은건 사실 없고 컨텐트와 컨텐트의 관계만 있을 뿐이다. 이 추상화를 통해 보면 여러 로직들이 상당히 간결해진다. 보통 게시판의 리스트와 View화면에서 댓글 리스트 모두 특정 컨텐트와 특정 관계를 가지고 있는 컨텐트의 리스트 일 뿐이다.


4. 컨텐트는 복합적이다.
3조건과 중복되는 얘기처럼 보이지만 여기서 복합적이란 한개 이상의 컨텐트가 동시에 Create되거나 Update되거나 Delete 되는  컨텐트로서 컨텐트지만 항상 다른 컨텐트의 inner컨텐트로 존재하는 컨텐트가 있다는 것을 말한다. 따라서 컨텐트가 교환될때 이를 항상 단수라고 가정해서는 안된다. 예컨데 파일이 첨부된 글의 경우 파일은 자체적인 속성 리스트를 가지고 있기 때문에 파일 자체가 하나의 컨텐트이고 글이란 컨텐트의 inner로 존재하지만 컨텐트의 교환시 항상 같이 참여하게 된다. 이러한 복합 컨텐트를 쪼개다 더이상 쪼갤수 없는 컨텐트를 Leaf 컨텐트라고 하고 Leaf 컨텐트는 속성과 속성값의 리스트를 가지고 있다.


5. 컨텐트는 참조관계수로 중요도를 측정한다.
구글의 페이지 랭크개념과 마찬가지로 컨텐트가 가지는 관계 수는 그 컨텐트의 중요도를 나타내는 지표중의 하나이다. 컨텐트는 상위 include 컨텐트를 가지고 있기 때문에 상위 컨텐트의 관계 수를 토대로 사이트의 중요도도 표시할 수 있다. (사이트도 하나의 컨텐트 이므로)


6. 관계는 타입을 가진다.
컨텐트끼리의 관계는 매우 여러개이며 이중 몇가지는 미리 지정하여 재사용이 가능하다. 예컨대 모든 컨텐트는 최상위 root 컨텐트를 제외하고 이미 존재하는 Parent 컨텐트로부터 create되는데 이때 자동적으로 parent-child 관계를 가지게 된다. 어떤 켄텐트가 다른 컨텐트를 포함하는 틀 개념이라면 이때의 관계는 include 관계라고 할 수 있다. 물론 사용자는 임의의 관계를 맺을 수 있지만 대부분의 관계는 이처럼 기 정의된 관계 타입을 사용하게 된다.


7. 관계는 동적이다.
RDBMS든 ODB든 기존에는 컨텐트간에 맺은 관계는 거의 변하지 않았다. 위키같은 프로그램이 있으니 본질적으로 이들이 정적이다라고 할 수는 없겠지만 AL에서는 기본적으로 관계는 동적이다 라고 정의한다. 어떤 타입의 컨텐트와도 관계를 맺을 수 있으며 생성시기와 상관없이 관계를 맺을 수 있다. 다시말해서 어떤 컨텐트가 생성될때 맺어진 관계뿐 아니라 이후 생존기간 내내 어느 컨텐트와도 다시 관계 설정이 가능하다는 뜻이다.


8. 컨텐트는 다중 관계를 가진다.
컨텐트가 단지 하나의 관계만을 가진다면 이를테면 이전의 게시판 컨텐트와 게시글 컨텐트는 하나의 관계만을 가진다. 그렇기 때문에 게시글은 쉽게 잊혀진다. 접근할수 있는 통로가 단 하나이기 때문이다. "Java로 구현하는 데이타베이스 아키텍쳐" 라는 책이 있다면 이는 자바 책일까? 데이타베이스 책일까? 아키텍쳐 책일까? 아니면 지하철에서 오고가며 읽을 수 잇는 책일까? 정답은 이 모든 분류에 속할 수 있다. 분류라는 것 자체가 철저히 주관적이기 때문에 하나의 분류에 종속이 되면 접근성이 극히 제한된다. 


... 아 생각이 안난다 -ㅅ-;; 몇개 더 있었는데..


간단한 Lore 창조 시나리오 코드를 보면 아래와 같다.
 public void init() throws Exception {
  AnotherLore anotherLore = new AnotherLore() ;   // 새로운 Service Lore가 창조됨
  UserSession session = anotherLore.login(new TestCredential("bleujin"), "com.bleujin.www") ;  // 사용자가 로그인
  Workspace workspace = session.getWorkspace() ;  // 작업 공간을 할당받음
  IGlobalPersistence globalPersistence = workspace.getGlobalPersistence(); // 공용 작업공간을 가져옴

  NodeType object = globalPersistence.createNodeType(NodeType.NO_SUPERTYPE, "_object", new PropertyDefinition[0]) ;  // 0개의 속성타입을 가지는 최상위 노드타입 생성
  Node root = session.createNode(Node.NO_PARENT, OBJECT_TYPE, "/") ;  // 최상위 노드 생성
  session.save() ;
 }

스팸 필터, 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은 자체가 서비스인 메타 서비스이므로 좀더 도메인에 치중되어 있다.