허허허허~
크라켄은 미들웨어랑 응용프로그램만 있다고 할 수 있겠네여~~ 뭐가 되든 자바로 보안 솔루션 개발하게 되면 크라켄 프로젝트에서 제공되는 다양한 번들의 기능을 이용해서 쉽게 개발할 수 있겠져 허허허허..
사람들이 안드로이드 플랫폼이라고 하면 이해(?)하는데 왜 크라켄은 이해 못 하지~~
사실은 안드로이드도 이해한다고 믿고 싶은거겠지~~~
가령 안드로이드는 이렇게 써있어여~~
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
크라켄이 돌아가는 방식을 이해하려면 OSGi를 대충 알아야 되는데.. OSGi 프레임워크에서는 번들(JAR)을 동적으로 설치할 수 있고 버전 관리가 되고 서비스 레지스트리가 있어서 인터페이스 이름으로 서비스를 등록하고 가져다가 쓸 수 있게 되어 있기 때문에.. 인프라 서비스라고 할만한 것들이 각자의 서비스를 인터페이스로 노출하고 응용 프로그램 개발자는 이걸 그냥 가져다가 쓰면 되지여 허허허허..
그런데 OSGi 규약을 다 이해하고 프로그래밍하기가 어려울 수도 있고 귀찮기도 하기 때문에 iPOJO를 쓰고 있는데.. 이걸 쓰면 OSGi API를 안 써도 어노테이션이나 XML로 설정만 걸어놓으면 자동으로 인터페이스에 서비스 인스턴스를 물려준다는 거에여 허허허허.. (외부에서 인스턴스를 밀어넣기 때문에 보통 인젝션이라고 표현함)
그래서 크라켄은 OSGi 번들(= OSGi 메타데이터를 MANIFEST에 포함하고 있는 JAR)이기만 하면 아무거나 돌릴 수 있는 유니버셜 플랫폼인거에여 허허허허.. 다만 우리가 보안 솔루션 개발을 하기 때문에 그쪽 도메인에 치우쳐서 라이브러리 개발하고 ESM 같은 key application을 만들고 있기 때문에 보안 플랫폼이라고 떠들고 있는 것이에여 허허허허..
지금 개발되고 있는 모듈들을 보면 벌써 많이 뿔었는데.. 물론 아직 정식 외부 공개(소개) 안 된 것들이 대부분이긴 하나..
- kraken-api: 크라켄 콘솔 명령 확장에 필요한 API를 담고 있음
- kraken-core: Felix 프레임웍을 포함하고 OSGi 번들 설치 관리 등 기본 기능만 있는 플랫폼 엔진
- kraken-filter: 런타임에 동적으로 연결하거나 끊을 수 있는 필터 파이프라인 구현체
- kraken-ipojo: iPOJO 관리용 스크립트만 들어있음 (iPOJO 팩토리나 인스턴스 목록, 컴포넌트 유효성 확인 등)
- kraken-jpa: Hibernate 기반으로 OSGi 환경의 JPA 서비스 구현 (OSGi 환경에서는 여전히 건드리기 골 때리는 물건..)
- kraken-cron: cron 서비스를 제공하므로 주기적인 작업을 쉽게 구현할 수 있음..
- kraken-dns: 맨바닥에서 구현한 DNS 클라이언트 (서버 구현은 없음)
- kraken-http: jetty로 구현된 HTTP 서비스 (OSGi HTTP Service 호환됨)
- kraken-jpcap: jpcap을 OSGi 번들로 컨버팅만 해놓은 녀석
- kraken-json: json.org에 있는 JSON 파서를 OSGi 번들로 컨버팅만 해놓은 녀석
- kraken-mac-lookup: MAC OUI만 가지고 벤더 이름과 주소 등 조회 가능함
- kraken-pcap: pcap 파일을 로딩하여 L3/L4 디코딩 가능
- kraken-rrd: RRD를 OSGi 환경 기반으로 구현 중 (jrobin 아님)
- kraken-rss: RSS 리더 구현됨. 크라켄 콘솔에서 RSS 볼 수도 있음.
- kraken-snmp: SNMP4J를 OSGi 번들로 컨버팅만 해놓은 녀석
- kraken-syslog: Syslog 수신/송신 가능한 번들.. 크라켄 콘솔에서도 syslog 트레이스 가능
- kraken-xmlrpc: XMLRPC 프로토콜 파서 구현한 것
- kraken-text-servlet: 특정 어노테이션을 메소드에 붙이면 즉시 웹으로 텍스트 데이터 서비스 가능
- kraken-xml-servlet: 특정 어노테이션을 메소드에 붙이면 즉시 웹으로 XML 데이터 서비스 가능
- kraken-xmlrpc-servlet: 특정 어노테이션을 메소드에 붙이면 즉시 웹으로 XMLRPC 서비스 가능
- kraken-json-servlet: 특정 어노테이션을 메소드에 붙이면 즉시 웹으로 JSON 데이터 서비스 가능
- kraken-csv-servlet: 특정 어노테이션을 메소드에 붙이면 즉시 웹으로 CSV 데이터 서비스 가능
- kraken-esm: 관제시스템의 핵심 인터페이스와 관련 레지스트리가 모두 구현되어 있음
- kraken-lc-openssh: openssh 로그 수집기 (esm 구현에 맞춰서 수정 중)
- kraken-lc-snort: snort 로그 수집기 (esm 구현에 맞춰서 수정 중)
가령 Runnable 인터페이스 구현해놓고 클래스 위에 @HourlyJob 이라고 어노테이션만 박아놓고 컴포넌트 인스턴스 하나 생성하도록 XML 설정만 해놓으면 자동으로 Cron 스케줄러에 등록되고 매 시간마다 해당 작업이 실행되는거져~ 이런 식이라 아직 일반인 입장에서는 직접 개발을 안 하므로 왜 편한지 이해하기 힘듬.. 나중에 애플리케이션이 UI 까지 붙어서 나오면 그제서야 좀 쓸만하네 소리가 나오겠져~
내년 말 정도 되면 kraken-esm과 연동되는 로그 수집 모듈이라든가 여러가지가 수십 개씩 붙어서 겉으로 보기에 규모가 한 3배 정도는 될텐데.. 지금은 뭐 흠.. 개발해야 될 게 다른 것도 많으니까.. 하지만 역시 널리 사용되려면 UI가 붙어있는 애플리케이션이 나와줘야 되는데 별도의 오픈소스 팀이 붙지 않는 이상 어렵지 않을까 뭐 그런 생각... (내 보기엔 UPnL 정도가 아니면 안 될거야 아마..)
아무튼 지금까지 설명한 것처럼 돌아가기 때문에 예전에 만들었던 에어스캔이나 와치캣이나 말린 서버나 기타 등등 모두 동일한 코드베이스로 개발된다 뭐 그런 얘기.. 커스터마이징 하더라도 웬만하면 브랜치를 따로 낼 필요가 없으므로 후반으로 갈수록 유리함..이라고는 하지만 그 때까지 버틸 수 있다면 좋은 얘기~~ (구현이 거지같더라도 빨리 만들어서 제품 팔면서 회사를 유지하는 경우가 대부분인 이유가 뭐 뻔한거 아니겠음..흠..)
혹시나 회사가 망해도 크라켄은 남겠지.. (..희망사항일까..)
Commented by xeraph at 2009/11/24 23:24 Commented by xeraph at 2009/11/24 23:38 Commented by xeraph at 2009/11/25 15:12 Commented by xeraph at 2009/11/25 21:07 Commented by frankly at 2009/11/25 22:00 
Commented by xeraph at 2009/11/25 22:05 Commented by frankly at 2009/11/25 22:22 Commented by xeraph at 2009/11/25 22:35 Commented by xeraph at 2009/11/27 17:46 Commented by xeraph at 2009/11/30 22:00 Commented by xeraph at 2009/11/29 00:58 Commented by 렘렘 at 2009/11/29 20:32 Commented by xeraph at 2009/11/30 21:57
