조대협의 블로그

Multiple row에 대한 리턴값 처리시에, FML 값의 순서에 대한 테스트 Tuxedo Transport에서 Transformation Style 설정에 따른 결과 입력 데이타 10 A 10 10 20 B 20 20 None일 경우 Ordered 를 적용한 경우 B C 10.0 20.0 10 20 10 20 Grouped and Ordered 10 A 10.0 10 20 B 20.0 20

(FML인 경우) 1. Tuxedo에서 도메인 Config 설정을 한다. 2. FML 파일을 java weblogic.wtc.jatmi.mkfldclass fmldata 로 해서 JAVA 클래스를 생성한다. 3. WLS에서 WTC 설정을 하고 Resource 탭에서 위에서 설정한 JAVA 클래스를 적는다. 4. 2에서 작성한 클래스를 JAR로 묶어서 클래스 패스에 추가한다. == 여기까지가 WLS의 WTC설정 5. SB에서 AnyXML로 비지니스 서비스를 만들고 6. JAR를 SB 프로젝트에 추가한후, CLASS에서 해당 JAR를 고른다. 7. 비지니스 서비스를 완성한후 테스트시에 FML이 다음과 같을때 #name number type flags comments ACCOUNT_ID 10 long - - ..

ALSB에서 SOAP 을 REST POX (Plain Old Xml)로 변환하는 XmlBeans 구현 예제. ALSB에서 Java Callout으로 사용이 가능함 == import javax.xml.namespace.QName; import org.apache.xmlbeans.XmlCursor; import org.apache.xmlbeans.XmlObject; import org.apache.xmlbeans.XmlCursor.TokenType; public class RESTTransformer { public static XmlObject toREST(XmlObject soap){ XmlCursor cur = soap.newCursor(); cur.toFirstChild(); cur.toChild(n..

Mediation에서 Route To 추가하고 거기에 Dynamic Routing 추가한후에, Expression에 다음과 같이 써줌 GeneralProxySampleProject/samplewebservice/localproxy/PersonService.local == Route하고자 하는 destination이 Proxy일 경우 isProxy를 true로 해줄것. service 경로는 "프로젝트명/폴더.../폴더/Proxy명" 예를 들어 default 프로젝트의 localproxy 폴더의 common.local.proxy의 경우 default/localproxy/common.local (.proxy를 뺀다.) 가 된다.

문제는 JMS Proxy에서는 Transaction start를 지원하지만 가장 많이 사용하는 WebService Proxy는 Global Transaction을 start하지 않기 때문에 Transactional EJB를 Composition하는 경우 분산 트렌젝션에 대한 구현 문제가 생긴다. 방법은 두가지 인데. 1) 단순하게 EJB를 하나 만들어서 ALSB(OSB)에 배포하여 Code로 Tx를 composition한후, 이 EJB를 Biz Service로 등록하고 WebService로 Expose하는 방법 2) 좀더 OSB 다운 방법은 WebService Proxy에서 JMS Q로 callout한후 JMS Proxy에서 읽어서 Tx 처리하고나서 Recv Q에 return하면 WebService Pr..

1. OSB 설치시 Default로 하면 Eclipse를 인스톨 하기를 요청하기 때문에 Custom으로 선택하고 Workshop에서 Eclipse 모듈을 제외하고 설치할것. 2. Managed Server을 추가로 추가하기가 복잡하기 때문에, 아예 설치시부터 Managed Server를 추가하는 것이 좋다. 3. DBMS를 사용하기 때문에, 초반에 DB 설정을 해놓고 인스톨하는 것이 좋다.

WebLogic에서 간만에 재미있는 기능을 찾아서 포스팅. ESB나 EAI 제품과 같은 아키텍쳐에서 Sync Call의 구조를 보면 다음과 같다. Request가 들어오면 특정 Thread가 그 request를 받아서 Backend의 Component에 보내고, 응답을 기다린다. 응답이 오면 Client에게 그 응답을 전달하는 구조이다. 그런데 이 경우 Client에서 요청을 받은 후 그 요청을 Component에 전달하고 나면 Component로 부터 응답이 오기까지는 Request Thread는 아무것도 하지 않고 단지 기다리기만 한다. 즉 하는 일없이 Thread만 점유하고 있는 것이다. 만약에 Component에서의 처리시간이 오래 걸리게 되면 Request Thread가 held 되는 시간이 늘..