ActiveX 클라이언트 프로그래밍 우수 사례

Java™ 컴포넌트에 액세스하는 가장 좋은 방법은 Java 언어를 사용하는 것입니다. Java 언어로 가능한 한 많은 프로그래밍을 수행하고 COM 자동화 컨테이너(예: Visual Basic) 및 Java 코드 사이에 작은 단순 인터페이스를 사용하는 것이 좋습니다. 이 인터페이스는 인터페이스에서 이동 시 발생할 수 있는 오버헤드 및 성능 문제점을 방지합니다.

우수 사례: 다음 주제를 다룹니다.
  • Visual Basic 가이드라인
  • CScript 및 Windows 스크립팅 호스트
  • ASP(Active Server Pages) 가이드라인
  • J2EE 가이드라인

Visual Basic 가이드라인

다음 가이드라인은 Visual Basic을 사용하여 ActiveX to EJB 브릿지의 사용을 최적화하는 데 도움이 되도록 합니다.

  • launchClientXJB.bat 파일을 통해 Visual Basic 복제를 시작하십시오. Visual Basic 디버거를 통해 Visual Basic 애플리케이션을 실행하려면, Visual Basic IDE(Integrated Development Environment)를 ActiveX to EJB 브릿지 환경 내에서 실행하십시오. Visual Basic 프로젝트를 작성한 후, 명령행에서 시작할 수 있습니다(예: launchClientXJB MyApplication.vbp). launchClientXJB.bat 파일이 VB6.EXE 파일에 대한 호출보다 앞서도록 Windows 시작 메뉴에서 Visual Basic 단축 아이콘을 변경하여 Visual Basic 애플리케이션을 ActiveX to EJB 환경에서 단독으로 시작할 수도 있습니다.
  • 프로그램을 디버깅하기 전에 Visual Basic IDE를 종료하십시오.

    JVM(Java virtual machine) 코드가 실행 중인 프로세스에 추가되기 때문에, 프로그램을 디버깅하기 전에 Visual Basic 편집기를 종료해야 합니다. 프로세스를 실행한 다음 Visual Basic IDE 내에서 프로그램을 종료하는 경우, XJBInit()가 디버거에서 호출되면 JVM 코드가 계속 실행되며 동일한 JVM 코드를 다시 추가합니다. 이렇게 되면 Visual Basic 프로그램을 다시 시작하기 전에 변경사항이 적용되지 않기 때문에 XJBInit() 인수(예: classpath)를 업데이트하려는 경우 문제가 발생합니다.

  • XJB.JClassFactory 오브젝트를 전체적으로 저장합니다.

    JVM 코드를 로드 해제하거나 다시 초기화할 수 없기 때문에, 결과 XJB.JClassFactory 오브젝트를 글로벌 변수로 캐시합니다. 이 오브젝트를 글로벌 변수로 처리 또는 단일 참조 전달의 오버헤드는 새 XJB.JClassFactory 오브젝트 재작성 및 둘 이상의 XJBInit() 인수 호출보다 훨씬 적습니다.

CScript 및 Windows 스크립팅 호스트

다음 가이드라인은 CScript 및 WSH(Windows Scripting Host)를 사용하여 ActiveX to EJB 브릿지의 사용을 최적화하는 데 도움이 되도록 합니다.
  • ActiveX to EJB 환경에서 시작합니다.
    ActiveX to EJB 브릿지 환경에서 VBScript 파일을 시작하여 .vbs 파일에서 VBScript 파일을 실행합니다. 스크립트를 실행하는 데 공통된 두 방법이 존재합니다.
    • launchClientXJB MyScript.vbs
    • launchClientXJB cscript MyScript.vbs

ASP(Active Server Pages) 가이드라인

다음 가이드라인은 ASP(Active Server Pages) 소프트웨어를 사용하여 ActiveX to EJB 브릿지의 사용을 최적화하는 데 도움이 되도록 합니다.

  • Active Server Pages 애플리케이션에서 ActiveX to EJB 헬퍼 기능을 사용합니다.

    ASP(Active Server Pages) 코드는 일반적으로 VBScript를 사용하기 때문에, 변경사항이 미비한 VBScript 환경에 포함된 헬퍼 기능을 사용할 수 있습니다. 이 헬퍼 기능에 대한 자세한 정보는 데이터 유형 변환에 대한 헬퍼 기능을 참조하십시오. ASP 환경 밖에서 실행하려면, 서버, 요청, 응답 및 애플리케이션과 세션 오브젝트에 대한 모든 참조를 제거하거나 변경합니다(예를 들어 Server.CreateObjectCreateObject로 변경).

  • 시스템에서 JRE 경로를 전체적으로 설정합니다.

    XJB.JClassFactory 오브젝트를 사용하여 초기화 시 Java 런타임 DLL(Dynamic Link Library)을 찾아야 합니다. Internet Information Server에서, 프로세스에 대한 경로를 독립적으로 지정할 수 없으며, 시스템 PATH 변수에 프로세스 경로를 설정해야 합니다. ASP 애플리케이션을 사용하여 메커니즘에서 사용 가능한 단일 JVM 버전만이 있을 수 있습니다. 또한, 시스템 PATH 변수를 변경한 후 Internet Information Server가 변경사항을 볼 수 있도록 Internet Information Server 시스템을 다시 부팅해야 합니다.

  • 시스템 TEMP 환경 변수를 설정하십시오.

    시스템 TEMP 환경 변수가 설정되지 않은 경우, Internet Information Server는 WINNT 디렉토리에 모든 임시 파일을 저장하며, 일반적으로 바람직하지 않습니다.

  • 높은 격리 또는 격리 프로세스를 사용합니다.

    Active Server Pages 소프트웨어로 ActiveX to Java 브릿지를 사용하는 경우, 자체 프로세스로 웹 애플리케이션을 작성하는 것이 좋습니다. 하나의 JVM 명령어를 단일 프로세스로 로드할 수 있으며 다른 JVM 환경 옵션(예: 다른 classpaths)으로 둘 이상의 애플리케이션을 실행하려는 경우, 별도의 프로세스가 있어야 합니다.

  • 애플리케이션 로드 해제 옵션을 사용합니다.

    애플리케이션을 디버깅할 때, Internet Information Server 관리 콘솔에서 ASP 애플리케이션 특성을 볼 때 로드 해제를 사용하여 메모리에서 프로세스를 로드 해제하므로 JVM 코드를 로드 해제합니다.

  • 애플리케이션당 하나의 프로세스를 실행합니다.

    ASP 환경에서 J2EE 애플리케이션 또는 JVM 환경당 하나의 ASP 애플리케이션만을 사용합니다. 별도의 클래스 경로나 JVM 설정이 필요한 경우, ASP 애플리케이션을 분리해야 합니다(격리 또는 격리 프로세스가 높은 가상 디렉토리).

  • XJB.JClassFactory 오브젝트를 애플리케이션 범위에 저장합니다.

    JVM 명령어와 프로세스 사이에 필요한 일대일 관계 및 JVM 코드가 프로세스에서 독립적으로 분리되거나 시스템 종료될 수 없기 때문에, XJB.JClassFactory 오브젝트를 애플리케이션 범위에서 캐시하고 XJBInit() 메소드를 한 번만 호출합니다.

    ActiveX to EJB 브릿지가 FTM(Free-Threaded Marshaler)을 사용하기 때문에, Internet Information Server 및 ASP 환경의 멀티 스레드된 네이처를 사용합니다. Page 범위(로컬 변수)에서 XJB.JClassFactory 오브젝트를 다시 초기화하도록 선택한 경우, XJBInit() 메소드는 로컬 XJB.JClassFactory 변수만 초기화할 수 있습니다. XJBInit() 메소드를 한 번 사용하는 것이 더욱 효율적입니다.

  • VBScript 변환 기능을 사용합니다.

    VBScript 코드만이 변형 데이터 유형을 지원하기 때문에, CStr(), CByte(), CBool(), CCur(), CInt(), Clng(), CSng() 및 CDbl() 함수를 사용하여 ActiveX to EJB 브릿지에게 사용 중인 데이터 유형을 지시합니다(예: oMyObject.Foo(CDbl(1.234))).

J2EE 가이드라인

다음 가이드라인은 J2EE 환경을 사용하여 ActiveX to EJB 브릿지의 사용을 최적화하는 데 도움이 되도록 합니다.

  • 클라이언트 컨테이너 오브젝트를 글로벌하게 저장합니다.

    프로세스당 하나의 JVM 명령어가 있을 수 있고 JVM 명령어당 단일 J2EE 클라이언트 컨테이너(com.ibm.websphere.client.applicationclient.launchClient)가 있을 수 있기 때문에, J2EE 클라이언트 컨테이너를 한 번만 초기화하고 다시 사용합니다. ASP 애플리케이션의 경우, J2EE 클라이언트 컨테이너를 애플리케이션 레벨 변수로 저장하고 한 번만 초기화합니다(global.asa 파일의 Application_OnStart() 이벤트에서, 또는 검사하여 IsEmpty()인지를 확인하여).

    글로벌한 클라이언트 컨테이너 오브젝트 저장의 부작용은 오브젝트를 영구 삭제하지 않고 새 오브젝트를 작성하는 클라이언트 컨테이너 매개변수를 변경할 수 없는 것입니다. 이 매개변수는 EAR 파일, BootstrapHost, 클래스 경로 등을 포함합니다. Visual Basic 애플리케이션을 실행하고 클라이언트 컨테이너 매개변수를 변경하려면, 애플리케이션을 종료하고 다시 시작해야 합니다. Active Server Pages 애플리케이션을 실행하는 경우, 먼저 Internet Information Server에서 애플리케이션을 로드 해제해야 합니다(Active Server Pages 가이드라인에서 "애플리케이션 로드 해제 단추 사용" 참조). 그런 다음 Active Server Pages 애플리케이션을 다른 클라이언트 컨테이너 매개변수로 로드합니다. 매개변수는 처음 Active Server Pages 애플리케이션이 로드되면 설정됩니다. 클라이언트 컨테이너가 Internet Information Server에 저장되기 때문에, 모든 브라우저 클라이언트는 Active Server Pages 애플리케이션을 사용하여 매개변수를 공유합니다. 이 동작은 Active Server Pages 코드에 대해 정상이지만, 동일한 Active Server Pages 애플리케이션을 사용하여 다른 WebSphere® Application Servers에 실행하려고 하는 경우 혼동될 수 있으므로 지원되지 않습니다.

  • EAR 파일 추출을 위한 사용자 정의 임시 디렉토리를 다시 사용합니다.

    기본적으로, 클라이언트 컨테이너가 시작되고 애플리케이션 .ear 파일을 temp 디렉토리로 추출한 다음 추출된 EAR 파일 디렉토리 및 클라이언트 JAR Manifest에 포함된 JAR 파일을 사용하도록 설정합니다. 이 프로세스는 시간이 많이 소요되며 JNI(Java Native Interface) 및 파일 잠금을 통한 JVM 시스템과의 일부 제한사항 때문에 이 파일은 정리되지 않습니다.

    특히, 클라이언트 컨테이너 launch() 메소드가 호출될 때마다, EAR 파일을 하드 디스크 드라이브의 사용자 임시 디렉토리에서 임의의 디렉토리 이름으로 추출합니다. 현재 Java 스레드 클래스 로더는 결국 내부 파일을 잠그는 이 추출된 디렉토리를 가리키도록 변경됩니다. 일반 J2EE Java 클라이언트에서는, 애플리케이션이 종료된 후 이 파일이 자동으로 정리됩니다. 클라이언트 컨테이너 시스템 종료 후크가 호출될 때 이 정리가 발생하며(ActiveX to EJB 브릿지에서 발생하지 않음), 거기에 임시 디렉토리를 남깁니다.

    이 문제를 방지하려면, 클라이언트 컨테이너 launch() 메소드를 호출하기 전에 com.ibm.websphere.client.applicationclient.archivedir Java 시스템 특성을 설정하여 EAR 파일을 추출하는 디렉토리를 지정할 수 있습니다. 디렉토리가 존재하지 않거나 비어 있는 경우 EAR 파일이 정상적으로 추출됩니다. EAR 파일이 이전에 추출된 경우에는 디렉토리를 재사용합니다. 이 기능은 특히 서버 프로세스에 대해 중요하며(예: ASP), launchClient() 메소드를 여러 번 호출하여 잠재적으로 중지하거나 다시 시작할 수 있습니다.

    사용자 EAR 파일을 업데이트해야 하는 경우 임시 디렉토리를 먼저 삭제합니다. 다음에 클라이언트 컨테이너 오브젝트를 작성하면 새 EAR 파일을 임시 디렉토리로 추출합니다. 임시 디렉토리를 삭제하거나 시스템 특성 값을 다른 임시 디렉토리를 가리키도록 변경하지 않으면, 클라이언트 컨테이너는 현재 추출된 EAR 파일을 다시 사용하며 변경된 EAR 파일을 사용하지 않습니다.

    참고: com.ibm.websphere.client.applicationclient.archivedir 특성을 지정할 때에는 지정하는 디렉토리가 사용하는 각 EAR 파일마다 고유한지 확인하십시오. 예를 들어, MyEar1.earMyEar2.ear 파일을 동일한 디렉토리로 가리키지 마십시오.

    이 시스템 특성을 사용하지 않도록 선택한 경우, 정기적으로 사용자 Windows temp 디렉토리로 이동하고 WSTMP* 서브디렉토리를 삭제합니다. 상대적으로 단기간 동안, 이 서브디렉토리는 하드 디스크 드라이브에서 상당히 많은 공간을 낭비할 수 있습니다.


주제 유형을 표시하는 아이콘 참조 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rcli_activexbestpractice
파일 이름:rcli_activexbestpractice.html