[AIX Solaris HP-UX Linux Windows][z/OS]

SCA 애플리케이션 패키지 배치(더 이상 사용되지 않음)

제품은 비즈니스 레벨 애플리케이션의 컴포지션 단위로 여러 유형의 SCA(Service Component Architecture) 아티팩트 배치를 지원합니다. 일반적인 아티팩트에는 압축된 Java™ 아카이브(JAR) 파일이 포함됩니다..zip 파일 및 WAR(웹 애플리케이션 아카이브) 파일.

더 이상 사용되지 않는 기능:8.5.5.19 또는 나중에 SCA(Service Component Architecture) 프로그래밍 모델 및 샘플은 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. 새 SCA 비즈니스 레벨 애플리케이션을 배치할 수 없습니다.

다른 프로그래밍 모델을 사용하도록 애플리케이션을 업데이트하십시오. 사용하는 프로그래밍 모델은 사용자의 애플리케이션에서 이전에 SCA를 통합시켰던 방법에 따라 다릅니다.

바인딩에 SCA를 사용했으면, JAX-RS(Java API for RESTful Web Services) 또는 JMS(Java Message Service)와 같은 사용자 애플리케이션이 몇 표준에 표시되는 방식을 통합합니다. 예를 들어, 애플리케이션 바인딩에 JAX-RS를 사용하십시오. 바인딩 레벨 구현의 복제를 최소화하려면, 공유 코드를 사용하도록 사용자 애플리케이션을 구성하십시오.

장기 전략의 일부로 SCA를 계속 사용하려면 다음 위치에서 애플리케이션을 호스팅하는 것을 고려하세요. IBM Business Process Manager.

다음은 SCA 아티팩트 배치에 대한 세부사항 개요입니다.

JAR 또는 압축 파일 배치

  • 제품은 각 패키지에 대해 하나의 컴포지트 파일을 지원합니다. 제품은 다음과 같은 프로세스를 사용하여 지원할 컴포지트 파일을 판별합니다.
    1. SCA 배치 확장이 META-INF/sca-contribution.xml 파일을 찾아 파일에 정의되어 있는 각 배치 가능 컴포지트의 이름을 가져온 후, QName 값을 사용하여 해당 컴포지트의 모든 디렉토리에서 실제 컴포지트 파일의 이름을 찾습니다. sca-contribution.xml 파일에 컴포지트가 둘 이상인 경우 배치할 컴포지트를 선택할 수 있습니다.
    2. 정의된 META-INF/sca-contribution.xml 파일이 없는 경우 SCA 배치 확장은 META-INF/sca-deployables 디렉토리에서 컴포지트 파일을 찾습니다.
  • 제품은 SCA 스펙과의 불일치를 확인하여 SCA 컴포지트 유효성을 검증합니다.

    스펙 요구사항 중 하나는 최상위 레벨 컴포넌트의 이름의 고유성입니다. 따라서 제품은 최상위 레벨 컴포넌트 이름이 고유한지 유효성을 검증합니다.

    팁: 최상위 구성 요소는 도메인 구성 요소라고도 하며, 일반적으로 다중 서버 설치의 경우 최상위 또는 도메인이 셀이고 단일 서버 설치의 경우 서버 범위입니다.

    제품은 아카이브에서 파일 위치 또는 sca-contribution.xml 파일이 컴포지트 파일을 참조하는지 여부에 상관없이 JAR 또는 압축 파일의 모든 컴포지트 파일의 유효성을 검증합니다. 제품은 일부 서비스 및 참조만 유효성 검증하지 않습니다.

    제품은 유효성 검증 테스트로 작성된 경고 및 오류 메시지를 SystemOut.log 파일에 기록합니다. SCA 컴포지트에서 스펙과 불일치에 대해 확인하려면 로그 파일을 참조하십시오.

    메모: 이 주제에서는 하나 이상의 애플리케이션 서버 로그 파일을 참조합니다. 권장되는 대안으로, HPEL(High Performance Extensible Logging) 로그 및 추적 인프라를 사용하는 대신 서버를 구성할 수 있습니다.SystemOut.log ,SystemErr.log ,trace.log , 그리고activity.log 배포된 파일 및 IBM® i 시스템. 네이티브와 함께 HPEL을 사용할 수도 있습니다. z/OS® 벌목 시설. HPEL을 사용할 경우에는 서버 프로파일 bin 디렉토리에서 LogViewer 명령행 도구를 사용하여 모든 로그 및 추적 정보를 액세스할 수 있습니다. 참조 HPEL 사용에 대한 정보 HPEL 사용에 대한 자세한 내용은 애플리케이션 문제 해결을 참조하세요.
  • 제품은 QName 해석을 위해 다음 프로세스를 사용합니다.
    • 제품은 QName을 사용하여 해당 요소가 사용된 최상위 레벨 컴포지트에 있는 컴포지트 파일을 해결합니다. 예를 들어, <include name="mynamespace:MyService"/> 문은 컴포지트 이름이 MyService이고, targetNameSpace가 mynamespace인 컴포지트 파일을 찾습니다. 다음 규칙이 적용됩니다.
      • name: 외부 컴포지트를 사용합니다.
      • namespace declarations: 외부 컴포지트에 병합됩니다.
      • targetNamespace: 외부 컴포지트를 사용합니다(동일해야 함).
      • local: 컴포지트를 사용합니다(동일한 것이 선호되지만 필수는 아님).
      • requires(intents) 및 policySets: 호환 가능하고 외부 컴포지트에 집계되어야 합니다.

      배치 가능한 컴포지트 파일에는 name 및 targetNamespace 값이 있어야 합니다. name 및 targetNamespace 값이 결합되어 컴포지트 파일의 QName을 구성합니다.

    • 컴포지트가 최상위 레벨 컴포지트의 컴포넌트 구현으로 사용되는 경우에도 QName을 사용하여 컴포지트를 해석합니다. 예를 들어 <implementation.composite name="mynamespace:MyComposite"/> 문은 제품 관리에서 컴포지트 이름이 MyComposite이고 targetNamespace가 mynamespace인 컴포지트 파일을 찾도록 합니다.
  • JAR 파일은 최상위 레벨에 다른 JAR 파일을 포함할 수 있습니다. 포함된 JAR 파일은 클래스 경로에서 사용할 수 있습니다. 그러나 이러한 JAR 파일 내의 모든 아카이브는 사용할 수 없습니다. 제품은 한 레벨의 임베디드 JAR 파일을 지원합니다.

WAR 파일 배치

  • WAR 파일의 컴포지트 파일 이름은 default.composite로 지정해야 합니다. WAR 파일에 없는 컴포지트 파일의 이름은 아무 이름이나 사용할 수 있습니다.
  • default.composite 컴포지트 파일은 META-INF/sca-deployables 디렉토리의 WAR 파일에 포함되어야 합니다.
  • META-INF/sca-deployables 디렉토리에는 컴포지트 파일이 하나만 있어야 합니다. META-INF/sca-deployables 디렉토리에 컴포지트 파일이 두 개 이상 있는 경우 제품은 유효성 검증 오류를 리턴하고 WAR 파일 배치를 중지합니다.

    그러나 META-INF/sca-deployables 이외의 디렉토리에 다른 컴포지트 파일을 배치하여 META-INF/sca-deployables 디렉토리에 있는 최상위 레벨 컴포지트의 컴포지트 파일을 참조할 수 있습니다.

  • 제품은 META-INF 디렉토리에 있는 WAR 파일 내에 sca-contribution.xml 파일을 보유하는 것은 지원하지 않습니다. 제품이 sca-contribution.xml 파일을 발견하면 유효성 검증 오류를 리턴하고 WAR 파일 배치를 중지합니다.

참고 및 제한사항

  • 컨트리뷰션을 구성하기 위한 관리 콘솔 페이지는 제공되지 않습니다.
  • 다른 컨트리뷰션 또는 JAR(contribution.xml)에서 패키지나 네임스페이스를 가져오는 경우 자체 자산을 가져오기 전에 해당 컨트리뷰션을 먼저 자산으로 가져와야 할 수 있습니다.

    예를 들어, 컨트리뷰션 A가 컨트리뷰션 B의 JAR 파일을 가져온다고 가정해 보십시오. 컨트리뷰션 A는 컨트리뷰션 B에 종속되므로 컨트리뷰션 A를 가져오기 전에 컨트리뷰션 B를 먼저 가져와야 합니다.

  • 클래스 로더 경계에서 로컬 인터페이스를 사용할 수 없습니다. 클래스 로더 경계를 넘으려면 원격 가능 인터페이스를 사용하십시오.