블로그 이미지
bro.Yobi

Rss feed Tistory
CSE/etcetera 2010.10.26 22:01

treebuilder


.
CSE/etcetera 2009.04.16 00:59

com(com+), RDS 그리고 .NET에서의 SOAP,WSDL

오랜만에 CSE카테고리에 글을 쓰게 됐다.

코드의 재사용성과 interoperability를 위해서 COM이 개발된것 같다. 또 기존의 MTS가 제공했던 트랜잭션 관리와 풀링과 DCOM의 개념이 합체해서 COM+이 나왔다. 
수백 개의 아주 복잡한 비즈니스 로직들이 그물처럼 뒤엉켜 있고, 이들 관계내에서 트랜잭션 처리도 해야하는 상황에서 사실  COM+은 아주 편리한 도구이다. COM+가 없었다면 아마도 전체 비즈니스로직을 usecase별로 트랙잭션으로 만들어야 했을 것이다. 또한 이런 COM+는 전체 시스템을 3(or more) tier 구조로 만듦으로써 client는 아주 간단해 졌고, 이것은 또한 Client의 배포를 비교적 용이하게 만들었다.
COM+는 사실상 remote의 개념과 무관하다. MS에서는 원격에서 COM+를 사용하게 하기 위해서 RDS라는 놈을 제공한다. 이것은 사실 HTTP의 POST 메소드를 이용하는 간단한 놈이다. (이것을 몰라서 한 참을 삽질했다. COM+에서 기본적으로 remote서비스를 해주는 줄 알았으니깐.. 또한 COM과 COM+이 어떻게 레지스트를 이용해서 객체를 만들고, 이것이 RDS와 어떤 연관을 맺어가면서 원격에서 사용되는지는 며칠간의 삽질을 통해서 알게되었다.)

하지만 환경이 바뀌고 있다. 소위말하는 smartclient를 구현하는 실버라이트와 같은 것이 막강한 개발 인터페이스와 배포 기능을 하기면서 그것의 플랫폼이 되는 .NET환경이 비즈니스 로직과 연동되어야하는 상황이 발생한것이다. 소위 Language Interoperability를 지향하는 .NET에는 당연히 COM, COM+과의 연동을 쉽게 제공해준다. 하지만 이것은 로컬에서만의 이야기다...

사실 문제는 서로 복잡하게 뒤엉켜진 C++, VB로 만들어졌던 수백개의 비즈니스 로직들을 어떻게 .net 환경에서(원격에서) 호출하냐의 문제였다. 위에서 이야기한 바와 같이 로컬에서는 .net com+을 사용하기 쉽다. 이것을 원격에서 이용하기 위해서는 기존의 RDS와 거의 같은 서비스인 SOAP, WSDL을 사용해야한다. (이것때문에도 며칠 동안 삽질했다. 더이상 볼 페이지가 없을 정도로 구글에서 검색된 모든 자료와 MSDN의 관련된 자료는 다 봤다. 하지만 딱 맞는 자료는 없었다. .net에서 COM+원격 객체에 접근하는 방법으로 검색해도 없었고, RDS를 사용하는 방법도 없었다. 사실 웃긴 얘기지만 당연히 있을리가 없다. 사실 몇개가 있긴한데.. 다 안된다. 그저 자신들의 생각일 뿐.. 구글링으로 검색된 외국의 개발자들의 의견도 다들 찌질이 같다. -_-;; ) RDS는.. 특히 VB에서 사용하는 RDS는 컴파일타임에 객체의 타입과 메소드의 존재를 알지 못해도 컴파일되고 실행되는 다소 느슨한 놈이다. 하지만 .net에서는 모든것을 다 알아야 컴파일 된다. 원격객체를 late binding 할 때는 Type을 원격에서 가지고 와서 인스턴싱 하는 방법을 사용한다. .net remoting 서비스 같은 경우는 원격과 로컬에서 공유되는 데이타를 미리 정의해서 각기 컴파일 할때 참조해야한다. WSDL같은 경우에도 서버쪽 객체를 만들고 이것을 사용할 수 있게하는 proxy를 만들어 줘야한다(이것은 자동으로 된다 ㅎㅎ)

로컬에서는 .net이 com+ 객체에 접근할 수 있는 방법이 있고, 원격에서 WSDL을 통해서 객체에 접근할 수 있는 방법이 있기 때문에 이 두개를 결합하면 middle tier에서 .net환경에서 접근 가능한 com+객체를 재사용할 수 있다.
단지 데이터의 마샬링이 문제가 될 수 있긴하지만, WSDL에서 제공하는 몇가지 간단한 data type을 응용하면 어떠한 정보도 전송가능한 상태로 변형시킬 수 있다.


결국은 소위 .net에서 말하는 unmanaged code에서는
client - RDS - IIS - MSADC(RDS) - COM+(server) 의 단계를 거쳐야함에 비해서

.net의 managed code에서는
client - WSDL(proxy?) - IIS - WSDL - COM+(server) 의 단계를 거친다.

결국은 RDS를 WSDL로 바꿔주고 데이타의 마샬링 문제만 풀면 될것이다. 이렇게 되면 기존의 모든 컴포넌트를 100% 변형없이 재사용 가능하다.

개념이 잘 잡히지 않은 상태에서 패킷잡아가면서.. com+ 만들고 설치하고 RDS와 IIS와 연동하면서..(결국 삽질해가면서) 알게된 간단한 구조다.

###
나와 같은 목적을 가진 사람들이 좀 있드라..
그런 사람들의 글에  Activator.GetTypeFromProgID()란 메소드를 이용하면 원격의 객체에 접근할 수 있다고 많이 나와있는데, 사실 안된다. 무조건 로컬의 레지스트만 검색한다. (그리고 익셉션이 발생하는데 이 익셉션이 원격의 문제인지 로컬의 문제인지를 판단할 수 없다. 이것 때문에 네턱 패킷을 모니터링하면서 결국에는 위 메소드가 로컬의 레지스트리만 검색한다는 것을 알게됐다.)이 문제로 고민하는 사람들이 아주(?) 많은것 같드라. 그들이 한국어를 배우면 이 글을 읽겠지...



CSE/etcetera 2008.10.17 00:18

사용자 인증

http://www.nic.com/~dave/SecurityAdminGuide/SecurityAdminGuide-9.html

http://www.virusexperts.com/xbi/programming/md5-crypt


결국은 DES,MD5 둘 다 맞네.. 다만 요즘엔 MD5를 쓴다.

이것도 맞지 않았고 저것도 맞지 않았지만, 이것도 맞았고 저것도 맞았다.

항상 정보들이.. 부분적으로만 존재해서 많은 의문점을 남기고.. 조사하게 만든다. >.<

이제는 DES를 one-way function으로 사용하는 법이 궁금하구나..


CSE/etcetera 2008.10.06 19:20

순봉에게

순봉아.. 아까 내가 준 해법은 잘못된거다.
n명의 순열을 생각못했다. 그렇다고 순열대로만 경우의 수를 곱해주면 중복이 발생해서 문제가 굉장히 복잡해져..

그래서 좀 다른 해법을 찾아야되

T(x) : x번째 내에서 모두 1이 1회 이상 나오는 확률. 따라서 x=3이면 1번째 2번째 3번째 모두 포함.
이렇게 정의하자. 구하고자하는 F(x) 는 x번째에서 모두 1이 1회 이상 나오는 확률.. 이렇게 정의하면
F(x) = T(x) - T(x-1) 이렇게 된다.

이제 T(x)를 구하면되니깐..
T(x)는 n명 모두가 x번째내에서 적어도 1번이상 1이 나오는 확률. 한명이 x번째 내에서 적어도 1번이상 1이 나오는 확률은 1-(1-p)^x   (p : 1이 나올확률=1/6)
따라서
T(x) = (1-(1-p)^x)^n  임..
결론 F(x) = (1-(1-p)^x)^n  - (1-(1-p)^(x-1))^n

예>  2명일때..2번째에 모두 1이 나오는 경우.. 문제의 조건에 대당하는 경우는 총 5가지 (1은 1이 나온는것.. 0은 나머지것..)
1>             2>           3>       4>          5>
봉 : 1, 1     봉: 0,1     봉:1,0    봉:0,1     봉:0,1
엽 : 0, 1     엽: 1,1     엽:0,1    엽:1,0     엽:0,1
--------------------------------------------
1>과 2> 의 확률:p^3*(1-p)
3> 4> 5> 의 확률 : ((1-p)p)^2
따라서 모두 합하면 p^4 - 4p^3 +3p^2

위에서 구한 공식으로 풀면,
(1-(1-p)^2)^2  - (1-(1-p))^2
= (2p-p^2)^2  - p^2
= p^4 -4p^3 + 4p^2     -  p^2 
= p^4 -4p^3 + 3p^2 (위와같음.)

이거 기대값 구하려면 식이 좀 복잡한데... 적분 이용하면 될것 같은데 어렵네..

엑셀로 노매너 5명이 주사위 놀이 할때.. 구해봤는데..



기대값은 13.0xx 정도 나오니깐..
평균적으로 14번 던지면 노매너 모두 1이 1번 이상씩 나온다. ㅋㅋㅋ



 

CSE/etcetera 2008.02.27 01:40

fork

fork.c more..


위 코드의 수행결과는 다음과 같다

첫번째 경우

$ ./fork.o
Writing to STD out.
before fork
pid = 25201, glob = 7, var 89
pid = 25200, glob = 6, var 88


두번째 경우

$ ./fork.o > out.txt
$ cat out.txt
Writing to STD out.
before fork
pid = 25206, glob = 7, var 89
before fork
pid = 25205, glob = 6, var 88

의문점 :  "before fork"가 나타나는 횟수가 다른이유??   힌트 : buffering

정답보기


 

buffer, Fork
CSE/etcetera 2007.12.23 23:47

buffer size에 따른 copy 명령의 시간 측정

buffer size
1           2.478u 24.802s 0:27.27
10          0.361u 3.128s 0:03.48
100         0.048u 0.359s 0:00.40
1000        0.001u 0.060s 0:00.06
10000       0.000u 0.026s 0:00.02
100000      0.000u 0.021s 0:00.02
1000000     0.000u 0.025s 0:00.02
10000000    0.000u 0.030s 0:00.03


버퍼 사이즈를 1byte 부터 10000000 byte까지 바꿔가면서 시험해봤다.

이론적으로는 버퍼 사이즈가 일정 정도가 넘어서면 속도 향상이 없다. 하지만 버퍼를 malloc으로 구현해서 그런지 오히려 100000 byte 이후부터는 시간이 증가한다.

mylib.h


mylib.c


myCopy.c

CSE/etcetera 2007.12.23 01:31

vi 사용법

vi사용법열기..

CSE/etcetera 2007.08.29 15:04

Threads compared with processes


Threads compared with processes


OS를 듣기 전이나 후나.. 솔직히 이 둘에 대해서 위에 언급한 정도의 차이점은 안다. 그런데 항상 막연했다. 뭐든지 실제로 만들어서 돌려봐야 감이 온다.

쓰레드와 프로세스의 차이점에 대한 질문에 아주 엉성하게 대답한 적이 있다. 지금이라면 조금더 깔끔하게 답변할 수 있을것 같다. 지식이 발효돼서 그런가?? 

음식이든 지식이든 시간으로 숙성을 시켜야 체득되는가보다.

CSE/etcetera 2007.08.26 12:12

한달동안 삽질하면 설치한 것들..

사용자 삽입 이미지

삽질만 했지.. 결과물은 영~ 빠이다.



 

CSE/etcetera 2007.08.23 22:00

인턴도 끝나간다

방학이 끝나간다. 2개월 남짓 일했던 T에서의 인턴도 끝나간다.
코딩을 많이 해보지도 않았고 잘 하지도 못해서, 막코딩 하기를 은근히 바랐지만 시스템 레벨의 제품을 개발하는 그곳에서는 인턴이 코딩하는 것은 어렵다.

오픈소스를 가져와서 빌드하고 이런저런 것들을 붙여서 동작시켜보는게 내가 하는 일이다. 덕분에 생소한 telecom분야의 IMS관련 쌩(生)원서도 봤고 HTTP보다 훨씬(?)복잡하다는 SIP도 수박 겉핥기식으로 RFC문서라는 처음 듣는 문서도 보면서 살펴봤다. 그리고 환경이 리눅스다 보니.. 좀 더 리눅스 환경에 친해졌다.

APM도 설치해보지 않은 상태에서 엄청난 삽질을 해가며 DNS서버 부터 차근차근 깔기 시작했다. openims core의 4가지 entity들.. 2~3가지 클아이언트, openser와 그 기반의 presence AS, weblogic sip as와 assistant.. 하나하나가 삽질의 굵직한 고비..하나를 build하기 위해서 필요한 또 몇개의dependency들..  또 dependency의 dependency.... 갈수록 많아지는 삽질의 연속..

하지만 삽질 덕분에 버젼 컨트롤도 사용해봤고 (물론 커밋을 안했지만) 이런 저런 잡다구리한거 많이 만져봐서 좋았다. 또 말만 들어본 WAS라는거.. 도통 감이 안왔는데, weblogic 설치하고 어플리케이션 deploy하면서 대충 '이런거구나..'란 감이 왔다.

오늘까지 했던 이종(異種) sip as간의 연동(?)은 weblogic인지 assistant라는 어플리케이션인지는 알 수 없지만 URI에서 포트만 파싱하는 부분에서 문제가 있는 것 같다. 결국은 정상적인 상태에서 연동은 못해봤고, 등록안된 URI에 INVITE 메시를 보내면(전화걸면) 등록 안됐다는 응답이 오는 것만 알 수 있었다. 어제 직접 이걸 만든 david아저씨에게 문의 이메일은 보내놨는데, 지금까지 쌩까고 있다.

기간이 한정돼 있는지라.. 여기까지하고 발표준비와 보고서 작성을 해야된다. 약간 찜찜한게 있지만 여기서 마무리해야겠다. 만약 내일까지 david burke 아저씨한테 답장이 오면 한번 더 해보고..


이 회사는 정말 실력있는 분들이 많은것 같다. 조유근 교수님 말씀대로 많은걸 배울 수 있는 곳이다. 그런데 단지 직장으로 좋은곳이냐..라고 묻는다면.. 모르겠다. 어떤 인생을 원하느냐가 먼저 답해야할 질문이다.
IMS, sip, 인턴
TOTAL 240,139 TODAY 4