Warning: Unexpected character in input: ''' (ASCII=39) state=1 in /webroot/libs/skin/post_widget_data.php(976) : eval()'d code on line 1 Parse error: syntax error, unexpected T_STRING in /webroot/libs/skin/post_widget_data.php(976) : eval()'d code on line 1 calmglow (최진호)

adsense(728_90)


프로젝트 셋업 Programming

요새 새로운 프로젝트를 시작하느라 프로젝트 셋업을 준비중이다. 새롭게 시작하는 만큼 더 나은 시스템과 프레임워크 그리고 기술을 이용하여 이제껏 팀원들이 느껴온 여러 문제점을 해결하고 싶었다.
아무튼 코딩 스타일이나 주석 스타일부터 네이밍룰 등등을 정하면서 그 외 프로젝트 셋업에 필요한 게 무엇이 있을까 이곳 저곳을 둘러보았다.
먼저 이번 프로젝트는 EJB기반하에서 개발될 예정이기 때문에 이전 EJB기반 프로젝트에서 겪어야 했던 잦은 Application Server Deploy에 의한 번거로움과 시간 낭비를 줄이고자 Mock Object기반 테스트 툴을 알아보았다.
가장 쓸만한 것은 MockEjb라는 툴로써 DB 테스트나 세션빈 테스트까지 지원이 되지만 애석하게도 Entity Bean이 아직까지 제대로 지원되지 않았다. 때문에 반쪽짜리 테스트를 하느라 MockEJB를 믿고 쓰느니 안쓰는 것이 낫겠다는 결론을 내었다. 대신에 Mock Object기반 테스트는 아니고 Container-In 방식의 테스트 툴인 Cactus를 아쉬운 대로(?) 도입하여 사용할까 생각중이다.
애초에 기대했던 deploy에 의한 부하를 막는 데에는 도움이 안되겠지만 보다 확실한 테스트가 가능할 것이므로 이것저것 테스트하느라 걸리는 시간을 조금은 줄일 수 있을 것이다. 자동화된 빌드를 위한 툴도 찾아보았다. 막강 Ant를 사용하였으나 요 근래 Maven이라는 빌드툴이 뜨길 래 자세하게 살펴보았다.
Maven은 이를테면 Ant를 개량하여 보다 쉽게 자동화된 빌드를 가능하게 하면서 고수준의 자동화된 플러그인을제공하는 툴이다. 여러가지 기능을 제공하는 데 이를테면 라이브러리 종속성을 관리하여 버젼별 빌드가 가능하고 주로 많이 쓰이는 Ant에서의 Task들이 Maven에서는 Goal이라는 형태로 특별한 수작업없이 바로 사용이 가능하다(컴파일 패키지 문서화 clean 등등등). 또한 자동화된 단위 테스트 기능도 훌륭하고 프로젝트의 현 상태를 바로 바로 비주얼하게 확인할 수 있는 프로젝트 사이트 자동 생성 기능도 매우 훌륭하다 하겠다. 그 많은 장점에도 불구하고 아직까지는 조금 불안한 모습을 보이는 것이 사실이며 실제로 이번 프로젝트의 경우 이클립스를 기반으로 개발되는데 MavenIde라는 좋은 툴이 있기는 하지만 아직 걸음마 수준이어서 이 것 믿고 지금 당장 프로젝트를 진행하기는 어려울 것 같다. 결국 Ant의 수많은 확장 Task들을 충분히 활용해야겠다고 결정하였다.

가장 결정하기 어려운 문제 중의 하나는 웹 프레임워크이다. 비록 몇몇 프로젝트에서 Struts가 요긴하게 사용되고 있기는 하나 저번 프로젝트에서도 일부분에 이 Struts를 실험적으로 구현해봤지만 아무리봐도 정이 들지 않는 프레임워크이고 팀원들도 그다지 좋아하지 않는다. 우째 그리 복잡한 건지... 그래서 보다 직관적이면서도 Layering이 잘되는 웹프레임워크는 없을지 찾아보고 있으나 딱히 입맛에 맞는 것이 보이질 않는다. 아직 Cocoon 쪽은 손대보질 않았는데 괜찮으려는지.... 이 블로그를 읽으시는 분들 중에 추천할만한 웹프레임워크가 있으면 제발 Comment 부탁합니다....

공유하기 버튼

 

Framework for Web Services Implementation (FWSI) Enterprise

그저께 30일에는 오아시스에서 Framework for Web Services Implementation (FWSI)라는 TG을 만들었다고 발표했다. 참여 업체는 Sun, 로제타넷, 홍콩대학, Yellow Dragon 등등이 있다. 즉 웹서비스 구현물을 개발할 때 지침이 될만하며 상호운영성을 맞출 수 있도록 기본적인 프레임워크를 제안하려는 TG인데 말을 좀 바꾸면 결국 웹서비스 구현물의 상호운영성을 위한 프로파일을 만든다는 의미이고 이건 결국 WS-I의 몫이었기도 하다. 그것도 같은 오아시스 내에서 비슷한 일을 하는 Group이 두 개가 있다는 건 오아시스는 아무튼 어떻게든 기업들 눈치만 보려는 건 아닌지 싶다. 물론 오아시스는 두 TG는 상호보완적인 관계라 이야기한다. WS-I는 웹서비스 구현물을 개발할 때 참조할만한 기능적인 요구사항을 제시하며 구매자는 자신이 구매하는 제품이 어떠한 수준의 상호운영성을 만족하는지 확신할 수 있게 하며 FWSI는 제품을 개발할 때 참조할만한 구체적인 구현 블럭을 제공한다고 한다. (대체 그게 뭐지? -_-;;) FWSI의 뼈대가 되는 구현물은 Java Smart Services Lab라는 곳에서 만든 WSRA라는 건데 아무튼 그걸 가지고 WS-I와는 다르게 좀 더 구체적으로 웹서비스 표준 프레임워크를 새롭게 만들려고 하는 듯 하다. 그러고보니 요즘 WS-I 소식 안들린지 오래인데... 내가 무관심했던 건가? 자 이제 이 TG의 그룹 구성원을 보자. 프레임워크의 바탕이 되는 것이 싱가폴에서 만든것이니 그쪽에서 참여하는 것은 그렇다쳐도 다른 회사들 보면 그다지 웹서비스 냄새 풍기는 곳 별로 없다. 오히려 웹서비스 보다는 기존에 ebXML하던 단체들이 더 많은 것을 볼 수가 있다. Yellow Dragon이나 홍콩대학 그리고 로제타넷 등등. IBM이나 MS, Oracle,HP등은 하나도 없다. 사실 이러한 프레임워크를 만드는 단체의 구성원은 일단 빵빵한 기업에서 나온 이들이어야 하는데 그닥 파워가 느껴지지 않는다. 그 의도는 잘 모르겠지만.. 그다지 이 TG의 앞으로의 행로가 희망적으로 보이지는 않게 된다. -_-;;;

공유하기 버튼

 

위키중독 IT

나는 요피라는 편리한 PDA를 항상 휴대하고 다닌다. 잠을 잘 때에도 가장 가까운 곳에 두며 어딜 가더라도 이 요피만은 꼭 휴대한다. 그도 그럴 것이 요피에는 노스모크판 위키위키가 설치되어 있어서 나의 거의 모든 기억들을 담고 있기 때문이다. 개인용도로 유용하게 사용하고는 있지만 나의 그 위키 중독이란 종종 너무 심하다 싶을 때가 있다.
우선 출근할 때 지하철에서 신문 한 두개를 읽고 사무실에 도착하면 먼저 그 날 읽은 신문에서 쓸만한 기사나 정보를 위키에 저장한다. 출근해서 서핑하고 메일을 탐색하는 족족 유용한 정보의 경우도 물론 위키에 저장하며 그날 해야할 일을 결정하고 지난 일을 돌아보며 하루 일과를 예측하는 데에도 위키를 사용한다.
내 위키에는 심지어 이제껏 내가 받아온 연봉내역과 연말정산 내용도 있으며 괜찮다 싶은 보고서나 제안서 양식이나 회의 요약자료도 있고 라면 맛있게 끓이는 100가지 방법과 개인적으로 노래방에서 부르고 싶은 노래 목록도 있다. 어제는 한 후배를 서울역에서 잠깐 만날 일이 있어서 전화통화를 했는데 만날 곳을 정하는데 서울역 어느 출구가 가장 적당한지를 알지 못하여 난처하였다.

나는 그 즉시 인터넷에서 서울역 및 내가 자주 들리는 지하철 역 정보를 알아내어 자세한 출구 정보와 첫차 막차 정보를 위키에 입력하였다. 오늘은 예비군훈련 문제로 동네 예비군 중대본부에 전화걸 일이 있었는데 어김없이 중대본부 전화번호를 기존에 위키에 있던 중대본부 근처 사회복지관 페이지를 연결시켜 위키에 저장시켰고 기존의 페이지를 탐색하여 중대본부관련 키워드가 나오는 페이지를 찾아서 링크를 걸어두었다.
이쯤되면 거의 결벽증에 가까운 위키중독이 아닐런지... 하지만 그래서 핸드폰보다 조금 더 큰 이 요피라는 PDA가 나에게는 더없이 유용하고 없어서는 안될 제2의 기억장소다.

공유하기 버튼

 

웹서비스 게이트웨이란? Enterprise

웹서비스 관련 문서를 찾다보면 참 별의별 희한한 개념을 많이 만난다. 웹서비스 게이트웨이란 클라이언트가 원하는 웹서비스에 접속하기 전에 보안이나 트래픽 등의 내용을 미리 제어하는 웹서비스의 게이트웨이란다.

일종의 방화벽 내지는 프록시서버라고 볼 수 있겠는데 내부에 많은 웹서비스가 정책이 변화되거나 생멸을 반복한다면 과연 게이트웨이가 내부 웹서비스의 보안정책을 반영하여 외부 요청을 처리할 수 있을지 그리고 그렇게 일괄적으로 내부 웹서비스의 보안정책을 처리하는 것이 옳은 건지는 좀 더 생각해봐야할 것 같다.

공유하기 버튼

 

자바 바인딩 툴 비교 Programming

XML 스키마와 자바 객체와의 변환은 생각보다 쉬운 작업은 아니다. 때문에 완벽하지 않은 변환기능이나 불편한 인터페이스 구조가 만들어질 경우 XML문서와 자바 객체와의 삐걱꺼림은 개발 내내 골치를 앓게 하는 중요한 요소이다. 2년 전부터 팀 내에서 주로 사용하던 바인딩 툴은 Castor였다. JAXB는 그 당시만 해도 DTD만을 겨우 제공하던 초보수준이었고 오픈소스로 쓸만한 것은 Castor뿐이었다. 하지만 많은 시간이 지났고 이번의 벤치마킹을 보고서 그동안 자바 바인딩쪽 툴에 관심을 기울이지 않았음을 깨달았다. XGen이라는 훌륭한 바인딩툴이 태어났음을 이제껏 몰랐다니... 벤치마킹 비교 기사

공유하기 버튼

 

웹서비스 Reliable Messaing의 모든 것 Enterprise

RM에 대해 이렇게 자세하게 다룬 문서는 본적이 없다. 꼭 필독! RM

공유하기 버튼

 

Apache 프로젝트 Geronimo Programming

Apache에서 Geronimo라는 J2EE 컨테이너 개발 프로젝트를 계획하고 있다. 주요 참여자는 JBOSS 개발자이지만 실제로 JBOSS 소스코드를 기반으로 하지는 않을 것이며 APACHE 프로젝트에서 나왔던 여러 구현물을 포함하는 형태로 갈 것이라고 한다. 하지만 J2EE 컨테이너를 개발하기에는 너무 늦어버린 것이 아닐까 하는 우려를 한다. JBoss는 그 개발 방식이나 저작권등에서 대표성을 띄는 J2EE 컨테이너라고 보기에는 어려운 점이 있었다. 그런 점에서 보았을 때 Apache의 이 늦은 대응은 일면 환영할만 하지만 이미 다른 J2EE 컨테이너가 컨테이너 자체의 성능 경쟁을 벗어나 웹서비스나 기타 여러 EAI관련 솔루션과 IDE를 결합한 형태의 토탈 솔루션 적인 형태로 진화하고 있는 현 시점에서 너무 늦은 선택이 아니기 바란다.

공유하기 버튼

 

이전 51 52 53 54 55 56 57 58 59 60 다음


Google Analytics