WebSphere InterChange Server 이주 프로세스의 우수 사례

다음 가이드라인은 WebSphere® InterChange Server에 사용되는 통합 아티팩트의 개발을 지원하기 위해 만들어진 것입니다. 이 가이드라인을 준수하여 WebSphere InterChange Server 아티팩트를 손쉽게 WebSphere Process Server로 이주할 수 있습니다.

이러한 권장사항은 새 통합 솔루션 개발에 대한 지침으로만 사용하는 것이 좋습니다. 기존의 컨텐츠는 이 가이드라인을 준수하지 않을 수 있습니다. 또한 해당 가이드라인을 위반해야 하는 경우도 있습니다. 이러한 경우에는 아티팩트를 이주하는 데 필요한 재작업의 양을 최소화하기 위해, 가이드라인의 위반 범위를 제한하도록 주의해야 합니다. 여기에서 요약된 가이드라인에는 일반적인 WebSphere InterChange Server 아티팩트 개발에 대한 우수 사례는 포함되어 있지 않습니다. 이 가이드라인은 나중에 아티팩트를 쉽게 이주하는 데 적용할 수 있는 고려사항으로 범위가 제한되어 있습니다.

일반 개발

대부분의 통합 아티팩트에 폭넓게 적용할 수 있는 몇 가지 고려사항이 있습니다. 일반적으로, 도구에서 제공되는 기능을 활용하고 해당 도구에 의해 강제되는 메타데이터 모델에 따르는 아티팩트는 대부분 자연스럽게 이주합니다. 또한 대규모 확장 및 외부 종속성을 갖는 아티팩트는 이주 시에 좀 더 직접적인 개입을 필요로 할 수도 있습니다.
다음 목록은 이후의 좀 더 쉬운 이주를 위해 WebSphere InterChange Server 기반 솔루션의 일반적 개발에 대한 우수 사례를 요약한 것입니다.
  • 실시간 자동화 프로세스 통합 솔루션을 위한 WebSphere InterChange Server의 사용
  • 시스템 및 구성요소 디자인의 문서화
  • 통합 아티팩트 편집을 위한 개발 도구의 사용
  • 도구 및 Java™ 스니펫을 사용하여 규칙을 정의하는 우수 사례 활용

당연한 사항이지만 통합 솔루션은 WebSphere InterChange Server에서 제공하는 프로그래밍 모델 및 아키텍처를 준수해야 합니다. WebSphere InterChange Server는 실시간 자동화 프로세스 통합 솔루션에 최적화되어 있습니다. 또한 WebSphere InterChange Server에 있는 각 통합 구성요소는 아키텍처 안에서 올바르게 정의된 역할을 수행합니다. 이 모델에서 크게 벗어나는 경우 WebSphere Process Server의 적합한 아티팩트로 컨텐츠를 이주하는 작업은 더욱 어려워집니다.

나중에 이주 프로젝트를 크게 성공할 수 있게 하는 또 다른 우수 사례는 시스템 디자인을 문서화하는 것입니다. 기능상의 디자인 및 서비스 요구사항의 품질, 프로젝트 간에 공유되는 아티팩트의 독립성 그리고, 배치 동안에 발생하는 디자인 결정을 포함하여 통합 아키텍처 및 디자인을 캡처하십시오. 이 작업은 이주 중의 시스템 분석을 지원하며 재작업 노력을 최소화합니다.

아티팩트 정의를 작성, 구성 및 수정하려면 반드시 제공된 개발 도구만을 사용해야 합니다. 아티팩트 메타데이터의 수동 조작(예: XML 파일의 직접 편집)은 이주할 아티팩트를 손상시킬 수도 있으므로 피해야 합니다.

협업 템플리트, 맵, 공통 코드 유틸리티 및 기타 구성요소 안의 Java 코드를 개발할 경우 고려해야 할 몇 가지 사항이 있습니다.
  • 공개된 API만 사용.
  • 활동 편집기만 사용.
  • 어댑터를 사용하여 EIS에 액세스.
  • Java 스니펫 코드에서 외부 종속성 방지.
  • 이식성을 위해 J2EE 개발 규칙 준수.
  • 스레드를 출력하거나 Thread Synchronization 기본요소를 사용하지 마십시오. 사용해야 한다면, 이주할 때 비동기 Bean을 사용하도록 변환해야 합니다.
  • java.io.*을 사용하여 디스크 I/O를 수행하지 마십시오. 데이터를 저장하려면 JDBC를 사용하십시오.
  • 소켓 I/O, 클래스로딩, 기본 라이브러리 로딩 등과 같이 EJB 컨테이너에 예약되었을 수 있는 함수를 실행하지 마십시오. 해당 함수를 실행해야 한다면, 이주할 때 EJB 컨테이너 함수를 사용하도록 스니펫을 수동으로 변환해야 합니다.

아티팩트에 대한 제품 문서에 출력된 API만 사용하십시오. 이러한 API는 WebSphere InterChange Server 개발 안내서에 자세히 설명되어 있습니다. 많은 경우에 호환성 API는 WebSphere Process Server에서 제공되며 여기에는 출력된 API만 포함됩니다. WebSphere InterChange Server에는 개발자가 사용하려는 여러 내부 인터페이스가 있지만, 인터페이스가 계속 지원될 것으로 확신할 수는 없습니다.

맵과 협업 템플리트에서 비즈니스 로직 및 변환 규칙을 디자인할 때 활동 편집기 도구를 최대한 활용하십시오. 이 경우 비즈니스 로직은 새 아티팩트로 더욱 쉽게 변환될 수 있는 메타데이터를 통해 기술됩니다. 도구에서 재사용하려는 오퍼레이션의 경우 가능하면 활동 편집기의 "내 콜렉션" 기능을 사용하십시오. WebSphere InterChange Server의 클래스 경로에 Java 아카이브(*.jar) 파일로 포함된 필드 개발 공통 코드 유틸리티 라이브러리는 수동으로 이주해야 하므로 사용하지 않는 것이 좋습니다.

개발해야 하는 Java 코드 스니펫에서 해당 코드는 가능한 단순하고 작게 작성하는 것이 좋습니다. Java 코드에서 정교화 수준은 기본 평가, 오퍼레이션, 계산, 데이터 형식화, 유형 변환 등과 관련된 스크립팅 순서로 유지되어야 합니다. 좀 더 폭넓고 정교한 응용프로그램 로직이 필요하면 WebSphere Application Server에서 실행되는 EJB를 사용하여 로직을 캡슐화하는 것이 좋습니다. 그런 다음 웹 서비스 호출을 사용하여 해당 EJB를 WebSphere InterChange Server에서 호출하십시오. 개별적으로 이주해야 하는 써드파티 또는 외부 라이브러리보다는 표준 JDK 라이브러리를 사용하십시오. 또한 단일 코드 스니펫 안에 있는 관련된 모든 로직을 수집하고 연결 및 트랜잭션 컨텍스트가 다중 코드 스니펫에 걸쳐 있는 로직은 사용하지 마십시오. 예를 들어, 데이터베이스 오퍼레이션의 경우 연결 확보, 트랜잭션 시작 및 종료, 연결 릴리스 등과 관련된 코드는 하나의 코드 스니펫으로 되어야 합니다.

일반적으로 EIS(Enterprise Information System)와 소통하도록 작성된 코드는 맵 또는 협업 템플리트가 아니라 어댑터 안에 위치해야 합니다. 이것은 일반적으로 아키텍처 디자인에 대한 우수 사례에 해당됩니다. 또한 코드 안에서 연결 관리 및 가능한 JNI(Java Native Interface) 구현과 같은 써드파티 라이브러리 및 관련 고려사항에 대한 전제조건을 생략하는 데 도움을 줍니다.

적합한 예외 핸들을 사용하여 가능한 안전하게 코드를 작성하십시오. 또한 현재 J2SE 환경에서 실행되는 코드라 하더라도 해당 코드를 J2EE 응용프로그램 서버 환경에서 실행할 수 있게 호환되도록 작성하십시오. 정적 변수, 스레드 출력 및 디스크 I/O 금지 등과 같은 J2EE 개발 규칙을 준수하십시오. 이러한 규칙은 일반적으로 준수할 최상의 우수 사례이지만 이식성에 적합해야 합니다.

공통 코드 유틸리티

앞서 설명한 바와 같이 WebSphere InterChange Server 환경에서 통합 아티팩트에 걸쳐 사용할 공통 코드 유틸리티 라이브러리의 개발은 피하는 것이 좋습니다. 통합 아티팩트에 걸쳐 코드 재사용이 필요하면 활동 편집기 도구의 “내 콜렉션” 기능을 활용하는 것이 좋습니다. 또한 WebSphere Application Server에서 실행되는 EJB를 사용하여 로직을 캡슐화하고 웹 서비스 호출을 사용하여 해당 EJB를 WebSphere InterChange Server에서 호출하십시오. 일부 공통 코드 유틸리티 라이브러리는 WebSphere Process Server에서 올바르게 실행될 수도 있지만 사용자는 사용자 정의 유틸리티의 이주에 책임이 있습니다.

데이터베이스 연결 풀

맵 및 협업 템플리트에서 사용자 정의 데이터베이스 연결 풀은 프로세스 인스턴스에 걸친 간단한 데이터 찾아보기 및 좀 더 정교한 상태 관리에 매우 유용합니다. WebSphere InterChange Server에서 데이터베이스 연결 풀은 WebSphere Process Server에서 표준 JDBC 자원으로 렌더링되며 기본 기능은 동일합니다. 그러나 연결 및 트랜잭션이 관리되는 방식은 서로 다를 수도 있습니다.

나중의 이식성을 최대화하려면 협업 템플리트 또는 맵 안의 Java 스니펫 노드에 걸쳐 데이터베이스 트랜잭션을 활성화하지 마십시오. 예를 들어, 연결 확보, 트랜잭션 시작 및 종료, 연결 릴리스 등과 관련된 코드는 하나의 코드 스니펫으로 되어야 합니다.

비즈니스 오브젝트

비즈니스 오브젝트의 개발에 대한 기본 고려사항은 아티팩트 구성을 위해 제공된 도구만 사용하는 것, 명시적 데이터 유형 사용 및 데이터 속성의 길이 사용, 문서화된 API만 활용 등입니다.

WebSphere Process Server 안의 비즈니스 오브젝트는 SDO(Service Data Object)에 기반하며 SDO는 강력한 유형의 데이터 속성을 사용합니다. WebSphere InterChange Server 및 어댑터의 비즈니스 오브젝트의 경우 데이터 속성은 강력한 유형이 아니며 사용자는 때때로 비문자열 데이터 속성에 대해 문자열 데이터 유형을 지정하기도 합니다. WebSphere Process Server의 문제를 방지하려면 데이터 유형의 스펙에서 명시적이어야 합니다.

WebSphere Process Server 안의 비즈니스 오브젝트는 구성요소 간에 전달될 때 런타임 시 직렬화될 수도 있기 때문에, 데이터 속성에 대해 필요한 길이로 명시하여 시스템 자원의 사용을 최소화하는 것이 중요합니다. 예를 들어, 문자열 속성에 최대 255 문자 길이는 사용하지 마십시오. 또한 현재 기본값이 255 문자인 길이 속성에 0을 지정하지 마십시오. 속성에 필요한 정확한 길이를 지정하십시오.

XSD NCName 규칙은 WebSphere Process Server의 비즈니스 오브젝트 속성 이름에 적용되므로 비즈니스 오브젝트 속성의 이름에 공백이나 ":"을 사용하지 마십시오. 공백 또는 ":"을 갖는 비즈니스 오브젝트 속성 이름은 WebSphere Process Server에서 올바르지 않습니다. 이주하기 전에 비즈니스 오브젝트 속성의 이름을 바꾸십시오.

비즈니스 오브젝트에서 배열을 사용하는 경우 맵 및 관계에서 배열에 색인화할 때 배열의 순서에 의존할 수는 없습니다. 이 경우 WebSphere Process Server로 이주되는 생성은 색인 순서를 보장하지 않으며 특히 항목이 삭제되었을 때 그러합니다.

앞서 설명한 바와 같이 비즈니스 오브젝트 정의를 편집하는데 Business Object Designer 도구만을 사용하고 통합 아티팩트 내부의 비즈니스 오브젝트용으로 출력된 API만을 사용해야 합니다.

협업 템플리트

앞에서 설명했던 여러 가이드라인은 협업 템플리트의 개발에 적용됩니다.

프로세스를 메타데이터로 적절하게 설명하려면 협업 템플리트의 작성 및 수정에 항상 Process Designer 도구를 사용하고 메타데이터 파일을 직접 편집하지는 마십시오. 가능하면 활동 편집기 도구에서 메타데이터를 최대한으로 사용하여 필요한 로직을 설명하십시오.

이주에 필요할 수도 있는 수동 재작업을 최소화하려면 협업 템플리트 안의 문서화된 API만 사용하십시오. 정적 변수는 사용하지 마십시오. 대신 비정적 변수 및 협업 특성을 사용하여 비즈니스 로직의 요구사항을 해결하십시오. Java 스니펫에서 Java 규정자 final, transient 및 native를 사용하지 마십시오. 이러한 규정자는 협업 템플리트 이주의 결과인 BPEL Java 스니펫에 강제 적용될 수 없습니다.

나중의 이식성을 최대화하려면 사용자 정의 데이터베이스 연결 풀에 명시적 연결 릴리스 호출 및 명시적 트랜잭션 묶음(예: 명시적 확약 및 명시적 롤백)을 사용하지 마십시오. 대신 컨테이너 관리 암시적 연결 정리 및 암시적 트랜잭션 묶음을 활용하십시오. 또한 협업 템플리트 안의 Java 스니펫 노드에 걸쳐 시스템 연결 및 트랜잭션을 활성화하지 마십시오. 이 사항은 사용자 정의 데이터베이스 연결 풀뿐만 아니라 외부 시스템에 대한 모든 연결에도 적용됩니다. 이미 설명한 바와 같이 외부 EIS를 사용한 오퍼레이션은 어댑터에서 관리되어야 하며 데이터베이스 오퍼레이션과 관련된 코드는 하나의 코드 스니펫 안에 포함되어야만 합니다. 이것은 BPEL 비즈니스 프로세스 구성요소로 렌더링될 때 인터럽트 가능한 플로우로, 선택적으로 배치될 수 있는 협업 안에 필요할 수도 있습니다. 이 경우에 프로세스는 활동 간에 전달되는 상태 및 글로벌 변수 정보만 갖는 몇몇 개별적인 트랜잭션으로 구성될 수 있습니다. 임의의 시스템 연결에 대한 컨텍스트 또는 해당 프로세스 트랜잭션을 확장하는 관련 트랜잭션은 손실됩니다.

협업 템플리트 특성 이름에는 특수 문자를 사용하지 마십시오. 특수 문자는 해당 문자가 이주되는 BPEL 특성 이름에 올바르지 않습니다. 이주에 의해 생성되는 BPEL에서 구문 오류를 피하려면 이주하기 전에 특성의 이름을 바꿔 특수 문자를 제거하십시오.

"this"를 사용하는 변수를 참조하지 마십시오. 예를 들어, "this.inputBusObj" 대신 "inputBusObj"를 사용하십시오.

시나리오 범위의 변수 대신 클래스 레벨 범위의 변수를 사용하십시오. 시나리오 범위는 이주 시에 앞으로 진행되지 않습니다.

Java 스니펫에 선언된 모든 변수를 기본값으로 초기화하십시오. 예를 들어, "Object myObject = null;"과 같이 초기화하십시오. 이주 전에 선언되는 동안 모든 변수가 초기화되는지 확인하십시오.

협업 템플리트의 사용자 수정 가능 섹션에 Java import 문이 없는지 확인하십시오. 협업 템플리트의 정의에서 import 필드를 사용하여 Java 패키지를 가져오도록 지정하십시오.

협업 템플리트에 대해 앞에서 설명했던 여러 가이드라인은 맵에도 적용됩니다.

맵이 메타데이터로 적절하게 설명되려면 맵의 작성 및 수정에 항상 Map Designer 도구를 사용하고 메타데이터 파일을 직접 편집하지는 마십시오. 가능하면 활동 편집기 도구에서 메타데이터를 최대한으로 사용하여 필요한 로직을 설명하십시오.

맵에서 하위 비즈니스 오브젝트를 참조할 때 해당 하위 비즈니스 오브젝트에 대해 하위 맵을 사용하십시오.

Java 코드를 SET에서 "value"로 사용하지 마십시오. 해당 코드는 WebSphere Process Server에 올바르지 않기 때문입니다. 대신 상수를 사용하십시오. 예를 들어, 설정 값이 "xml version=" + "1.0" + " encoding=" + "UTF-8"인 경우 이 값은 WebSphere Process Server에서 유효하지 않습니다. 이 경우에는 이주하기 전에 해당 값을 "xml version=1.0 encoding=UTF-8"로 변경하십시오.

이주에 필요할 수도 있는 수동 재작업을 최소화하려면 협업 템플리트 안의 문서화된 API만 사용하십시오. 정적 변수는 사용하지 마십시오. 대신 비정적 변수 및 협업 특성을 사용하여 비즈니스 로직의 요구사항을 해결하십시오. Java 스니펫에서 Java 규정자 final, transient 및 native를 사용하지 마십시오.

비즈니스 오브젝트에서 배열을 사용하는 경우 맵에서 배열로 색인화할 때 배열 순서에 의존할 수는 없습니다. 이 경우 WebSphere Process Server로 이주되는 생성은 색인 순서를 보장하지 않으며 특히 항목이 삭제되었을 때 그러합니다.

나중의 이식성을 최대화하려면 사용자 정의 데이터베이스 연결 풀에 명시적 연결 릴리스 호출 및 명시적 트랜잭션 묶음(예: 명시적 확약 및 명시적 롤백)을 사용하지 마십시오. 대신 컨테이너 관리 암시적 연결 정리 및 암시적 트랜잭션 묶음을 활용하십시오. 또한 변환 노드 경계에 걸쳐 Java 스니펫 코드에서 시스템 연결 및 트랜잭션을 활성화하지 마십시오. 이 사항은 사용자 정의 데이터베이스 연결 풀뿐만 아니라 외부 시스템에 대한 모든 연결에도 적용됩니다. 이미 설명한 바와 같이 외부 EIS를 사용한 오퍼레이션은 어댑터에서 관리되어야 하며 데이터베이스 오퍼레이션과 관련된 코드는 하나의 코드 스니펫 안에 포함되어야만 합니다.

관계

관계의 경우 관계 정의는 WebSphere Process Server에서 사용하도록 이주될 수 있으며 관계 테이블 스키마 및 인스턴스 데이터는 WebSphere Process Server에서 재사용될 수 있고 또한 WebSphere InterChange Server 및 WebSphere Process Server 간에 동시에 공유됩니다.

관계에 대한 핵심 고려사항은 관련 구성요소를 구성하도록 제공된 도구만 사용하는 것, 통합 아티팩트 내부의 관계용으로 출력된 API만 사용하는 것입니다.

Relationship Designer 도구만을 사용하여 관계 정의를 편집해야 합니다. 또한 WebSphere InterChange Server만 관계 스키마를 구성하도록 허용하십시오. 이 스키마는 관계 정의 배치 시 자동으로 생성됩니다. 데이터베이스 도구 또는 SQL 스크립트를 사용하여 관계 테이블 스키마를 직접 변경하지 마십시오.

또한 관계 테이블 스키마 안의 관계 인스턴스 데이터를 직접 수정하려면 Relationship Designer에서 제공하는 기능을 사용하십시오.

앞서 설명한 바와 같이 통합 아티팩트 안의 관계용으로 출력된 API만 사용해야 합니다.

액세스 프레임워크 클라이언트

CORBA IDL 인터페이스 API를 채택하는 새 클라이언트를 개발하지 마십시오. 이 클라이언트는 WebSphere Process Server에서 지원되지 않습니다.
관련 태스크
WebSphere InterChange Server 이주 확인
WebSphere InterChange Server에서 이주 실패에 대한 처리

피드백
(C) Copyright IBM Corporation 2005, 2006. All Rights Reserved.