Monthly Archives: December 2013

Spring에서 Redis사용하기

의존성부분. springdata만 넣으면 jedis는 알아서 들어가니 따로 넣어줄 필요는 없다.

스프링에 레디스 설정 넣기

스프링은 자동으로 스트링앞에 잡문자를 붙인다. 이종언어간 통신하는데 방해된다. 이걸 없애려면 위의 처리가 필요.

펍섭/키밸류스토어는 접속을따로하니별도설정

redis.clients.jedis.JedisPubSub abstract클래스가 있다. 이걸 구현.
JedisPubSubLocal extends JedisPubSub처럼했다

그리고 그냥 실행.

Postgresql – ,로 구분된 키값으로 조인

다음 사이트들을 참고해서 해겷했다.
http://stackoverflow.com/questions/8584967/split-comma-separated-column-data-into-additional-columns
http://stackoverflow.com/questions/11730777/postgres-not-in-array
http://stackoverflow.com/questions/10738446/postgresql-select-rows-where-column-array
나머지는 진짜 참고만 했고 첫번째 링크에 솔루션이 있다.

테이블 두개…

admin_ids가 문제다. 배열이 아닌 문자열형태로 ,구분자로 저장…
m-n조인을 하는것도 좋지만… 편의를 위해서 저렇게 하는 경우가 자주 있다.

이런경우에 조인을 하려면…
설명 생략하고 테스트과정을 순차적으로 다 써놓는다.
나야 보면 생각나겠지만… 다른사람들도 순서대로 실행시켜보면 뭔지 알 수 있을거다. 아마…

내용 변경했으니까 그냥 막 올려도 되겠지??? 아닌가…

NextWebFramework 3. 뷰단의 구조

View단에서 사용가능한 REST Client.

Engine에서 DB2API가 자동으로 지원되게 하는 부분은 간단히 구현이 가능하다.
그렇다면…. thrift를 쓸까 어쩔까 하던… 웹/모바일/…등등등에서 이 API or RPC를 직접 호출하기 위한 방법…?

자바스크립트에서 간편하게 사용 가능한 REST Client가 존재한다면…?
이 부분을 Thrift에서 처리할 생각이었지만 더 간단한게 있다면… 적용할만하다는 생각이 들었다.

그리고 그 기반기술이 될만한것들…
https://github.com/garycourt/JSV
Json Validation라이브러리. 이거 조금 적용해서 도메인 구조를 json으로 정의하도록 만든다.
https://github.com/jashkenas/backbone/
js 모델 라이브러리
http://abaaso.com/
REST관련 라이브러리

프레임워크의 생산성 향상을 위해서는 전용 ide가 필수적인데… json기반으로 도메인을 정의한다면 웹쪽의 ide는 별도로 개발이 필요하지 않게 된다.

그래도 묶음배송기능, 로컬AJAX에서 외부 리소스호출을 위한(크로스도메인땜에) 인터페이스같은건 따로 개발이 필요하긴 하다.
좀 큰 부분은 해결된듯하다.
회사때리치는 일만 남았다.

VCS svn,git ignore셋팅 샘플

Subversion(svn) property
svn:ignore

 

Git

{GIT_ROOT}/.gitignore

 

NextWebFramework 2 : 다언어 모듈분산형 웹개발 프레임워크

프레임워크라는 말이 어울리나.. 아키텍처라고 해야할까

장점 : 멀티플랫폼 개발시, 다양한 언어로 대규모서비스 개발시, 병렬확장구조 개발시

단점 : 성가실수있다

– 필요한것

1. 각 모듈간 호환되는 도메인 정의가 필요하다. 예를들자면… Avro? 그런데 Avro도 이종언어간 통신시에 문제가 발생하는 경우가 있다. avro생성기는 Python의 숫자형을 Java의 Int형으로 변환을 시키는데 이 경우 자릿수가 달라서 Python->Java 방향으로 전송시 오류가 발생한다.

2. Model부분 간소화. rails와 같은 getUserByUsername, getUserByAddress같은 명령이 자동으로 생성되야한다. 자동이 안되는 부분은 model에서 수동으로 처리해야하니까….
ORM의 경우 rails처럼 자동으로 메서드 생성이 안되기도 하고 명확한게 좋기도 하고 자바에 다들 익숙하기도 하니까…. selectQuery(table(by(columns…), joinColumns(…)) …)같은 형태면 어떨까 싶다. V-E-M 구조를 사용할 경우 View설계와 함께 도메인 설계 다음에 테이블 설계가 먼저 이뤄진 상태일테니….
QUERY의 경우 select * from Users u, Board b where u.id = b.user_id; 와 같은 쿼리를 넣고 이름을 정하면 이 요청에 대한 응답은 자동생성….이 되야하는데 데이터 타입이 애매하니 avro나 각 언어 코드로 도메인을 같이 설정해줘야할것같다. 구현은 mybatis를 사용하면 간단. 다른 언어의 경우에는 비슷한 방법을 찾아보도록 해야겠다. 조인데이터의 경우에는 insert, update는 지원되지않고 각 테이블별로 자동으로 생성되는 insert,update코드를 사용하도록 한다.

3. Engine은 MVC모델에서 Service단 역할을 하는데 이 경우 Model의 데이터를 Direct로 필요로 하는 경우가 많다. 이런 처리를 위해서는 pass 자동화 필요. pass의 경우에는 Engine을 거치지 않고 Model로 요청. 각 테이블이 MQ의 채널이 된다면 Engine으로 매핑된 테이블과 엔진으로 매핑된 테이블을 분리시킬 수 있다.

4. Engine부분이 분리되어있기 때문에 View에서 Cross도메인 제약때문에 js만가지고 코딩을 하기는 힘들다. View와 함께 있는 php코드라면 요청 라이브러리를 지원해서 메서드를 호출하게 해서 직접 호출하고, java의 경우에는 controler를 자동으로 생성해주도록 한다. thrift에서 이 부분이 자동화되던데… 좀 고려해봐야겠다.

5. 각 모듈간의 보안..MQ를 쓰는 경우 여기 의존하도록 한다. 직접 통신하는 경우에는 … 설정값 중앙화 라이브러리를 추가로 만들어야하지 않을까…?

6. 모듈분리로 인해 통신포인트가 많아져 속도상에 문제가 발생할 가능성…
있긴한데… 클까? WAS-DB(1개)에서 View-MQ-Engine-MQ-Model-DB(5개)로 늘어난다.
요즘 웹페이지가 예전처럼 단일호스트단일페이지가 아니라 로그인하고 화면을 보여주는데도 리소스서버WAS인증서버등등을 거치게 되는것을 고려한다면 뭐 별로 커지는건 아닐지도 모르겠다. 다중 ajax요청을 묶음배송기능을 추가한다면 이 부분을 커버가능하겠다. 그런데 ajax묶음배송기능을 그냥웹에서도 쓰게될텐데…..

 

만들것 :

ajax묶음배송기능.

ajax용 controller 자동생성기능. javascript에서 도메인 설정을 해놓으면 거기에 맞게 자동으로 처리되도록… thrift 사용을 심각하게 고려.

Model자동화기능. 테이블을 스캔해서 domain파일을 자동생성해주는 기능은 필수. 만들어본적은 있는데… 디비마다 값이 다를 수 있어서 내가 쓰는 디비만 만들고 나머지는 설정파일을 추가해서 사용하도록 변경필요.

 

NextWebFramework 1 : 무거운 프레임워크와 복잡한 테스트

요즘 웹 프로젝트는 사양이 상당히 좋은 컴퓨터로도 가동시키는데 30초? 조금 안좋은 컴퓨터로 하면 1~2분 무거운 프로젝트라면 5분까지 걸리기도 한다.

어마어마하다.

화면하나 고치고 테스트를 해보려면 5분을 기다려야 할 수도 있다. 동적으로 로딩이 되지만… 무거운 프로젝트라면 이조차도 버겁다. 로딩하다가 Pergem어쩌고 하면서 멈춰버린다. 그러면 재시작을 해줘야하니까….

그래서 사용하는게 Unit 테스트…. 그런데 View는 어쩔건가

별수없이 서버를 올려야된다.

아니면 가벼운구조로 새 프로젝트를 생성하고서 테스트를 하거나…  뭐 어쨌든 저쨌든 귀찮은 과정을 거쳐야만 한다.

자바는 너무 과도하게 무거워졌다. 루비도 몇번 돌려보긴 했는데 역시 마찬가지다. 서버 올리는데는 조금 시간이 걸린다. html테스트하는것처럼 바로바로 로딩이 되질 않는다.

이건 확실히 문제가 있다.

 

이 부분을 개선하기 위해서 필요한 것은 역시 모듈화.

그렇다면 어떤 구조로 나눌것인가가 문제가 된다.

 

1. SSO 를 중심으로 각 기능별로 웹사이트를 나눠버린다.

2. View / Controller / Service / Model / DB 의 방향으로 각 모듈별로 나눈다.

1번은 흔히 사용되는 방식으로 프로젝트의 크기를 적절히 분할한다면 효과적인 방법일 수 있다.

그런데 개인적으로 2번의 방법을 시도해보고싶었다. 이유는 간단하다. 2번이 더 간단하고 더 가볍고 효율적이다. 다만… 적절한 아키텍처가 제시되지 않고 있다. (찾아봤는데 없어서 없다고 단정지었다)

 

2번의 방법을 View-Engine-Model 구조로 정의한다.

VEM(가칭)

각 업무담당자별로 모듈을 나눌 수 있다는게 장점이다. 협업을 줄여서 각 모듈간의 충돌을 최소화한다.

설계단계는 별로바뀌는게 없을 것 같다. 기획이 나오고 개발자와 회의를 거쳐 구현이 가능한지를 결정한 다음 스토리보드를 뽑아낸다. 도메인모델과 디비도 이 단계에서 어느정도 설계가 될거고.

이 모델의 강점은 여기있다. 뷰단계에서 데이터가 들어있는 것처럼 화면을 동적으로 보여줄 수 있다는 점.

입력할 데이터를 미리 정의된 프로토콜형태로 text로 저장시켜놓은 후 화면단코드(자바스크립트,css등)을 수정하면서 바로바로 확인하며 코딩이 가능하다.

대략이런식으로 매핑이 되게 할 수 있다.

현재 나와있는 jquery , angular 등의 JS라이브러리로 구현이 가능할것으로 보인다. 이 부분은 조금 더 검토필요…. 화면단은 좀 덜해봐서

어쨌든 데이터를 기다리지 않고 화면단의 변경이 가능하다는 점이 가장 큰 장점이다. 일반 SI회사에서 가장 요구사항 변경이 잦고 고객사에서 귀찮게 하는 부분이 이 화면단인데 이 부분에 대해 초기대응이 가능하고 변경이 적어진다는 것이 장점이다.

보안이슈가 있는 경우에는 view쪽에서 사용자 인증 필터를 깔아야되는 경우도 있을 수 있다.(있을수도 있다가 아니라 대부분 경우-필요없는데서도- 이런 요청을 하지 않을까 싶다. 인증시스템은 기존에 만들던대로 만들면된다.)

 

View – Engine간의 연결

Ajax와 RPC.

언어에 따라 달라지겠지만 표준은 ajax와 rpc가 될 것이다. 화면과 로컬서버간에 ajax로 통신을 하고 ajax로 데이터를 가져오는 것은 cross domain제약이 있기 때문에 rpc를 이용해 통신을 하도록 한다. 쓰리프트의 경우 js도 지원을 하기 때문에 더 편리?하게 사용이 가능할지도 모르겠따. 생각해보니 쓰리프트 js거치는게 이것과 비슷하게 생성이 됏떤것같다.

앞의 화면코드에서 User배열을 json형태로 받았는데 이 부분은 다음과 같은 파라미터를 전송해서 호출한다.

묶음배송기능. ajax호출시 여러개의 데이터를 한꺼번에 호출하는 경우가 많은데 이 경우 RPC에 부하가 크기 때문에 묶음배송기능이 필요하다. 그래서 파라미터는 배열로 전송한다.

request : [{메서드명, 데이터(테이블 or 도메인)명}, {} …]

response : {{rpc상태메세지}, {data}, {data}}

response Set 첫번째 데이터는 상태메세지다. Set이지만 텍스트형태니까 앞쪽에 포함시키면 앞쪽이 된다.

각 domain이 가공되는 형태는 pre/post handler resolver 등을 붙여서 후처리 가공할 수 있도록 지원한다.

화면단에 보일 데이터의 형태인 도메인과 디비에 저장될 테이블은 같은 형태가 아닐 수 있다. 화면단에서는 완성된 vo를 호출하기 때문에 뷰에서 필요로 하는 데이터를 쿼리만 입력하면 완성된 데이터로 출력을 해 준다. 이 부분에 대해서는 api를 만들면서 만들어본적이 있으니 간단할듯 싶다.

 

Model : Engine부분과 굳이 분리할 필요는 없다. 합쳐지는게 더 효율적이지 않을까

ORM을 사용할 경우 Engine에 상당부분 포함될 수 있다.
ActiveRecord 생각하다보니 Rails구조가 떠올랐는데….
이 구조가 왠지 레일즈와 닮은것같다.

ORM을 써도 그냥 쿼리를 넣을 경우에는 그냥 쿼리로 뽑아볼수도 있어야한다.

 

이걸 분리시키면 너무 복잡하니 그냥 View-Engine Structure로 하는게 나을것같다.

구체적인 아키텍처는 다음번에 이어서.

Maven메이븐 이용시 라이브러리 관리 주의해야할 점

http://stackoverflow.com/questions/7064269/the-method-getjspapplicationcontextservletcontext-is-undefined-for-the-type-js

이번 경우는 jsp-api때문이었다.

2.2와 2.5버전에서 변경된 메서드때문에…

이번경우는 joda time에서 jsp-api를 참조하는바람에 다 제외시켜놓은 jsp-api가 지맘대로 포함이되서 문제가 생긴 경우다. 톰캣7에서 문제가 발생한다.

그런데 더 문제는 이클립스에서는 문제가 안 생기다가 서버에서만 문제가 발견된다는거.. 이 경우에는 참 성가시다. 서버로그를 확인해야 되서

jstl, jsp 관련 jar파일은 맨날 문제를 일으키니 미리미리 관리해놓는게 좋다

jsp-api를 provided로 묶어놓으면 괜찮을까 했는데 ..쪼다놈이 2.0파일을 끌어다놓는다.

2.2를 dependency에 넣었는데 왜 2.0을 또 끌어들이나… 메이븐 관리체계에 좀 문제가 있긴하지만 뭐 그래도 잘 설정해놓으면 쓰기는 편하니…하나하나 찾아서 제외시켜야지 뭐 별수없는듯…

joda 1.1은 jsp-api를 참조하지않는다.

Tomcat7 Virtualhost 설정

apache, nginx등과 연결할 때 사용하면 좋다.

서버 한개에 여러개 호스트를 띄워야 하는 경우..(홈서버나 소규모 사무실일듯)

<Host name=”api.beansugar.org” appBase=”webapps/ApiProvider”
unpackWARs=”true” autoDeploy=”true”
xmlValidation=”true” xmlNamespaceAware=”false”>
<Context path=”” docBase=”” reloadable=”true” privileged=”true”
antiResourceLocking=”false” anitJARLocking=”false”>
</Context>
</Host>

</Engine>
</Service>
</Server>

server.xml에 이런식으로 설정을 추가하면된다. 보안에 상관없는 부분이라 그냥 공개…

톰캣 설치시에 기본으로 깔려있는 host-manager기능을 사용해도 되겠지만…. 자주 쓰지도 않는 manager같은것들도 다 톰캣 메모리를 잡아먹으니.. 그런거 다 지워버리고 직접 하는게 낫다.

자바웹앱이 의외로 메모리를 많이 먹어서 하이버네이트앱같은거 실행시키면 메모리릭나서 다운되는 경우도 많으니…

 

자바Java Generic제네릭 콜백Callback 사용시 T.class를 대체Alternative하는 방법들…

결론 : 메서드의 파라미터로 받는다.
T가 있는데 굳이 파라미터로 새로 받으려면 좀 갑갑하지만… 괜히 두번하는것같아서 하기싫지만 현재 이 방법이 가장 좋은것 같다.

토끼 메세지큐 사용중..

위 구조로 만들었는데…. 메세지 프로토콜을 json형태로 정했는데…

 

위에놈을 가지고 jsonString을 domain으로 만들려고 하니 문제가 생기는거다.

T t = (T)JSONObject.toBean(jsonObject, T.class);

를 쓰고싶은데 안되니까… 그래서 콜백에 메서드를 한개 추가해줬다. getThis() 위의 소스코드는 밑의 메서드가 포함되어있다.

T t = (T)JSONObject.toBean(jsonObject, callback.getThis());

그럼 제네릭될때 처리된다.

까먹을까봐…. 그리고 아무나 참고하시라고 써놓는다
제목에 영어와 한글을 섞는건 검색하기 쉬우라고