WebLogic Integration 8.1sp2 JPD Proxy Start Guide

PROFESSIONAL SERVICE

HYUN-SOO KIM

BEA SYSTEMS KOREA, INC.

Document ID: WebLogic Integration 8.1sp2 JPD Proxy User’s Guide.doc Version No: 1.0 Version Date: MAR 17, 2004

Table of Contents

1. WebLogic Integration 8.1...... 3 2. Business Process 호출...... 4

2.1. Process Control...... 4 2.2. Service Broker Control...... 4 2.3. JPD Proxy...... 4

3. JPD Proxy...... 6 3.1. JPD Proxy 란?...... 6 3.2. Test용 Business Process 생성...... 6 3.3. Business Process의 JPD Proxy를 Download...... 16 3.4. Stand-Alone Java Application에서 JPD Proxy 사용...... 19

3.4.1. 프록시 클래스를 가져오려면...... 20 3.4.2. 프록시 팩토리 메소드(JpdProxy.create())를 사용하려면...... 20

3.4.2.1. 클라이언트가 대상 JPD와 같은 WebLogic Server 도메인에서 실행되는 경우...... 20

3.4.2.2. 클라이언트가 대상 JPD와 다른 도메인에서 실행되는 경우...... 21 3.4.3. 대상 비즈니스 프로세스에서 메소드를 호출하려면...... 23 3.4.4. 비즈니스 프로세스의 강력한 형식의 XML 또는 MFL 인수 정보...... 23 3.4.5. 대화 관리 정보...... 23 3.4.6. Java 클라이언트를 실행하려면...... 24

4. 결론...... 25

bea Systems Korea 2 Professional Service

1. WebLogic Integration 8.1

WebLogic Integration에서 제공하는 Business Process Management(BPM) 기능을 사용하면 Enterprise 외부의 거래 업체 간 정보 교환 조정은 물론 다양한 애플리케이션과 참여자 인티 그레이션이 가능합니다. Business Process를 사용하면 비즈니스 논리의 실행과 백엔드 시스템, 사용자, 거래 업체들 간의 비즈니스 문서 교환을 느슨하게 연결되 방식(Loosely-Coupled)으로 잘 구성할 수 있다. WebLogic Integration의 기능을 간략하게 요약해 보면 아래와 같다.

Business Process Management : Business Process를 모델링하고 통합을 조율하고 자동화등의 기능 Web Service Available as Business Process Resources : Business Process를 사용하듯이 Web Service를 사용할 수 있는 기능 Data Transformation : XML, non-XML, Java 데이터 간의 데이터를 자유로이 변환하는 기능 Messge Broker : 고성능의 rule-기반의 메시지 라우팅 기능 WebLogic Integration Controls : ERP, CRM, Legacy 등의 기존 어플리케이션을 쉽게 통합하는 기능 Worklist System : Business Process와 user간의 상호작용 지원 기능 Trading Partner Integration : 기업의 외부 거래 업체 간의 정보 교환 조정 기능 Application Integration and Adapters : Adapter 기반의 Enterprise Application 통합 기능 Administration and Management : WLI의 모든 기능 및 설정들을 Admin Console을 통하여 조정하는 기능

이와 같이 WLI는 EAI, BPM등의 기능을 모두 제공하는 통합 제품이다. 다음 절에서는 Business Process를 호출하는 방법에 대해서 알아본다.

bea Systems Korea 3 Professional Service

2. Business Process 호출

WSDL file, Process Control, Service Broker Control, JPD Proxy 등 다양한 방법을 사용하여 Business Process를 클라이언트에서 호출할 수 있다. Process Control과 Service Broker Control 은 WebLogic Workshop 구성요소인 Web Services(JWS), Business Process(JPD) 또는 Java Page Flow(JPF) 간에만 사용할 수 있다. 2.1. Process Control

Process Control을 사용하면 Business Process(JPD), Web Services(JWS) 또는 Java Page Flow(JPF)에서 Business Process에 요청을 보내거나 Business Process로부터 콜백을 받을 수 있다. Process Control 호출은 Java RMI 호출방식을 사용한다. 대상 Business Process는 호출자 와 같은 WebLogic Server 도메인에 호스팅되어야 하는 제약이 있다. 일반적으로 Process Control은 부모 Business Process에서 하위 프로세스를 호출하는 데 사용되며 Process Control 호출을 통해 부모 프로세스에서 하위 프로세스로 트랜잭션 컨텍스트가 자동으로 전파된다. 즉, 대상 Business Process는 호출자와 같은 트랜잭션에서 실행된다는 의미이다.

2.2. Service Broker Control

Service Broker Control을 사용하면 여러 가지 프로토콜 중 하나를 사용하여 Business Process(JPD) 또는 Web Services(JWS)에서 다른 서비스로부터의 콜백을 호출하거나 받을 수 있다. 이때 SOAP over HTTP 프로토콜이 가장 일반적으로 사용된다. 프로토콜에 대한 자세한 내용은 동적 바인딩 사용을 참조하기 바란다. 대상 서비스는 WSDL 인터페이스를 제공해야 하 는데 이러한 서비스는 Business Process(JPD), Web Services(JWS) 또는 리모트(non- Workshop) Web Services가 될 수 있다. HTTP 또는 JMS 전송이 사용되므로 Service Broker Control 호출을 통해 트랜잭션 컨텍스트가 전파되지 않는다. 일반적으로 Service Broker Control 은 리모트 서비스에 대해 호출된다.

2.3. JPD Proxy

Non-Workshop 클라이언트로부터 Business Process를 호출하려면 JPD Proxy를 사용하면 된 다. JPD Proxy를 사용하면 Java 코드를 통해 Business Process와 통신할 수 있다. JPD Proxy 를 사용하여 Business Process를 호출하는 경우 이러한 호출은 Java RMI 호출방식이 된다. JPD Proxy 호출을 통해 클라이언트에서 Business Process로 트랜잭션 컨텍스트가 전파된다. 즉, 클라이언트에 트랜잭션 컨텍스트가 있는 경우 대상 Business Process는 클라이언트와 같 bea Systems Korea 4 Professional Service

은 트랜잭션에서 실행된다는 의미이다. 일반적으로 JPD Proxy는 non-Workshop J2EE 클라이언 트 또는 stand-alone Java 클라이언트에서 Business Process를 호출하는 데 사용된다.

위에서 살펴본 것처럼, 클라이언트에서 Business Process를 호출하는 방법은 해당 클라이언트 의 특징과 대상 Business Process에 대한 클라이언트 위치 등에 따라 각각 다르다. 이 문서에 서는 위의 여러 방법들 중에서 특히 JPD Proxy를 사용하는 방법에 대해서 설명한다.

bea Systems Korea 5 Professional Service

3. JPD Proxy

JPD 프록시(Proxy)를 사용하여 독립 실행형 Java 애플리케이션, EJB, JSP, Servlet 등 모든 Java 클라이언트에서 Business Process(동기, 비동기, 상태 유지, 상태 비유지)를 호출할 수 있 다. Business Process에 대한 Java Proxy를 사용하는 단계는 해당 Proxy를 사용하는 클라이언 트 애플리케이션이 대상 Business Process와 같은 JVM에 있는지 여부에 따라 다르다. 또한 JPD Proxy는 WebLogic Integration 8.1sp2부터 지원된다.

3.1. JPD Proxy 란?

JPD Proxy는 Business Process(JPD)에 대한 RMI 클라이언트이다. Business Process의 클라이 언트 요청과 일치하는 인터페이스는 각 Business Process와 연관되어 있으며 이 인터페이스 를 JPD pulic contract 라고 한다. JPD pulic contract의 각 메소드는 해당하는 클라이언트 request와 같은 signature를 가진다. JPD Proxy는 JPD contract의 컴파일된 클래스 파일을 포 함하는 JAR 파일이다. 이 클래스 파일을 사용하면 Business Process(JPD)를 로컬 Java 클래스 처럼 액세스할 수 있다. JPD Proxy는 Java RMI를 통해 호출되고 JPD Proxy 호출을 통해 클라 이언트에서 Business Process로 트랜잭션 컨텍스트가 전파된다. WebLogic Workshop 테스트 브라우저의 Overview 페이지에 있는 JPD Proxy 링크를 통해 JPD Proxy JAR 파일을 다운로드할 수 있다. JpdProxy 클래스는 WebLogic Integration Business Process 유형에 대한 Proxy의 팩토리 클래 스이다. 클라이언트는 이 클래스의 create() 메소드 중 하나를 호출하여 Proxy 인스턴스를 가져 오게 된다. create() 메소드는 JPD contract 클래스(java.lang.Class)를 입력으로 사용한다.

경고 : 클라이언트 콜백을 포함하는 Business Process는 해당 프로세스를 시작한 클라이언트 에 이러한 콜백을 보내게 된다. JPD Proxy는 Business Process로부터의 콜백을 받을 수 없으 며 클라이언트 콜백을 JPD Proxy에 보내려고 하면 Business Process에서 오류가 발생하게 된 다. 즉, 클라이언트가 JPD Proxy를 사용하여 클라이언트 콜백을 포함하는 Business Process를 시작할 경우 해당 프로세스를 시작한 클라이언트(JPD Proxy)에 콜백을 보내려고 하면 런타임 에 Business Process에서 오류가 발생하게 된다.

3.2. Test용 Business Process 생성

우리는 여기서 Test용으로 사용하게될 Business Process(두개의 수를 받아서 합을 구하여 리 bea Systems Korea 6 Professional Service

턴하는)를 만들어 보겠다. Businees Process를 만들려면 우선 WebLogic Workshop을 시작해야 한다. WebLogic Platform 8.1 sp 2를 설치한 후에, 시작  Programs  BEA WebLogic Platform 8.1  WebLogic Workshop 8.1 을 클릭하면 WebLogic Workshop 8.1을 시작할 수 있다.

[그림 3-1] WebLogic Workshop 시작

Workshop을 시작하면 아래의 초기화면을 볼 수 있다.

[그림 3-2] WebLogic Workshop 의 초기화면

bea Systems Korea 7 Professional Service

WebLogic Platform 8.1 sp2 한글판을 설치했기 때문에 한글로 된 메뉴들을 볼 수 있다. 새로운 application을 만들기 위해 아래의 그림처럼 파일  새로 만들기  애플리케이션 을 클릭한 다.

[그림 3-3] 새로운 Application 생성

클릭을 하면 아래의 다이얼로그가 나타난다. 여기서 “빈 애플리케이션”을 선택하고 이름에 Test를 적어넣고 서버에서 아래의 미리 만들어 놓은 “integration” 도메인을 선택하고 “만들 기”를 클릭한다.

[그림 3-4] 새 애플리케이션 생성을 위한 다이얼로그

bea Systems Korea 8 Professional Service

아래의 그림처럼 아무것도 들어있지 않은 빈 애플리케이션이 생성된다.

[그림 3-5] 생성된 빈 애플리케이션

Test 폴더에 오른쪽 마우스를 누르면 팝업 메뉴가 뜬다. 새로 만들기  프로젝트를 클릭한다.

[그림 3-6] 새 프로젝트 생성

새 프로젝트 다이얼로그가 뜨는데 프로세스를 선택하고 프로세스 프로젝트를 선택한 후에 프

로젝트 이름을 add로 하고 만들기를 클릭한다.

[그림 3-7] 새 프로세스 프로젝트 생성

bea Systems Korea 9 Professional Service

아래에서 보는 것처럼 process.jpd 파일이 만들어 진다.

[그림 3-8] 만들어진 프로세스 파일

이것을 더블클릭하면 workshop화면 중간에 아래와 같은 Business Process를 정의하기 위한 그림이 나타난다.

[그림 3-9] JPD 파일의 초기화면

중간 node인 시작 이벤트를 더블 클릭하면 아래의 화면을 볼 수 있다.

[그림 3-10] 프로세스의 시작을 정의

bea Systems Korea 10 Professional Service

라디오 버튼 중에 “리턴을 갖는 클라이언트 요청을 동기적으로 호출”을 선택하고 확인을

누르면 아래의 그림처럼 된다.

[그림 3-11] 시작 이벤트를 정의한 프로세스

생성된 두개의 노드 중에 위의 것을 더블 클릭하면 아래의 화면처럼 바뀐다.

[그림 3-12] 초기 node를 연 화면

bea Systems Korea 11 Professional Service

일반 설정 탭에서 이 비즈니스 프로세스가 받아들일 두개의 int형 argument를 설정한다. 추가 버튼을 누르고 Java타입으로 선택하고 int를 선택하고 argument의 이름을 적는 과정을 반복 하여 두개의 argument를 설정한다.

[그림 3-13] 프로세스의 input argument를 설정

설정이 끝난 후에, 수신 데이터 탭을 클릭하면 실제로 넘어온 데이터를 할당하기 위한 변수를 만들기 위한 화면을 볼 수 있다.

[그림 3-14] input argument로 넘어온 값을 할당할 변수를 만듬

bea Systems Korea 12 Professional Service

위의 그림에서 두개의 argument에 각각 할당받을 변수를 설정한다. 새 변수 만들기를 클릭하 면 아래의 다이얼로그가 나타난다.

[그림 3-15] 변수 만들기 다이얼로그

변수 이름에 이름을 적고 타입을 선택한 후에 확인을 클릭하면 설정을 마치게 되고 다 한 후

의 화면은 아래와 같다.

[그림 3-16] 설정이 끝난 화면

적용을 클릭하고 닫기를 클릭하면 첫번째 node에 대한 설정이 끝났다. 이어서 두번째의 bea Systems Korea 13 Professional Service

Return하는 node를 설정해야한다. 설정방법은 앞의 방법과 유사하다. 다만 input을 받느냐 return을 하느냐의 차이가 있을 뿐이다. 두번째 node를 더블클릭하면 아래의 화면을 볼 수 있 고 추가 버튼을 클릭하여 리턴하기 위한 변수의 타입을 선택하게 된다. 여기서는 int를 리턴하 기 위해 int를 선택하였다.

[그림 3-17] 리턴 타입의 설정

타입 설정 후에 전송 데이터 탭을 클릭하여 실제로 리턴할 변수를 할당하게 된다.

[그림 3-18] 리턴할 변수를 생성 bea Systems Korea 14 Professional Service

리턴할 변수를 할당하기 위해 새 변수 만들기를 클릭하여 int형의 result변수를 만든다. 아래의 그림은 다 설정한 후의 화면이다.

[그림 3-19] 리턴할 변수를 할당

설정이 끝난 후에 적용을 클릭하고 닫기를 클릭하면 아래의 화면을 볼 수 있다.

[그림 3- 20] 프로세스 생성 화면

여기서 아래의 소스 뷰를 클릭하면 아래처럼 실제로 생성된 소스를 볼 수 있는데 우리는 여

bea Systems Korea 15 Professional Service

기서 간단한 덧셈 계산을 위해 소스를 약간 수정해야 한다.

[그림 3-21] 프로세스의 실제 소스

위의 부분을 찾아서 아래와 같이 수정한다.

[그림 3-22] 수정한 프로세스의 소스

수정후에 저장한다.

3.3. Business Process의 JPD Proxy를 Download

방금 만든 Business Process를 WebLogic Workshop에서 시작버튼 을 눌러서 비즈니스 프로세스를 실행한다. 만약 WebLogic Server를 기동해야 한다는 다이얼로그가 뜨면 확인을 눌 러 서버를 기동시킨다. 서버의 기동이 완료되면 프로그레스 바의 진행이 완료되면 Workshop 아래에 다음과 같은 표시를 볼 수 있다.

[그림 3-23] 서버의 상태 정보

서버의 기동이 완료되면 자동으로 Business Process를 컴파일하고 WebLogic Workshop 테스 트 브라우저가 뜨고 테스트용 화면을 아래와 같이 보여준다. 이 화면에서 JPD의 테스트와 같 은 작업들을 해볼 수가 있다.

bea Systems Korea 16 Professional Service

[그림 3-24] Workshop 테스트 브라우저

위의 화면에서 “개요”를 클릭하면 아래의 화면으로 바뀐다.

[그림 3-25] 개요 페이지 개요 페이지의 프로세스 클라이언트 섹션에서 JPD 프록시를 찾는다. 참고 : 기본적으로 패키지는 weblogic.wli.jpdproxy이다. 생성된 JPD Proxy에 대해 다른 패키지 를 지정하려면 JPD 프록시 버튼과 연결된 Java 패키지 필드에 패키지 이름을 입력하면 된다.

JPD 프록시를 클릭하면 디스크에 저장하라는 메시지가 나타난다. 이때 프록시의 사용방법에 따라 적절한 디스크에 파일을 저장한다.  WebLogic Workshop 애플리케이션(EJB, JSP or Servlet)에서 JPD 프록시를 사용하려면

bea Systems Korea 17 Professional Service

JAR 파일을 클라이언트 웹 애플리케이션의 WEB-INF/lib 디렉토리 또는 애플리케이션의 루트 에 있는 APP-INF/lib 디렉토리에 저장한다. WEB-INF/lib-프록시를 사용할 웹 애플리케이션(클라이언트 어플리케이션) 의 WEB-INF/lib 디렉 토리에 JAR 파일을 저장한다. WebLogic Workshop 그래픽 디자인 환경에서 JAR 파일은 애플 리케이션 분할창의 WEB-INF/lib 폴더에 표시된다. APP-INF/lib-클라이언트 애플리케이션의 여러 프로젝트에서 JPD 프록시 JAR을 사용하려면 JAR 파일을 애플리케이션의 루트에 있는 APP-INF/lib 디렉토리에 저장한다. WebLogic Workshop 그래픽 디자인 환경에서 JAR 파일은 애플리케이션 분할창의 애플리케이션 루트에 있는 라이브러리 폴더에 표시된다.  Stand-Alone Java 애플리케이션에서 JPD 프록시를 사용하려면 WebLogic Server 외부의 독립 실행형 Java 클라이언트에서 JPD 프록시를 사용하는 경우 JAR 을 클라이언트 Java 애플리케이션에서 사용하기 편리한 위치에 저장하고 이 JAR을 클라이언 트의 CLASSPATH 환경 변수에 추가한다. 참고 : JAR 파일의 기본 이름은 Proxy.jar 이다. 여기서 business- process-name은 JPD 프록시를 생성하는 비즈니스 프로세스의 이름을 나타낸다. 기존 JAR 파 일과 충돌하지만 않으면 기본 이름을 사용하는 것이 좋다.

대상 비즈니스 프로세스를 실행 중인 JVM과 다른 JVM에서 실행 중인 애플리케이션으로부터 JPD 프록시를 사용하려면 다음 JAR 파일을 클라이언트의 CLASSPATH 환경 변수에 추가해야 한다.  Proxy.jar WebLogic Workshop 테스트 브라우저에서 다운로드한 JPD 프록시이다. 여기서 business- process-name은 JPD 프록시를 생성한 비즈니스 프로세스의 이름을 나타낸다.  jpdproxy_client.jar 비즈니스 프로세스에 독립적인 클라이언트 측 클래스를 포함하는 지원 JAR이며 WebLogic Platform 설치 환경의 다음 디렉토리에 있다. [BEA_HOME]\weblogic81\integration\lib 여기서 [BEA_HOME]은 WebLogic Platform이 설치된 위치를 나타낸다. 이 JAR에는 JpdProxy라고 하는 추상 프록시 팩토리 클래스, 프록시 구현 JpdProxyImpl 및 기 타 클라이언트 측 런타임 클래스가 포함된다.  Schemas.jar 다운로드한 JPD 프록시(Proxy.jar) 파일에 강력한 형식의 XML 인수

bea Systems Korea 18 Professional Service

또는 MFL 인수에 대한 참조가 포함되어 있는 경우 Schemas.jar 파일을 클래스 경로에 추가한 다. 여기서 Schemas는 애플리케이션의 Schemas 프로젝트에 지정한 이름을 나타낸다. Schemas.jar 파일은 애플리케이션의 루트에 있는 APP-INF\lib 디렉토리에 포함되어 있다.  weblogic.jar weblogic.jar 파일은 WebLogic Platform 설치 환경의 \bea\weblogic81\server\lib 디렉토리에 있 다.  wlcipher.jar 양방향 SSL을 포함하는 클라이언트를 사용하는 경우 wlcipher.jar 파일을 CLASSPATH에 추가 한다. wlcipher.jar 파일은 WebLogic Platform 설치 환경의 [BEA_HOME]\weblogic81\server\lib 디 렉토리에 있다. 여기서 [BEA_HOME]은 WebLogic Platform이 설치된 위치를 나타낸다.

3.4. Stand-Alone Java Application에서 JPD Proxy 사용

우리는 앞서 Test용 Business Process를 만들었고 테스트 브라우저를 호출하여 Business Process의 JPD Proxy JAR 파일을 얻었다. 이제는 Java Application을 만들 차례이다. 아래는 샘플 코드이다. 파일의 이름은 callProcess.java 이다.

// 프록시 클래스는 com.bea.wli.bpm.proxy 패키지에 있다. import com.bea.wli.bpm.proxy.JpdProxy; import com.bea.wli.bpm.proxy.JpdProxySession;

import weblogic.wli.jpdproxy.process; /** * 애플리케이션에 필요한 패키지를 가져온다. 예를 들어 비즈니스 * 프로세스에서 XML Beans 를 사용하는 경우 적절한 패키지를 가져와야 한다. * 여기서는 별다른 것을 쓰지 않았으므로 필요없다. */ import javax.naming.Context; import javax.naming.NamingException; import javax.naming.InitialContext; import weblogic.jndi.Environment; import java.io.*; public class callProcess { public static void main(String[] args) { try { process p = (process) JpdProxy.create( process.class, process.SERVICE_URI, new JpdProxy.ContextHandler() { public Context getContext() throws NamingException bea Systems Korea 19 Professional Service

{ Environment env = new Environment(); env.setProviderUrl("t3://localhost:7001"); env.setSecurityPrincipal("weblogic"); env.setSecurityCredentials("weblogic"); return env.getInitialContext(); } } ); int input1 = 10; int input2 = 10; int ret = p.clientRequest(input1, input2); System.out.println("Return is : " + ret); } catch (Exception e) { e.printStackTrace(); } } }

아래는 소스 코드에 대한 설명이다.

3.4.1. 프록시 클래스를 가져오려면

위의 Java 클라이언트 예제에서는 다음 패키지를 가져온다. import com.bea.wli.bpm.proxy.JpdProxy; import com.bea.wli.bpm.proxy.JpdProxySession; 프록시 클래스는 com.bea.wli.bpm.proxy 패키지에 있다. 클라이언트는 JpdProxy.create()에 의 해 JpdProxySession에 반환된 프록시의 유형을 캐스팅하여 비즈니스 프로세스를 호출할 때 사용되는 대화 ID를 설정하고 가져올 수 있게 된다.

3.4.2. 프록시 팩토리 메소드(JpdProxy.create())를 사용하려면

프록시 팩토리 메소드 (JpdProxy.create())는 2개의 signature를 제공하는데, 클라이언트가 대상 비즈니스 프로세스(JPD)와 같은 WebLogic Server 도메인에서 실행되는 경우와 대상 비즈니스 프로세스와 다른 도메인에서 실행되는 경우에 각각 사용된다.  create() 메소드 세부 사항 - 클라이언트가 대상 JPD와 같은 WebLogic Server 도메인에서 실행되는 경우 사용

 create() 메소드 세부 사항 - 클라이언트가 대상 JPD와 다른 도메인에서 실행되는 경우 사 용

bea Systems Korea 20 Professional Service

1.1.1.1. 클라이언트가 대상 JPD와 같은 WebLogic Server 도메인에서 실행되는 경우

JpdProxy.create() 메소드는 비즈니스 프로세스(JPD)의 클라이언트 프록시를 만든다. JpdProxy.create()는 JPD 메소드를 기술하는 public contract interface를 입력으로 사용하고 이 메소드를 호출하면 public contract class에 대한 유형 캐스트가 실행된다. 서비스 URI는 서버에 서 JPD를 고유하게 식별한다. 클라이언트가 대상 JPD와 같은 WLS 도메인에서 실행되는 경우 다음 메소드를 사용한다. 샘플 코드: JpdProxy.create() public static final Object create(Class publicContract, String serviceUri) throws JpdProxyException 위의 샘플 코드에서

publicContract는 JPD의 public contract interface를 지정한다. serviceUri는 JPD의 URI를 지정한다. 참고: 대부분의 경우 public contract interface는 비즈니스 프로세스의 모든 버전에 대해 동일하 지만 특정 버전의 비즈니스 프로세스에서는 원본 프로세스의 public interface를 확장할 수 있 다. 이런 경우 프록시 팩토리 메소드에 전달된 서비스 URI와 JPD contract interface에 일관성 이 있어야 한다. 버전 관리된 비즈니스 프로세스의 JPD 프록시를 생성하는 데 대한 자세한 내 용은 버전 관리된 비즈니스 프로세스 정보를 참조하라.

이 메소드는 public contract interface로 캐스팅할 수 있는 프록시 객체를 반환한다. 이 메소드는 프록시를 작성하는 동안 발생한 확인된 예외를 랩핑하는 JpdProxyException을 발생시킨다. 1.1.1.2. 클라이언트가 대상 JPD와 다른 도메인에서 실행되는 경우 이 메소드 signature는 위에서 나온 샘플 코드의 JpdProxy.create()에 나와 있다. JpdProxy.create() 메소드는 비즈니스 프로세스(JPD)의 클라이언트 프록시를 만든다. JpdProxy.create()는 비즈니스 프로세스의 메소드를 기술하는 public contract interface를 입력 으로 사용하고 이 메소드를 호출하면 공용 계약 클래스에 대한 유형 캐스트가 실행된다. 서비 스 URI는 서버에서 비즈니스 프로세스를 고유하게 식별하는데 사용된다. 클라이언트가 대상 JPD와 다른 도메인에서 실행되는 경우 프록시에 의해 JpdProxy.ContextHandler가 호출되어 서버에 로그인하고 서버 측 자원을 조회하는 데 사용되는 JNDI 컨텍스트를 얻을 수 있다. ContextHandler를 사용하지 않는 버전의 JpdProxy.create()를 사용할 경우에는 클라이언트의 JNDI 컨텍스트를 사용하여 ProxyDispatcher EJB를 찾게 된다.

bea Systems Korea 21 Professional Service

다음과 같은 경우 ContextHandler가 필요하다.  클라이언트가 WebLogic Server에서 실행되지만 대상 비즈니스 프로세스와 다른 도메 인에 있는 경우

 클라이언트가 독립 실행형 Java 애플리케이션인 경우  클라이언트가 대상 비즈니스 프로세스와 같은 WebLogic Server에서 실행되지만 클라 이언트의 자격 증명이 적절하지 않은 경우. 클라이언트가 익명으로 실행 중이거나 JPD 프록시 디스패처 빈 또는 비즈니스 프로세스에 다른 자격 증명이 필요한 경우를 예로 들 수 있다. 참고: ProxyDispatcher EJB는 JPD 프록시로부터 들어오는 요청을 처리하는 WebLogic Integration 시스템의 상태 비유지 세션 빈이며 범위는 WebLogic Server 도메인이다. ProxyDispatcher는 클러스터의 모든 관리되는 서버를 대상으로 한다. 관리자는 WebLogic Server Administration Console을 사용하여 이 EJB에 인증 및 권한 부여 정책을 설정할 수 있 다. BEA에서는 사용자를 보안 컨텍스트와 연결할 때 JNDI 대신 JAAS(Java Authentication and Authorization Service)를 사용할 것을 권장한다. 자세한 내용은 WebLogic Server 설명서에서 WebLogic JNDI(영문) 및 Java 클라이언트에서 JAAS 인증 사용(영문)을 참조하라.

JpdProxy 구현은 서버에 대해 명시적으로 인증되지 않는다. 대신 ContextHandler에서 반환된 JNDI 컨텍스트를 사용하여 ProxyDispatcherHome을 찾을 때 JNDI 인증에 의존한다. ContextHandler가 필요한 경우 다음 메소드를 사용한다. 샘플 코드: JpdProxy.create() public static final Object create(Class publicContract, String serviceUri, JpdProxy.ContextHandler ch) throws JpdProxyException 위의 샘플 코드에서

publicContract는 JPD의 public contract interface를 지정한다. serviceUri는 JPD의 URI를 지정한다. ch는 컨텍스트 핸들러를 지정한다. 클라이언트는 이 JpdProxy.ContextHandler 인터페이스의 인 스턴스를 create 메소드에 전달하고 프록시 구현에서 런타임에 이 인스턴스를 사용하여 JNDI 컨텍스트를 할당한다. 이 컨텍스트는 서버에 로그인한 다음 들어오는 프록시 요청을 처리하는 서버 측 자원을 조회하는 데 사용된다. 위의 Java 클라이언트 예제에서는 Java 클라이언트에 사용되는 getContext() 메소드를 보여 준다. 참고 : 컨텍스트 핸들러 인터페이스에 대한 자세한 내용은 다음 URL을 통해 WebLogic Integration Javadoc의 JpdProxy.ContextHandler 인터페이스(영문)를 참조하라.

bea Systems Korea 22 Professional Service

http://edocs.bea.com/wli/docs81/javadoc/index.html 참고 : 초기 컨텍스트를 만드는 데 대한 자세한 내용은 다음 URL을 통해 Environment 클래스 (영문)를 참조하라. http://e-docs.bea.com/wls/docs81/javadocs/weblogic/jndi/Environment.html

이 메소드는 public contract interface로 캐스팅할 수 있는 프록시 객체를 반환한다. 이 메소드는 프록시를 작성하는 동안 발생한 확인된 예외를 랩핑하는 JpdProxyException을 발생시킨다.

3.4.3. 대상 비즈니스 프로세스에서 메소드를 호출하려면

JPD 프록시를 통해 사용할 수 있는 클라이언트 요청 메소드를 확인하려면 비즈니스 프로세스 의 소스 코드를 살펴보면 된다. 이렇게 하려면 WebLogic Workshop 그래픽 디자인 환경에서 비즈니스 프로세스(JPD)를 열고, 디자인 뷰 또는 소스 뷰에서 클라이언트 요청 호출을 식별하 고, 소스 뷰를 열어 메소드 이름과 signature를 검토해야 한다. 비즈니스 프로세스의 클라이언 트 요청 및 클라이언트 응답 메소드에 대한 자세한 내용은 비즈니스 프로세스 빌드 가이드의

Start 노드 디자인을 참조하라. JPD 프록시는 비즈니스 프로세스로부터의 콜백을 받을 수 없다. 자세한 내용은 클라이언트 콜 백을 포함하는 비즈니스 프로세스에 JPD 프록시를 사용하는 경우의 제한 사항을 참조하라.

3.4.4. 비즈니스 프로세스의 강력한 형식의 XML 또는 MFL 인수 정보

비즈니스 프로세스에서는 형식 있는 XML(XML Beans) 및 형식 있는 바이너리 데이터(MFL)를 입력 및 리턴 값으로 사용할 수 있다. 이러한 비즈니스 프로세스에서 생성된 JPD contract interface는 해당 유형을 참조한다. 여기서는 이 내용을 사용하지는 않았으므로 이런 것도 있 구나 인식하는 정도로 넘어가도록 하자.

3.4.5. 대화 관리 정보

JpdProxySession 인터페이스를 사용하면 비즈니스 프로세스를 호출할 때 사용되는 대화 ID를 설정하고 가져올 수 있다. JpdProxySession 인터페이스를 사용하려면 클라이언트에서는 JpdProxy.create()에서 반환된 프록시를 JpdProxySession으로 유형 캐스트만 하면 된다. JpdProxy.create()에서 반환된 동적 프록시는 JpdProxySession 인터페이스를 구현한다. JpdProxySession 인터페이스의 메소드는 다음과 같다. bea Systems Korea 23 Professional Service

String getConversationID() JPD 프록시에서 사용하는 현재 대화 ID를 반환한다. void reset() 대화 ID를 널로 재설정한다. void setConversationID(String conversationID) 이후에 비즈니스 프로세스의 같은 인터페이스를 호출할 때 사용할 대화 ID를 설정한다.

대화 ID는 null로 초기화된다. JPD 프록시를 통해 비즈니스 프로세스의 메소드를 호출할 때 대 화 ID가 null인 경우 고유 대화 ID가 생성된다. 이 고유 ID는 클라이언트 측에서 런타임 상태 로 유지 관리된다. 즉, 클라이언트에서 대화 ID를 새로 지정하거나 널로 재설정할 때까지는 이 후 호출에 이 값을 계속 사용하게 된다. 같은 JPD 프록시 인스턴스를 사용하여 다른 비즈니스 프로세스 인스턴스의 메소드를 호출할 수 있지만 잘못된 대화 ID를 사용하여 호출하지 않도록 주의해야 한다. 즉, 클라이언트 애플리 케이션에서 JPD 프록시를 통해 비즈니스 프로세스 인스턴스 호출을 완료한 경우 새 대화를 시작하려면 두 번째 대화의 대화 ID를 명시적으로 설정하거나 JpdProxySession.reset()을 호 출하여 JPD 프록시에서 대화 ID를 널로 재설정해야 한다. JpdProxySession 인터페이스에 대한 자세한 내용은 다음 URL을 통해 WebLogic Integration Javadoc의 JpdProxySession 인터페이스(영문)를 참조하라. http://edocs.bea.com/wli/docs81/javadoc/index.html

3.4.6. Java 클라이언트를 실행하려면

다음 커맨드 라인에서는 위에서 나온 예제를 실행할 때 설정해야 하는 옵션에 대해 설명한다. java -Dbea.home=C:\bea callProcess 여기서 -Dbea.home=C:\bea는 BEA 라이센스 파일(license.bea)의 위치를 지정하기 위해 사용 한다.

bea Systems Korea 24 Professional Service

[그림 3-26] 예제를 수행한 결과

bea Systems Korea 25 Professional Service

4. 결론

지금까지 JPD Proxy의 사용법 및 관련되는 여러 내용들을 살펴보았다. 비즈니스 프로세스가 이미 만들어져 있다면 그것을 외부에서 호출하는 방법은 사실 알고 보면 별로 할 것이 없다. 대부분의 class를 WebLogic Integration에서 이미 제공해 주고, 우리는 그것들을 가져다가 import해서 호출해주기만 하면 되는 것이다. 아무쪼록 이 문서의 내용이 독자들에게 많은 도 움이 되길 바라며 이만 줄이겠다.

bea Systems Korea 26 Professional Service