제목 : 여러 쇼핑몰들과의 Data교환
글쓴이: 정진호(fade3blk) 2003/05/15 09:56:31 조회수:5673 줄수:14 |
|
수많은 쇼핑몰들의 주문정보를 새벽시간대에 받고자 합니다.
그리고 거기에 따른 저희쪽의 정보를 다시 다음날 새벽에 보내고자 합니다.
이 과정에서 각 쇼핑몰과..저희쪽에서 데이타를 주고 받아야 합니다.
각 쇼핑몰의 운영체제는 유닉스도 잇고 윈도우도 있고 다양합니다.
그리고 그 프로그램을 저희가 제공해 주어야 하는 상황입니다.
어떤 방법이 좋을지 알고 싶습니다.
일단은 socket을 사용할까 하는데???
그러자니..각각의 쇼핑몰에 socket client모듈과 서버 모듈이 모두 있어야 할거 같네요..
그래도 괜찮은건지..
기술적으로 어려움은 없는지 알고 싶습니다.
|
제목 : Re: 음.. 보기에..
글쓴이: 손님(guest) 2003/05/15 11:38:16 조회수:961 줄수:3 |
|
미들웨어를 이용하심이..
규모나 일의 성격으로 보나 EAI나 B2Bi 쪽 솔루션들을 도입하시는것이 좋을 듯 합니다.
|
제목 : Re: 잘 모르지만 간단히 첨부합니다.
글쓴이: hongjuru(guest) 2003/05/15 12:02:40 조회수:1004 줄수:22 |
|
저도 잘은 모르지만, 아는대 까지 적어 봅니다.
첫번째
위에서 설명 하시대로, 클라이언트랑 서버 모듈을 따로 만드셔야 겠고요.
클라이언트랑 서버쪽의 데이터를 만드는 것은 XML 형태로 하면 될 것 같습니다.
굳이 XML로만 할 필요는 없지만, 데이터를 원하는 포맷으로 변환 하는 작업시
데이터의 가독성이 좋아 지므로 작업이 원할해 질 것 같습니다.
그리고 각각의 데이터를 보내고 받는 부분에서는 B2Bi, EAI 와 같은 중간의 받는 큐와
보내는 큐를 두셔서 비동기적으로 처리를 해야 시스템의 부담이 안 갈 것 같고요.
기술적으로 구현 보다는 각 쇼핑몰 마다 데이터의 구조 즉 스키마가 다를 수 있으므로,
그것을 공통된 포맷으로 만드는 작업, 혹은 각각 다른 스키마를 다 수용 할 수 있는 구조를
만들어 가는 것이 힘든 작업이라고 사료 됩니다.
데이터의 송/수신 부분은 기술적으로 다른 여러 곳에서 사용 하고 있으므로,
기존의 Reference 싸이트를 참조 하면 될 것 같습니다.
점심시간 이라서..
나중에 시간이 되면 몇자 더 적어 보겠습니다.
|
제목 : Re: 위의 글 계속 첨부 합니다
글쓴이: hongjuru(guest) 2003/05/15 13:14:41 조회수:952 줄수:30 |
|
아 죄송합니다.
도중에 끊겨서..
그러니까 다시 설명 하자면,
그림 으로 먼저 표현을 해 보죠.
C: 클라이언트
S: 서버
클라이언트 ----> 보내는 큐(C) --------> 받는 큐(S) ------> 서버
(데이타셋 생성) <---- 받는 큐(C) <-------- 보내는 큐(S) <------
전반적으로 위의 그림과 같이 되겠네요..
즉 클라이언트에서 XML 형태의 데이터를 생성 해서 큐에 넣고, 서버쪽에서는 받아온 데이터를
필요한 경우라면 파싱하여 원하는 데이터 포멧으로 서버에 저장을 합니다.
반대의 경우일 경우에는 서버에서 해당 클라이언트마다 데이터를 변환해서 보내던지,
아니면 클라이언트측 모듈에서 변환하는 파싱 작업을 수행해서 원하는 데이터를 받게
되는 거지요.
위의 데이터 변환 파싱은 앞에서 얘기했듯이 정책에 따라서 달라질 수 있겠죠..
아무튼 위의 구조로 하시면 될 것 같습니다.
도움이 되었는지 모르겠네요..
|
제목 : Re: 큐의 경우 문제가 있다고 들었습니다. 제가 잘못 안건가요?
글쓴이: 정진호(fade3blk) 2003/05/15 13:30:02 조회수:1103 줄수:15 |
|
subscriber가 다수인 경우 큐의 사용은 좋지 않다고 들었습니다.
subscriber 이 1,2,3,4,5,6 이 있다고 할 경우...
현재 큐에 4,3,2,1에 대한 데이터가 순차적으로 있다면..
4가 처리되기까지는 계속 처리가 안된다고 들었구요..
혹시나 subscriber 4가 가동을 안하고 있다면..
나머지도 모두 처리를 못한다고 들었습니다.
혹시 제가 잘못 알고 있는지요????
|
제목 : Re: XFML , ebXML
글쓴이: 손님(guest) 2003/05/15 13:30:32 조회수:1123 줄수:11 |
|
원래 MetaData 교환에 쓰이기는 하지만 실 데이타 교환해도 별 문제는 없을꺼 같네요
XFML을 사용해 보면 어떨까요?
http://www.xfml.org/spec/1.0.html
아니면 OS에 상관없는 ebXML 같은 것을 도입하면 어떨까요?
차후 확장성과 유지보수를 생각한다면 이것도 나쁘다고 할 순 없겠죠.
처음에 구축 하기는 글쎄요..쉬울지 어려울지...^^:
|
제목 : Re: JMS...
글쓴이: 손님(guest) 2003/05/15 13:41:30 조회수:1335 줄수:11 |
|
아범의 MQ같은 걸루 JMS를 구현하는 방법이 제일 간단할 듯 합니다...
메세지를 받음과 동시에 보낼필요는 없는 것 같으니 서버의 부담도 적을테고...
그런데 가장 큰 문제는 위에서도 언급이 되었지만 xml 스키마를 어떻게 정의하느냐
일겁니다...
이부분은 아무래도 전문 XML업체의 도움이 필요할 듯.......
|
제목 : Re: 웹으로 연동페이지를 만들면 제일 간단하겠네요.
글쓴이: 남형석(namhs9) 2003/05/15 15:39:06 조회수:1012 줄수:10 |
|
각 쇼핑몰마다 연동 정보를 제공하는 페이지를 하나 만듭니다.
님의 싸이트도 연동 정보를 제공하는 페이지가 있어야겠지요?
그리고 연동 정보 페이지에서 정보를 가져와서 처리하는 배치 프로그램을 만듭니다.
배치 프로그램을 새벽마다 스케줄을 돌립니다.
내용은 웹 페이지에 XML로 기술하면 되겠네요.
URL 클래스를 이용해서 페이지의 내용을 읽은 다음에 SAX같은걸 돌려서 연동처리하면
기술적으로 제일 간단한 구조가 될것 같습니다.
연동정보용량이 수십메가정도로 올라가면 웹서버에 부하가 걸리겠지만 많지 않다면
부담이 되진 않을것 같네요.
|
제목 : Re: 큐 구조가 가장 접합합니다.
글쓴이: 정호철(guest) 2003/05/16 13:42:57 조회수:1288 줄수:55 |
|
음.제가 회사에서 4년동안 한 일과 거의 비슷한 요구사항이네요..
회사에서 한일을 기준으로 몇자 적어보겠습니다.
=== 개발언어 : 각종 OS에서 돌아가야 한다면 당근 자바겠네요
=== 전송방식 : 새벽시간대에 배치성으로 돌린다면 큐를 이용하는게 좋겠군요
그게 아니고 웹화면이나 기타 ERP 화면에서 즉시 응답을 기다린다면 큐가
적합하지 않지만 배치성으로는 큐가 적합합니다.
Partner가 여럿이라면 각 Partner별로 큐를 만들고 Multithread로 처리했을 경우
위에서 우려하셨던 처럼 한 Partner때문에 처리가 지연되는 일은 없습니다.
=== 통신방식 : 각 Partner별로 방화벽이 있을 수도 있으니 무작정 포트 열어달라고 하기도 참
어려운 경우가 많습니다. 그러니 당연히 일반 socket프로그램으로는 이런 환경적
문제가 많을꺼라 예상이 됩니다. 또한 구현상에서도 서버쪽 socket의 원할한
처리를 위해서는 thread pooling, socket queueing등과 같은 골때리는 코딩을
하셔야 되는데 음...이거 쫌 까다롭습니다. 디버깅하기도 만만치 않고요
그래서 HTTP 방식으로 하는게 좋을 듯 하고요
배포하는 프로그램은 일종의 HTTP Client가 되는거고
서버쪽에는 단순히 서블릿으로 처리하면 되니까 별도의 socket 코딩을 할필요가 없어서
훨씬 수월합니다. 화면 없는 프로그램에서는 jsp보다는 서블릿이 좋더군요
jsp의 경우 response에 불필요한 공백을 제거해야되고 그렇게 되면
혹시라도 common.jsp같은 걸 include 했을 경우 골때리는 일이 일어납니다.
=== 큐적용 : 서블릿은 단순히 데이타를 받아들이는 창구로써 역할만 하고 바로 큐에
넘기도록 합니다.
그리고 서버에서는 daemon같은 놈이 각각의 큐를 보고 있다가 잘 처리하면됩니다.
그러니까 큐는 서버에서만 있는거고 클라이언트(Partner프로그램)들과는 상관없게 됩니다.
JMS를 적용하는 것도 좋습니다. 그런데 JMS는 API일 뿐이고 실제 제품을 도입하셔야되는데
Open Source인것도 있고 IBM MQ, SonicMQ 같은 상용 제품들도 있습니다.(돈이 쫌 들어가겟죠 ^.^)
그런데 JMS도 좋고 다 좋은데 배보다 배꼽이 더 커지면 안되겠죠...
업무를 잘 파악하시고 꼭 JMS를 돈주고 사야되는가 부터 살펴보셔야 겠네요.
=== 문서 포멧: 당근 XML로 하면 좋겠죠..
그런데 주로 이럴 요구사항에 맞는거 제품 만들어서 파는 회사인데요
Partner들한테 XML던져주면 상당히 난감해 하는 회사들이 적지 않더군요
javaservice.net을 돌아다니는 개발자 분들은 뭐 까지꺼 XML 할줄알어 하겠지만
기존 전산실에서 HOST, COBOL환경같이 Legacy쪽에서 일하시는 분들은 XML을
상당히 남감해 합니다. 파서라는게 뭐냐..어떻게 해야되냐..
뭐가 이리 복잡하냐..등등 그래서 XML<->Flat화일로 변환하고 뭐 그런 작업들도
해주곤합니다.
이것도 고민을 해보셔야될꺼 같네요
===============================================
쪼끔 아는척 해봤습니다. ㅎㅎㅎ -.-&
p.s. 저위에 "hongjuru" 님은 혹시 Pion**** 에 계시던 분이신가요?
맞다면...ㅎㅎㅎ 반가워요..잘지내시나요?
|
제목 : Re: 하나더요...
글쓴이: 정호철(guest) 2003/05/16 13:54:02 조회수:859 줄수:16 |
|
위에 어느분 께서
XFML, ebXML을 말하셨는데
이거 솔직히 열라 복잡하고 어렵습니다.
spec공부하는 시간도 아마 몇달 걸릴껍니다.
그렇다고 대충하기도 그렇고
(이런거 대충해놓으면 호환성 문제 뭐니해서 따지기 시작하면 정말로 한도 끝도 없거든요)
위에 것들은 정말로 정부 주도로 해서
수십, 수백억의 지원이 있어야지 제대로 구축하고 성공할 수 있는 프로젝트라 생각됩니다.
몇몇 쇼핑몰과 데이타 주고 받는 거에는 글쎄요..쩝쩝...
빈대 몇마리 잡으려고 로동 미사일 쏘는 격이 아닐까 싶네요..켁켁...쩝
|
제목 : Re: 현재 그런 시스템을 운영하고 있는 데가 있죠
글쓴이: 손님(guest) 2003/05/16 14:41:19 조회수:1053 줄수:20 |
|
발주서는 업체마다 다를 듯 하지만 공통적으로 들어가야 하는 요소들이 있답니다.
말씀하신 시스템을 구현하려면
1. 데이터 : EDI, XML-EDI 이용
2. 데이터 교환 : 통신 프로그램 이용( 서버나 클라이언트 모두 실시간 프로그램이
아니라 배치성 프로그램이라고 생각하시면 되죠. 예를들면 서버는 일정주기 마다 발주
정보가 담긴 DB를 조회하여 처리안된 데이터가 있으면 일정포맷의 전송 데이터를 만들고
클라이언트는 일정주기마다 서버에 접속하여 가져올 데이터가 있으면 전송해오고
클라이언트 측의 데이터 처리 프로그램을 호출하는 거죠..
3. 플랫폼 : 플랫폼은 상관없습니다. 통신 시스템, 데이터 처리 시스템은 어떤 언어로도
구현할 수 있을테니까요. 미들웨어를 사용한다거나, 전문 메시징 솔루션( 이를테면 MQ
Series )을 사용하는 것도 시스템에 부가적인 부분입니다.
4. 참고 : 유통관련 EDI나 XML-EDI 관련 정보는 http://www.eankorea.or.kr 여기를
참고하세요.
PS) 제가 좀더 자세한 정보를 드릴 형편이 아니라 죄송하네요... 참고가 되셨기를.
|
제목 : Re: 내 그 hongjuru 맞아요
글쓴이: hongjuru(guest) 2003/05/16 15:52:18 조회수:1031 줄수:11 |
|
잘 지내시죠 호철님..
호철님 회사 그만 두었다고 하던데..
어디서 지내시는지...
MSN 좀 가르쳐 주세요...
건강 하시고요..
또 기회가 다면 만나겠죠..
|
제목 : Re: 배치작업인데 왜 관계없는 해결안이 나오는지;;
글쓴이: 손님(guest) 2003/05/16 17:03:21 조회수:1019 줄수:17 |
|
분명히 질문하신 내용은 새벽에 데이터를 통으로 날린다고 했습니다.
두말할 필요없는 배치작업 성격입니다.
이에 tcp/ip로 껀껀이 보내고, validation check하거나,
데이터양식을 xml로 만들 요구사항 자체가 존재하지 않는겁니다.
(xml/edi, xfml, eb/xml 요구사항과 전혀 거리가 먼 얘기입니다-_-;;
(그리고 어렵지 않습니다-_-;;; 단지 스펙과 필요성에 대한 이해만 필요로 할 따름이죠
(xml스키마 설계가 필요한 부분도 아닙니다, schema defendency application도 아닌데--;
파일을 head/content/tail로 작성해서 flat file로 구분자를 주고,
db->file export가 일정주기로 돌고나면, file->db import하는 놈이 인식할 수 있는
위치에 쏩니다;;
프로세스가 일정시간 마다 한번씩 돌아가게 하시면 됩니다.
검코드와 로그등을 관리하는 것 하나 작성해주시구요..
쏘는 방식은 마음대로 입니다. (jms가 가장 낫겠죠)
|
제목 : Re: 회사마다 DB테이블 모양이 다 다른데..
글쓴이: 정호철(guest) 2003/05/16 17:46:54 조회수:942 줄수:11 |
|
앵...이론...
각 Partner (쇼핑몰) 마다 DB Table schema가 다르기 때문에
단순히 db<->file export, import하는 놈 만으로는 해결이 쉽지 않을꺼 같은데요
flatfile도 어차피 각 쇼핑몰 DB Table에 맞게 고쳐야된다면
기준이 되는 거 뭔가는 만드는게 좋다는거고 그럴려면 XML로 하자는 말이죠..
쇼핑몰 마다의 DB Table schema가 똑같다면 문제가 안되겠지만
그럴일은 거의 없지 않나요...
p.s. 홍주 아저씨 반가워요...크헐...
|
제목 : Re: 데이터 소스는 여러번 제너레이트하지 않음, 그리고 xml을 쓰지 않는 이유,
글쓴이: 손님(guest) 2003/05/16 18:23:59 조회수:1072 줄수:32 |
|
정호철님, 가령 20여개의 회사에 10메가의 데이터를 뿌려준다고 했을 때,
어차피 xml이든 flatfile이든 db->file export는 한번만 발생시켜야 합니다.
말씀하신 것 같이 각 쇼핑몰 DB table에 맞게
flat file을 수정하는 경우를 말씀하셨는데,
기본 데이터 소스에 대한 수정을 가능하다 생각하시는 듯 싶네요.
그런 방식은 비효율적이기 때문에 피해야 할 방법입니다.
게다가 client쪽의 importer도 같이 제공해야한다고 했을 때,
xml이든 flat file이든 데이터 자체가, 개별 스키마에 맞게
커스터마이징 되어 있을 필요가 있다는건,
importer자체도 매회사마다 커스터마이징 되어 있어야 한다는 얘기인데,
그러한 방식은 아무래도 좋지 않죠..;;
exporter, importer는 디비스키마가 어떻든 단 한개만 개발, 제공되고,
mapping에 대한 configuration파일만 데이터를 제공받는 곳에서 작성하면 되는 형태로 되야죠..
또, xml에 대해 말씀을 하셔서 추가하자면,
xx메가단위에 대한 파싱속도를 재보셨는지 모르겠지만,
상상을 초월할 만큼 사이즈에 비례이상으로 느려집니다.
그리고 단순 데이터 사이즈가 10메가라하면, xml로 제너레이션할 경우 최소 2배이상입니다;
다양한 연산을 지원하기 위해 attribute라던가, xml본연의 readability를 강화하자 한다면,
최소 10배이상 데이터 사이즈가 증가합니다;;;
(ex) a/
<rowset><row num=1><a id='1' type='..'>a</a>...</rowset>
xslt를 떠올리는 분도 계시겠지만, 빠를듯 싶어도,
일반 어플리케이션보다 배이상 느립니다. 단순 i/o에 tag검사해서 해당 객체에 넣고,
그것을 스택에 보관하고 있으면서 값을 비교해서 또 다른 객체에 넣습니다;;; 느려질만하죠.
이번 케이스에서 xml을 쓴다고 하면, flatfile-db mapping의 규칙을 정의하는
configuration파일에 써야 적정한거겠죠..
|
제목 : Re: 동일 케이스 :)
글쓴이: 손님(guest) 2003/05/16 18:32:19 조회수:878 줄수:1 |
|
금융정보, 이력정보 등, 쌓인것을 새벽에 날릴때 어떻게 하는지 물어봅시다.
|
제목 : Re: 감정이 격해 지는 것 같아서요
글쓴이: hongjuru(guest) 2003/05/16 19:08:06 조회수:959 줄수:32 |
|
다들 감정이 격해 지는 것 같아서요.
좀 정리를 해 볼려고 합니다.
어차피 여기 싸이트는 누가 옳고 누가 틀리다고 말을 할 수 있는 곳이 아니라,
여러 사람들의 다른 생각들을 토대로 생각의 전환이나 아이디어를 창출을 하고자 하는 것이
저 개인 적으로는 목적이라고 생각이 드는데요.
위에서 말씀 하신 정호철님과 그리고 손님 모두 다 맞는 말이라고 생각이 듭니다.
기술적인 면을 보면, 퍼포먼스 측면과 확장성/수용성의 측면 둘다를 생각 해야 하니까요.
퍼포먼스 측면에서 보면 손님 께서 하실 말씀이 백배 옳죠.
그러나, 정호철님의 생각은 하나의 스키마가 아닌 여러 스키마를 범용적으로 수용 하고자
하니까 중간단의 전환 하는 로직이 들어 가고, XML 같은 것을 쓰게 되는 거고요.
어느 것이 옳다고 볼 수는 없어요.
기술이라는 것은 주어진 환경에 맞추어서 최선의 방법을 선택해서 구현 할 수 밖에 없으니까요.
한가지 안타까운 것은, 저 또한 개발자 인데 , 저희 개발자들은 남의 얘기를 좀 더 긍정적으로
듣고, 비록 내 생각에는 틀린 것 같지만, 왜 그 사람이 그렇게 말을 하는지를 먼저 생각
해 볼 수 있는 심적 여유가 부족한 것 같아요.
저희들은 엔지니어 이므로, 기술적인 면이 중요하지만 그것 못지 않게도 communication의
Skill 를 높이는 자세가 많이 필요 한 것 같습니다.
좀 더 차분하게 자신의 의견을 말씀 해 주시면 좋겠습니다.
질문 하신 분 이 정도면 어느 정도 좋은 의견들이 나온 것 같은데 고려해 보시고요,
거기의 환경(조건) 사항과 그 조건에서 어떻게 결정 하셨는지 정리 글 올려 주시면
감사 하겠습니다.
|
제목 : Re: 앵...이론...
글쓴이: 정호철(guest) 2003/05/16 20:13:37 조회수:1062 줄수:39 |
|
켁
홍주 아저씨!!..나 감정 안 격해졌는디...크ㅎㅎ..쩝쩝..
손님 님의 말씀도 일리 있습니다.
xml 이든 flat file이든 상황에 맞게 좋은거 쓰면 되는거니까요...
그런데..한 회사 내에서 EAI 적인 성격일 경우 우리끼리 포멧 맞추고 하자 하면 Flat이
더 좋을 수 있고 포멧이 변경될 경우. 소주한잔 하면서 언제한번 날잡고 밤새지뭐..
이런게 통하는 상황이라면야 뭐 굳이 XML을 쓸 필요는 없죠.
제가 XML을 생각했던 이유는 여기 질문같이 B2Bi적인 성격일 경우 각 회사의 상황이
어떨지 모르니깐요
쫌더 유연한걸 생각한거였고요.. 예를 들면 Flat화일을
길이기반으로 했을때 만약 어떤 Partner가 어떤 항목 길이 늘리자 하면 전체 Partner들이
다같이 길이를 늘려야 되고 구분자기반으로 했을때 만약 어디 항목 사이에 항목 하나 더
추가 하자 했을 경우 나머지 Partner들도 다 같이 해야되는 부담이 있으니까.
B2Bi 환경에선 이런거에 유연하게 대처할 수 있는 XML이 좋지 않겠냐는 얘기를 한거였고요
실제로 해보니까 이런일 비일비재하거든요..
저도 전에 DOM위주로 XML을 사용할 때는 큰 데이타를 처리할때는 XML이라는게 그림에
떡이구나 라고 생각했었는데 SAX을 위주로 사용해 보니 Flat화일 그대로 사용하는거와
거의 차이가 없더라구요. 메모리 부담도 없고 속도도 괜찮고
그리고 반드시 XML이 flat 보다 크기가 큰건 아니더군요.
지금 제가 은행권에서 prj하고 있는데 이거 하기 전까지만 해도 XML은 Flat보다
커질수 밖에 없다라고 생각했었는데 여기 상황을 보고선...꼭 그렇지많은 않더군요
제가 여기서 사용하는 문서가 약 70개 정도 되는데
크기로 볼때 XML > Flat, Flat > XML 등등 다양합니다.
어떤건 Flat 200 Byte인게 XML로 2~3KB 되는것도 있고, 또 반대로
심한건 XML로는 20K인게 Flat으로 되면서 1M가 되는것도 있더라구요.
기존 COBOL프로그램의 한계로 인해서 어쩔수 없이 이렇게 해야된다고 하더라구요
(Loop가 많은 경우 이런일이 일어나더군요)
======================
예암튼..이렇게 보면 상황에 따라 판단할 수 있는 변수가 무한한거 같죠?
어디까지나 결정은 맨위..질문자께서 하시는 거니 이러저려 여러가지
경우가 있을수 있다는 말만하고 전 갑니다용..
|
제목 : Re: 제 의견을 종합하면..
글쓴이: 손님(guest) 2003/05/17 03:10:46 조회수:965 줄수:40 |
|
저두 감정 격해진게 아니라, 논리적으로 설명드렸을 뿐인데, 그렇게 보였다면 죄송^^;;
xml개발회사에서 제품도 개발하고 프로젝트도 몇개 뛰어봐서 경험한 내용을 적었을
따름입니다 :)
아직 제 얘기에 대해 이해를 잘 못하시는 부분이 있어 부연설명 드립니다.
(1) exporter : 데이터베이스 -> exporter -> 데이터소스
: 한회사에서 수행한다, xml이나 flat파일로 생성가능
(2) importer : 데이터소스 -> importer -> 데이터베이스
: 여러회사에서 서로 다른 데이터베이스 스키마에 importer를 통해 집어넣는다.
데이터소스의 의미에 대해서 생각을 하면,
이 데이터는 변경 가능한 여러형태의 소스가 되어서는 않됩니다.
단순하게 하나의 소스를 importer가 자신에 맞게 읽어들일 수 있는 형태가 되면 됩니다.
importer도 여러회사에 납품하는 제품이 개별 제품에 맞게 커스터마이징 되어서는 않됩니다.
단지 컨피규레이션 파일만을 수정해서 원래의 데이터소스로부터 필요한걸 얻을 수 있는
형태가 되어야 합니다.
자 그럼 xml과 플랫파일이 두역할을 수행하는데 차이가 있을까요?
길이기반을 말씀하셨는데 tcp/ip와 같이 언어와 머신별로 바이트사이즈를 조절해서
보내는 작업이 아닌 ascii 텍스트를 구분자로 읽어들일 수 있는 형태입니다.
xml schema를 동반한 xml파일, 헤더 동반한 flat파일,
xml->db 맵핑정보, flat파일->db맵핑정보, 둘 모두 설정파일 형태로 밖으로 빠져나오겠죠.
xml의 데이터 사이즈가 작아진다는 말씀.. 작아지게 만들 수는 있지만,
본연의 readability를 없애고, 데이터를 풀어낼때는 수행시간이 두배이상이므로
이와같이 시간에 쫓기는 배치작업에는 좋다고 생각되지 듯 싶습니다.
참고로, dom과 sax.. dom은 projectx이후로 내부적으로는 sax를 이용해서
dom객체를 생성하니, 최초 읽어들이는 시간은 sax와 비교가 않되는게 당연합니다.
sax는 start와 end tag를 체크하며 조건에 맞는 명령만 수행하니 느리진 않습니다.
그렇다고 제가 xml을 쓸모없는 기술이라는 평가에서 내린 의견은 아닙니다.
xml은 생각을 풀어내서 공통으로 공유, 표현이 가능하게 하는 세계공통어죠..
단, 이와 같은 케이스에는 별로 추천하고 싶지는 않을 따름입니다.
룰정의, 인포메이션 아키텍쳐 드리븐 어플리케이션과 같은 부분은 추천하지만 말이죠..
그럼 이만~
|
제목 : Re: 답변에 감사드립니다. 그런데 JMS는 안되는 걸로 알고 있습니다.
글쓴이: 정진호(fade3blk) 2003/05/19 18:23:58 조회수:1295 줄수:18 |
|
JMS를 사용하는 것은 안된다는 결론으로 나왔습니다.
WEBLOGIC이나 SONICMQ에 문의한 결과이죠.
큐나 토픽은 장단점이 있는데
저희 모델에는 적합하기 않다는 결론입니다.
저희쪽에서 받을때는 큐가 적당하지만..
저희가 쇼핑몰에 보낼때는 적당하지 않습니다..
큐는 FIFO구조라서..
처리대상자료가 앞에서 막고 있는경우 처리 되지 않습니다..
그래서 적당하지 않다는 거지요..
아니면 수많은 큐를 만들어서 1:1로 맵핑을 해야 되는데..
이건 저희가 관리차원에서 좋다고 생각하지 않습니다...
이런연유로 JMS는 포기하였습니다.
|
제목 : Re: 데이터를 껀껀이 보내는게 아니면 ftp로 올리세요
글쓴이: 손님(guest) 2003/05/20 01:19:01 조회수:1054 줄수:9 |
|
A.배치돌리고 -> 데이터파일생성 -> 정해진 이름으로 업로드
B.일정시간에 정해진 위치에 파일검색 -> 읽어들이며 디비쓰기 -> 로그남기기
A.로그가져가기 -> 로그분석 -> 조치 -> 로그
B.조치파일검색 -> 읽어들이며 조치 -> 로그
A.B : 일정기간에 한번씩 미조치,조치불가에러에 대한 리포팅 및 협의
|
제목 : Re: FIFO 구조에서
글쓴이: 정호철(guest) 2003/05/20 13:56:32 조회수:1034 줄수:29 |
|
ㅎㅎㅎ 또 글을 쓰는군요...
웬지..제가 경험했던 문제들을 그대로 고민하시는거 같아서..
ㅎㅎㅎ 입이 근질 거려..못참겠네요...말이 많다고 욕하시는건 아닌지..
저희도 그런 문제가 있었어요..
그래서 사용자별로 In/Out 큐를 따로따로 만들어 보기도 했는데
역시나 큐가 많아지니 관리가 어려워 지더군요..
그래서 고민한끝에..이렇게 했습니다.
In 큐는 모든 사용자가 다 같이 공유하는 하나만 만들고
Out 큐는 각 사용자 별로 [사용자ID]_Q 라는 이름으로 큐를 만들고요
이렇게 하면 특별히 매핑하거나 할 일이 없습니다.
그리고 In 처리시 중간에 하나가 에러나거나..뭐 이런 저런 사정때문에
멈췄을때 뒤에꺼 처리가 문제가 생기는건 Multi thread로 충분히 해결 가능합니다.
javax.jms.QueueReceiver객체를 In큐에 대해서 한 5~10 개 정도 생성하고
이렇게 하면 내부적으로 자동으로 스레드가 Receiver 별로 생성됩니다.
특별히 JMS를 사용하지 않는다고 해도 FIFO구조에서
In큐를 처리하는놈을 Multi thread로 할 경우 하나가 오랜시간 걸리더라도
놀고 있는 다른 스레드가 다음 메세지를 꺼내 처리를 하게 되므로
문제는 없습니다. 이렇게 할려면 In 큐를 보고 있다가 메세지를 GET하는 놈들간에
synchronize가 필요한데 JMS의 경우 이런걸 자동으로 다 알아서 해줍니다.
웹로직에 알아보신걸 보니..웹로직을 사용하시나 본데요..
웹로직 5.* 경우 JMS에 버그가 쫌 있어서 반드시 최신 sp를 patch하고
사용하시면..아무 문제 없습니다.
예 그럼..
|
제목 : Re: 금융권(카드)에서의 제 경험 상으로는
글쓴이: 워니(nawon2000) 2003/06/03 11:34:00 조회수:1421 줄수:6 |
|
-워니-
아주 전통적이고 안전하고 확실한 방법을 사용합니다
위에서 손님 분이 말씀하신...수작업FTP
|
제목 : Re: 워니님 말씀과 같이..
글쓴이: 손님(guest) 2003/06/06 13:28:28 조회수:1240 줄수:12 |
|
왠지 기술을 위한 기술들이 많이 언급되어 있군요.
큐, xml-edi 등이 대량의 데이터에 대한 배치작업을 수행하는 데는
경운기가 갈 길을, bmw스포츠카 몰고와서 경주하자는 모양입니다.
배치ftp네요, 워니님 말씀과 같이 ftp로 해결합니다. 절대로 껀껀이 처리안합니다.
그리고 양측에 서버를 작성해서 파일전송, 리포팅응답, 재전송등으로
자동화 하기도 하지만, 가령 네트워크장애, 서버다운, 에러리포팅, 기타 등
너무나 많은 변수와 업무책임 데이터 위변조등에 대한 조치
일정주기마다 미처리, 미해결의 재조치를 반드시 거쳐야 하는 등 여러 문제로 인해,
올리는 쪽(ftp), 내리는쪽이 따로따로 일을수행하는 방식입니다.
|
|
