동기방식(sync), 비동기방식(ASync)
Sync(동기방식)
동기방식이란?
- transaction 함수를 호출하게 되면 Server로부터 데이터를 받게 된다
transaction 호출 후 서버에서 응답이 완료되는 시점까지 대기 후 결과를 받으면 다음 Script가 진행한다
- 예를 들어 1만 건의 데이터, 또는 10만 건의 데이터, 100건의 데이터를 서버로 받는다고 했을 때 해당 데이터를 받을 때까지 transaction 함수 라인에서 Script는 멈춰있다
- 데이터를 모두 받게 되면 위 이미지 Sync 맨 밑에 있는 로직이 수행된다
즉, Script가 순차적으로 실행되기 때문에 동기방식이다
동기방식 같은 경우 transaction 함수 호출 후, 바로 밑에서 trace 로그를 남기게 되면 정확한 (데이터 조회)건수를 구할 수 있다
-> 왜? Script가 순차적으로 흘러가기 때문이다
ASync(비동기방식)
비동기방식이란?
transaction 함수 호출 후 통신 완료와 상관없이 다음 스크립트를 수행하며, 서버에서 결과가 반환되면 callback 함수가 호출된다
비동기방식 같은 경우 통신의 완료와 상관없이 다음 Script가 실행된다 transaction이 실행되고 서버에서 데이터를 받아야 하는데 데이터를 받기 전에 바로 밑에 문장이 실행된다
-> 따라서 trace를 통해 데이터 건수를 확인하면 이곳에서는 정확한 건수를 알 수가 없다 0이나, 또는 개발 시 테스트 데이터가 있다고 하면 테스트 데이터의 데이터 건수가 나온다
ASync(비동기)방식에서는 callback 함수에서 다음 로직을 처리해야 정확한 건수를 얻을 수 있다
동기방식을 사용하면 안되는 이유
동기방식 같은 경우에는 하나의 서비스를 호출하고 서버로부터 데이터를 받는 데까지 1초가 걸린다고 하면 동일한 서비스를 두 번 호출했을 때 정확하게 2초가 걸린다
비동기방식의 경우 transaction 첫 번째가 실행되고 바로 밑에 로직이 실행되기 때문에 두 번째 transaction를 바로 실행할 수 있고 1초 조금 더 걸리게 된다
만약에 동기방식을 사용하게 되면 아래와 같은 현상이 발생한다
- 통신 응답대기인 상태에서 다른 오퍼레이션 발생 시 백화현상,응답없음
- Form의 onload Event에서 사용할 경우 화면 구성이 멈춰지는 듯한 현상
- 통신의 경우 통신대기 상태를 나타내는 이미지 등의 비정상적 표현
통신방식
개발과정에서는 전혀 문제가 안되지만 개발이 끝나고 통합테스트 진행한다고 하면 머릿속에 가장 먼저 떠올라야 하는 옵션이 통신 타입을 바꾸는거다
넥사크로플랫폼에서는 3가지 통신 타입을 제공한다
- XML(Default)
- Binary
- SSV
개발자 입장에서는 Client와 Server 간에 데이터 통신을 할 때 데이터 송수신 내용을 눈으로 확인할 때 XML로 송수신하는 것이 디버깅하기 편하다
Default는 XML로 되어 있고 통합테스트나 운영으로 전환되면 Binary나 SSV로 바꿔야한다
WRE(Web Runtime Environment)로 실행한다면 Binary는 사용할 수 없다
-> 왜? Web 브라우저가 Binary 포맷을 인식할 수 없다(SSV 타입을 사용)
즉, 최소한 WRE 운영하면 SSV타입으로 설정하고 만약 NRE 환경으로 사용한다면 1번 Binary로 사용하면 된다
NRE 환경에서는 데이터 통신 시 한번 더 압축할 수 있다
-> 압축을 하게 되면 통신 패킷 사이즈를 줄일 수 있다
통합테스트나 운영으로 전환됩니다라고 하면 제일 먼저 통신 포맷 설정이 생각나야 한다
-> 이 부분을 수정하지 않고 Open하게 되면 데이터 100건만 조회해도 사용자는 속도가 느리다고 불만이 접수될 것이다
동일출처정책(Cross domain)
- 웹 브라우저 실행 시 화면 페이지와 데이터 통신시 호출하는 서버 페이지 도메인이 일치해야 함
여기서 체크하는 것은 3가지를 체크
첫 번째 Protocol만 변경돼도 다른 것으로 판단하고, 중간 도메인 그리고 세 번째 Port까지 셋 중 하나만 달라도 브라우저 정책의 유배되어 오류 메시지를 보여준다
반드시 운영할 때 화면을 부르는 서비스 경로와 데이터를 가져오는 서비스 경로가 같아야 한다
-> 경로가 다르면 지금처럼 '동일출처정책' 오류 메시지가 발생한다
Fiddler
Client단에서도 동작하고 서버 백엔드 단에는 Java Framework이 동작하고, 그러면 Client와 Server 간의 통신을 하는데 http 통신을 한다
네트워크 구간의 데이터를 확인해 보고 싶을 때가 있을거다
-> 이것을 확인할 수 있는 유틸리티가 Fiddler라는 프로그램이다
Fiddler 프로그램이 웹을 통해 배포되고 있으므로 여러분은 해당 유틸리티정도 다룰 수 있으면 디버깅에 많은 도움이 된다
Cache는 Web 브라우저를 실행했을 때 동일한 페이지를 열고, 닫고를 반복해서 볼 수가 있다
-> 이때 Cache 기능을 사용하게 되면 최초 한 번은 서버로부터 화면 정보를 받아오고 그다음부터는 Cache 정보를 올리게 되면 네트워크 구간에서 발생하는 패킷 전송 시간을 줄일 수 있으므로 빠르게 Response를 할 수 있다
PrefixID를 사용하게 되면 typedefinition 환경 파일 하나만 수정해서 반영하게 되면 소스 수정 없이 바로 적용할 수 있다
CacheLevel
- none
- Cache 기능을 사용하지 않겠다는 것이다
-> 어떠한 화면을 여닫고 할 때마다 항상 웹 서버로부터 최신 소스를 받아오겠다 무조건 내려받겠다는 설정
- session
- Application이 시작되어 최초 한번 메뉴를 누르게 되면 무조건 웹 서버에서 파일을 내려받는다
- 그런데 동일한 화면 소스를 여닫고 반복 시 두 번째부터는 무조건 Cache에 있는 파일을 사용한다
- dynamic
Application 실행해서 A라고 하는 화면을 여닫고를 반복할건데 dynamic은 매번 웹 서버에 변경 여부를 확인해서 변경된 내용이 있으면 내려받고 바뀌지 않으면 Cache의 내용을 사용한다
- static
소스를 Client에 내려받고 사용할 수 있는 방식(모든 소스를 Client에 내릴 수 있음)
관리자 입장에서는 번거롭다
-> Client로 소스를 내려야 하므로 그에 맞는 버전 관리를 별도로 해줘야 한다
CacheLevel은 실제 사용자에게 배포되었을 때 즉 사용자가 접속하는 환경에서만 동작한다
transaction 사용 시 SvcURL PrefixID를 사용했는데 데이터를 가져올 때는 반드시 CacheLevel을 none으로 해주어야 한다
-> 동일한 조건으로 데이터를 여러 번 조회할 수 있다(이때, none으로 사용하지 않게 되면 한 번만 데이터를 가져오는 현상이 발생)
가능하면 this.trandaction 함수는 적게 호출하고 데이터는 많이 가져오는 것이 좋다
-> 그래서 한 번의 호출로 n개의 Dataset을 가져오도록 서비스를 작성해야 한다
서비스 호출 시 데이터가 없는 경우에도 반드시 Layout이 필요하다
Layout을 안 넘겨주고 데이터만 넘기면?
-> 컬럼 정보가 모두 없어져서 컬럼을 바인딩 할 수 없다
그래서 무조건 상단에는 데이터가 있건 없건 무조건 Column Info는 가져와야 한다
e.reason
이 속성(e.reason)이 있을 때는 Dataset이 append가 발생해도 이벤트가 동작하고 delete, soft가 돼도 해당 이벤트가 동작한다
-> 그래서 해당 옵션이 있는 이벤트에서는 정확한 이벤트 동작을 할 수 있도록 분기 처리를 반드시 해주어야 한다
