검색

Apache CXF 개발 가이드

download PDF
Red Hat Fuse 7.11

Apache CXF 웹 서비스를 사용하여 애플리케이션 개발

Red Hat Fuse Documentation Team

초록

Apache CXF를 사용한 웹 서비스 개발 가이드.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지에서 참조하십시오.

I 부. WSDL 계약 작성

이 부분에서는 WSDL을 사용하여 웹 서비스 인터페이스를 정의하는 방법을 설명합니다.

1장. WSDL 계약 소개

초록

WSDL 문서는 웹 서비스 설명 언어와 여러 가지 가능한 확장을 사용하여 서비스를 정의합니다. 문서에는 논리적 부분이 있고 구체적인 부분이 있습니다. 계약의 추상 부분은 구현 중립 데이터 유형 및 메시지의 측면에서 서비스를 정의합니다. 문서의 구체적인 부분은 서비스를 구현하는 엔드포인트가 외부 세계와 상호 작용하는 방식을 정의합니다.

서비스를 설계하는 데 권장되는 접근 방식은 코드를 작성하기 전에 WSDL 및 XML 스키마에서 서비스를 정의하는 것입니다. WSDL 문서를 직접 편집할 때는 문서와 올바른 정보가 올바른지 확인해야 합니다. 이 작업을 수행하려면 WSDL에 대해 어느 정도 익숙해야 합니다. W3C 웹 사이트 www.w3.org 에서 표준을 찾을 수 있습니다.

1.1. WSDL 문서의 구조

1.1.1. 개요

WSDL 문서는 루트 정의 요소에 포함된 요소의 컬렉션을 간단히 설명합니다. 이러한 요소는 서비스와 해당 서비스를 구현하는 엔드포인트가 액세스하는 방법을 설명합니다.

WSDL 문서에는 다음 두 가지 부분이 있습니다.

1.1.2. 논리 부분

WSDL 문서의 논리적 부분에는 유형 , 메시지, portType 요소가 포함되어 있습니다. 서비스의 인터페이스와 서비스에서 교환된 메시지를 설명합니다. 형식 요소 내에서 XML 스키마는 메시지를 구성하는 데이터의 구조를 정의하는 데 사용됩니다.Within the types element, XML Schema is used to define the structure of the data that make up the messages. 많은 메시지 요소는 서비스에서 사용하는 메시지의 구조를 정의하는 데 사용됩니다. portType 요소에는 서비스에서 노출하는 작업에서 보낸 메시지를 정의하는 하나 이상의 작업 요소가 포함되어 있습니다.

1.1.3. 세부 사항

WSDL 문서의 구체적인 부분에는 바인딩서비스 요소가 포함되어 있습니다. 서비스를 구현하는 끝점이 외부 세계에 연결하는 방법을 설명합니다. 바인딩 요소는 메시지 요소에 의해 설명된 데이터 단위가 SOAP와 같은 구체적인 유선 데이터 형식으로 매핑되는 방법을 설명합니다. 서비스 요소에는 서비스를 구현하는 엔드포인트를 정의하는 하나 이상의 포트 요소가 포함됩니다.

1.2. WSDL 요소

WSDL 문서는 다음과 같은 요소로 구성되어 있습니다.

  • definitions - WSDL 문서의 루트 요소입니다. 이 요소의 특성은 WSDL 문서의 이름, 문서의 대상 네임스페이스, WSDL 문서에서 참조되는 네임스페이스의 단축 정의를 지정합니다.
  • Type - 서비스에서 사용하는 메시지의 빌딩 블록을 구성하는 데이터 단위의 XML 스키마 정의입니다. 데이터 유형 정의에 대한 자세한 내용은 2장. 논리 데이터 단위 정의 을 참조하십시오.
  • Message - 서비스 작업을 호출하는 동안 교환된 메시지에 대한 설명입니다. 이러한 요소는 서비스를 구성하는 작업의 인수를 정의합니다. 메시지 정의에 대한 자세한 내용은 3장. 서비스에서 사용하는 논리 메시지 정의 을 참조하십시오.
  • portType - 서비스의 논리 인터페이스를 설명하는 작업 요소의 컬렉션입니다. 포트 유형 정의에 대한 자세한 내용은 4장. 논리 인터페이스 정의 을 참조하십시오.
  • 작업 - 서비스에서 수행한 작업에 대한 설명입니다. 작업은 작업을 호출할 때 두 끝점 간에 전달되는 메시지에 의해 정의됩니다. 작업 정의에 대한 자세한 내용은 “작업” 을 참조하십시오.
  • 바인딩 - 끝점에 대한 구체적인 데이터 형식 사양입니다. 바인딩 요소는 추상 메시지가 끝점에서 사용하는 구체적인 데이터 형식으로 매핑되는 방법을 정의합니다. 이 요소는 매개 변수 순서 및 반환 값과 같은 특정 값을 지정합니다.
  • Service - 관련 포트 요소의 컬렉션입니다. 이러한 요소는 끝점 정의를 구성하는 리포지토리입니다.
  • port - 바인딩 및 물리적 주소로 정의된 끝점입니다. 이러한 요소는 모든 추상 정의와 함께 전송 세부 정보를 가져오고, 서비스가 노출되는 물리적 끝점을 정의합니다.

1.3. 계약 설계

서비스에 대한 WSDL 계약을 설계하려면 다음 단계를 수행해야 합니다.

  1. 서비스에서 사용하는 데이터 유형을 정의합니다.
  2. 서비스에서 사용하는 메시지를 정의합니다.
  3. 서비스의 인터페이스를 정의합니다.
  4. 각 인터페이스에서 사용하는 메시지 간 바인딩과 유선 데이터의 구체적인 표시를 정의합니다.
  5. 각 서비스에 대한 전송 세부 정보를 정의합니다.

2장. 논리 데이터 단위 정의

초록

WSDL 계약 복잡한 데이터 형식의 서비스를 설명하는 경우 XML 스키마를 사용하여 논리 단위로 정의됩니다.

2.1. 논리 데이터 단위 소개

서비스를 정의할 때 가장 먼저 고려해야 할 것은 노출된 작업에 대한 매개 변수로 사용되는 데이터가 표현되는 방법입니다. 고정 데이터 구조를 사용하는 프로그래밍 언어로 작성된 애플리케이션과 달리 서비스는 여러 애플리케이션에서 사용할 수 있는 논리 단위로 데이터를 정의해야 합니다. 여기에는 두 단계가 포함됩니다.

  1. 데이터를 서비스의 물리적 구현에서 사용하는 데이터 형식으로 매핑할 수 있는 논리 단위로 분할
  2. 작업을 수행하기 위해 논리 단위를 엔드포인트 간에 전달되는 메시지로 결합

이 장에서는 첫 번째 단계에 대해 설명합니다. 3장. 서비스에서 사용하는 논리 메시지 정의 두 번째 단계에 대해 설명합니다.

2.2. 데이터를 논리 데이터 단위로 매핑

2.2.1. 개요

서비스를 구현하는 데 사용되는 인터페이스는 작업 매개 변수를 XML 문서로서 나타내는 데이터를 정의합니다. 이미 구현된 서비스에 대한 인터페이스를 정의하는 경우 구현된 작업의 데이터 형식을 메시지로 어셈블할 수 있는 XML 요소를 구분하여 변환해야 합니다. 처음부터 시작하는 경우 메시지가 빌드된 빌딩 블록을 결정해야 구현 관점에서 이해할 수 있습니다.

2.2.2. 서비스 데이터 단위를 정의하는 데 사용 가능한 유형 시스템

WSDL 사양에 따르면 WSDL 계약에서 데이터 유형을 정의하기 위해 선택한 모든 유형 시스템을 사용할 수 있습니다. 그러나 W3C 사양은 XML 스키마가 WSDL 문서의 기본 표준 형식 시스템이라고 명시되어 있습니다. 따라서 XML 스키마는 Apache CXF의 내장 유형 시스템입니다.

2.2.3. 형식 시스템으로 XML 스키마

XML 스키마는 XML 문서를 구성하는 방법을 정의하는 데 사용됩니다. 이 작업은 문서를 구성하는 요소를 정의하여 수행됩니다. 이러한 요소는 xsd:int 와 같은 네이티브 XML 스키마 유형을 사용하거나 사용자가 정의한 형식을 사용할 수 있습니다. 사용자 정의 형식은 XML 요소의 조합을 사용하여 빌드되거나 기존 형식을 제한하여 정의됩니다.User defined types are either built up using combinations of XML elements or they are defined by restricting existing types. 형식 정의와 요소 정의를 결합하면 복잡한 데이터를 포함할 수 있는 복잡한 XML 문서를 만들 수 있습니다.

WSDL XML 스키마에서 사용되는 경우 서비스와 상호 작용하는 데 사용되는 데이터를 보유하는 XML 문서의 구조를 정의합니다. 서비스에서 사용하는 데이터 단위를 정의할 때 메시지 파트의 구조를 지정하는 유형으로 정의할 수 있습니다. 또한 데이터 단위를 메시지 부분을 구성하는 요소로 정의할 수도 있습니다.

2.2.4. 데이터 단위 생성에 대한 고려 사항

서비스를 구현할 때 사용하는 유형을 직접 매핑하는 논리 데이터 단위를 생성하는 것이 좋습니다. 이 접근 방식이 효과가 있고 RPC 스타일 애플리케이션을 빌드하는 모델을 면밀하게 따르지만, 서비스 지향 아키텍처의 일부를 구축하는 데 반드시 이상적인 것은 아닙니다.

웹 서비스 상호 운용성 조직의 WS-I 기본 프로필은 데이터 단위를 정의하는 데 필요한 여러 지침을 제공하며 http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#WSDLTYPES 에서 액세스할 수 있습니다. 또한 W3C에서는 XML 스키마를 사용하여 WSDL 문서의 데이터 유형을 표현하기 위한 다음 지침도 제공합니다.

  • 속성이 아닌 요소를 사용합니다.
  • 프로토콜별 유형을 기본 유형으로 사용하지 마십시오.

2.3. 계약에 데이터 단위 추가

2.3.1. 개요

WSDL 계약을 만드는 방법에 따라 새로운 데이터 정의를 만들려면 다양한 양의 지식이 필요합니다. Apache CXF GUI 도구는 XML 스키마를 사용하여 데이터 유형을 설명하는 여러 가지 도움말을 제공합니다. 다른 XML 편집기는 다양한 수준의 지원을 제공합니다. 어떤 편집기를 선택하든 결과 계약이 어떻게 보이는지에 대한 지식을 갖는 것이 좋습니다.

2.3.2. 절차

WSDL 계약에 사용되는 데이터를 정의하려면 다음 단계가 포함됩니다.

  1. 계약에서 설명하는 인터페이스에서 사용되는 모든 데이터 단위를 결정합니다.
  2. 계약에서 형식 요소를 만듭니다.Create a types element in your contract.
  3. 예 2.1. “WSDL 계약의 스키마 항목” 에 표시된 스키마 요소를 type 요소의 자식으로 생성합니다.

    targetNamespace 속성은 새 데이터 형식이 정의된 네임스페이스를 지정합니다. 가장 좋은 방법은 대상 네임스페이스에 대한 액세스를 제공하는 네임스페이스도 정의하는 것입니다. 나머지 항목은 변경하지 않아야 합니다.

    예 2.1. WSDL 계약의 스키마 항목

    <schema targetNamespace="http://schemas.iona.com/bank.idl"
            xmlns="http://www.w3.org/2001/XMLSchema"
            xmlns:xsd1="http://schemas.iona.com/bank.idl"
            xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
  4. 요소의 컬렉션인 각 복잡한 형식에 대해 complexType 요소를 사용하여 데이터 형식을 정의합니다. 2.5.1절. “데이터 구조 정의” 을 참조하십시오.
  5. 각 배열에 대해 complexType 요소를 사용하여 데이터 유형을 정의합니다. 2.5.2절. “배열 정의” 을 참조하십시오.
  6. 단순 형식에서 파생되는 각 복잡한 형식에 대해 simpleType 요소를 사용하여 데이터 형식을 정의합니다.For each complex type that is derived from a simple type, define the data type using a simpleType element. 2.5.4절. “제한으로 유형 정의” 을 참조하십시오.
  7. 열거된 각 형식에 대해 simpleType 요소를 사용하여 데이터 형식을 정의합니다. 2.5.5절. “열거된 유형 정의” 을 참조하십시오.
  8. 각 요소에 대해 요소 요소 를 사용하여 정의합니다. 2.6절. “요소 정의” 을 참조하십시오.

2.4. XML 스키마 간단한 유형

2.4.1. 개요

메시지 부분이 간단한 유형이 될 경우 이를 위한 유형 정의를 생성할 필요가 없습니다. 그러나 계약에 정의된 인터페이스에서 사용하는 복잡한 유형은 간단한 유형을 사용하여 정의됩니다.

2.4.2. 간단한 유형 입력

XML Schema 단순 유형은 주로 계약의 유형 섹션에 사용되는 요소 요소에 배치됩니다. 또한 제한 요소 및 확장 요소의 기본 특성에 사용됩니다.

간단한 유형은 xsd 접두사를 사용하여 항상 입력합니다. 예를 들어 요소가 int 임을 지정하려면 예 2.2. “간단한 유형으로 요소 정의” 에 표시된 대로 type 속성에 xsd:int 를 입력합니다.

예 2.2. 간단한 유형으로 요소 정의

<element name="simpleInt" type="xsd:int" />

2.4.3. 지원되는 XSD 간단한 유형

Apache CXF는 다음과 같은 XML 스키마 간단한 유형을 지원합니다.

  • xsd:string
  • xsd:normalizedString
  • xsd:int
  • xsd:unsignedInt
  • xsd:long
  • xsd:unsignedLong
  • xsd:short
  • xsd:unsignedShort
  • xsd:float
  • xsd:double
  • xsd:boolean
  • xsd:byte
  • xsd:unsignedByte
  • xsd:integer
  • xsd:positiveInteger
  • xsd:negativeInteger
  • xsd:nonPositiveInteger
  • xsd:nonNegativeInteger
  • xsd:decimal
  • xsd:dateTime
  • xsd:time
  • xsd:date
  • xsd:QName
  • xsd:base64Binary
  • xsd:hexBinary
  • xsd:ID
  • xsd:token
  • xsd:language
  • xsd:Name
  • xsd:NCName
  • xsd:NMTOKEN
  • xsd:anySimpleType
  • xsd:anyURI
  • xsd:gYear
  • xsd:gMonth
  • xsd:gDay
  • xsd:gYearMonth
  • xsd:gMonthDay

2.5. 복잡한 데이터 유형 정의

초록

XML 스키마는 단순 데이터 형식에서 복잡한 데이터 구조를 구축하기 위한 유연하고 강력한 메커니즘을 제공합니다. 요소 및 속성 시퀀스를 만들어 데이터 구조를 만들 수 있습니다.You can create data structures by creating a sequence of elements and attributes. 정의된 유형을 확장하여 더욱 복잡한 유형을 생성할 수도 있습니다.

복잡한 데이터 구조를 빌드하는 것 외에도 열거된 형식, 특정 범위의 값이 있는 데이터 형식 또는 기본 형식을 확장하거나 제한하여 특정 패턴을 따라야 하는 데이터 형식도 설명할 수 있습니다.In addition to building complex data structures, you can also describe specialized types such as enumerated types, data types that have a specific range of values, or data types that need to follow certain patterns by either extending or restricting the primitive types.

2.5.1. 데이터 구조 정의

2.5.1.1. 개요

XML 스키마에서 데이터 필드 컬렉션인 데이터 단위는 complexType 요소를 사용하여 정의됩니다. 복잡한 유형을 지정하려면 다음 세 가지 정보가 필요합니다.

  1. 정의된 형식의 이름은 complexType 요소의 name 특성에 지정됩니다.
  2. complexType 의 첫 번째 자식 요소는 유선에 배치될 때 구조 필드의 동작을 설명합니다. “복잡한 유형 종류” 을 참조하십시오.
  3. 정의된 구조의 각 필드는 complexType 요소 의 손자인 요소에 정의됩니다. “구조의 부분 정의” 을 참조하십시오.

예를 들어 예 2.3. “간단한 구조” 에 표시된 구조는 두 개의 요소가 있는 복잡한 유형으로 XML 스키마로 정의됩니다.

예 2.3. 간단한 구조

struct personalInfo
{
  string name;
  int age;
};

예 2.4. “복잡한 유형” 예 2.3. “간단한 구조” 에 정의된 구조의 사용 가능한 XML 스키마 매핑을 보여 줍니다. 예 2.4. “복잡한 유형” 로 정의된 구조는 nameage 의 두 가지 요소를 포함하는 메시지를 생성합니다.

.

예 2.4. 복잡한 유형

<complexType name="personalInfo">
  <sequence>
    <element name="name" type="xsd:string" />
    <element name="age" type="xsd:int" />
  </sequence>
</complexType>

2.5.1.2. 복잡한 유형 종류

XML 스키마에는 XML 문서를 표시하고 유선으로 전달될 때 복잡한 형식의 필드를 구성하는 방법을 설명하는 세 가지 방법이 있습니다. complexType 요소의 첫 번째 자식 요소는 사용 중인 복잡한 유형을 결정합니다. 표 2.1. “복잡한 유형 설명자 요소” 복잡한 유형 동작을 정의하는 데 사용되는 요소를 보여줍니다.

표 2.1. 복잡한 유형 설명자 요소
요소복잡한 유형 동작

순서

모든 복잡한 유형의 필드가 있을 수 있으며 유형 정의에 지정된 순서에 있어야 합니다.

all

모든 복잡한 유형의 필드는 존재할 수 있지만 임의의 순서로 있을 수 있습니다.

choice

구조의 요소 중 하나만 메시지에 배치할 수 있습니다.

예 2.5. “간단한 복잡한 선택 유형” 에 표시된 대로 선택 요소를 사용하여 구조가 정의된 경우 name 요소 또는 age 요소와 함께 메시지를 생성합니다.

예 2.5. 간단한 복잡한 선택 유형

<complexType name="personalInfo">
  <choice>
    <element name="name" type="xsd:string"/>
    <element name="age" type="xsd:int"/>
  </choice>
</complexType>

2.5.1.3. 구조의 부분 정의

요소 요소 를 사용하여 구조를 구성하는 데이터 필드를 정의합니다. 모든 complexType 요소에는 하나 이상의 요소 가 포함되어야 합니다. complexType 요소 의 각 요소는 정의된 데이터 구조의 필드를 나타냅니다.

데이터 구조의 필드를 완전히 설명하기 위해 요소 요소에 는 다음 두 가지 필수 특성이 있습니다.

  • name 속성은 데이터 필드의 이름을 지정하고 정의된 복잡한 유형 내에서 고유해야 합니다.
  • type 속성은 필드에 저장된 데이터 유형을 지정합니다. 형식은 XML Schema 단순 유형 중 하나이거나 계약에 정의된 이름이 지정된 복잡한 유형일 수 있습니다.

nametype 외에도요소 요소에minOcurrsmaxOccurs 라는 두 가지 일반적으로 사용되는 선택적 속성이 있습니다. 이러한 속성은 구조에서 필드가 발생하는 횟수에 바인딩됩니다. 기본적으로 각 필드는 복잡한 유형에서 한 번만 수행됩니다. 이러한 특성을 사용하여 필드에 필요한 횟수 또는 구조에 나타날 수 있는 횟수를 변경할 수 있습니다. 예를 들어 예 2.6. “발생 제약 조건을 사용하는 간단한 복합 유형” 과 같이 최소 세 번 이상 발생해야 하는 필드인 previous Job을 정의할 수 있으며, 7번 이상은 지정할 수 없습니다.

예 2.6. 발생 제약 조건을 사용하는 간단한 복합 유형

<complexType name="personalInfo">
  <all>
    <element name="name" type="xsd:string"/>
    <element name="age" type="xsd:int"/>
    <element name="previousJobs" type="xsd:string:
             minOccurs="3" maxOccurs="7"/>
  </all>
</complexType>

minOccurs 를 사용하면 예 2.7. “minOccurs를 0으로 설정한 간단한 복합 유형” 에 표시된 대로 minOccurs 를 0으로 설정하여 age 필드를 선택적으로 만들 수도 있습니다. 이 경우 사용 기간 을 생략할 수 있으며 데이터는 계속 유효합니다.

예 2.7. minOccurs를 0으로 설정한 간단한 복합 유형

<complexType name="personalInfo">
  <choice>
    <element name="name" type="xsd:string"/>
    <element name="age" type="xsd:int" minOccurs="0"/>
  </choice>
</complexType>

2.5.1.4. 속성 정의

XML 문서에서 특성은 요소의 태그에 포함됩니다. 예를 들어 아래 코드의 complexType 요소에서 name 은 특성입니다. 복잡한 유형의 특성을 지정하려면 complexType 요소 정의에 특성 요소를 정의합니다. 특성 요소는 모든 , 시퀀스 또는 선택 요소 이후에만 나타날 수 있습니다.An attribute element can appear only after the all,sequence, or choice element. 각 복잡한 유형의 특성에 대해 하나의 특성 요소를 지정합니다. 모든 특성 요소는 complexType 요소의 직접 자식이어야 합니다.

예 2.8. 속성이 있는 복합 유형

<complexType name="personalInfo">
  <all>
    <element name="name" type="xsd:string"/>
    <element name="previousJobs" type="xsd:string"
             minOccurs="3" maxOccurs="7"/>
  </all>
  <attribute name="age" type="xsd:int" use="required" />
</complexType>

이전 코드에서 특성 요소는 personalInfo 복잡한 형식에 age 속성이 있음을 지정합니다.In the previous code, the attribute element specifies that the personalInfo complex type has an age attribute. attribute 요소에는 다음과 같은 속성이 있습니다.

  • name - 특성을 식별하는 문자열을 지정하는 필수 특성입니다.
  • type - 필드에 저장된 데이터의 유형을 지정합니다. 형식은 XML Schema 단순 유형 중 하나일 수 있습니다.
  • 이 특성 갖는 데 복잡한 유형이 필요한지 여부를 지정하는 선택적 특성입니다. 유효한 값은 필수 또는 선택적 입니다. 기본값은 속성이 선택 사항입니다.

특성 요소에서 특성 의 기본값을 지정할 수 있는 선택적 default 특성을 지정할 수 있습니다.

2.5.2. 배열 정의

2.5.2.1. 개요

Apache CXF는 계약에서 배열을 정의하는 두 가지 방법을 지원합니다. 첫 번째는 maxOccurs 특성에 값이 1보다 큰 단일 요소를 사용하여 복잡한 형식을 정의합니다. 두 번째는 SOAP 배열을 사용하는 것입니다. SOAP 배열은 다차원 배열을 쉽게 정의하고 스파스로 채워진 배열을 전송할 수 있는 기능과 같은 추가 기능을 제공합니다.

2.5.2.2. 복합 형식 배열

복합 형식 배열은 시퀀스 복잡한 유형의 특수한 경우입니다. 단일 요소로 복잡한 유형을 정의하고 maxOccurs 특성에 대한 값을 지정하기만 하면 됩니다. 예를 들어, 20개의 부동 소수점 숫자로 이루어진 배열을 정의하려면 예 2.9. “복잡한 유형 배열” 에 표시된 것과 유사한 복잡한 유형을 사용합니다.

예 2.9. 복잡한 유형 배열

<complexType name="personalInfo">
  <element name="averages" type="xsd:float" maxOccurs="20"/>
</complexType>

minOccurs 특성의 값을 지정할 수도 있습니다.You can also specify a value for the minOccurs attribute.

2.5.2.3. SOAP 배열

SOAP 배열은 wsdl:arrayType 요소를 사용하여 SOAP-ENC:Array 기본 형식에서 파생하여 정의됩니다. 이에 대한 구문은 예 2.10. “wsdl:arrayType을 사용하여 파생되는 SOAP 배열의 구문” 에 표시되어 있습니다. definitions 요소가 xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 를 선언하는지 확인합니다.

예 2.10. wsdl:arrayType을 사용하여 파생되는 SOAP 배열의 구문

<complexType name="TypeName">
  <complexContent>
    <restriction base="SOAP-ENC:Array">
      <attribute ref="SOAP-ENC:arrayType"
                 wsdl:arrayType="ElementType<ArrayBounds>"/>
    </restriction>
  </complexContent>
</complexType>

TypeName 은 이 구문을 사용하여 새로 정의된 배열 유형의 이름을 지정합니다. elementType 은 배열의 요소 형식을 지정합니다. ArrayBounds 배열의 차원 수를 지정합니다. 단일 차원 배열을 지정하려면 [].2를 사용하여 2 차원 배열을 지정하려면 [][] 또는 [,] 를 사용합니다.

예를 들어 예 2.11. “SOAP 배열의 정의” 에 표시된 SOAP 배열인 SOAPStrings는 1차원 문자열 배열을 정의합니다. wsdl:arrayType 속성은 배열 요소, xsd:string 및 차원의 수를 지정합니다. [] 은 하나의 차원을 의미합니다.

예 2.11. SOAP 배열의 정의

<complexType name="SOAPStrings">
  <complexContent>
    <restriction base="SOAP-ENC:Array">
      <attribute ref="SOAP-ENC:arrayType"
                 wsdl:arrayType="xsd:string[]"/>
    </restriction>
  </complexContent>
</complexType>

SOAP 1.1 사양에 설명된 대로 간단한 요소를 사용하여 SOAP Array를 설명할 수도 있습니다. 이에 대한 구문은 예 2.12. “요소를 사용하여 파생되는 SOAP 배열의 구문” 에 표시되어 있습니다.

예 2.12. 요소를 사용하여 파생되는 SOAP 배열의 구문

<complexType name="TypeName">
  <complexContent>
    <restriction base="SOAP-ENC:Array">
      <sequence>
        <element name="ElementName" type="ElementType"
                 maxOccurs="unbounded"/>
      </sequence>
    </restriction>
  </complexContent>
</complexType>

이 구문을 사용하는 경우 요소의 maxOccurs 특성은 항상 unbounded 로 설정해야 합니다.

2.5.3. 확장으로 유형 정의

대부분의 주요 코딩 언어와 마찬가지로 XML 스키마를 사용하면 다른 데이터 형식에서 일부 요소를 상속하는 데이터 형식을 만들 수 있습니다. 이를 확장 기능으로 유형을 정의라고 합니다. 예를 들어, planet 이라는 새 요소를 추가하여 예 2.4. “복잡한 유형” 에 정의된 personalInfo 구조를 확장하는anInfo라는 새 유형을 만들 수 있습니다.

확장으로 정의된 유형에는 네 가지 부분이 있습니다.

  1. 형식 이름은 complexType 요소의 name 특성으로 정의됩니다.
  2. complexContent 요소는 새 형식에 둘 이상의 요소를 갖도록 지정합니다.

    참고

    복잡한 형식에 새 특성만 추가하는 경우 간단한Content 요소를 사용할 수 있습니다.

  3. 기본 형식이라고 하는 새 형식을 파생 되는 형식은 확장 요소의 기본 특성에 지정됩니다.The type from which the new type is derived, called the base type, is specified in the base attribute of the extension element.
  4. 새 유형의 요소 및 특성은 일반 복잡한 유형의 경우와 동일하게 확장 요소에 정의됩니다.

예를 들어, 외계인Info예 2.13. “확장 기능으로 정의된 유형” 과 같이 정의됩니다.

예 2.13. 확장 기능으로 정의된 유형

<complexType name="alienInfo">
  <complexContent>
    <extension base="xsd1:personalInfo">
      <sequence>
        <element name="planet" type="xsd:string"/>
      </sequence>
    </extension>
  </complexContent>
</complexType>

2.5.4. 제한으로 유형 정의

2.5.4.1. 개요

XML 스키마를 사용하면 XML 스키마 단순 형식의 가능한 값을 제한하여 새 형식을 만들 수 있습니다.XML Schema allows you to create new types by restricting the possible values of an XML Schema simple type. 예를 들어 SSN은 정확히 9자로 구성된 간단한 유형 SSN 을 정의할 수 있습니다.For example, you can define a simple type, SSN , which is a string of exactly 9 characters. 단순 형식을 제한하여 정의한 새 형식은 simpleType 요소를 사용하여 정의됩니다.

제한으로 유형을 정의하려면 다음 세 가지 사항이 필요합니다.

  1. 새 형식의 이름은 simpleType 요소의 name 특성으로 지정됩니다.
  2. 기본 형식 이라고 하는 새 형식을 파생 되는 단순 형식은 제한 요소에 지정 됩니다.The simple type from which the new type is derived, called the base type, is specified in the restriction element. “기본 유형 지정” 을 참조하십시오.
  3. 기본 유형에 배치된 제한을 정의하는 facets 라는 규칙은 제한 요소의 자식으로 정의됩니다. “제한 정의” 을 참조하십시오.

2.5.4.2. 기본 유형 지정

기본 유형은 새 유형을 정의하도록 제한되는 유형입니다. 제한 요소를 사용하여 지정됩니다. restriction 요소는 simpleType 요소의 유일한 자식이며 기본 유형을 지정하는 하나의 속성 base 를 갖습니다. 기본 유형은 XML Schema 간단한 유형 중 하나일 수 있습니다.

예를 들어, xsd:int 의 값을 제한하여 새 유형을 정의하려면 예 2.14. “기본 유형으로 int 사용” 에 표시된 정의를 사용합니다.

예 2.14. 기본 유형으로 int 사용

<simpleType name="restrictedInt">
  <restriction base="xsd:int">
    ...
  </restriction>
</simpleType>

2.5.4.3. 제한 정의

기본 유형에 따라 제한 사항을 정의하는 규칙을 facets 라고 합니다. facet는 facet가 적용되는 방법을 정의하는 하나의 속성 값이 있는 요소입니다. 사용 가능한 facet 및 유효한 설정은 기본 유형에 따라 다릅니다. 예를 들어 xsd:string 은 다음을 포함하여 6개의 facet를 지원합니다.

  • 길이
  • minLength
  • maxLength
  • 패턴
  • whitespace
  • enumeration

각 facet 요소는 제한 요소의 자식입니다.

2.5.4.4. 예제

예 2.15. “SSN 단순 유형 설명” 는 소셜 보안 번호를 나타내는 간단한 유형의 SSN 의 예를 보여줍니다. 결과 유형은 xxx-xx-xxxx. <SSN>032-43-9876<SSN>은 이 유형의 요소에 유효한 값이지만 <SSN>032439876</SSN>은 그렇지 않습니다.

예 2.15. SSN 단순 유형 설명

<simpleType name="SSN">
  <restriction base="xsd:string">
    <pattern value="\d{3}-\d{2}-\d{4}"/>
  </restriction>
</simpleType>

2.5.5. 열거된 유형 정의

2.5.5.1. 개요

XML 스키마의 열거된 형식은 제한에 따라 정의의 특별한 사례입니다. 이러한 항목은 모든 XML 스키마 기본 형식에서 지원하는 열거 facet를 사용하여 설명합니다. 대부분의 최신 프로그래밍 언어에서 열거된 형식과 마찬가지로, 이 유형의 변수는 지정된 값 중 하나만 가질 수 있습니다.

2.5.5.2. XML 스키마에서 열거형 정의

열거형 정의의 구문은 예 2.16. “열거형 구문” 에 표시되어 있습니다.

예 2.16. 열거형 구문

<simpleType name="EnumName">
  <restriction base="EnumType">
    <enumeration value="Case1Value"/>
    <enumeration value="Case2Value"/>
    ...
    <enumeration value="CaseNValue"/>
  </restriction>
</simpleType>

열거형 형식의 이름 을 지정합니다.Specifies the name of the enumeration type. EnumType 은 case 값의 형식을 지정합니다. caseNValue . 여기서 N 은 열거의 각 특정 사례에 대한 값을 지정합니다. CaseNValue, where N is any number one or greater, specifies the value for each specific case of the enumeration. 열거된 형식은 임의의 수의 대/소문자 값을 가질 수 있지만 간단한 형식에서 파생되기 때문에 한 번에 하나의 케이스 값만 유효합니다.An enumerated type can have any number of case values, but because it is derived from a simple type, only one of the case values is valid at a time.

2.5.5.3. 예제

예를 들어 예 2.17. “widgetSize enumeration” 에 표시된 열거형 위젯Size에 정의된 요소가 포함된 XML 문서는 <wid getSize >big>big <widgetSize>가 포함된 경우 유효하지만 <widgetSize>big,mungo</widgetSize>가 포함된 경우 유효하지 않습니다.

예 2.17. widgetSize enumeration

<simpleType name="widgetSize">
  <restriction base="xsd:string">
    <enumeration value="big"/>
    <enumeration value="large"/>
    <enumeration value="mungo"/>
  </restriction>
</simpleType>

2.6. 요소 정의

XML 스키마의 요소는 스키마에서 생성된 XML 문서에 있는 요소의 인스턴스를 나타냅니다. 가장 기본적인 요소는 단일 요소로 구성됩니다. 복잡한 형식의 멤버를 정의하는 데 사용되는 요소 요소와 마찬가지로 다음 세 가지 특성이 있습니다.

  • XML 문서에 표시되는 요소의 이름 을 지정하는 필수 특성입니다.A required attribute that specifies the name of the element as it appears in an XML document.
  • type - 요소의 유형을 지정합니다. 형식은 모든 XML 스키마 기본 유형 또는 계약에 정의된 이름이 지정된 복잡한 유형일 수 있습니다. 형식에 인라인 정의가 있는 경우 이 속성을 생략할 수 있습니다.
  • nillable - 문서에서 요소를 완전히 생략할 수 있는지 여부를 지정합니다. nillabletrue 로 설정하면 스키마를 사용하여 생성된 문서에서 요소를 생략할 수 있습니다.

한 요소에는 인라인 유형 정의가 있을 수도 있습니다. 인라인 형식은 complexType 요소 또는 simpleType 요소를 사용하여 지정됩니다. 데이터 유형이 복잡하고 간단한지 지정하면 각 데이터 유형에 사용 가능한 도구를 사용하여 필요한 모든 유형의 데이터를 정의할 수 있습니다. 인라인 유형 정의는 재사용할 수 없으므로 권장되지 않습니다.

3장. 서비스에서 사용하는 논리 메시지 정의

초록

서비스는 해당 작업이 호출될 때 교환된 메시지에 의해 정의됩니다. WSDL 계약에서 이러한 메시지는 message 요소를 사용하여 정의됩니다. 메시지는 부분 요소를 사용하여 정의된 하나 이상의 부분 으로 구성됩니다.

3.1. 개요

서비스의 작업은 작업이 호출될 때 교환되는 논리 메시지를 지정하여 정의합니다. 이러한 논리 메시지는 네트워크를 XML 문서로 전달되는 데이터를 정의합니다. 메서드 호출의 일부인 모든 매개 변수가 포함되어 있습니다. 논리 메시지는 계약의 message 요소를 사용하여 정의됩니다. 각 논리 메시지는 부분 요소에 정의된 하나 이상의 부분 으로 구성됩니다.

메시지에서 각 매개 변수를 별도의 부분으로 나열할 수 있지만 권장 방법은 작업에 필요한 데이터를 캡슐화하는 단일 부분만 사용하는 것입니다.

3.2. messages 및 parameter 목록

서비스에서 노출하는 각 작업에는 하나의 입력 메시지와 하나의 출력 메시지만 있을 수 있습니다. 입력 메시지는 작업이 호출될 때 서비스에서 수신하는 모든 정보를 정의합니다. 출력 메시지는 작업이 완료될 때 서비스에서 반환하는 모든 데이터를 정의합니다. 오류 메시지는 오류가 발생할 때 서비스에서 반환하는 데이터를 정의합니다.

또한 각 작업에는 여러 개의 오류 메시지가 있을 수 있습니다. 오류 메시지는 서비스가 오류가 발생할 때 반환되는 데이터를 정의합니다. 이러한 메시지는 일반적으로 소비자가 오류를 이해하기 위해 충분한 정보를 제공하는 한 부분만 있습니다.

3.3. 레거시 시스템과의 통합을 위한 메시지 설계

기존 애플리케이션을 서비스로 정의하는 경우 작업을 구현하는 메서드에서 사용하는 각 매개 변수가 메시지에 표시되어 있는지 확인해야 합니다. 또한 반환 값이 작업의 출력 메시지에 포함되어 있는지 확인해야 합니다.

메시지를 정의하는 한 가지 방법은 RPC 스타일입니다. RPC 스타일을 사용할 때 메서드의 매개 변수 목록에서 각 매개변수에 대해 하나의 부분을 사용하여 메시지를 정의합니다. 각 메시지 부분은 계약의 형식 요소에 정의된 유형을 기반으로 합니다. 입력 메시지에는 메서드의 각 입력 매개변수에 대해 하나의 부분이 포함됩니다. 출력 메시지에는 각 출력 매개 변수에 대한 한 부분이 포함되어 있으며 필요한 경우 반환 값을 나타내는 파트가 포함되어 있습니다. 매개변수가 입력 및 출력 매개변수 둘 다이면 입력 메시지와 출력 메시지의 일부로 나열됩니다.

RPC 스타일 메시지 정의는 서비스가 Tibco 또는 CORBA와 같은 전송을 사용하는 레거시 시스템을 활성화하는 경우 유용합니다. 이러한 시스템은 절차 및 방법을 중심으로 설계되었습니다. 따라서 호출되는 작업의 매개 변수 목록과 유사한 메시지를 사용하여 모델링할 수 있습니다. RPC 스타일은 또한 노출 중인 서비스와 애플리케이션을 더 깔끔하게 매핑합니다.

3.4. SOAP 서비스에 대한 메시지 설계

RPC 스타일은 기존 시스템을 모델링하는 데 유용하지만 서비스의 커뮤니티는 래핑된 문서 스타일을 적극 권장합니다. 포장된 문서 스타일로, 각 메시지에는 하나의 부분이 있습니다. 메시지의 부분은 계약의 형식 요소에 정의된 래퍼 요소를 참조합니다. 래퍼 요소에는 다음과 같은 특징이 있습니다.

  • 요소 시퀀스를 포함하는 복합 형식입니다.A complex type containing a sequence of elements. 자세한 내용은 2.5절. “복잡한 데이터 유형 정의” 에서 참조하십시오.
  • 입력 메시지의 래퍼인 경우:

    • 각 메서드의 입력 매개 변수에 대해 하나의 요소가 있습니다.
    • 해당 이름은 연결된 작업의 이름과 동일합니다.
  • 출력 메시지의 래퍼인 경우:

    • 각 메서드의 출력 매개 변수와 메서드의 inout 매개 변수에 대해 하나의 요소가 있습니다.
    • 첫 번째 요소는 메서드의 return 매개 변수를 나타냅니다.
    • 해당 이름은 래퍼가 연결된 작업의 이름에 Response 를 추가하여 생성됩니다.

3.5. 메시지 이름 지정

계약의 각 메시지에는 해당 네임 스페이스 내에서 고유한 이름이 있어야 합니다. 다음 명명 규칙을 사용하는 것이 좋습니다.

  • 메시지는 단일 작업에서만 사용해야 합니다.
  • 입력 메시지 이름은 작업 이름에 요청 을 추가하여 구성됩니다.
  • 출력 메시지 이름은 작업 이름에 Response 를 추가하여 구성됩니다.
  • 오류 메시지 이름은 오류 이유를 나타냅니다.

3.6. 메시지 부분

메시지 부분은 논리 메시지의 공식적인 데이터 단위입니다. 각 부분은 부분 요소를 사용하여 정의되며 name 속성 및 해당 데이터 유형을 지정하는 type 속성 또는 요소 특성으로 식별됩니다. 데이터 유형 속성은 표 3.1. “파트 데이터 유형 속성” 에 나열됩니다.

표 3.1. 파트 데이터 유형 속성
속성설명

element="elem_name"

이 부분의 데이터 유형은 elem_name 이라는 요소에 의해 정의됩니다.

type="type_name"

이 부분의 데이터 유형은 type_name 이라고 하는 유형으로 정의됩니다.

메시지는 부분 이름을 재사용할 수 있습니다. 예를 들어 메서드에 참조로 전달되는 매개 변수가 있는 foo 이거나 in/out인 경우 예 3.1. “재사용된 부분” 과 같이 요청 메시지와 응답 메시지 모두에 포함될 수 있습니다.

예 3.1. 재사용된 부분

<message name="fooRequest">
  <part name="foo" type="xsd:int"/>
<message>
<message name="fooReply">
  <part name="foo" type="xsd:int"/>
<message>

3.7. 예제

예를 들어, 개인 정보를 저장하고 직원의 ID 번호를 기반으로 직원의 데이터를 반환하는 방법을 제공하는 서버가 있다고 가정해 보겠습니다. 데이터를 조회하기 위한 메서드 서명은 예 3.2. “personalInfo lookup method” 과 유사합니다.

예 3.2. personalInfo lookup method

personalInfo lookup(long empId)

이 메서드 서명은 예 3.3. “RPC WSDL 메시지 정의” 에 표시된 RPC 스타일 WSDL 조각에 매핑할 수 있습니다.

예 3.3. RPC WSDL 메시지 정의

<message name="personalLookupRequest">
  <part name="empId" type="xsd:int"/>
<message/>
<message name="personalLookupResponse>
  <part name="return" element="xsd1:personalInfo"/>
<message/>

또한 예 3.4. “문서 WSDL 메시지 정의 줄 바꿈” 에 표시된 래핑된 문서 스타일 WSDL 조각에 매핑할 수도 있습니다.

예 3.4. 문서 WSDL 메시지 정의 줄 바꿈

<wsdl:types>
  <xsd:schema ... >
  ...
  <element name="personalLookup">
    <complexType>
      <sequence>
        <element name="empID" type="xsd:int" />
      </sequence>
    </complexType>
  </element>
  <element name="personalLookupResponse">
    <complexType>
      <sequence>
        <element name="return" type="personalInfo" />
      </sequence>
    </complexType>
  </element>
  </schema>
</types>
<wsdl:message name="personalLookupRequest">
  <wsdl:part name="empId" element="xsd1:personalLookup"/>
<message/>
<wsdl:message name="personalLookupResponse">
  <wsdl:part name="return" element="xsd1:personalLookupResponse"/>
<message/>

4장. 논리 인터페이스 정의

초록

논리 서비스 인터페이스는 portType 요소를 사용하여 정의합니다.

4.1. 개요

논리 서비스 인터페이스는 WSDL portType 요소를 사용하여 정의합니다. portType 요소는 추상 작업 정의의 컬렉션입니다. 각 작업은 작업에서 나타내는 트랜잭션을 완료하는 데 사용되는 입력, 출력 및 오류 메시지에 의해 정의됩니다.Each operation is defined by the input, output, and fault messages used to complete the transaction the operation represents. portType 요소에서 정의한 서비스 인터페이스를 구현하기 위해 코드가 생성되면 각 작업은 계약에 지정된 입력, 출력 및 오류 메시지에 정의된 매개 변수를 포함하는 메서드로 변환됩니다.

4.2. 프로세스

WSDL 계약에서 논리 인터페이스를 정의하려면 다음을 수행해야합니다.

  1. interface 정의를 포함하도록 portType 요소를 만들고 이를 고유한 이름을 지정합니다. “포트 유형” 을 참조하십시오.
  2. 인터페이스에 정의된 각 작업에 대해 작업 요소를 생성합니다. “작업” 을 참조하십시오.
  3. 각 작업에 대해 작업의 매개 변수 목록, 반환 유형 및 예외를 나타내는 데 사용되는 메시지를 지정합니다. “작업 메시지” 을 참조하십시오.

4.3. 포트 유형

WSDL portType 요소는 논리 인터페이스 정의의 루트 요소입니다. 많은 웹 서비스 구현에서는 portType 요소를 생성된 구현 오브젝트에 직접 매핑하지만, 논리 인터페이스 정의는 구현된 서비스에서 제공하는 정확한 기능을 지정하지 않습니다. 예를 들어, ticketSystem이라는 논리적 인터페이스는 콘서트 티켓을 판매하거나 주차 티켓을 발행하는 구현을 초래할 수 있습니다.

portType 요소는 정의된 서비스를 노출하는 엔드포인트에서 사용하는 물리적 데이터를 정의하기 위해 바인딩에 매핑되는 WSDL 문서의 단위입니다.

WSDL 문서의 각 portType 요소에는 name 특성을 사용하여 지정된 고유한 이름이 있어야 하며 작업 요소에 설명된 작업 컬렉션으로 구성되어 있습니다. WSDL 문서는 모든 수의 포트 유형을 설명할 수 있습니다.

4.4. 작업

WSDL 작업 요소를 사용하여 정의하는 논리적 작업 에서는 두 끝점 간의 상호 작용을 정의합니다. 예를 들어, 검사 계정 균형을 위한 요청과 위젯의 그라스에 대한 주문은 모두 동작으로 정의될 수 있습니다.

portType 요소 내에 정의된 각 작업에는 name 특성을 사용하여 지정된 고유한 이름이 있어야 합니다. 작업을 정의하는 데 name 속성이 필요합니다.

4.5. 작업 메시지

논리 작업은 작업을 실행하기 위해 끝점 간에 전달되는 논리 메시지를 나타내는 요소 집합으로 구성됩니다. 작업을 설명할 수 있는 요소는 표 4.1. “작업 메시지 요소” 에 나열되어 있습니다.

표 4.1. 작업 메시지 요소
요소설명

input

요청이 수행될 때 클라이언트 끝점에서 서비스 공급자로 보내는 메시지를 지정합니다.Specifies the message the client endpoint sends to the service provider when a request is made. 이 메시지의 일부는 작업의 입력 매개변수에 해당합니다.

출력

서비스 공급자가 요청에 대한 응답으로 클라이언트 끝점으로 보내는 메시지를 지정합니다. 이 메시지의 일부는 참조로 전달된 값과 같이 서비스 공급자가 변경할 수 있는 모든 작업 매개변수에 해당합니다. 여기에는 작업의 반환 값이 포함됩니다.

fault

끝점 간에 오류 조건을 전달하는 데 사용되는 메시지를 지정합니다.

하나 이상의 입력 또는 하나의 출력 요소가 있어야 하는 작업입니다.An operation is required to have at least one input or one output element. 작업에는 입력출력 요소가 둘 다 있을 수 있지만 각 요소 중 하나만 있을 수 있습니다. 작업에 오류 가 있는 요소가 필요하지 않지만 필요한 경우 여러 개의 오류 요소가 있을 수 있습니다.

요소에는 표 4.2. “입력 및 출력 요소의 특성” 에 나열된 두 가지 속성이 있습니다.

표 4.2. 입력 및 출력 요소의 특성
속성설명

name

작업을 구체적인 데이터 형식으로 매핑할 때 참조할 수 있도록 메시지를 식별합니다.Identifies the message so it can be referenced when mapping the operation to a specific data format. 이름은 포함된 포트 유형 내에서 고유해야 합니다.

message

전송 또는 수신 중인 데이터를 설명하는 추상 메시지를 지정합니다. message 속성 값은 WSDL 문서에 정의된 추상 메시지 중 하나의 name 속성에 해당해야 합니다.

모든 입력출력 요소에 대한 name 속성을 지정할 필요는 없습니다. WSDL은 포함된 작업의 이름을 기반으로 기본 이름 지정 스키마를 제공합니다. 작업에 하나의 요소만 사용되는 경우 요소 이름은 기본적으로 작업 이름으로 설정됩니다. 입력출력 요소를 모두 사용하는 경우 요소 이름은 각각 이름에 Request 또는 Response 가 포함된 작업의 이름으로 설정됩니다.

4.6. 반환 값

작업 요소는 작업 중에 전달된 데이터에 대한 추상 정의이므로 WSDL은 작업에 대해 지정된 반환 값을 제공하지 않습니다. 메서드가 값을 반환하면 출력 요소에 해당 메시지의 마지막 부분으로 매핑됩니다.

4.7. 예제

예를 들어 예 4.1. “personalInfo 조회 인터페이스” 에 표시된 인터페이스와 유사한 인터페이스가 있을 수 있습니다.

예 4.1. personalInfo 조회 인터페이스

interface personalInfoLookup
{
  personalInfo lookup(in int empID)
  raises(idNotFound);
}

이 인터페이스는 예 4.2. “personalInfo 조회 포트 유형” 의 포트 유형에 매핑할 수 있습니다.

예 4.2. personalInfo 조회 포트 유형

<message name="personalLookupRequest">
  <part name="empId" element="xsd1:personalLookup"/>
<message/>
<message name="personalLookupResponse">
  <part name="return" element="xsd1:personalLookupResponse"/>
<message/>
<message name="idNotFoundException">
  <part name="exception" element="xsd1:idNotFound"/>
<message/>
<portType name="personalInfoLookup">
  <operation name="lookup">
    <input name="empID" message="tns:personalLookupRequest"/>
    <output name="return" message="tns:personalLookupResponse"/>
    <fault name="exception" message="tns:idNotFoundException"/>
  </operation>
</portType>

II 부. 웹 서비스 바인딩

이 부분에서는 Apache CXF 바인딩을 WSDL 문서에 추가하는 방법을 설명합니다.

5장. WSDL의 바인딩 이해

초록

바인딩은 서비스를 정의하는 데 사용되는 논리 메시지를 엔드포인트에서 전송 및 수신할 수 있는 구체적인 페이로드 형식으로 매핑합니다.

5.1. 개요

바인딩은 서비스에서 사용하는 논리 메시지 사이의 브리지를 물리적 세계에서 사용하는 구체적인 데이터 형식으로 제공합니다. 이는 논리 메시지가 끝점에 의해 유선에서 사용되는 페이로드 형식으로 매핑되는 방법을 설명합니다. 매개 변수 순서, 구체적인 데이터 형식 및 반환 값 같은 세부 정보가 지정된 바인딩 내에 있습니다.It is within the bindings that details such as parameter order, specific data types, and return values are specified. 예를 들어 메시지의 일부는 RPC 호출에 필요한 순서를 반영하도록 바인딩에서 다시 정렬할 수 있습니다.For example, the parts of a message can be reordered in a binding to reflect the order required by an RPC call. 바인딩 유형에 따라 메서드의 반환 유형을 나타내는 메시지 부분(▂ 있는 경우)을 식별할 수도 있습니다.Depending on the binding type, you can also identify which of the message parts, if any, represent the return type of a method.

5.2. 포트 유형 및 바인딩

포트 유형 및 바인딩은 직접 관련이 있습니다. 포트 유형은 두 논리 서비스 간의 상호 작용 집합에 대한 추상 정의입니다. 바인딩은 논리 서비스를 구현하는 데 사용되는 메시지가 물리적 세계에서 인스턴스화되는 방법에 대한 구체적인 정의입니다. 그러면 각 바인딩이 포트 유형에서 정의한 논리 서비스를 노출하는 끝점의 정의를 완료하는 네트워크 세부 정보 집합과 연결됩니다.

endpoint가 단일 서비스만 정의하도록 하기 위해 WSDL은 바인딩이 단일 포트 유형만 나타낼 수 있어야 합니다. 예를 들어 두 포트 유형과 계약을 체결한 경우 두 포트 유형을 모두 매핑하는 단일 바인딩을 구체적인 데이터 형식으로 작성할 수 없었습니다. 두 개의 바인딩이 필요합니다.

그러나 WSDL은 포트 유형을 여러 바인딩에 매핑할 수 있습니다. 예를 들어 계약에 단일 포트 유형이 있는 경우 둘 이상의 바인딩에 매핑할 수 있습니다. 각 바인딩은 메시지의 일부가 매핑되는 방식을 변경하거나 메시지에 대해 완전히 다른 페이로드 형식을 지정할 수 있습니다.

5.3. WSDL 요소

바인딩은 WSDL 바인딩 요소를 사용하여 계약에 정의됩니다. 바인딩 요소는 PortType에 대한 참조를 제공하는 바인딩 및 형식에 대한 고유 이름을 지정하는 등의 특성으로 구성됩니다. 이 속성의 값은 4장. 논리 인터페이스 정의 에서 설명한 대로 바인딩을 엔드포인트와 연결하는 데 사용됩니다.

실제 매핑은 바인딩 요소의 자식에서 정의됩니다. 이러한 요소는 사용하기로 결정한 페이로드 형식의 유형에 따라 달라집니다. 다양한 페이로드 형식과 매핑을 지정하는 데 사용되는 요소는 다음 장에서 설명합니다.

5.4. 계약에 추가

Apache CXF는 사전 정의된 서비스 인터페이스에 대한 바인딩을 생성할 수 있는 명령줄 도구를 제공합니다.

이 도구는 귀하의 계약에 적절한 요소를 추가합니다. 그러나 다양한 유형의 바인딩 작동 방식에 대한 지식이 있는 것이 좋습니다.

텍스트 편집기를 사용하여 계약에 바인딩을 추가할 수도 있습니다. 직접 계약을 편집하면 계약이 유효한지 확인할 책임이 있습니다.

5.5. 지원되는 바인딩

Apache CXF는 다음 바인딩을 지원합니다.

  • SOAP 1.1
  • SOAP 1.2
  • CORBA
  • 순수 XML

6장. SOAP 1.1 메시지 사용

초록

Apache CXF는 SOAP 헤더를 사용하지 않는 SOAP 1.1 바인딩을 생성하는 도구를 제공합니다. 그러나 텍스트 또는 XML 편집기를 사용하여 바인딩에 SOAP 헤더를 추가할 수 있습니다.However, you can add SOAP headers to your binding using any text or XML editor.

6.1. SOAP 1.1 바인딩 추가

6.1.1. wsdl2soap 사용

wsdl2soap 을 사용하여 SOAP 1.1 바인딩을 생성하려면 다음 명령을 사용합니다. wsdl2soap-iport-type-name-bbinding-name-doutput-directory-o output-namespace -nsoap-body-namespace-style (ral/rpc)-use (ral/encoded)-verb-oselll

참고

wsdl2soap 을 사용하려면 Apache CXF 배포판을 다운로드해야 합니다.

명령에는 다음 옵션이 있습니다.

옵션해석

-i port-type-name

바인딩이 생성되는 portType 요소를 지정합니다.

wsdlurl

portType 요소 정의를 포함하는 WSDL 파일의 경로와 이름입니다.

툴에는 다음과 같은 선택적 인수가 있습니다.

옵션해석

-b binding-name

생성된 SOAP 바인딩의 이름을 지정합니다.

-d output-directory

생성된 WSDL 파일을 배치할 디렉터리를 지정합니다.

-o output-file

생성된 WSDL 파일의 이름을 지정합니다.

-n soap-body-namespace

스타일이 RPC일 때 SOAP body 네임스페이스를 지정합니다.

-style (document/rpc)

SOAP 바인딩에서 사용할 인코딩 스타일(document 또는 RPC)을 지정합니다.Specifies the encoding style (document or RPC) to use in the SOAP binding. 기본값은 document입니다.

-use (literal/encoded)

SOAP 바인딩에 사용할 바인딩 사용(encoded 또는 literal)을 지정합니다.Specifies the binding use (encoded or literal) to use in the SOAP binding. 기본값은 literal입니다.

-v

도구의 버전 번호를 표시합니다.

-verbose

코드 생성 프로세스 중 주석을 표시합니다.

-quiet

코드 생성 프로세스 중 주석을 비활성화합니다.

-iport-type-namewsdlurl 인수가 필요합니다. -style rpc 인수가 지정된 경우 -nsoap-body-namspace 인수도 필요합니다. 다른 모든 인수는 선택 사항이며 순서에 따라 나열될 수 있습니다.

중요

wsdl2soap문서 / 인코딩된 SOAP 바인딩 생성을 지원하지 않습니다.

6.1.2. 예제

시스템에 주문을 처리하고 주문을 처리하는 단일 작업을 제공하는 인터페이스가 있는 경우 예 6.1. “시스템 인터페이스 순서” 에 표시된 것과 유사한 WSDL 조각에 정의되어 있습니다.

예 6.1. 시스템 인터페이스 순서

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="widgetOrderForm.wsdl"
    targetNamespace="http://widgetVendor.com/widgetOrderForm"
    xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:tns="http://widgetVendor.com/widgetOrderForm"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsd1="http://widgetVendor.com/types/widgetTypes"
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

<message name="widgetOrder">
  <part name="numOrdered" type="xsd:int"/>
</message>
<message name="widgetOrderBill">
  <part name="price" type="xsd:float"/>
</message>
<message name="badSize">
  <part name="numInventory" type="xsd:int"/>
</message>

<portType name="orderWidgets">
  <operation name="placeWidgetOrder">
    <input message="tns:widgetOrder" name="order"/>
    <output message="tns:widgetOrderBill" name="bill"/>
    <fault message="tns:badSize" name="sizeFault"/>
  </operation>
</portType>
...
</definitions>

orderWidgets 에 대해 생성된 SOAP 바인딩은 예 6.2. “orderWidgets에 대한 SOAP 1.1 바인딩” 에 표시됩니다.

예 6.2. orderWidgets에 대한 SOAP 1.1 바인딩

<binding name="orderWidgetsBinding" type="tns:orderWidgets">
  <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="placeWidgetOrder">
      <soap:operation soapAction="" style="document"/>
      <input name="order">
        <soap:body use="literal"/>
      </input>
      <output name="bill">
        <soap:body use="literal"/>
      </output>
      <fault name="sizeFault">
        <soap:body use="literal"/>
      </fault>
  </operation>
</binding>

이 바인딩은 문서/ 전문 메시지 스타일을 사용하여 메시지를 전송하도록 지정합니다.

6.2. SOAP 1.1 바인딩에 SOAP 헤더 추가

6.2.1. 개요

SOAP 헤더는 soap:header 요소를 기본 SOAP 1.1 바인딩에 추가하여 정의됩니다. soap:header 요소는 바인딩의 입력,출력fault 요소의 선택적 자식입니다. SOAP 헤더는 상위 메시지의 일부가 됩니다. SOAP 헤더는 메시지 및 메시지 부분을 지정하여 정의됩니다. 각 SOAP 헤더에는 하나의 메시지 부분만 포함할 수 있지만 필요한 만큼 SOAP 헤더를 삽입할 수 있습니다.

6.2.2. 구문

SOAP 헤더 정의의 구문은 예 6.3. “Header Syntax” 에 표시됩니다. soap:headermessage 속성은 헤더에 삽입되는 메시지의 정규화된 이름입니다. part 속성은 SOAP 헤더에 삽입된 메시지 부분의 이름입니다. SOAP 헤더는 항상 문서 스타일이므로 SOAP 헤더에 삽입된 WSDL 메시지 부분은 요소를 사용하여 정의해야 합니다. 메시지부분 속성을 함께 사용하면 SOAP 헤더에 삽입할 데이터를 완전히 설명합니다.

예 6.3. Header Syntax

<binding name="headwig">
  <soap:binding style="document"
                transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="weave">
      <soap:operation soapAction="" style="document"/>
      <input name="grain">
        <soap:body ... />
        <soap:header message="QName" part="partName"/>
      </input>
...
</binding>

필수 메시지부분 속성 외에도 soap:header네임스페이스, 사용, encodingStyle 속성도 지원합니다. 이 속성은 soap:header 에 대해 동일한 기능을 합니다. soap:body.

6.2.3. 본문과 헤더 간 메시지 분할

SOAP 헤더에 삽입된 메시지 부분은 계약의 유효한 메시지 부분일 수 있습니다. SOAP 본문으로 사용되는 상위 메시지의 일부일 수도 있습니다. 동일한 메시지에서 정보를 두 번 보낼 가능성이 낮기 때문에 SOAP 바인딩은 SOAP 본문에 삽입되는 메시지 부분을 지정하기 위한 수단을 제공합니다.

soap:body 요소에는 공백으로 구분된 부분 이름 목록을 사용하는 선택적 속성인 파트가 있습니다. 일부 가 정의되면 나열된 메시지 부분만 SOAP 본문에 삽입됩니다. 그런 다음 나머지 부분을 SOAP 헤더에 삽입할 수 있습니다.

참고

상위 메시지의 일부를 사용하여 SOAP 헤더를 정의할 때 Apache CXF는 자동으로 SOAP 헤더를 채웁니다.

6.2.4. 예제

예 6.4. “SOAP 헤더와의 SOAP 1.1 바인딩” 예 6.1. “시스템 인터페이스 순서” 에 표시된 orderWidgets 서비스의 수정된 버전을 표시합니다. 각 주문에 요청 및 응답의 SOAP 헤더에 배치된 xsd:base64binary 값이 있도록 이 버전이 수정되었습니다. SOAP 헤더는 widgetKey 메시지의 keyVal 파트로 정의됩니다. 이 경우 입력 또는 출력 메시지의 일부가 아니기 때문에 애플리케이션 논리에 SOAP 헤더를 추가해야 합니다.

예 6.4. SOAP 헤더와의 SOAP 1.1 바인딩

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="widgetOrderForm.wsdl"
    targetNamespace="http://widgetVendor.com/widgetOrderForm"
    xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:tns="http://widgetVendor.com/widgetOrderForm"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsd1="http://widgetVendor.com/types/widgetTypes"
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

<types>
  <schema targetNamespace="http://widgetVendor.com/types/widgetTypes"
           xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
    <element name="keyElem" type="xsd:base64Binary"/>
  </schema>
</types>

<message name="widgetOrder">
  <part name="numOrdered" type="xsd:int"/>
</message>
<message name="widgetOrderBill">
  <part name="price" type="xsd:float"/>
</message>
<message name="badSize">
  <part name="numInventory" type="xsd:int"/>
</message>
<message name="widgetKey">
  <part name="keyVal" element="xsd1:keyElem"/>
</message>

<portType name="orderWidgets">
  <operation name="placeWidgetOrder">
    <input message="tns:widgetOrder" name="order"/>
    <output message="tns:widgetOrderBill" name="bill"/>
    <fault message="tns:badSize" name="sizeFault"/>
  </operation>
</portType>

<binding name="orderWidgetsBinding" type="tns:orderWidgets">
  <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="placeWidgetOrder">
      <soap:operation soapAction="" style="document"/>
      <input name="order">
        <soap:body use="literal"/>
        <soap:header message="tns:widgetKey" part="keyVal"/>
      </input>
      <output name="bill">
        <soap:body use="literal"/>
        <soap:header message="tns:widgetKey" part="keyVal"/>
      </output>
      <fault name="sizeFault">
        <soap:body use="literal"/>
      </fault>
  </operation>
</binding>
...
</definitions>

헤더 값이 입력 및 출력 메시지의 일부임을 예 6.4. “SOAP 헤더와의 SOAP 1.1 바인딩” 로 수정할 수도 있습니다.

7장. SOAP 1.2 메시지 사용

초록

Apache CXF는 SOAP 헤더를 사용하지 않는 SOAP 1.2 바인딩을 생성하는 도구를 제공합니다. 텍스트 또는 XML 편집기를 사용하여 바인딩에 SOAP 헤더를 추가할 수 있습니다.

7.1. WSDL 문서에 SOAP 1.2 바인딩 추가

7.1.1. wsdl2soap 사용

참고

wsdl2soap을 사용하려면 Apache CXF 배포판을 다운로드해야 합니다.

wsdl2soap 을 사용하여 SOAP 1.2 바인딩을 생성하려면 다음 명령을 사용합니다. wsdl2soap-iport-type-name-bbinding-name-soap12-doutput-directory-ooutput-file-nsoap-body-namespace-style (document/rpc)-use(literal/encoded)-v-verbose-quietwsdlurl 툴에는 다음과 같은 필수 인수가 있습니다.

옵션해석

-i port-type-name

바인딩이 생성되는 portType 요소를 지정합니다.

-soap12

생성된 바인딩에서 SOAP 1.2를 사용하도록 지정합니다.

wsdlurl

portType 요소 정의를 포함하는 WSDL 파일의 경로와 이름입니다.

툴에는 다음과 같은 선택적 인수가 있습니다.

옵션해석

-b binding-name

생성된 SOAP 바인딩의 이름을 지정합니다.

-soap12

생성된 바인딩에서 SOAP 1.2를 사용하도록 지정합니다.

-d output-directory

생성된 WSDL 파일을 배치할 디렉터리를 지정합니다.

-o output-file

생성된 WSDL 파일의 이름을 지정합니다.

-n soap-body-namespace

스타일이 RPC일 때 SOAP body 네임스페이스를 지정합니다.

-style (document/rpc)

SOAP 바인딩에서 사용할 인코딩 스타일(document 또는 RPC)을 지정합니다.Specifies the encoding style (document or RPC) to use in the SOAP binding. 기본값은 document입니다.

-use (literal/encoded)

SOAP 바인딩에 사용할 바인딩 사용(encoded 또는 literal)을 지정합니다.Specifies the binding use (encoded or literal) to use in the SOAP binding. 기본값은 literal입니다.

-v

도구의 버전 번호를 표시합니다.

-verbose

코드 생성 프로세스 중 주석을 표시합니다.

-quiet

코드 생성 프로세스 중 주석을 비활성화합니다.

-i port-type-namewsdlurl 인수가 필요합니다. -style rpc 인수를 지정하면 -n soap-body-namspace 인수도 필요합니다. 다른 모든 인수는 선택 사항이며 순서에 따라 나열할 수 있습니다.

중요

wsdl2soap문서/ 로깅 SOAP 1.2 바인딩 생성을 지원하지 않습니다.

7.1.2. 예제

시스템에 주문을 처리하고 주문을 처리하는 단일 작업을 제공하는 인터페이스가 있는 경우 예 7.1. “시스템 인터페이스 순서” 에 표시된 것과 유사한 WSDL 조각에 정의되어 있습니다.

예 7.1. 시스템 인터페이스 순서

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="widgetOrderForm.wsdl"
    targetNamespace="http://widgetVendor.com/widgetOrderForm"
    xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
    xmlns:tns="http://widgetVendor.com/widgetOrderForm"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsd1="http://widgetVendor.com/types/widgetTypes"
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

<message name="widgetOrder">
  <part name="numOrdered" type="xsd:int"/>
</message>
<message name="widgetOrderBill">
  <part name="price" type="xsd:float"/>
</message>
<message name="badSize">
  <part name="numInventory" type="xsd:int"/>
</message>

<portType name="orderWidgets">
  <operation name="placeWidgetOrder">
    <input message="tns:widgetOrder" name="order"/>
    <output message="tns:widgetOrderBill" name="bill"/>
    <fault message="tns:badSize" name="sizeFault"/>
  </operation>
</portType>
...
</definitions>

orderWidgets에 대해 생성된 SOAP 바인딩은 예 7.2. “orderWidgets에 대한 SOAP 1.2 Bindings” 에 표시됩니다.

예 7.2. orderWidgets에 대한 SOAP 1.2 Bindings

<binding name="orderWidgetsBinding" type="tns:orderWidgets">
  <soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="placeWidgetOrder">
      <soap12:operation soapAction="" style="document"/>
      <input name="order">
        <soap12:body use="literal"/>
      </input>
      <output name="bill">
        <wsoap12:body use="literal"/>
      </output>
      <fault name="sizeFault">
        <soap12:body use="literal"/>
      </fault>
  </operation>
</binding>

이 바인딩은 문서/ 전문 메시지 스타일을 사용하여 메시지를 전송하도록 지정합니다.

7.2. SOAP 1.2 메시지에 헤더 추가

7.2.1. 개요

SOAP 메시지 헤더는 soap12:header 요소를 SOAP 1.2 메시지에 추가하여 정의됩니다. soap12:header 요소는 바인딩의 입력,출력fault 요소의 선택적 자식입니다. SOAP 헤더는 상위 메시지의 일부가 됩니다. SOAP 헤더는 메시지 및 메시지 부분을 지정하여 정의됩니다. 각 SOAP 헤더는 하나의 메시지 부분만 포함할 수 있지만 필요한 만큼의 헤더를 삽입할 수 있습니다.

7.2.2. 구문

SOAP 헤더 정의의 구문은 예 7.3. “Header Syntax” 에 표시됩니다.

예 7.3. Header Syntax

<binding name="headwig">
  <soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="weave">
      <soap12:operation soapAction="" style="documment"/>
      <input name="grain">
        <soap12:body ... />
        <soap12:header message="QName" part="partName"
                       use="literal|encoded"
                        encodingStyle="encodingURI"
                        namespace="namespaceURI" />
      </input>
...
</binding>

soap12:header 요소의 속성은 표 7.1. “soap12:header 특성s” 에 설명되어 있습니다.

표 7.1. soap12:header 특성s
속성설명

message

헤더에 삽입되는 메시지의 정규화된 이름을 지정하는 필수 속성입니다.

part

SOAP 헤더에 삽입된 메시지 부분의 이름을 지정하는 필수 속성입니다.

Use

인코딩 규칙을 사용하여 메시지 파트를 인코딩할지 여부를 지정합니다. 인코딩 으로 설정된 경우 message parts은 encodingStyle 속성 값으로 지정된 인코딩 규칙을 사용하여 인코딩됩니다. 리터럴 로 설정된 경우 메시지 부분은 참조되는 스키마 유형에서 정의됩니다.

encodingStyle

메시지를 구성하는 데 사용되는 인코딩 규칙을 지정합니다.

namespace

use="encoded" 로 직렬화된 헤더 요소에 할당할 네임스페이스를 정의합니다.

7.2.3. 본문과 헤더 간 메시지 분할

SOAP 헤더에 삽입된 메시지 부분은 계약의 유효한 메시지 부분일 수 있습니다. SOAP 본문으로 사용되는 상위 메시지의 일부일 수도 있습니다. 동일한 메시지에서 정보를 두 번 보낼 가능성이 낮기 때문에 SOAP 1.2 바인딩은 SOAP 본문에 삽입되는 메시지 부분을 지정할 수 있는 수단을 제공합니다.

soap12:body 요소에는 공백으로 구분된 부분 이름 목록을 사용하는 선택적 속성인 파트가 있습니다. 부분 도 정의되면 나열된 메시지 부분만 SOAP 1.2 메시지의 본문에 삽입됩니다. 그런 다음 나머지 부분을 메시지의 헤더에 삽입할 수 있습니다.

참고

상위 메시지의 일부를 사용하여 SOAP 헤더를 정의할 때 Apache CXF는 자동으로 SOAP 헤더를 채웁니다.

7.2.4. 예제

예 7.4. “SOAP 1.2 Binding with a SOAP Header” 예 7.1. “시스템 인터페이스 순서” 에 표시된 orderWidgets 서비스의 수정된 버전을 표시합니다. 이 버전은 각 주문에 요청 헤더와 응답에 xsd:base64binary 값이 배치되도록 수정되었습니다. 헤더는 widgetKey 메시지의 keyVal 파트로 정의됩니다. 이 경우 입력 또는 출력 메시지의 일부가 아니기 때문에 헤더를 생성하는 애플리케이션 논리를 추가합니다.

예 7.4. SOAP 1.2 Binding with a SOAP Header

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="widgetOrderForm.wsdl"
    targetNamespace="http://widgetVendor.com/widgetOrderForm"
    xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
    xmlns:tns="http://widgetVendor.com/widgetOrderForm"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsd1="http://widgetVendor.com/types/widgetTypes"
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

<types>
  <schema targetNamespace="http://widgetVendor.com/types/widgetTypes"
           xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
    <element name="keyElem" type="xsd:base64Binary"/>
  </schema>
</types>

<message name="widgetOrder">
  <part name="numOrdered" type="xsd:int"/>
</message>
<message name="widgetOrderBill">
  <part name="price" type="xsd:float"/>
</message>
<message name="badSize">
  <part name="numInventory" type="xsd:int"/>
</message>
<message name="widgetKey">
  <part name="keyVal" element="xsd1:keyElem"/>
</message>

<portType name="orderWidgets">
  <operation name="placeWidgetOrder">
    <input message="tns:widgetOrder" name="order"/>
    <output message="tns:widgetOrderBill" name="bill"/>
    <fault message="tns:badSize" name="sizeFault"/>
  </operation>
</portType>

<binding name="orderWidgetsBinding" type="tns:orderWidgets">
  <soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="placeWidgetOrder">
      <soap12:operation soapAction="" style="document"/>
      <input name="order">
        <soap12:body use="literal"/>
        <soap12:header message="tns:widgetKey" part="keyVal"/>
      </input>
      <output name="bill">
        <soap12:body use="literal"/>
        <soap12:header message="tns:widgetKey" part="keyVal"/>
      </output>
      <fault name="sizeFault">
        <soap12:body use="literal"/>
      </fault>
  </operation>
</binding>
...
</definitions>

예 7.4. “SOAP 1.2 Binding with a SOAP Header” 에 표시된 대로 헤더 값이 입력 및 출력 메시지의 일부임을 알 수 있습니다. 예 7.5. “SOAP Header을 사용한 orderWidgets에 대한 SOAP 1.2 Binding” 이 경우 keyVal 은 입력 및 출력 메시지의 일부입니다. soap12:body 요소에서 parts 속성이 keyVal 을 본문에 삽입하지 않도록 지정합니다. 그러나 헤더에 삽입됩니다.

예 7.5. SOAP Header을 사용한 orderWidgets에 대한 SOAP 1.2 Binding

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="widgetOrderForm.wsdl"
    targetNamespace="http://widgetVendor.com/widgetOrderForm"
    xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
    xmlns:tns="http://widgetVendor.com/widgetOrderForm"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsd1="http://widgetVendor.com/types/widgetTypes"
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

<types>
  <schema targetNamespace="http://widgetVendor.com/types/widgetTypes"
           xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
    <element name="keyElem" type="xsd:base64Binary"/>
  </schema>
</types>

<message name="widgetOrder">
  <part name="numOrdered" type="xsd:int"/>
  <part name="keyVal" element="xsd1:keyElem"/>
</message>
<message name="widgetOrderBill">
  <part name="price" type="xsd:float"/>
  <part name="keyVal" element="xsd1:keyElem"/>
</message>
<message name="badSize">
  <part name="numInventory" type="xsd:int"/>
</message>

<portType name="orderWidgets">
  <operation name="placeWidgetOrder">
    <input message="tns:widgetOrder" name="order"/>
    <output message="tns:widgetOrderBill" name="bill"/>
    <fault message="tns:badSize" name="sizeFault"/>
  </operation>
</portType>

<binding name="orderWidgetsBinding" type="tns:orderWidgets">
  <soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="placeWidgetOrder">
      <soap12:operation soapAction="" style="document"/>
      <input name="order">
        <soap12:body use="literal" parts="numOrdered"/>
        <soap12:header message="tns:widgetOrder" part="keyVal"/>
      </input>
      <output name="bill">
        <soap12:body use="literal" parts="bill"/>
        <soap12:header message="tns:widgetOrderBill" part="keyVal"/>
      </output>
      <fault name="sizeFault">
        <soap12:body use="literal"/>
      </fault>
  </operation>
</binding>
...
</definitions>

8장. 첨부 파일과 함께 SOAP를 사용하여 바이너리 데이터 전송

초록

SOAP 첨부 파일은 SOAP 메시지의 일부로 바이너리 데이터를 전송하는 메커니즘을 제공합니다. 첨부 파일과 함께 SOAP를 사용하려면 SOAP 메시지를 MIME 다중 파트 메시지로 정의해야 합니다.

8.1. 개요

SOAP 메시지는 일반적으로 바이너리 데이터를 포함하지 않습니다. 그러나 W3C SOAP 1.1 사양을 사용하면 MIME 다중 파트/관련 메시지를 사용하여 SOAP 메시지에서 바이너리 데이터를 보낼 수 있습니다. 이 기술을 첨부 파일과 함께 SOAP을 사용합니다. SOAP 첨부 파일은 첨부파일을 사용하여 W3C의 SOAP 메시지에 정의되어 있습니다.

8.2. 네임스페이스

MIME 다중 파트/ 관련 메시지를 정의하는 데 사용되는 WSDL 확장 기능은 네임스페이스 http://schemas.xmlsoap.org/wsdl/mime/ 에 정의되어 있습니다.

다음 설명에서는 이 네임스페이스가 mime 이 앞에 있다고 가정합니다. 이를 설정하는 WSDL 정의 요소의 항목은 예 8.1. “계약의 MIME 네임스페이스 사양” 에 표시됩니다.

예 8.1. 계약의 MIME 네임스페이스 사양

xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"

8.3. 메시지 바인딩 변경

기본 SOAP 바인딩에서 입력,출력오류 요소의 첫 번째 하위 요소는 데이터를 나타내는 SOAP 메시지의 본문을 설명하는 soap:body 요소입니다. 첨부 파일과 함께 SOAP를 사용하면 soap:body 요소가 mime:multipartRelated 요소로 교체됩니다.

참고

WSDL은 오류 메시지에 대한 mime:multipartRelated 사용을 지원하지 않습니다.

mime:multipartRelated 요소는 Apache CXF에 메시지 본문이 바이너리 데이터를 포함하는 다중 부분 메시지임을 알립니다. 요소의 내용은 메시지 및 해당 콘텐츠의 부분을 정의합니다. MIME:multipartRelated 요소에는 메시지의 개별 부분을 설명하는 하나 이상의 mime:part 요소가 포함되어 있습니다.

첫 번째 mime:part 요소에는 일반적으로 기본 SOAP 바인딩에 표시되는 soap:body 요소가 포함되어야 합니다. 나머지 mime:part 요소는 메시지에서 전송되는 첨부 파일을 정의합니다.

8.4. MIME 다중 부분 메시지 설명

MIME 다중 파트 메시지는 여러 mime:part 요소를 포함하는 mime:multipartRelated 요소를 사용하여 설명합니다. MIME 다중 파트 메시지를 완전히 설명하려면 다음을 수행해야 합니다.

  1. MIME 다중 부분으로 보내는 입력 또는 출력 메시지 내에 mime:mulipartRelated 요소를 enclosing 메시지의 첫 번째 하위 요소로 추가합니다.
  2. mime:part 하위 요소를 mime:multipartRelated 요소에 추가하고 name 속성을 고유한 문자열로 설정합니다.
  3. soap:body 요소를 mime:part 요소의 자식으로 추가하고 해당 속성을 적절하게 설정합니다.

    참고

    계약에 기본 SOAP 바인딩이 있는 경우 기본 바인딩에서 MIME multipart 메시지로 해당 메시지의 soap:body 요소를 복사할 수 있습니다.

  4. mime:part 하위 요소를 mime:multipartReleated 요소에 추가하고 name 속성을 고유한 문자열로 설정합니다.
  5. mime:content 하위 요소를 mime:part 요소에 추가하여 메시지의 이 부분의 내용을 설명합니다.

    MIME 메시지의 내용을 완전히 설명하기 위해 mime:content 요소에는 다음과 같은 속성이 있습니다.

    표 8.1. MIME:content 속성
    속성description +

    part

    바인딩에 배치되는 MIME 다중 파트 메시지의 콘텐츠로 사용되는 상위 메시지 정의에서 WSDL 메시지 파트의 이름을 지정합니다.

    +

    type

    이 메시지 부분에 있는 데이터의 MIME 유형입니다. MIME 유형은 구문 유형/하위 유형을 사용하여 type 및sub type 으로 정의됩니다.

    +

    image/jpegtext/plain 과 같은 사전 정의된 MIME 유형이 많이 있습니다. MIME 유형은 IANA(Internet Assigned Numbers Authority)에 의해 유지 관리되며, MIME(Multipurpose Internet Mail Extensions)에 자세히 설명되어 있습니다. one: Internet Message BodiesMultipurpose Internet Mail Extensions (MIME) Part two: 미디어 유형.

    +

  6. 추가 MIME 부분의 경우 [i303819][i303821] 단계를 반복합니다.

8.5. 예제

예 8.2. “첨부파일과 함께 SOAP를 사용한 계약” 에서는 JPEG 형식으로 X-ray를 저장하는 서비스를 정의하는 WSDL 조각을 보여줍니다. 이미지 데이터인 xRayxsd:base64binary 로 저장되며 MIME multipart 메시지의 두 번째 파트인 imageData 에 포장되어 있습니다. 입력 메시지의 나머지 두 부분인 patientNamepatientNumber 는 SOAP 본문의 일부로 MIME 다중 파트 이미지의 첫 번째 부분으로 전송됩니다.

예 8.2. 첨부파일과 함께 SOAP를 사용한 계약

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="XrayStorage"
    targetNamespace="http://mediStor.org/x-rays"
    xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:tns="http://mediStor.org/x-rays"
    xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <message name="storRequest">
    <part name="patientName" type="xsd:string"/>
    <part name="patientNumber" type="xsd:int"/>
    <part name="xRay" type="xsd:base64Binary"/>
  </message>
  <message name="storResponse">
    <part name="success" type="xsd:boolean"/>
  </message>

  <portType name="xRayStorage">
    <operation name="store">
      <input message="tns:storRequest" name="storRequest"/>
      <output message="tns:storResponse" name="storResponse"/>
    </operation>
  </portType>

  <binding name="xRayStorageBinding" type="tns:xRayStorage">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="store">
      <soap:operation soapAction="" style="document"/>
      <input name="storRequest">
        <mime:multipartRelated>
          <mime:part name="bodyPart">
            <soap:body use="literal"/>
          </mime:part>
          <mime:part name="imageData">
            <mime:content part="xRay" type="image/jpeg"/>
          </mime:part>
        </mime:multipartRelated>
      </input>
      <output name="storResponse">
        <soap:body use="literal"/>
      </output>
    </operation>
  </binding>

  <service name="xRayStorageService">
    <port binding="tns:xRayStorageBinding" name="xRayStoragePort">
      <soap:address location="http://localhost:9000"/>
    </port>
  </service>
</definitions>

9장. SOAP MTOM을 사용하여 바이너리 데이터 전송

초록

SOAP Message Transmission Optimization Mechanism(MTOM)은 SOAP를 XML 메시지의 일부로 바이너리 데이터를 전송하는 메커니즘으로 교체합니다. Apache CXF와 함께 MTOM을 사용하려면 서비스의 계약에 올바른 스키마 유형을 추가하고 MTOM 최적화를 활성화해야 합니다.

9.1. MTOM 개요

SOAP Message Transmission Optimization Mechanism(MTOM)은 SOAP 메시지의 일부로 바이너리 데이터를 전송하기 위한 최적화된 방법을 지정합니다. 첨부 파일의 SOAP와 달리 MTOM은 바이너리 데이터를 전송하기 위해 XML-binary Optimized Packaging (XOP) 패키지를 사용해야 합니다. MTOM을 사용하여 바이너리 데이터를 전송하면 MIME Multipart/Related 메시지를 SOAP 바인딩의 일부로 완전히 정의할 필요가 없습니다. 그러나 다음과 같은 작업을 수행해야 합니다.

  1. 첨부 파일로 보낼 데이터에 주석 을 답니다.

    WSDL 또는 데이터를 구현하는 Java 클래스에 주석을 달 수 있습니다.

  2. 런타임의 MTOM 지원을 활성화합니다.

    이는 프로그래밍 방식으로 또는 구성을 통해 수행할 수 있습니다.

  3. 첨부 파일로 전달되는 데이터에 대한 DataHandler 를 개발합니다.

    참고

    DataHandlerS 개발은 이 책의 범위를 벗어납니다.

9.2. MTOM을 사용하도록 데이터 유형 주석

9.2.1. 개요

WSDL에서 이미지 파일 또는 사운드 파일과 같은 바이너리 데이터 블록을 전달하는 데이터 유형을 정의할 때 xsd:base64Binary 유형의 데이터가 될 요소를 정의합니다. 기본적으로 xsd:base64Binary 형식의 모든 요소가 MTOM을 사용하여 직렬화될 수 있는 byte[] 가 생성됩니다. 그러나 코드 생성기의 기본 동작은 직렬화를 최대한 활용하지 않습니다.However, the default behavior of the code generators does not take full advantage of the serialization.

MTOM을 완전히 활용하려면 서비스의 WSDL 문서 또는 바이너리 데이터 구조를 구현하는 JAXB 클래스에 주석을 추가해야 합니다. WSDL 문서에 주석을 추가하면 코드 생성기가 바이너리 데이터에 대한 스트리밍 데이터 처리기를 생성하도록 강제 적용합니다. JAXB 클래스에 주석을 달려면 적절한 콘텐츠 유형을 지정해야 하며 바이너리 데이터가 포함된 필드의 유형 사양을 변경해야 할 수도 있습니다.

9.2.2. WSDL 첫 번째

예 9.1. “MTOM에 대한 메시지” 하나의 문자열 필드, 하나의 정수 필드 및 바이너리 필드를 포함하는 메시지를 사용하는 웹 서비스의 WSDL 문서를 보여줍니다. 바이너리 필드는 큰 이미지 파일을 전송하기 위한 것이므로 일반 SOAP 메시지의 일부로 보내는 것은 적절하지 않습니다.

예 9.1. MTOM에 대한 메시지

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="XrayStorage"
    targetNamespace="http://mediStor.org/x-rays"
    xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:tns="http://mediStor.org/x-rays"
    xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
    xmlns:xsd1="http://mediStor.org/types/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <types>
    <schema targetNamespace="http://mediStor.org/types/"
            xmlns="http://www.w3.org/2001/XMLSchema">
      <complexType name="xRayType">
        <sequence>
          <element name="patientName" type="xsd:string" />
          <element name="patientNumber" type="xsd:int" />
          <element name="imageData" type="xsd:base64Binary" />
        </sequence>
      </complexType>
      <element name="xRay" type="xsd1:xRayType" />
    </schema>
  </types>

  <message name="storRequest">
    <part name="record" element="xsd1:xRay"/>
  </message>
  <message name="storResponse">
    <part name="success" type="xsd:boolean"/>
  </message>

  <portType name="xRayStorage">
    <operation name="store">
      <input message="tns:storRequest" name="storRequest"/>
      <output message="tns:storResponse" name="storResponse"/>
    </operation>
  </portType>

  <binding name="xRayStorageSOAPBinding" type="tns:xRayStorage">
    <soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="store">
      <soap12:operation soapAction="" style="document"/>
      <input name="storRequest">
        <soap12:body use="literal"/>
      </input>
      <output name="storResponse">
        <soap12:body use="literal"/>
      </output>
    </operation>
  </binding>
  ...
</definitions>

MTOM을 사용하여 메시지의 바이너리 부분을 최적화된 첨부 파일로 보내려면 바이너리 데이터가 포함된 요소에 xmime:expectedContentTypes 속성을 추가해야 합니다. 이 속성은 http://www.w3.org/2005/05/xmlmime 네임스페이스에 정의되어 있으며 요소가 포함할 것으로 예상되는 MIME 유형을 지정합니다. MIME 유형의 쉼표로 구분된 목록을 지정할 수 있습니다. 이 속성의 설정은 코드 생성기가 데이터에 대한 JAXB 클래스를 만드는 방법을 변경합니다. 대부분의 MIME 유형의 경우 코드 생성기는 DataHandler를 생성합니다. 이미지용과 같은 일부 MIME 유형에는 매핑이 정의되어 있습니다.

참고

대부분의 경우 application/octet-stream 을 지정합니다.

예 9.2. “MTOM용 바이너리 데이터” MTOM 사용을 위해 예 9.1. “MTOM에 대한 메시지” 에서 xRayType 을 수정하는 방법을 보여줍니다.

예 9.2. MTOM용 바이너리 데이터

...
  <types>
    <schema targetNamespace="http://mediStor.org/types/"
            xmlns="http://www.w3.org/2001/XMLSchema"
            xmlns:xmime="http://www.w3.org/2005/05/xmlmime">
      <complexType name="xRayType">
        <sequence>
          <element name="patientName" type="xsd:string" />
          <element name="patientNumber" type="xsd:int" />
          <element name="imageData" type="xsd:base64Binary"
                   xmime:expectedContentTypes="application/octet-stream"/>
        </sequence>
      </complexType>
      <element name="xRay" type="xsd1:xRayType" />
    </schema>
  </types>
...

xRayType 에 대해 생성된 JAXB 클래스에는 더 이상 바이트[] 가 포함되어 있지 않습니다. 대신 코드 생성기가 xmime:expectedContentTypes 특성을 확인하고 imageData 필드에 대한 DataHandler를 생성합니다.

참고

MTOM을 사용하기 위해 바인딩 요소를 변경할 필요가 없습니다. 런타임은 데이터가 전송될 때 적절한 변경을 수행합니다.

9.2.3. Java 첫 번째

Java 첫 개발을 수행하는 경우 다음을 수행하여 JAXB 클래스 MTOM을 준비시킬 수 있습니다.

  1. 바이너리 데이터를 보유한 필드가 DataHandler인지 확인합니다.
  2. 스트리밍하려는 데이터가 MTOM 첨부 파일로 포함된 필드에 @XmlMimeType() 주석을 추가합니다.

예 9.3. “MTOM용 JAXB 클래스” MTOM 사용에 대한 주석이 있는 JAXB 클래스를 표시합니다.

예 9.3. MTOM용 JAXB 클래스

@XmlType
public class XRayType {
    protected String patientName;
    protected int patientNumber;
    @XmlMimeType("application/octet-stream")
    protected DataHandler imageData;
  ...
}

9.3. MTOM 활성화

기본적으로 Apache CXF 런타임은 MTOM 지원을 활성화하지 않습니다. 모든 바이너리 데이터를 일반 SOAP 메시지의 일부로 전송하거나 최적화되지 않은 첨부 파일로 보냅니다. 프로그래밍 방식으로 또는 구성을 통해 MTOM 지원을 활성화할 수 있습니다.

9.3.1. JAX-WS API 사용

9.3.1.1. 개요

서비스 공급자와 소비자 모두 MTOM 최적화를 활성화해야 합니다. JAX-WS API는 각 엔드포인트 유형에 대해 서로 다른 메커니즘을 제공합니다.

9.3.1.2. 서비스 공급자

JAX-WS API를 사용하여 서비스 공급자를 게시한 경우 다음과 같이 런타임의 MTOM 지원을 활성화합니다.

  1. 게시된 서비스의 Endpoint 오브젝트에 액세스합니다.

    Endpoint 오브젝트에 액세스하는 가장 쉬운 방법은 끝점을 게시하는 것입니다. 자세한 내용은 31장. 서비스 게시 에서 참조하십시오.

  2. 예 9.4. “끝점에서 SOAP 바인딩 가져오기” 과 같이 getBinding() 메서드를 사용하여 끝점에서 SOAP 바인딩을 가져옵니다.

    예 9.4. 끝점에서 SOAP 바인딩 가져오기

    // Endpoint ep is declared previously
    SOAPBinding binding = (SOAPBinding)ep.getBinding();

    반환된 바인딩 개체를 MTOM 속성에 액세스하려면 SOAPBinding 개체에 캐스팅해야 합니다.

  3. 바인딩의 MTOM enabled 속성을 예 9.5. “서비스 공급자의 MTOM 사용 속성 설정” 와 같이 setMTOMEnabled() 메서드를 사용하여 true 로 설정합니다.

    예 9.5. 서비스 공급자의 MTOM 사용 속성 설정

    binding.setMTOMEnabled(true);

9.3.1.3. 소비자

MTOM으로 JAX-WS 소비자를 활성화하려면 다음을 수행해야 합니다.

  1. 소비자의 프록시를 BindingProvider 개체로 캐스팅합니다.

    소비자 프록시를 가져오는 방법에 대한 자세한 내용은 25장. WSDL 계약 없이 소비자 개발 또는 28장. WSDL 계약에서 소비자 개발 을 참조하십시오.

  2. 예 9.6. “BindingProvider에서 SOAP 바인딩 가져오기” 과 같이 getBinding() 메서드를 사용하여 BindingProvider 에서 SOAP 바인딩을 가져옵니다.

    예 9.6. BindingProvider에서 SOAP 바인딩 가져오기

    // BindingProvider bp declared previously
    SOAPBinding binding = (SOAPBinding)bp.getBinding();
  3. 바인딩의 setMTOMEnabled() 메서드를 사용하여 예 9.7. “소비자의 MTOM 사용 속성 설정” 에 표시된 대로 MTOM enabled 속성을 true 로 설정합니다.

    예 9.7. 소비자의 MTOM 사용 속성 설정

    binding.setMTOMEnabled(true);

9.3.2. 구성 사용

9.3.2.1. 개요

컨테이너에 배포할 때와 같이 XML을 사용하여 서비스를 게시하는 경우 엔드포인트 구성 파일에서 끝점의 MTOM 지원을 활성화할 수 있습니다. 엔드 포인트 구성에 대한 자세한 내용은 IV 부. 웹 서비스 엔드 포인트 구성 을 참조하십시오.

9.3.2.2. 절차

MTOM 속성은 엔드포인트의 jaxws:endpoint 요소 내에 설정됩니다. MTOM을 활성화하려면 다음을 수행합니다.

  1. jaxws:property 하위 요소를 엔드포인트의 jaxws:endpoint 요소에 추가합니다.
  2. jaxws:property 요소에 항목 하위 요소를 추가합니다.
  3. entry 요소의 key 속성을 mtom-enabled 로 설정합니다.
  4. entry 요소의 value 속성을 true 로 설정합니다.

9.3.2.3. 예제

예 9.8. “MTOM 활성화를 위한 구성” MTOM이 활성화된 끝점을 보여줍니다.

예 9.8. MTOM 활성화를 위한 구성

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jaxws="http://cxf.apache.org/jaxws"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                           http://cxf.apache.org/jaxws http://cxf.apache.org/schema/jaxws.xsd">

  <jaxws:endpoint id="xRayStorage"
                  implementor="demo.spring.xRayStorImpl"
                  address="http://localhost/xRayStorage">
    <jaxws:properties>
      <entry key="mtom-enabled" value="true"/>
    </jaxws:properties>
  </jaxws:endpoint>
</beans>

10장. XML 문서 사용

초록

순수 XML 페이로드 형식은 SOAP의 오버헤드 없이 간단한 XML 문서를 사용하여 데이터를 교환할 수 있도록 하여 SOAP 바인딩에 대한 대안을 제공합니다.

10.1. XML 바인딩 네임스페이스

XML 형식 바인딩을 설명하는 데 사용되는 확장 기능은 네임스페이스 http://cxf.apache.org/bindings/xformat 에 정의되어 있습니다. Apache CXF 툴은 xformat 접두사를 사용하여 XML 바인딩 확장을 나타냅니다. 계약에 다음 줄을 추가합니다.Add the following line to your contract:

xmlns:xformat="http://cxf.apache.org/bindings/xformat"

10.2. 수동 편집

인터페이스를 순수 XML 페이로드 형식으로 매핑하려면 다음을 수행합니다.

  1. 네임스페이스 선언을 추가하여 XML 바인딩을 정의하는 확장을 포함합니다. “XML 바인딩 네임스페이스” 을 참조하십시오.
  2. 표준 WSDL 바인딩 요소를 계약에 추가하여 XML 바인딩을 보유하고, 바인딩에 고유한 이름 을 지정한 다음, 바인딩되는 인터페이스를 나타내는 WSDL portType 요소의 이름을 지정합니다.
  3. xformat:binding 하위 요소를 바인딩 요소에 추가하여 메시지가 SOAP 봉투 없이 순수 XML 문서로 처리되는지 확인합니다.
  4. 필요한 경우 xformat:binding 요소의 rootNode 속성을 유효한 QName으로 설정합니다. rootNode 특성의 영향에 대한 자세한 내용은 “글의 XML 메시지” 을 참조하십시오.
  5. 바인딩된 인터페이스에 정의된 각 작업에 대해 작업 메시지에 대한 바인딩 정보를 보유하는 표준 WSDL 작업 요소를 추가합니다.
  6. 바인딩에 추가된 각 작업에 대해 입력 , 출력 및 오류 자식 요소를 추가하여 작업에서 사용하는 메시지를 나타냅니다.For each operation added to the binding, add the input,output, and fault children elements to represent the messages used by the operation.

    이러한 요소는 논리 작업의 인터페이스 정의에 정의된 메시지에 해당합니다.

  7. 선택적으로 유효한 rootNode 속성이 있는 xformat:body 요소를 추가된 입력,출력, fault 요소에 추가하여 바인딩 수준에서 설정된 rootNode 의 값을 재정의합니다.
참고

메시지에 void를 반환하는 작업에 대한 출력 메시지와 같이 어떤 메시지가 아무런 부분도 없는 경우, 전선에 작성된 메시지가 유효한지 확인하도록 메시지의 rootNode 특성을 설정해야 합니다.

10.3. 글의 XML 메시지

인터페이스의 메시지가 SOAP 봉투 없이 XML 문서로 전달되도록 지정하는 경우 메시지가 전선에 기록될 때 유효한 XML 문서를 형성하도록 해야 합니다. 또한 XML 문서를 수신하는 Apache CXF 이외의 사용자가 Apache CXF가 생성한 메시지를 이해하고 있는지 확인해야 합니다.

두 문제를 해결하는 간단한 방법은 글로벌 xformat:binding 요소 또는 개별 메시지의 xformat:body 요소에서 선택적 rootNode 특성을 사용하는 것입니다. rootNode 속성은 Apache CXF에서 생성된 XML 문서에 대한 루트 노드 역할을 하는 요소의 QName을 지정합니다. rootNode 속성이 설정되지 않은 경우 Apache CXF는 doc 스타일 메시지를 사용할 때 메시지 부분의 루트 요소를 루트 요소로 사용하거나 rpc 스타일 메시지를 사용할 때 메시지 파트 이름을 루트 요소로 사용합니다.

예를 들어 rootNode 속성이 예 10.1. “유효한 XML 바인딩 메시지” 에 정의된 메시지를 설정하지 않으면 루트 요소 lineNumber 를 사용하여 XML 문서를 생성합니다.

예 10.1. 유효한 XML 바인딩 메시지

<type ... >
  ...
  <element name="operatorID" type="xsd:int"/>
  ...
</types>
<message name="operator">
  <part name="lineNumber" element="ns1:operatorID"/>
</message>

한 부분이 있는 메시지의 경우, Apache CXF는 rootNode 속성이 설정되지 않은 경우에도 항상 유효한 XML 문서를 생성합니다. 그러나 예 10.2. “잘못된 XML 바인딩 메시지” 의 메시지는 유효하지 않은 XML 문서를 생성합니다.

예 10.2. 잘못된 XML 바인딩 메시지

<types>
  ...
  <element name="pairName" type="xsd:string"/>
  <element name="entryNum" type="xsd:int"/>
  ...
</types>

<message name="matildas">
  <part name="dancing" element="ns1:pairName"/>
  <part name="number" element="ns1:entryNum"/>
</message>

XML 바인딩에 지정된 rootNode 특성이 없으면 Apache CXF는 예 10.2. “잘못된 XML 바인딩 메시지” 로 정의된 메시지에 대해 예 10.3. “잘못된 XML 문서” 와 유사한 XML 문서를 생성합니다. 생성된 XML 문서는 pairNameentryNum 의 두 가지 루트 요소가 있기 때문에 유효하지 않습니다.

예 10.3. 잘못된 XML 문서

<pairName>
  Fred&Linda
</pairName>
<entryNum>
  123
</entryNum>

rootNode 특성을 설정하면 예 10.4. “rootNode 세트가 있는 XML 바인딩” Apache CXF에서 지정된 루트 요소에 요소를 래핑합니다. 이 예제에서 rootNode 특성은 전체 바인딩에 대해 정의되며 루트 요소 이름이 entrants로 지정되도록 지정합니다.

예 10.4. rootNode 세트가 있는 XML 바인딩

<portType name="danceParty">
  <operation name="register">
    <input message="tns:matildas" name="contestant"/>
  </operation>
</portType>

<binding name="matildaXMLBinding" type="tns:dancingMatildas">
  <xmlformat:binding rootNode="entrants"/>
  <operation name="register">
    <input name="contestant"/>
    <output name="entered"/>
</binding>

입력 메시지에서 생성된 XML 문서는 예 10.5. “rootNode 특성을 사용하여 생성된 XML 문서” 과 유사합니다. XML 문서에는 이제 하나의 루트 요소만 있습니다.

예 10.5. rootNode 특성을 사용하여 생성된 XML 문서

<entrants>
  <pairName>
    Fred&Linda
  <entryNum>
    123
  </entryNum>
</entrants>

10.4. 바인딩의 rootNode 특성 설정 덮어쓰기

각 개별 메시지에 대해 rootNode 특성을 설정하거나 메시지 바인딩 내부의 xformat:body 요소를 사용하여 특정 메시지에 대한 전역 설정을 덮어쓸 수도 있습니다. 예를 들어 예 10.4. “rootNode 세트가 있는 XML 바인딩” 에 정의된 출력 메시지가 입력 메시지와 다른 루트 요소를 갖도록 하려면 예 10.6. “xformat:body사용” 에 표시된 대로 바인딩의 루트 요소를 재정의할 수 있습니다.

예 10.6. xformat:body사용

<binding name="matildaXMLBinding" type="tns:dancingMatildas">
  <xmlformat:binding rootNode="entrants"/>
  <operation name="register">
    <input name="contestant"/>
    <output name="entered">
      <xformat:body rootNode="entryStatus" />
    </output>
  </operation>
</binding>

III 부. 웹 서비스 전송

이 부분에서는 Apache CXF 전송을 WSDL 문서에 추가하는 방법을 설명합니다.

11장. Endpoints가 WSDL에서 정의되는 방법 이해

초록

끝점은 인스턴스화된 서비스를 나타냅니다. 바인딩과 끝점을 노출하는 데 사용되는 네트워킹 세부 정보를 결합하여 정의합니다.

11.1. 개요

엔드포인트는 서비스의 물리적 표현으로 간주될 수 있습니다. 서비스에서 사용하는 논리 데이터의 물리적 표현과 다른 엔드포인트에서 서비스를 연결하는 데 사용되는 물리적 연결 세부 정보를 정의하는 네트워킹 세부 정보 집합을 지정하는 바인딩을 결합합니다.

참고

CXF 공급자는 클라이언트에 해당하는 CXF 소비자의 서버입니다. CXF(camel-cxf) 구성 요소를 경로에서 시작 끝점으로 사용하는 경우 엔드포인트는 Camel 소비자와 CXF 공급자입니다. Camel CXF 구성 요소를 경로에서 종료 끝점으로 사용하는 경우 엔드포인트는 Camel 생산자와 CXF 소비자입니다.

11.2. 엔드 포인트 및 서비스

바인딩이 단일 인터페이스만 매핑할 수 있는 것과 동일한 방식으로 끝점은 단일 서비스에만 매핑할 수 있습니다. 그러나 서비스를 여러 끝점으로 표시할 수 있습니다. 예를 들어, 4개의 엔드포인트에서 표시되는 티켓 판매 서비스를 정의할 수 있습니다. 그러나 티켓 판매 서비스와 위젯 판매 서비스를 모두 나타내는 단일 엔드 포인트가 없었습니다.

11.3. WSDL 요소

엔드포인트는 WSDL 서비스 요소와 WSDL 포트 요소의 조합을 사용하여 계약에 정의됩니다. 서비스 요소는 관련 포트 요소의 컬렉션입니다. 포트 요소는 실제 엔드포인트를 정의합니다.

WSDL 서비스 요소에는 고유한 이름을 지정하는 단일 속성 이름 가 있습니다. 서비스 요소는 관련 포트 요소의 컬렉션의 부모 요소로 사용됩니다. WSDL은 포트 요소가 어떻게 관련되어 있는지에 대한 사양을 만들지 않습니다. 필요에 따라 포트 요소를 연결할 수 있습니다.You can associate the port elements in any manner you see fit.

WSDL 포트 요소에는 바인딩 특성이 있습니다. 이는 끝점에서 사용하는 바인딩을 지정하고 wsdl:binding 요소에 대한 참조입니다. 또한 모든 포트 간에 고유한 이름 을 제공하는 필수 속성인 name 속성도 포함합니다. port 요소는 끝점에서 사용하는 실제 전송 세부 정보를 지정하는 요소의 부모 요소입니다. 전송 세부 정보를 지정하는 데 사용되는 요소는 다음 섹션에서 설명합니다.

11.4. 계약에 끝점 추가

Apache CXF는 사전 정의된 서비스 인터페이스 및 바인딩 조합에 대해 끝점을 생성할 수 있는 명령줄 도구를 제공합니다.

이 도구는 귀하의 계약에 적절한 요소를 추가합니다. 그러나 끝점 작업을 정의하는 데 사용되는 다양한 전송 방법을 알고 있는 것이 좋습니다.

텍스트 편집기를 사용하여 계약에 끝점을 추가할 수도 있습니다. 계약을 직접 편집하면 계약이 유효한지 확인할 책임이 있습니다.

11.5. 지원되는 전송

엔드포인트 정의는 각 전송 Apache CXF에 대해 정의된 확장을 사용하여 빌드됩니다. 여기에는 다음 전송이 포함됩니다.

  • HTTP
  • CORBA
  • Java Messaging Service

12장. HTTP 사용

초록

HTTP는 웹의 기본 전송입니다. 엔드포인트 간에 통신할 수 있도록 표준화되고 강력하고 유연한 플랫폼을 제공합니다. 이러한 요인으로 인해 대부분의 WS-* 사양에 대한 전송이 가정되고 RESTful 아키텍처에 통합되어 있습니다.

12.1. 기본 HTTP 끝점 추가

12.1.1. 대체 HTTP 런타임

Apache CXF는 다음과 같은 대체 HTTP 런타임 구현을 지원합니다.

12.1.2. Netty HTTP URL

일반적으로 HTTP 엔드포인트는 클래스 경로에 포함된 모든 HTTP 런타임( Undertow 또는 Netty)을 사용합니다. Undertow 런타임과 Netty 런타임이 모두 classpath에 포함된 경우, 기본적으로 Undertow 런타임이 사용되므로 Netty 런타임을 사용할 때 명시적으로 지정해야 합니다.

classpath에서 두 개 이상의 HTTP 런타임을 사용할 수 있는 경우 다음 형식을 갖도록 끝점 URL을 지정하여 Undertow 런타임을 선택할 수 있습니다.

netty://http://RestOfURL

12.1.3. 페이로드 유형

사용 중인 페이로드 형식에 따라 HTTP 끝점의 주소를 지정하는 세 가지 방법이 있습니다.

  • SOAP 1.1은 표준화된 soap:address 요소를 사용합니다.
  • SOAP 1.2는 soap12:address 요소를 사용합니다.
  • 다른 모든 페이로드 형식은 http:address 요소를 사용합니다.
참고

Camel 2.16.0 릴리스에서 Apache Camel CXF Payload는 즉시 스트림 캐시를 지원합니다.

12.1.4. SOAP 1.1

HTTP를 통해 SOAP 1.1 메시지를 전송하는 경우 SOAP 1.1 주소 요소를 사용하여 끝점의 주소를 지정해야 합니다. 여기에는 끝점의 주소를 URL로 지정하는 하나의 속성 위치 가 있습니다. SOAP 1.1 address 요소는 네임스페이스 http://schemas.xmlsoap.org/wsdl/soap/ 에 정의되어 있습니다.

예 12.1. “SOAP 1.1 포트 요소” HTTP를 통해 SOAP 1.1 메시지를 보내는 데 사용되는 포트 요소를 표시합니다.

예 12.1. SOAP 1.1 포트 요소

<definitions ...
             xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" ...>
  ...
  <service name="SOAP11Service">
    <port binding="SOAP11Binding" name="SOAP11Port">
      <soap:address location="http://artie.com/index.xml">
    </port>
  </service>
  ...
<definitions>

12.1.5. SOAP 1.2

HTTP를 통해 SOAP 1.2 메시지를 전송하는 경우 SOAP 1.2 주소 요소를 사용하여 끝점의 주소를 지정해야 합니다. 여기에는 끝점의 주소를 URL로 지정하는 하나의 속성 위치 가 있습니다. SOAP 1.2 address 요소는 네임스페이스 http://schemas.xmlsoap.org/wsdl/soap12/ 에 정의되어 있습니다.

예 12.2. “SOAP 1.2 포트 요소” HTTP를 통해 SOAP 1.2 메시지를 보내는 데 사용되는 포트 요소를 표시합니다.

예 12.2. SOAP 1.2 포트 요소

<definitions ...
             xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" ... >
  <service name="SOAP12Service">
    <port binding="SOAP12Binding" name="SOAP12Port">
      <soap12:address location="http://artie.com/index.xml">
    </port>
  </service>
  ...
</definitions>

12.1.6. 기타 메시지 유형

메시지가 SOAP 이외의 페이로드 형식으로 매핑되면 HTTP 주소 요소를 사용하여 끝점 주소 를 지정해야 합니다. 여기에는 끝점의 주소를 URL로 지정하는 하나의 속성 위치 가 있습니다. HTTP 주소 요소는 네임스페이스 http://schemas.xmlsoap.org/wsdl/http/ 에 정의되어 있습니다.

예 12.3. “HTTP 포트 요소” XML 메시지를 보내는 데 사용되는 포트 요소를 표시합니다.

예 12.3. HTTP 포트 요소

<definitions ...
             xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" ... >
  <service name="HTTPService">
    <port binding="HTTPBinding" name="HTTPPort">
      <http:address location="http://artie.com/index.xml">
    </port>
  </service>
  ...
</definitions>

12.2. 소비자 구성

12.2.1. HTTP Consumer Endpoints 관련 메커니즘

HTTP 소비자 끝점은 끝점에서 자동으로 리디렉션 응답을 수락하는지 여부, 청크를 사용할 수 있는지 여부, 엔드포인트에서 keep-alive를 요청할지 여부 및 엔드포인트가 프록시와 상호 작용하는 방식을 포함하여 여러 HTTP 연결 속성을 지정할 수 있습니다. HTTP 연결 속성 외에도 HTTP 소비자 끝점은 보안 방법을 지정할 수 있습니다.

소비자 끝점은 다음 두 가지 메커니즘을 사용하여 구성할 수 있습니다.

12.2.2. 구성 사용

12.2.2.1. 네임스페이스

HTTP 소비자 끝점을 구성하는 데 사용되는 요소는 네임스페이스 http://cxf.apache.org/transports/http/configuration 에 정의되어 있습니다. 일반적으로 접두사 http-conf 를 사용합니다. HTTP 구성 요소를 사용하려면 예 12.4. “HTTP Consumer 구성 네임스페이스” 에 표시된 줄을 끝점 구성 파일의 빈 요소에 추가해야 합니다. 또한 구성 요소의 네임스페이스를 xsi:schemaLocation 속성에 추가해야 합니다.

예 12.4. HTTP Consumer 구성 네임스페이스

<beans ...
       xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"
       ...
       xsi:schemaLocation="...
                           http://cxf.apache.org/transports/http/configuration
                              http://cxf.apache.org/schemas/configuration/http-conf.xsd
                          ...">

12.2.2.2. Undertow 런타임 또는 Netty 런타임

http-conf 네임스페이스의 요소를 사용하여 Undertow 런타임 또는 Netty 런타임을 구성할 수 있습니다.

12.2.2.3. 구성 요소

http-conf:conduit 요소와 해당 하위 항목을 사용하여 HTTP 소비자 끝점을 구성합니다. http-conf:conduit 요소는 엔드포인트에 해당하는 WSDL 포트 요소를 지정하는 단일 속성인 name 을 사용합니다. name 속성의 값은 portQName'.http-conduit' 형식을 사용합니다. 예 12.5. “HTTP-conf:conduit Element” 는 끝점의 대상 네임스페이스가 http://widgets.widgetvendor.net인 경우의 WSDL 조각 < port binding="widgetSOAPBinding" name="widgetSOAPPort >에 의해 지정된 엔드포인트에 대한 구성을 추가하는 데 사용되는 http-conf:conduit 요소를 표시합니다.

예 12.5. HTTP-conf:conduit Element

...
  <http-conf:conduit name="{http://widgets/widgetvendor.net}widgetSOAPPort.http-conduit">
    ...
  </http-conf:conduit>
...

http-conf:conduit 요소에는 구성 정보를 지정하는 하위 요소가 있습니다. 자세한 내용은 표 12.1. “HTTP Consumer Endpoint를 구성하는 데 사용되는 요소” 에 설명되어 있습니다.

표 12.1. HTTP Consumer Endpoint를 구성하는 데 사용되는 요소
요소설명

http-conf:client

시간 초과, 유지 요청, 콘텐츠 유형 등과 같은 HTTP 연결 속성을 지정합니다.Specifies the HTTP connection properties such as timeouts, keep-alive requests, content types, etc. “클라이언트 요소” 을 참조하십시오.

http-conf:authorization

끝점에서 선점하여 사용하는 기본 인증 방법을 구성하기 위한 매개변수를 지정합니다. 가장 선호되는 방법은 http-conf:basicAuthSupplier 오브젝트를 제공하는 것입니다.

http-conf:proxyAuthorization

발신 HTTP 프록시 서버에 대한 기본 인증을 구성하는 매개변수를 지정합니다.

http-conf:tlsClientParameters

SSL/TLS를 구성하는 데 사용되는 매개변수를 지정합니다.

http-conf:basicAuthSupplier

끝점에서 사용하는 기본 인증 정보를 제공하는 오브젝트의 빈 참조 또는 클래스 이름을 선점적으로 또는 401 HTTP 챌린지에 대한 응답으로 지정합니다.

http-conf:trustDecider

정보를 전송하기 전에 HTTP(S) URLConnection 오브젝트를 검사하여 HTTPS 서비스 공급자와의 연결을 설정하는 오브젝트의 빈 참조 또는 클래스 이름을 지정합니다.

12.2.2.4. 클라이언트 요소

http-conf:client 요소는 소비자 엔드포인트의 HTTP 연결의 비보안 속성을 구성하는 데 사용됩니다. 표 12.2. “HTTP 소비자 구성 속성” 에 설명된 해당 속성은 연결의 속성을 지정합니다.

표 12.2. HTTP 소비자 구성 속성
속성설명

ConnectionTimeout

시간이 초과되기 전에 소비자가 연결을 설정하려고 시도하는 시간(밀리초)을 지정합니다. 기본값은 30000 입니다.

0 은 소비자가 요청을 무기한 계속 보내도록 지정합니다.

ReceiveTimeout

시간이 초과되기 전에 소비자가 응답을 대기할 시간(밀리초)을 지정합니다. 기본값은 30000 입니다.

0 은 소비자가 무기한 기다리도록 지정합니다.

AutoRedirect

소비자가 발급한 서버를 자동으로 따르는지 여부를 지정합니다. 기본값은 false입니다.

MaxRetransmits

소비자가 리디렉션을 충족하기 위해 요청을 다시 전송할 최대 횟수를 지정합니다. 기본값은 -1 이며 무제한 재전송이 허용되도록 지정합니다.

AllowChunking

사용자가 청크를 사용하여 요청을 보낼지 여부를 지정합니다. 기본값은 사용자가 요청을 보낼 때 청크를 사용하도록 지정하는 true 입니다.

다음 중 하나라도 해당하는 경우 청크를 사용할 수 없습니다.

  • HTTP-conf:basicAuthSupplier 는 인증 정보를 사전에 제공하도록 구성되어 있습니다.
  • AutoRedirecttrue 로 설정됩니다.

두 경우 모두 AllowChunking 값이 무시되고 청크는 허용되지 않습니다.

accept

소비자가 처리할 준비가 된 미디어 유형을 지정합니다. 이 값은 HTTP Accept 속성의 값으로 사용됩니다. 특성 값은MIME(Multipurpose Internet mail extensions) 유형을 사용하여 지정됩니다.

AcceptLanguage

소비자가 응답을 받기 위해 선호하는 언어(예: 미국 영어)를 지정합니다. 이 값은 HTTP AcceptLanguage 속성 값으로 사용됩니다.

언어 태그는 International Organization for Standards(ISO)에 의해 규제되며 일반적으로 ISO-639 표준에 따라 결정된 언어 코드와 하이픈으로 구분된 ISO-3166 표준에 따라 국가 코드를 결합하여 구성됩니다. 예를 들어 en-US는 미국어를 나타냅니다.

AcceptEncoding

소비자가 처리할 준비가 된 콘텐츠 인코딩을 지정합니다. 콘텐츠 인코딩 레이블은 IANA(Internet Assigned Numbers Authority)에 의해 규제됩니다. 이 값은 HTTP AcceptEncoding 속성 값으로 사용됩니다.

ContentType

메시지의 본문에 전송되는 데이터의 미디어 유형을 지정합니다.Specifies the media type of the data being sent in the body of a message. 미디어 유형은 다목적 인터넷 메일 확장 (MIME) 유형을 사용하여 지정됩니다. 값은 HTTP ContentType 속성 값으로 사용됩니다. 기본값은 text/xml 입니다.

웹 서비스의 경우 이 값을 text/xml 로 설정해야 합니다. 클라이언트가 CGI 스크립트로 HTML 양식 데이터를 전송하는 경우 이를 application/x-www-form-urlencoded 로 설정해야 합니다. HTTP POST 요청이 SOAP와 반대되는 고정 페이로드 형식에 바인딩된 경우 일반적으로 콘텐츠 유형이 애플리케이션/octet-stream 으로 설정됩니다.

호스트

요청이 호출되는 리소스의 인터넷 호스트 및 포트 번호를 지정합니다. 이 값은 HTTP Host 속성 값으로 사용됩니다.

이 속성은 일반적으로 필요하지 않습니다. 이는 특정 DNS 시나리오 또는 애플리케이션 설계에만 필요합니다. 예를 들어, 동일한 인터넷 프로토콜(IP) 주소에 매핑되는 가상 서버의 경우 클라이언트가 클러스터를 선호하는 호스트를 나타냅니다.

연결

각 요청/응답 대화 상자 이후 특정 연결을 열린 상태로 유지할지 여부를 지정합니다.Specifies whether a particular connection is to be kept open or closed after each request/response dialog. 두 가지 유효한 값이 있습니다.

  • keep-Alive - 소비자가 초기 요청/응답 시퀀스 후 연결을 열린 상태로 설정하도록 지정합니다. 서버가 이를 수락하면 소비자가 이를 닫을 때까지 연결이 열려 있습니다.
  • 닫기(기본값) - 요청/응답 시퀀스 후에 서버에 대한 연결이 종료되도록 지정합니다.

CacheControl

소비자의 서비스 공급자 요청을 포함하는 체인과 관련된 캐시에 의해 준수해야 하는 동작에 대한 지시문을 지정합니다.Specifies directives about the behavior that must be adhered to by caches involved in the chain consisting a request from a consumer to a service provider. 12.2.4절. “소비자 캐시 제어 지침” 을 참조하십시오.

쿠키

모든 요청과 함께 보낼 정적 쿠키를 지정합니다.

BrowserType

요청이 시작되는 브라우저에 대한 정보를 지정합니다. 월드 와이드 웹 컨소시엄 (W3C)의 HTTP 사양에서 이것을 user-agent 라고도 합니다. 일부 서버는 요청을 전송하는 클라이언트에 따라 최적화됩니다.

Referer

소비자가 특정 서비스에 대한 요청을 수행하도록 지시하는 리소스의 URL을 지정합니다. 값은 HTTP Referer 속성의 값으로 사용됩니다.

이 HTTP 속성은 요청이 URL을 입력하는 대신 하이퍼링크를 클릭하는 브라우저 사용자의 결과인 경우에 사용됩니다. 이를 통해 서버는 이전 작업 흐름에 따라 처리를 최적화하고, 로깅, 최적화된 캐싱, 사용되지 않는 링크 추적 등의 목적으로 리소스에 백 링크 목록을 생성할 수 있습니다. 그러나 일반적으로 웹 서비스 애플리케이션에서는 사용되지 않습니다.

AutoRedirect 특성이 true 로 설정되고 요청이 리디렉션되면 Referer 속성에 지정된 모든 값이 재정의됩니다. HTTP Referer 속성의 값은 소비자의 원래 요청을 리디렉션하는 서비스의 URL로 설정됩니다.

DecoupledEndpoint

별도의 공급자를 통해 응답을 받기 위한 분리된 엔드포인트의 URL을 지정합니다.Specifies the URL of a decoupled endpoint for the received of responses over a separate providerconsumer connection. 분리된 엔드포인트 사용에 대한 자세한 내용은 12.6절. “분리된 모드에서 HTTP 전송 사용” 에서 참조하십시오.

분리된 끝점에 대해 WS-Addressing을 사용하도록 소비자 끝점과 서비스 공급자 끝점을 모두 구성해야 합니다.

ProxyServer

라우팅되는 요청을 통과하는 프록시 서버의 URL을 지정합니다.

ProxyServerPort

라우팅되는 요청을 통한 프록시 서버의 포트 번호를 지정합니다.

ProxyServerType

요청을 라우팅하는 데 사용되는 프록시 서버의 유형을 지정합니다. 유효한 값은 다음과 같습니다.

  • HTTP(기본값)
  • SOCKS

12.2.2.5. 예제

예 12.6. “HTTP Consumer Endpoint 구성” 는 호출당 한 번만 요청을 다시 전송하며 청크 스트림을 사용할 수 없는 요청 간에 공급자에 대한 연결을 열어 두고자 하는 HTTP 소비자 끝점의 구성을 보여줍니다.

예 12.6. HTTP Consumer Endpoint 구성

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"
       xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration
                             http://cxf.apache.org/schemas/configuration/http-conf.xsd
                           http://www.springframework.org/schema/beans
                             http://www.springframework.org/schema/beans/spring-beans.xsd">

  <http-conf:conduit name="{http://apache.org/hello_world_soap_http}SoapPort.http-conduit">
    <http-conf:client Connection="Keep-Alive"
                      MaxRetransmits="1"
                      AllowChunking="false" />
  </http-conf:conduit>
</beans>

12.2.2.6. 더 알아보기

HTTP 구성에 대한 자세한 내용은 16장. 구성 요소 에서 참조하십시오.

12.2.3. WSDL 사용

12.2.3.1. 네임스페이스

HTTP 소비자 끝점을 구성하는 데 사용되는 WSDL 확장 요소는 네임스페이스 http://cxf.apache.org/transports/http/configuration 에 정의되어 있습니다. 일반적으로 접두사 http-conf 를 사용합니다. HTTP 구성 요소를 사용하려면 예 12.7. “HTTP Consumer WSDL Element's Namespace” 에 표시된 줄을 끝점의 WSDL 문서의 정의 요소에 추가해야 합니다.

예 12.7. HTTP Consumer WSDL Element's Namespace

<definitions ...
       xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"

12.2.3.2. Undertow 런타임 또는 Netty 런타임

http-conf 네임스페이스의 요소를 사용하여 Undertow 런타임 또는 Netty 런타임을 구성할 수 있습니다.

12.2.3.3. 클라이언트 요소

http-conf:client 요소는 WSDL 문서에서 HTTP 소비자의 연결 속성을 지정하는 데 사용됩니다. http-conf:client 요소는 WSDL 포트 요소의 자식입니다. 구성 파일에서 사용되는 클라이언트 요소와 동일한 속성이 있습니다. 속성은 표 12.2. “HTTP 소비자 구성 속성” 에서 확인할 수 있습니다.

12.2.3.4. 예제

예 12.8. “HTTP Consumer Endpoint 구성” 에는 캐시와 상호 작용하지 않도록 지정하는 HTTP 소비자 엔드포인트를 구성하는 WSDL 조각을 보여줍니다.

예 12.8. HTTP Consumer Endpoint 구성

<service ... >
  <port ... >
    <soap:address ... />
    <http-conf:client CacheControl="no-cache" />
  </port>
</service>

12.2.4. 소비자 캐시 제어 지침

표 12.3. “HTTP-conf:client 캐시 제어 지침” HTTP 소비자가 지원하는 캐시 제어 지시문을 나열합니다.

표 12.3. HTTP-conf:client 캐시 제어 지침
directive동작

no-cache

캐시는 먼저 서버와의 응답을 재검증하지 않고 후속 요청을 충족하기 위해 특정 응답을 사용할 수 없습니다. 특정 응답 헤더 필드가 이 값으로 지정된 경우 제한은 응답 내의 해당 헤더 필드에만 적용됩니다. 응답 헤더 필드를 지정하지 않으면 제한이 전체 응답에 적용됩니다.

no-store

캐시는 응답의 일부 또는 이를 호출한 요청의 일부를 저장해야 합니다.

max-age

소비자는 지정된 시간(초)보다 긴 응답을 허용할 수 있습니다.

max-stale

소비자는 만료 시간을 초과한 응답을 수락할 수 있습니다. 값이 max-stale에 할당되면 소비자가 해당 응답을 허용할 수 있는 응답의 만료 시간 이외의 초 수를 나타냅니다. 값이 할당되지 않은 경우 소비자는 모든 연령의 오래된 응답을 수락할 수 있습니다.

min-fresh

소비자는 최소한 지정된 시간(초) 동안 새로운 응답을 원하는 것입니다.

no-transform

캐시는 공급자와 소비자 간 응답으로 콘텐츠의 미디어 유형 또는 위치를 수정하지 않아야 합니다.

only-if-cached

캐시는 현재 캐시에 저장된 응답만 반환하고, 다시 로드하거나 재검토해야 하는 응답이 아닙니다.

cache-extension

다른 캐시 지시문에 대한 추가 확장을 지정합니다. 확장 기능은 정보 또는 동작일 수 있습니다. 확장된 지시문은 표준 지시문의 컨텍스트에 지정되므로 확장 지시문을 이해하지 못하는 애플리케이션이 standard 지시문에서 요구하는 동작을 따를 수 있습니다.

12.3. 서비스 공급자 구성

12.3.1. HTTP 서비스 공급자의 메커니즘

HTTP 서비스 공급자 끝점은 활성 요청을 유지할지 여부, 캐시와 상호 작용하는 방법, 소비자와 통신하는 데 오류의 내결함성을 포함하여 여러 HTTP 연결 특성을 지정할 수 있습니다.

서비스 공급자 끝점은 다음 두 가지 메커니즘을 사용하여 구성할 수 있습니다.

12.3.2. 구성 사용

12.3.2.1. 네임스페이스

HTTP 공급자 끝점을 구성하는 데 사용되는 요소는 네임스페이스 http://cxf.apache.org/transports/http/configuration 에 정의되어 있습니다. 일반적으로 접두사 http-conf 를 사용합니다. HTTP 구성 요소를 사용하려면 예 12.9. “HTTP 공급자 구성 네임스페이스” 에 표시된 줄을 끝점 구성 파일의 빈 요소에 추가해야 합니다. 또한 구성 요소의 네임스페이스를 xsi:schemaLocation 속성에 추가해야 합니다.

예 12.9. HTTP 공급자 구성 네임스페이스

<beans ...
       xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"
       ...
       xsi:schemaLocation="...
                           http://cxf.apache.org/transports/http/configuration
                              http://cxf.apache.org/schemas/configuration/http-conf.xsd
                          ...">

12.3.2.2. Undertow 런타임 또는 Netty 런타임

http-conf 네임스페이스의 요소를 사용하여 Undertow 런타임 또는 Netty 런타임을 구성할 수 있습니다.

12.3.2.3. 대상 요소

http-conf:destination 요소와 해당 하위 항목을 사용하여 HTTP 서비스 공급자 끝점을 구성합니다. http-conf:destination 요소는 엔드포인트에 해당하는 WSDL 포트 요소를 지정하는 단일 속성인 name 을 사용합니다. name 속성의 값은 portQName'.http-destination' 형식을 사용합니다. 예 12.10. “HTTP-conf:destination Element” 는 끝점의 대상 네임스페이스가 http://widgets.widgetvendor.net인 경우 WSDL 조각 < port binding="widgetSOAPBinding" name="widgetSOAPPort >에 의해 지정된 엔드포인트에 대한 구성을 추가하는 데 사용되는 http-conf:destination 요소를 표시합니다.

예 12.10. HTTP-conf:destination Element

...
  <http-conf:destination name="{http://widgets/widgetvendor.net}widgetSOAPPort.http-destination">
    ...
  </http-conf:destination>
...

http-conf:destination 요소에는 구성 정보를 지정하는 여러 하위 요소가 있습니다. 자세한 내용은 표 12.4. “HTTP 서비스 공급자 끝점을 구성하는 데 사용되는 요소” 에 설명되어 있습니다.

표 12.4. HTTP 서비스 공급자 끝점을 구성하는 데 사용되는 요소
요소설명

http-conf:server

HTTP 연결 속성을 지정합니다. “서버 요소” 을 참조하십시오.

http-conf:contextMatchStrategy

HTTP 요청을 처리하기 위한 컨텍스트 일치 전략을 구성하는 매개변수를 지정합니다.

http-conf:fixedParameterOrder

이 대상에서 처리하는 HTTP 요청의 매개변수 순서가 고정되는지 여부를 지정합니다.

12.3.2.4. 서버 요소

http-conf:server 요소는 서비스 공급자 끝점의 HTTP 연결 속성을 구성하는 데 사용됩니다. 표 12.5. “HTTP 서비스 공급자 구성 속성” 에 설명된 해당 속성은 연결의 속성을 지정합니다.

표 12.5. HTTP 서비스 공급자 구성 속성
속성설명

ReceiveTimeout

연결 시간이 초과되기 전에 서비스 공급자가 요청을 수신하려고 하는 시간(밀리초)을 설정합니다. 기본값은 30000 입니다.

0 공급자는 공급자가 시간 초과되지 않도록 지정합니다.

SuppressClientSendErrors

요청 수신 시 오류가 발생할 때 예외가 throw되는지 여부를 지정합니다.Specifies whether exceptions are to be thrown when an error is encountered on receiving a request. 기본값은 false 입니다. 오류 발생 시 예외가 발생합니다.

SuppressClientReceiveErrors

소비자에게 응답을 보내는 데 오류가 발생할 때 예외가 throw되는지 여부를 지정합니다.Specifies whether exceptions are to be thrown when an error is encountered on sending a response to a consumer. 기본값은 false 입니다. 오류 발생 시 예외가 발생합니다.

HonorKeepAlive

응답이 전송된 후에도 서비스 공급자가 연결 요청을 열린 상태로 유지할지 여부를 지정합니다. 기본값은 false 입니다. 유지 요청은 무시됩니다.

RedirectURL

클라이언트 요청에 지정된 URL이 요청된 리소스에 더 이상 적합하지 않은 경우 클라이언트 요청을 리디렉션해야 하는 URL을 지정합니다. 이 경우 서버 응답의 첫 번째 줄에 상태 코드가 자동으로 설정되지 않으면 상태 코드가 302로 설정되고 상태 설명이 Object Moved로 설정됩니다. 값은 HTTP RedirectURL 속성 값으로 사용됩니다.

CacheControl

서비스 공급자의 응답을 소비자로 구성된 체인과 관련된 캐시에 의해 준수해야 하는 동작에 대한 지시문을 지정합니다. 12.3.4절. “서비스 공급자 캐시 제어 지침” 을 참조하십시오.

ContentLocation

응답에 전송되는 리소스가 있는 URL을 설정합니다.

ContentType

응답으로 전송되는 정보의 미디어 유형을 지정합니다. 미디어 유형은 다목적 인터넷 메일 확장 (MIME) 유형을 사용하여 지정됩니다. 값은 HTTP ContentType 위치 값으로 사용됩니다.

ContentEncoding

서비스 공급자가 전송하는 정보에 적용된 추가 콘텐츠 인코딩을 지정합니다. 콘텐츠 인코딩 레이블은 IANA(Internet Assigned Numbers Authority)에 의해 규제됩니다. 가능한 콘텐츠 인코딩 값에는 zip, gzip, compress, deflate, identity가 포함됩니다. 이 값은 HTTP ContentEncoding 속성 값으로 사용됩니다.

콘텐츠 인코딩의 주된 사용은 zip 또는 gzip과 같은 일부 인코딩 메커니즘을 사용하여 문서를 압축하도록 허용하는 것입니다. Apache CXF는 콘텐츠 코딩에 대한 유효성 검사를 수행하지 않습니다. 지정된 콘텐츠 코딩이 애플리케이션 수준에서 지원되도록 해야 합니다.

ServerType

응답을 보내는 서버의 유형을 지정합니다. 값은 program-name/version (예: Apache/1.2.5) 형식을 사용합니다.

12.3.2.5. 예제

예 12.11. “HTTP 서비스 공급자 끝점 구성” keep-alive 요청을 준수하고 모든 통신 오류를 방지하는 HTTP 서비스 공급자 끝점의 구성을 보여줍니다.

예 12.11. HTTP 서비스 공급자 끝점 구성

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"
       xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration
                             http://cxf.apache.org/schemas/configuration/http-conf.xsd
                           http://www.springframework.org/schema/beans
                             http://www.springframework.org/schema/beans/spring-beans.xsd">

  <http-conf:destination name="{http://apache.org/hello_world_soap_http}SoapPort.http-destination">
    <http-conf:server SuppressClientSendErrors="true"
                      SuppressClientReceiveErrors="true"
                      HonorKeepAlive="true" />
  </http-conf:destination>
</beans>

12.3.3. WSDL 사용

12.3.3.1. 네임스페이스

HTTP 공급자 끝점을 구성하는 데 사용되는 WSDL 확장 요소는 네임스페이스 http://cxf.apache.org/transports/http/configuration 에 정의되어 있습니다. 일반적으로 접두사 http-conf 를 사용합니다. HTTP 구성 요소를 사용하려면 예 12.12. “HTTP Provider WSDL Element's Namespace” 에 표시된 줄을 끝점의 WSDL 문서의 정의 요소에 추가해야 합니다.

예 12.12. HTTP Provider WSDL Element's Namespace

<definitions ...
       xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"

12.3.3.2. Undertow 런타임 또는 Netty 런타임

http-conf 네임스페이스의 요소를 사용하여 Undertow 런타임 또는 Netty 런타임을 구성할 수 있습니다.

12.3.3.3. 서버 요소

http-conf:server 요소는 WSDL 문서에서 HTTP 서비스 공급자의 연결 속성을 지정하는 데 사용됩니다. http-conf:server 요소는 WSDL 포트 요소의 자식입니다. 구성 파일에 사용된 server 요소와 동일한 속성이 있습니다. 속성은 표 12.5. “HTTP 서비스 공급자 구성 속성” 에서 확인할 수 있습니다.

12.3.3.4. 예제

예 12.13. “HTTP 서비스 공급자 엔드 포인트 구성” 에는 캐시와 상호 작용하지 않도록 지정하는 HTTP 서비스 공급자 엔드포인트를 구성하는 WSDL 조각을 보여줍니다.

예 12.13. HTTP 서비스 공급자 엔드 포인트 구성

<service ... >
  <port ... >
    <soap:address ... />
    <http-conf:server CacheControl="no-cache" />
  </port>
</service>

12.3.4. 서비스 공급자 캐시 제어 지침

표 12.6. “http-conf:server Cache Control Directives” HTTP 서비스 공급자가 지원하는 캐시 제어 지시문을 나열합니다.

표 12.6. http-conf:server Cache Control Directives
directive동작

no-cache

캐시는 먼저 서버와의 응답을 재검증하지 않고 후속 요청을 충족하기 위해 특정 응답을 사용할 수 없습니다. 특정 응답 헤더 필드가 이 값으로 지정된 경우 제한은 응답 내의 해당 헤더 필드에만 적용됩니다. 응답 헤더 필드를 지정하지 않으면 제한이 전체 응답에 적용됩니다.

public

모든 캐시는 응답을 저장할 수 있습니다.

private

공용(공유) 캐시는 응답이 단일 사용자를 대상으로 하므로 응답을 저장할 수 없습니다. 특정 응답 헤더 필드가 이 값으로 지정된 경우 제한은 응답 내의 해당 헤더 필드에만 적용됩니다. 응답 헤더 필드를 지정하지 않으면 제한이 전체 응답에 적용됩니다.

no-store

캐시는 응답의 일부 또는 이를 호출한 요청의 일부를 저장해야 합니다.

no-transform

캐시는 서버와 클라이언트 간의 응답으로 콘텐츠의 미디어 유형 또는 위치를 수정하지 않아야 합니다.

must-revalidate

캐시는 응답과 관련된 만료된 항목을 다시 시작해야 후속 응답에 해당 항목을 사용할 수 있습니다.

proxy-revalidate

공유 캐시에만 적용할 수 있고 공유되지 않은 비공개 캐시에서 무시할 수 있다는 점을 제외하고 must-revalidate와 동일합니다. 이 지시문을 사용하는 경우 public cache 지시문도 사용해야 합니다.

max-age

클라이언트는 지정된 시간(초)보다 오래된 응답을 수락할 수 있습니다.

s-max-age

공유 캐시에서만 시행할 수 있으며 개인 비공유 캐시에서 무시된다는 점을 제외하고 max-age와 동일한 작업을 수행합니다. s-max-age에서 지정한 기간은 max-age에서 지정한 기간을 재정의합니다. 이 지시문을 사용하는 경우 proxy-revalidate 지시문도 사용해야 합니다.

cache-extension

다른 캐시 지시문에 대한 추가 확장을 지정합니다. 확장 기능은 정보 또는 동작일 수 있습니다. 확장된 지시문은 표준 지시문의 컨텍스트에 지정되므로 확장 지시문을 이해하지 못하는 애플리케이션이 standard 지시문에서 요구하는 동작을 따를 수 있습니다.

12.4. Undertow 런타임 구성

12.4.1. 개요

Undertow 런타임은 분리된 끝점을 사용하여 HTTP 서비스 공급자 및 HTTP 소비자가 사용합니다. 런타임의 스레드 풀을 구성할 수 있으며, Undertow 런타임을 통해 HTTP 서비스 공급자에 대한 여러 보안 설정도 설정할 수 있습니다.

12.4.2. Maven 종속성

Apache Maven을 빌드 시스템으로 사용하는 경우 프로젝트의 pom.xml 파일에 다음 종속성을 포함하여 프로젝트에 Undertow 런타임을 추가할 수 있습니다.

<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-transports-http-undertow</artifactId>
    <version>${cxf-version}</version>
</dependency>

12.4.3. 네임스페이스

Undertow 런타임을 구성하는 데 사용되는 요소는 네임스페이스 http://cxf.apache.org/transports/http-undertow/configuration 에 정의되어 있습니다. Undertow 구성 요소를 사용하려면 예 12.14. “Undertow 런타임 구성 네임스페이스” 에 표시된 줄을 끝점 구성 파일의 빈 요소에 추가해야 합니다. 이 예에서 네임스페이스에는 httpu 접두사가 할당됩니다. 또한 구성 요소의 네임스페이스를 xsi:schemaLocation 속성에 추가해야 합니다.

예 12.14. Undertow 런타임 구성 네임스페이스

<beans ...
       xmlns:httpu="http://cxf.apache.org/transports/http-undertow/configuration"
       ...
       xsi:schemaLocation="...
                           http://cxf.apache.org/transports/http-undertow/configuration
                              http://cxf.apache.org/schemas/configuration/http-undertow.xsd
                          ...">

12.4.4. engine-factory 요소

httpu:engine-factory 요소는 애플리케이션에서 사용하는 Undertow 런타임을 구성하는 데 사용되는 루트 요소입니다. 구성 중인 Undertow 인스턴스를 관리하는 버스 의 이름이 값인 단일 필수 속성 버스가 있습니다.

참고

값은 일반적으로 기본 버스 인스턴스의 이름인 cxf 입니다.

http:engine-factory 요소에는 Undertow 런타임 팩토리에서 인스턴스화한 HTTP 포트를 구성하는 데 사용되는 정보가 포함된 세 개의 자식이 있습니다. 어린이는 표 12.7. “Undertow Runtime Factory 구성을 위한 요소” 에 설명되어 있습니다.

표 12.7. Undertow Runtime Factory 구성을 위한 요소
요소설명

httpu:engine

특정 Undertow 런타임 인스턴스에 대한 구성을 지정합니다. “엔진 요소” 을 참조하십시오.

httpu:identifiedTLSServerParameters

HTTP 서비스 공급자를 보호하기 위해 재사용 가능한 속성 세트를 지정합니다. 속성 집합을 참조할 수 있는 고유 식별자를 지정하는 단일 속성 id 가 있습니다.

httpu:identifiedThreadingParameters

Undertow 인스턴스의 스레드 풀을 제어하기 위해 재사용 가능한 속성 세트를 지정합니다. 속성 집합을 참조할 수 있는 고유 식별자를 지정하는 단일 속성 id 가 있습니다.

“스레드 풀 구성” 을 참조하십시오.

12.4.5. 엔진 요소

httpu:engine 요소는 Undertow 런타임의 특정 인스턴스를 구성하는 데 사용됩니다. 여기에는 두 개의 속성인 host 가 포함되어 있는 undertow 및 port 가 포함된 글로벌 IP 주소를 지정합니다. 이 속성은 Undertow 인스턴스에서 관리하는 포트의 수를 지정합니다.

참고

port 특성에 값을 0 으로 지정할 수 있습니다. 포트 특성이 0 으로 설정된 httpu:engine 요소에 지정된 모든 스레드 속성은 명시적으로 구성되지 않은 모든 Undertow 리스너의 구성으로 사용됩니다.

httpu:engine 요소에는 두 개의 하위 항목이 있을 수 있습니다. 하나는 보안 속성을 구성하고 다른 하나는 Undertow 인스턴스의 스레드 풀을 구성하는 데 사용됩니다. 각 유형의 구성에 대해 구성 정보를 직접 제공하거나 상위 httpu:engine-factory 요소에 정의된 구성 속성 집합에 대한 참조를 제공할 수 있습니다.

구성 속성을 제공하는 데 사용되는 하위 요소는 표 12.8. “Undertow 런타임 인스턴스 구성을 위한 요소” 에 설명되어 있습니다.

표 12.8. Undertow 런타임 인스턴스 구성을 위한 요소
요소설명

httpu:tlsServerParameters

특정 Undertow 인스턴스에 사용되는 보안을 구성하기 위한 속성 세트를 지정합니다.

httpu:tlsServerParametersRef

identifiedTLSServerParameters 요소에 의해 정의된 보안 속성 집합을 나타냅니다. id 속성은 참조된 identifiedTLSServerParameters 요소의 id를 제공합니다.

httpu:threadingParameters

특정 Undertow 인스턴스에서 사용하는 스레드 풀의 크기를 지정합니다. “스레드 풀 구성” 을 참조하십시오.

httpu:threadingParametersRef

확인된ThreadingParameters 요소에 의해 정의된 속성 집합을 나타냅니다. id 속성은 참조 된ThreadingParameters 요소의 id를 제공합니다.

12.4.6. 스레드 풀 구성

다음 중 하나를 통해 Undertow 인스턴스의 스레드 풀 크기를 구성할 수 있습니다.

  • engine-factory 요소에서 확인된ThreadingParameters 요소를 사용하여 스레드 풀의 크기를 지정합니다. 그런 다음 threadingParametersRef 요소를 사용하여 요소를 참조합니다.
  • threadingParameters 요소를 사용하여 스레드 풀의 크기를 직접 지정합니다.

threadingParameters 에는 스레드 풀의 크기를 지정하는 두 개의 속성이 있습니다. 속성은 표 12.9. “Undertow 스레드 풀 구성을 위한 속성” 에서 확인할 수 있습니다.

참고

httpu:identifiedThreadingParameters 요소에는 단일 자 식 스레드 매개 변수 요소가 있습니다.

표 12.9. Undertow 스레드 풀 구성을 위한 속성
속성설명

workerIOThreads

작업자에 대해 생성할 I/O 스레드 수를 지정합니다. 지정하지 않으면 dafult 값이 선택됩니다. 기본값은 CPU 코어당 하나의 I/O 스레드입니다.

minThreads

요청을 처리하는 데 Undertow 인스턴스에서 사용할 수 있는 최소 스레드 수를 지정합니다.

maxThreads

요청을 처리하는 데 Undertow 인스턴스에서 사용할 수 있는 최대 스레드 수를 지정합니다.

12.4.7. 예제

예 12.15. “Undertow 인스턴스 구성” 포트 번호 9001에서 Undertow 인스턴스를 구성하는 구성 조각을 보여줍니다.

예 12.15. Undertow 인스턴스 구성

<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:sec="http://cxf.apache.org/configuration/security"
  xmlns:http="http://cxf.apache.org/transports/http/configuration"
  xmlns:httpu="http://cxf.apache.org/transports/http-undertow/configuration"
  xmlns:jaxws="http://java.sun.com/xml/ns/jaxws"
  xsi:schemaLocation="http://cxf.apache.org/configuration/security
  		      http://cxf.apache.org/schemas/configuration/security.xsd
            http://cxf.apache.org/transports/http/configuration
            http://cxf.apache.org/schemas/configuration/http-conf.xsd
            http://cxf.apache.org/transports/http-undertow/configuration
            http://cxf.apache.org/schemas/configuration/http-undertow.xsd
            http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
  ...

  <httpu:engine-factory bus="cxf">
    <httpu:identifiedTLSServerParameters id="secure">
      <sec:keyManagers keyPassword="password">
        <sec:keyStore type="JKS" password="password"
                      file="certs/cherry.jks"/>
      </sec:keyManagers>
    </httpu:identifiedTLSServerParameters>

    <httpu:engine port="9001">
      <httpu:tlsServerParametersRef id="secure" />
      <httpu:threadingParameters minThreads="5"
                                 maxThreads="15" />
    </httpu:engine>
  </httpu:engine-factory>
 </beans>

12.4.8. 동시 요청 및 대기열 크기 제한

Undertow 서버 인스턴스에서 처리할 수 있는 최대 동시 연결 요청 수 및 대기열 크기에 대한 제한을 설정하는 Request Limiting Handler를 구성할 수 있습니다. 이 구성의 예는 다음과 같습니다. 예 12.16. “연결 요청 및 대기열 크기 제한”

표 12.10. 요청 제한 핸들러 구성을 위한 속성
속성설명

maximumConcurrentRequests

Undertow 인스턴스에서 처리할 수 있는 최대 동시 요청 수를 지정합니다. 요청 수가 이 제한을 초과하면 요청이 대기됩니다.

queueSize

Undertow 인스턴스에서 처리하기 위해 대기열에 있을 수 있는 총 요청 수를 지정합니다. 요청 수가 이 제한을 초과하면 요청이 거부됩니다.

예 12.16. 연결 요청 및 대기열 크기 제한

<httpu:engine-factory>
     <httpu:engine port="8282">
         <httpu:handlers>
             <bean class="org.jboss.fuse.quickstarts.cxf.soap.CxfRequestLimitingHandler">
                 <property name="maximumConcurrentRequests" value="1" />
                 <property name="queueSize" value="1"/>
             </bean>
         </httpu:handlers>
     </httpu:engine>
</httpu:engine-factory>

12.5. Netty 런타임 구성

12.5.1. 개요

Netty 런타임은 분리된 끝점을 사용하여 HTTP 서비스 공급자 및 HTTP 소비자가 사용합니다. 런타임의 스레드 풀을 구성할 수 있으며 Netty 런타임을 통해 HTTP 서비스 공급자에 대한 여러 보안 설정을 설정할 수도 있습니다.

12.5.2. Maven 종속 항목

Apache Maven을 빌드 시스템으로 사용하는 경우 프로젝트의 pom.xml 파일에 다음 종속성을 포함하여 Netty 런타임(웹 서비스 엔드포인트 정의)의 서버 측 구현을 프로젝트에 추가할 수 있습니다.

<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-transports-http-netty-server</artifactId>
    <version>${cxf-version}</version>
</dependency>

프로젝트의 pom.xml 파일에 다음 종속성을 포함하여 Netty 런타임(웹 서비스 클라이언트 정의)의 클라이언트 측 구현을 프로젝트에 추가할 수 있습니다.

<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-transports-http-netty-client</artifactId>
    <version>${cxf-version}</version>
</dependency>

12.5.3. 네임스페이스

Netty 런타임을 구성하는 데 사용되는 요소는 네임스페이스 http://cxf.apache.org/transports/http-netty-server/configuration 에 정의되어 있습니다. 일반적으로 httpn 접두사를 사용합니다. Netty 구성 요소를 사용하려면 예 12.17. “Netty Runtime 구성 네임스페이스” 에 표시된 줄을 끝점 구성 파일의 빈 요소에 추가해야 합니다. 또한 구성 요소의 네임스페이스를 xsi:schemaLocation 속성에 추가해야 합니다.

예 12.17. Netty Runtime 구성 네임스페이스

<beans ...
       xmlns:httpn="http://cxf.apache.org/transports/http-netty-server/configuration"
       ...
       xsi:schemaLocation="...
               http://cxf.apache.org/transports/http-netty-server/configuration
            http://cxf.apache.org/schemas/configuration/http-netty-server.xsd
               ...">

12.5.4. engine-factory 요소

httpn:engine-factory 요소는 애플리케이션에서 사용하는 Netty 런타임을 구성하는 데 사용되는 루트 요소입니다. 구성되는 Netty 인스턴스를 관리하는 버스 의 이름이 값인 단일 필수 속성인 버스 가 있습니다.

참고

값은 일반적으로 기본 버스 인스턴스의 이름인 cxf 입니다.

httpn:engine-factory 요소에는 Netty 런타임 팩토리에서 인스턴스화한 HTTP 포트를 구성하는 데 사용되는 정보가 포함된 세 개의 자식이 있습니다. 어린이는 표 12.11. “Netty Runtime Factory 구성을 위한 요소” 에 설명되어 있습니다.

표 12.11. Netty Runtime Factory 구성을 위한 요소
요소설명

httpn:engine

특정 Netty 런타임 인스턴스에 대한 구성을 지정합니다. “엔진 요소” 을 참조하십시오.

httpn:identifiedTLSServerParameters

HTTP 서비스 공급자를 보호하기 위해 재사용 가능한 속성 세트를 지정합니다. 속성 집합을 참조할 수 있는 고유 식별자를 지정하는 단일 속성 id 가 있습니다.

httpn:identifiedThreadingParameters

Netty 인스턴스의 스레드 풀을 제어하기 위해 재사용 가능한 속성 세트를 지정합니다. 속성 집합을 참조할 수 있는 고유 식별자를 지정하는 단일 속성 id 가 있습니다.

“스레드 풀 구성” 을 참조하십시오.

12.5.5. 엔진 요소

httpn:engine 요소는 Netty 런타임의 특정 인스턴스를 구성하는 데 사용됩니다. 표 12.12. “Netty Runtime Instance 구성을 위한 속성” httpn:engine 요소에서 지원하는 특성을 보여줍니다.

표 12.12. Netty Runtime Instance 구성을 위한 속성
속성설명

port

Netty HTTP 서버 인스턴스에서 사용하는 포트를 지정합니다. port 특성에 값을 0 으로 지정할 수 있습니다. 포트 특성을 0 으로 설정하여 engine 요소에 지정된 모든 스레드 속성은 명시적으로 구성되지 않은 모든 Netty 리스너의 구성으로 사용됩니다.

host

Netty HTTP 서버 인스턴스에서 사용하는 수신 주소를 지정합니다. 값은 호스트 이름 또는 IP 주소일 수 있습니다. 지정되지 않은 경우 Netty HTTP 서버는 모든 로컬 주소에서 수신 대기합니다.

readIdleTime

Netty 연결의 최대 읽기 유휴 시간을 지정합니다. 기본 스트림에 읽기 작업이 있을 때마다 타이머가 재설정됩니다.

writeIdleTime

Netty 연결의 최대 쓰기 유휴 시간을 지정합니다. 기본 스트림에 쓰기 작업이 있을 때마다 타이머가 재설정됩니다.

maxChunkContentSize

Netty 연결에 대해 집계된 최대 콘텐츠 크기를 지정합니다. 기본값은 10MB입니다.

httpn:engine 요소에는 Netty 인스턴스의 스레드 풀을 구성하기 위한 하나의 하위 요소와 보안 속성을 구성하는 하위 요소가 있습니다. 각 유형의 구성에 대해 구성 정보를 직접 제공하거나 상위 httpn:engine-factory 요소에 정의된 구성 속성 집합에 대한 참조를 제공할 수 있습니다.

httpn:engine 의 지원되는 하위 요소는 표 12.13. “Netty Runtime Instance 구성을 위한 요소” 에 표시됩니다.

표 12.13. Netty Runtime Instance 구성을 위한 요소
요소설명

httpn:tlsServerParameters

특정 Netty 인스턴스에 사용되는 보안을 구성하기 위한 속성 세트를 지정합니다.

httpn:tlsServerParametersRef

identifiedTLSServerParameters 요소에 의해 정의된 보안 속성 집합을 나타냅니다. id 속성은 참조된 identifiedTLSServerParameters 요소의 id를 제공합니다.

httpn:threadingParameters

특정 Netty 인스턴스에서 사용하는 스레드 풀의 크기를 지정합니다. “스레드 풀 구성” 을 참조하십시오.

httpn:threadingParametersRef

확인된ThreadingParameters 요소에 의해 정의된 속성 집합을 나타냅니다. id 속성은 참조 된ThreadingParameters 요소의 id를 제공합니다.

httpn:sessionSupport

true 인 경우 HTTP 세션에 대한 지원을 활성화합니다. 기본값은 false 입니다.

httpn:reuseAddress

ReuseAddress TCP 소켓 옵션을 설정하는 부울 값을 지정합니다. 기본값은 false 입니다.

12.5.6. 스레드 풀 구성

다음 중 하나를 통해 Netty 인스턴스의 스레드 풀 크기를 구성할 수 있습니다.

  • engine-factory 요소에서 확인된ThreadingParameters 요소를 사용하여 스레드 풀의 크기를 지정합니다. 그런 다음 threadingParametersRef 요소를 사용하여 요소를 참조합니다.
  • threadingParameters 요소를 사용하여 스레드 풀의 크기를 직접 지정합니다.

threadingParameters 요소에는 표 12.14. “Netty Thread Pool 구성을 위한 속성” 에 설명된 대로 스레드 풀의 크기를 지정하는 하나의 속성이 있습니다.

참고

httpn:identifiedThreadingParameters 요소에는 단일 자 식 스레드 매개 변수 요소가 있습니다.

표 12.14. Netty Thread Pool 구성을 위한 속성
속성설명

threadPoolSize

요청을 처리하는 데 Netty 인스턴스에서 사용할 수 있는 스레드 수를 지정합니다.

12.5.7. 예제

예 12.18. “Netty 인스턴스 구성” 는 다양한 Netty 포트를 구성하는 구성 조각을 보여줍니다.

예 12.18. Netty 인스턴스 구성

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:beans="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:h="http://cxf.apache.org/transports/http/configuration"
       xmlns:httpn="http://cxf.apache.org/transports/http-netty-server/configuration"
       xmlns:sec="http://cxf.apache.org/configuration/security"
       xsi:schemaLocation="
        http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans.xsd
        http://cxf.apache.org/configuration/security
            http://cxf.apache.org/schemas/configuration/security.xsd
        http://cxf.apache.org/transports/http/configuration
            http://cxf.apache.org/schemas/configuration/http-conf.xsd
        http://cxf.apache.org/transports/http-netty-server/configuration
            http://cxf.apache.org/schemas/configuration/http-netty-server.xsd"
>
    ...
    <httpn:engine-factory bus="cxf">
       <httpn:identifiedTLSServerParameters id="sample1">
         <httpn:tlsServerParameters jsseProvider="SUN" secureSocketProtocol="TLS">
            <sec:clientAuthentication want="false" required="false"/>
         </httpn:tlsServerParameters>
       </httpn:identifiedTLSServerParameters>

       <httpn:identifiedThreadingParameters id="sampleThreading1">
          <httpn:threadingParameters threadPoolSize="120"/>
       </httpn:identifiedThreadingParameters>

       <httpn:engine port="9000" readIdleTime="30000" writeIdleTime="90000">
          <httpn:threadingParametersRef id="sampleThreading1"/>
       </httpn:engine>

       <httpn:engine port="0">
          <httpn:threadingParameters threadPoolSize="400"/>
       </httpn:engine>

       <httpn:engine port="9001" readIdleTime="40000" maxChunkContentSize="10000">
         <httpn:threadingParameters threadPoolSize="99" />
         <httpn:sessionSupport>true</httpn:sessionSupport>
       </httpn:engine>

       <httpn:engine port="9002">
         <httpn:tlsServerParameters>
           <sec:clientAuthentication want="true" required="true"/>
         </httpn:tlsServerParameters>
       </httpn:engine>

       <httpn:engine port="9003">
          <httpn:tlsServerParametersRef id="sample1"/>
       </httpn:engine>

    </httpn:engine-factory>
</beans>

12.6. 분리된 모드에서 HTTP 전송 사용

12.6.1. 개요

일반적인 HTTP 요청/응답 시나리오에서는 요청 및 응답이 동일한 HTTP 연결을 사용하여 전송됩니다. 서비스 공급자는 요청을 처리하고 적절한 HTTP 상태 코드 및 응답 콘텐츠를 포함하는 응답으로 응답합니다. 요청이 성공하면 HTTP 상태 코드가 200으로 설정됩니다.

WS-RM을 사용하거나 요청이 실행하는 데 시간이 오래 걸리는 경우와 같이 일부 경우 요청 및 응답 메시지를 분리하는 것이 좋습니다. 이 경우 서비스 제공 업체는 요청을 수신한 HTTP 연결의 백채널을 통해 소비자에게 202 Accepted 응답을 보냅니다. 그런 다음 요청을 처리하고 새로운 분리 된 서버를 사용하여 소비자로 응답을 다시 보냅니다. 소비자 런타임은 들어오는 응답을 수신하고 애플리케이션 코드로 반환하기 전에 적절한 요청과 관련이 있습니다.

12.6.2. 분리된 상호 작용 구성

분리된 모드에서 HTTP 전송을 사용하려면 다음을 수행해야 합니다.

  1. WS-Addressing을 사용하도록 소비자를 구성합니다.

    “WS-Addressing을 사용하도록 엔드포인트 구성” 을 참조하십시오.

  2. 분리된 엔드포인트를 사용하도록 소비자를 구성합니다.

    “소비자 구성” 을 참조하십시오.

  3. 사용자가 WS-Addressing을 사용하도록 소비자가 상호 작용하는 서비스 공급자를 구성합니다.

    “WS-Addressing을 사용하도록 엔드포인트 구성” 을 참조하십시오.

12.6.3. WS-Addressing을 사용하도록 엔드포인트 구성

소비자가 WS-Addressing을 사용하는 소비자 및 모든 서비스 공급자를 지정합니다.

끝점이 다음 두 가지 방법 중 하나로 WS-Addressing을 사용하도록 지정할 수 있습니다.

  • 예 12.19. “WSDL을 사용하여 WS 주소 지정 활성화” 과 같이 wswa:UsingAddressing 요소를 엔드포인트의 WSDL 포트 요소에 추가합니다.

    예 12.19. WSDL을 사용하여 WS 주소 지정 활성화

    ...
    <service name="WidgetSOAPService">
      <port name="WidgetSOAPPort" binding="tns:WidgetSOAPBinding">
        <soap:address="http://widgetvendor.net/widgetSeller" />
        <wswa:UsingAddressing xmlns:wswa="http://www.w3.org/2005/02/addressing/wsdl"/>
      </port>
    </service>
    ...
  • 예 12.20. “정책을 사용하여 WS 연결 활성화” 과 같이 끝점의 WSDL 포트 요소에 WS-Addressing 정책 추가

    예 12.20. 정책을 사용하여 WS 연결 활성화

    ...
    <service name="WidgetSOAPService">
      <port name="WidgetSOAPPort" binding="tns:WidgetSOAPBinding">
        <soap:address="http://widgetvendor.net/widgetSeller" />
        <wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy"> <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata"> <wsp:Policy/> </wsam:Addressing> </wsp:Policy>
      </port>
    </service>
    ...
참고

WS-Addressing 정책은 wswa:UsingAddressing WSDL 요소를 대체합니다.

12.6.4. 소비자 구성

http-conf:conduit 요소의 DecoupledEndpoint 특성을 사용하여 분리된 엔드포인트를 사용하도록 소비자 엔드포인트를 구성합니다.

예 12.21. “분리된 HTTP 끝점을 사용하도록 소비자 구성” 분리된 끝점을 사용하도록 예 12.19. “WSDL을 사용하여 WS 주소 지정 활성화” 에 정의된 엔드포인트를 설정하는 구성을 보여줍니다. 이제 소비자는 http://widgetvendor.net/widgetSellerInbox 에서 모든 응답을 받습니다.

예 12.21. 분리된 HTTP 끝점을 사용하도록 소비자 구성

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:http="http://cxf.apache.org/transports/http/configuration"
       xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration
                             http://cxf.apache.org/schemas/configuration/http-conf.xsd
                           http://www.springframework.org/schema/beans
                             http://www.springframework.org/schema/beans/spring-beans.xsd">

  <http:conduit name="{http://widgetvendor.net/services}WidgetSOAPPort.http-conduit">
    <http:client DecoupledEndpoint="http://widgetvendor.net:9999/decoupled_endpoint" />
  </http:conduit>
</beans>

12.6.5. 메시지를 처리하는 방법

분리된 모드에서 HTTP 전송을 사용하면 HTTP 메시지 처리에 더 복잡한 계층을 추가합니다. 애플리케이션의 구현 수준 코드에 더 복잡한 복잡성이 투명하지만, 디버깅 이유를 위해 발생하는 상황을 이해하는 것이 중요할 수 있습니다.

그림 12.1. “분리된 HTTP 전송을 위한 메시지 흐름” 는 HTTP를 분리된 모드로 사용할 때 메시지 흐름을 표시합니다.

그림 12.1. 분리된 HTTP 전송을 위한 메시지 흐름

분리된 메시지 교환에는 15 단계가 있습니다.

요청은 다음 프로세스를 시작합니다.

  1. 소비자 구현은 작업을 호출하고 요청 메시지가 생성됩니다.
  2. WS-Addressing 계층은 WS-A 헤더를 메시지에 추가합니다.

    분리된 끝점이 소비자 구성에 지정되면 decoupled 엔드포인트의 주소가 WS-A ReplyTo 헤더에 배치됩니다.

  3. 메시지가 서비스 공급자로 전송됩니다.
  4. 서비스 공급자가 메시지를 수신합니다.
  5. 소비자의 요청 메시지는 공급자의 WS-A 계층으로 디스패치됩니다.
  6. WS-A ReplyTo 헤더가 anonymous로 설정되지 않았기 때문에 공급자는 HTTP 상태 코드가 202로 설정된 메시지를 다시 보냅니다. 요청이 수신되었음을 인정합니다.
  7. HTTP 계층은 원래 연결의 백채널을 사용하여 202 수락된 메시지를 소비자에게 다시 보냅니다.
  8. 소비자는 원본 메시지를 보내는 데 사용되는 HTTP 연결의 백채널에 202 Accepted 응답을 수신합니다.

    소비자가 202 Accepted 응답을 받으면 HTTP 연결이 종료됩니다.

  9. 요청은 요청이 처리되는 서비스 공급자의 구현에 전달됩니다.
  10. 응답이 준비되면 WS-A 계층으로 디스패치됩니다.
  11. WS-A 계층은 WS-Addressing 헤더를 응답 메시지에 추가합니다.
  12. HTTP 전송은 고객의 분리된 엔드포인트에 응답을 보냅니다.
  13. 소비자의 분리된 엔드포인트는 서비스 공급자로부터 응답을 수신합니다.
  14. 이 응답은 WS-A RelatesTo 헤더를 사용하여 적절한 요청과 상관 관계가 있는 소비자의 WS-A 계층으로 디스패치됩니다.
  15. 상관 관계가 클라이언트 구현으로 반환되고 호출은 차단 해제됩니다.

13장. SOAP Over JMS 사용

초록

Apache CXF는 W3C 표준 SOAP/JMS 전송을 구현합니다. 이 표준은 SOAP/HTTP 서비스에 대한 보다 강력한 대안을 제공하기 위한 것입니다. 이 전송을 사용하는 Apache CXF 애플리케이션은 SOAP/JMS 표준도 구현하는 애플리케이션과 상호 운용할 수 있어야 합니다. 전송은 끝점의 WSDL에서 직접 구성됩니다.

참고: CXF 3.0에서는 JMS 1.0.2 API에 대한 지원이 제거되었습니다. RedHat JBoss Fuse 6.2 이상을 사용하는 경우(CXF 3.0 포함) JMS 공급자는 JMS 1.1 API를 지원해야 합니다.

13.1. 기본 설정

13.1.1. 개요

JMS 프로토콜을 통한 SOAP 는 대부분의 서비스에서 사용하는 사용자 지정 SOAP/HTTP 프로토콜에 보다 안정적인 전송 계층을 제공하는 방식으로 W3C(World Wide Web Consortium)에 의해 정의됩니다. Apache CXF 구현은 사양을 완전히 준수하므로 호환 가능한 모든 프레임워크와 호환되어야 합니다.

이 전송에서는 JNDI를 사용하여 JMS 대상을 찾습니다. 작업이 호출되면 요청은 SOAP 메시지로 패키지되고 JMS 메시지 본문에서 지정된 대상에 전송됩니다.

SOAP/JMS 전송을 사용하려면 다음을 수행합니다.

  1. 전송 유형을 SOAP/JMS로 지정합니다.
  2. JMS URI를 사용하여 대상 대상을 지정합니다.
  3. 필요한 경우 JNDI 연결을 구성합니다.
  4. 선택적으로 추가 JMS 구성을 추가합니다.

13.1.2. JMS 전송 유형 지정

WSDL 바인딩을 지정할 때 JMS 전송을 사용하도록 SOAP 바인딩을 구성합니다. soap:binding 요소의 transport 속성을 http://www.w3.org/2010/soapjms/ 로 설정합니다. 예 13.1. “JMS 바인딩 사양을 통한 SOAP” SOAP/JMS를 사용하는 WSDL 바인딩을 보여줍니다.

예 13.1. JMS 바인딩 사양을 통한 SOAP

<wsdl:binding ... >
  <soap:binding style="document"
                transport="http://www.w3.org/2010/soapjms/" />
  ...
</wsdl:binding>

13.1.3. 대상 대상 지정

엔드포인트에 대한 WSDL 포트를 지정할 때 JMS 대상의 주소를 지정합니다. SOAP/JMS 엔드포인트의 address 사양은 SOAP/HTTP 끝점과 동일한 soap:address 요소 및 속성을 사용합니다. 차이점은 주소 사양입니다. JMS 엔드포인트는 JMS 1.0의 URI Scheme에 정의된 대로 JMS URI를 사용합니다. 예 13.2. “JMS URI 구문” 는 JMS URI의 구문을 표시합니다.

예 13.2. JMS URI 구문

jms:variant:destination?options

표 13.1. “JMS URI 변형” JMS URI에 사용 가능한 변형에 대해 설명합니다.

표 13.1. JMS URI 변형
변형설명

jndi

대상 이름이 JNDI 대기열 이름임을 지정합니다. 이 변형을 사용하는 경우 JNDI 공급자에 액세스하기 위한 구성을 제공해야 합니다.

jndi-topic

대상 이름이 JNDI 주제 이름임을 지정합니다. 이 변형을 사용하는 경우 JNDI 공급자에 액세스하기 위한 구성을 제공해야 합니다.

queue

대상이 JMS를 사용하여 확인된 대기열 이름임을 지정합니다. 제공된 문자열은 대상의 표현을 생성하기 위해 Session.createQueue() 로 전달됩니다.

주제

대상이 JMS를 사용하여 확인된 주제 이름임을 지정합니다. 제공된 문자열은 대상 표현을 생성하기 위해 Session.createTopic() 로 전달됩니다.

JMS URI의 옵션 부분은 전송을 구성하는 데 사용되며 13.2절. “JMS URI” 에서 설명합니다.

예 13.3. “SOAP/JMS 엔드포인트 주소” 대상 대상이 JNDI를 사용하여 조회되는 SOAP/JMS 엔드포인트에 대한 WSDL 포트 항목을 표시합니다.

예 13.3. SOAP/JMS 엔드포인트 주소

<wsdl:port ... >
  ...
  <soap:address location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue" />
</wsdl:port>

13.1.4. JNDI 및 JMS 전송 구성

SOAP/JMS는 JNDI 연결 및 JMS 전송을 구성하는 여러 가지 방법을 제공합니다.

13.2. JMS URI

13.2.1. 개요

SOAP/JMS를 사용하는 경우 JMS URI를 사용하여 끝점의 대상 대상을 지정합니다. URI에 하나 이상의 옵션을 추가하여 JMS 연결을 구성하는 데 JMS URI를 사용할 수도 있습니다. 이러한 옵션은 IETF 표준, Java Message Service 1.0용 URI Scheme에 자세히 설명되어 있습니다. JNDI 시스템, 응답 대상, 사용할 전달 모드 및 기타 JMS 속성을 구성하는 데 사용할 수 있습니다.

13.2.2. 구문

예 13.4. “JMS URI 옵션의 구문” 에 표시된 대로 대상의 주소에서 물음표(?)로 구분하여 JMS URI 끝에 하나 이상의 옵션을 추가할 수 있습니다. 여러 옵션은 앰퍼샌드(&amp;)로 구분됩니다. 예 13.4. “JMS URI 옵션의 구문” 는 JMS URI에서 여러 옵션을 사용하는 구문을 보여줍니다.

예 13.4. JMS URI 옵션의 구문

jms:variant:jmsAddress?option1=value1&option2=value2&_optionN_=valueN

13.2.3. JMS 속성

표 13.2. “URI 옵션으로 설정된 JMS 속성” 는 JMS 전송 계층에 영향을 주는 URI 옵션을 보여줍니다.

표 13.2. URI 옵션으로 설정된 JMS 속성
속성기본값설명

conduitIdSelectorPrefix

 

[선택 사항] conduit이 생성하는 모든 상관 관계 ID 앞에 있는 문자열 값입니다. 선택기는 이를 사용하여 응답을 수신할 수 있습니다.

deliveryMode

PERSISTENT

JMS PERSISTENT 또는 NON_PERSISTENT 메시지 의미 체계를 사용할지 여부를 지정합니다. PERSISTENT 전달 모드의 경우 JMS 브로커는 메시지를 인증하기 전에 영구 스토리지에 저장합니다. 반면 NON_PERSISTENT 메시지는 메모리에만 유지됩니다.

durableSubscriptionClientID

 

[선택 사항] 연결의 클라이언트 식별자를 지정합니다. 이 속성은 공급자가 클라이언트를 대신하여 유지 관리하는 상태와 연결을 연결하는 데 사용됩니다.This property is used to associate a connection with a state that the provider maintains on behalf of the client. 이를 통해 후속 ID를 가진 구독자는 이전 구독자가 남겨 두었던 상태에서 서브스크립션을 재개할 수 있습니다.

durableSubscriptionName

 

[선택 사항] 서브스크립션의 이름을 지정합니다.

messageType

byte

CXF에서 사용하는 JMS 메시지 유형을 지정합니다. 유효한 값은 다음과 같습니다.

  • byte
  • text
  • Binary

암호

 

[선택 사항] 연결 생성을 위한 암호를 지정합니다. URI에 이 속성을 추가하는 것은 권장되지 않습니다.

priority

4

0(최저)에서 9(최고) 사이의 범위인 JMS 메시지 우선 순위를 지정합니다.

receiveTimout

60000

요청/복원 교환이 사용될 때 클라이언트가 응답을 기다리는 시간을 지정합니다.Specifies the time, in milliseconds, the client will wait for a reply when request/reply exchange are used.

reconnectOnException

true

[CXF 3.0에서 사용 중지됨] 예외가 발생할 때 전송이 다시 연결되는지 여부를 지정합니다.

3.0에서는 예외가 발생할 때 항상 전송이 다시 연결됩니다.

replyToName

 

[선택 사항] 큐 메시지의 응답 대상을 지정합니다. 응답 대상은 JMSReplyTo 헤더에 나타납니다. JMS 공급자가 지정되지 않은 경우 임시 응답 큐를 할당하므로 request-reply 의미가 있는 애플리케이션에 이 속성을 설정하는 것이 좋습니다.

이 속성의 값은 JMS URI에 지정된 변형에 따라 해석됩니다.

  • JNDI 변형 - JNDI로 확인된 대상 대기열의 이름입니다.
  • queue variant- JMS를 사용하여 확인된 대상 대기열의 이름입니다.

sessionTransacted

false

트랜잭션 유형을 지정합니다. 유효한 값은 다음과 같습니다.

  • true-resource 로컬 트랜잭션
  • False-JTA 트랜잭션

timeToLive

0

JMS 공급자가 메시지를 삭제할 시간(밀리초)을 지정합니다. 값 0은 무한한 수명을 나타냅니다.A value of 0 indicates an infinite lifetime.

topicReplyToName

 

[선택 사항] 주제 메시지의 응답 대상을 지정합니다. 이 속성의 값은 JMS URI에 지정된 변형에 따라 해석됩니다.

  • JNDI-topic -JNDI로 확인된 대상 항목의 이름입니다.
  • topic- JMS에서 해결한 대상 항목의 이름입니다.

useConduitIdSelector

true

conduit의 UUID가 모든 상관 관계 ID의 접두사로 사용되는지 여부를 지정합니다.

모든 conduits에는 고유한 UUID가 할당되므로 이 속성을 true 로 설정하면 여러 끝점이 JMS 대기열 또는 주제를 공유할 수 있습니다.

사용자 이름

 

[선택 사항] 연결을 만드는 데 사용할 사용자 이름을 지정합니다.

13.2.4. JNDI 속성

표 13.3. “URI 옵션으로 설정된 JNDI 속성” 는 이 엔드포인트에 대해 JNDI를 구성하는 데 사용할 수 있는 URI 옵션을 보여줍니다.

표 13.3. URI 옵션으로 설정된 JNDI 속성
속성설명

jndiConnectionFactoryName

JMS 연결 팩토리의 JNDI 이름을 지정합니다.

jndiInitialContextFactory

JNDI 공급자의 정규화된 Java 클래스 이름을 지정합니다(Java x.jms.InitialContextFactory 유형 여야 함). java.naming.factory.initial Java 시스템 속성을 설정하는 것과 동일합니다.

jndiTransactionManagerName

Spring, Blueprint 또는 JNDI에서 검색할 JTA 트랜잭션 관리자의 이름을 지정합니다. 트랜잭션 관리자가 발견되면 JTA 트랜잭션이 활성화됩니다. sessionTransacted JMS 속성을 참조하십시오.

jndiURL

JNDI 공급자를 초기화하는 URL을 지정합니다. java.naming.provider.url Java 시스템 속성을 설정하는 것과 동일합니다.

13.2.5. 추가 JNDI 속성

java.naming.factory.initialjava.naming.provider.url 의 속성은 JNDI 공급자를 초기화하는 데 필요한 표준 속성입니다. 그러나 JNDI 공급자는 표준 속성 외에도 사용자 정의 속성을 지원할 수도 있습니다. 이 경우 jndi-PropertyName 형식의 URI 옵션을 설정하여 임의의 JNDI 속성을 설정할 수 있습니다.

예를 들어, JNDI의 SUN의 LDAP 구현을 사용하는 경우 예 13.5. “JMS URI에서 JNDI 속성 설정” 과 같이 JMS URI에서 JNDI 속성 java.naming.factory.control 을 설정할 수 있습니다.

예 13.5. JMS URI에서 JNDI 속성 설정

jms:queue:FOO.BAR?jndi-java.naming.factory.control=com.sun.jndi.ldap.ResponseControlFactory

13.2.6. 예제

JMS 공급자가 아직 구성되지 않은 경우 옵션을 사용하여 URI에 필수 JNDI 구성 세부 정보를 제공할 수 있습니다( 표 13.3. “URI 옵션으로 설정된 JNDI 속성”참조). 예를 들어 Apache ActiveMQ JMS 공급자를 사용하도록 엔드포인트를 구성하고 test.cxf.jmstransport.queue 라는 큐에 연결하려면 예 13.6. “JNDI 연결을 구성하는 JMS URI” 에 표시된 URI를 사용합니다.

예 13.6. JNDI 연결을 구성하는 JMS URI

jms:jndi:dynamicQueues/test.cxf.jmstransport.queue
?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory
&jndiConnectionFactoryName=ConnectionFactory
&jndiURL=tcp://localhost:61616

13.2.7. 서비스 게시

JAX-WS 표준 publish() 메서드를 사용하여 SOAP/JMS 서비스를 게시할 수 없습니다. 대신 예 13.7. “SOAP/JMS 서비스 게시” 과 같이 Apache CXF의 JaxWsServerFactoryBean 클래스를 사용해야 합니다.

예 13.7. SOAP/JMS 서비스 게시

String address = "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue3"
    + "?jndiInitialContextFactory"
    + "=org.apache.activemq.jndi.ActiveMQInitialContextFactory"
    + "&jndiConnectionFactoryName=ConnectionFactory"
    + "&jndiURL=tcp://localhost:61500";
Hello implementor = new HelloImpl();
JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
svrFactory.setServiceClass(Hello.class);
svrFactory.setAddress(address);
svrFactory.setTransportId(JMSSpecConstants.SOAP_JMS_SPECIFICIATION_TRANSPORTID);
svrFactory.setServiceBean(implementor);
svrFactory.create();

예 13.7. “SOAP/JMS 서비스 게시” 의 코드는 다음을 수행합니다.

끝점의 주소를 나타내는 JMS URI를 생성합니다.

JaxWsServerFactoryBean 을 인스턴스화하여 서비스를 게시합니다.

서비스의 JMS URI를 사용하여 팩토리 빈의 address 필드를 설정합니다.

팩토리에 의해 생성된 서비스가 SOAP/JMS 전송을 사용하도록 지정합니다.

13.2.8. 서비스 사용

표준 JAX-WS API는 SOAP/JMS 서비스를 사용하는 데 사용할 수 없습니다. 대신 예 13.8. “SOAP/JMS 서비스 사용” 과 같이 Apache CXF의 JaxWsProxyFactoryBean 클래스를 사용해야 합니다.

예 13.8. SOAP/JMS 서비스 사용

// Java
public void invoke() throws Exception {
    String address = "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue3"
        + "?jndiInitialContextFactory"
        + "=org.apache.activemq.jndi.ActiveMQInitialContextFactory"
        + "&jndiConnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61500";
    JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
    factory.setAddress(address);
    factory.setTransportId(JMSSpecConstants.SOAP_JMS_SPECIFICIATION_TRANSPORTID);
    factory.setServiceClass(Hello.class);
    Hello client = (Hello)factory.create();
    String reply = client.sayHi(" HI");
    System.out.println(reply);
}

예 13.8. “SOAP/JMS 서비스 사용” 의 코드는 다음을 수행합니다.

끝점의 주소를 나타내는 JMS URI를 생성합니다.

JaxWsProxyFactoryBean 을 인스턴스화하여 프록시를 생성합니다.

서비스의 JMS URI를 사용하여 팩토리 빈의 address 필드를 설정합니다.

팩토리에서 생성한 프록시가 SOAP/JMS 전송을 사용하도록 지정합니다.

13.3. WSDL 확장

13.3.1. 개요

바인딩 범위, 서비스 범위 또는 포트 범위에서 WSDL 확장 요소를 계약에 삽입하여 JMS 전송의 기본 구성을 지정할 수 있습니다. WSDL 확장 기능을 사용하면 JNDI InitialContext 를 부트스트래핑하는 속성을 지정할 수 있습니다. 그러면 JMS 대상을 조회하는 데 사용할 수 있습니다. JMS 전송 계층의 동작에 영향을 미치는 일부 속성을 설정할 수도 있습니다.

13.3.2. SOAP/JMS 네임스페이스

SOAP/JMS WSDL 확장은 http://www.w3.org/2010/soapjms/ 네임스페이스에 정의되어 있습니다. WSDL 계약에서 이를 사용하려면 다음과 같은 설정을 wsdl:definitions 요소에 추가합니다.

<wsdl:definitions ...
    xmlns:soapjms="http://www.w3.org/2010/soapjms/"
  ... >

13.3.3. WSDL 확장 요소

표 13.4. “SOAP/JMS WSDL 확장 요소” JMS 전송을 구성하는 데 사용할 수 있는 모든 WSDL 확장 요소를 보여줍니다.

표 13.4. SOAP/JMS WSDL 확장 요소
요소기본값설명

soapjms:jndiInitialContextFactory

 

JNDI 공급자의 정규화된 Java 클래스 이름을 지정합니다. java.naming.factory.initial Java 시스템 속성을 설정하는 것과 동일합니다.

soapjms:jndiURL

 

JNDI 공급자를 초기화하는 URL을 지정합니다. java.naming.provider.url Java 시스템 속성을 설정하는 것과 동일합니다.

soapjms:jndiContextParameter

 

JNDI InitialContext 를 생성하기 위한 추가 속성을 지정합니다. namevalue 속성을 사용하여 속성을 지정합니다.

soapjms:jndiConnectionFactoryName

 

JMS 연결 팩토리의 JNDI 이름을 지정합니다.

soapjms:deliveryMode

PERSISTENT

JMS PERSISTENT 또는 NON_PERSISTENT 메시지 의미 체계를 사용할지 여부를 지정합니다. PERSISTENT 전달 모드의 경우 JMS 브로커는 메시지를 인증하기 전에 영구 스토리지에 저장합니다. 반면 NON_PERSISTENT 메시지는 메모리에만 유지됩니다.

soapjms:replyToName

 

[선택 사항] 큐 메시지의 응답 대상을 지정합니다. 응답 대상은 JMSReplyTo 헤더에 나타납니다. JMS 공급자가 지정되지 않은 경우 임시 응답 큐를 할당하므로 request-reply 의미가 있는 애플리케이션에 이 속성을 설정하는 것이 좋습니다.

이 속성의 값은 JMS URI에 지정된 변형에 따라 해석됩니다.

  • JNDI 변형 - JNDI로 확인된 대상 대기열의 이름입니다.
  • queue variant- JMS를 사용하여 확인된 대상 대기열의 이름입니다.

soapjms:priority

4

0(최저)에서 9(최고) 사이의 범위인 JMS 메시지 우선 순위를 지정합니다.

soapjms:timeToLive

0

시간(밀리초)은 JMS 공급자가 메시지를 삭제합니다. 값 0은 무한한 수명을 나타냅니다.A value of 0 represents an infinite lifetime.

13.3.4. 구성 범위

WSDL 계약을 배치하는 WSDL 요소는 계약에 정의된 끝점에 대한 구성 변경 범위에 영향을 미칩니다. SOAP/JMS WSDL 요소는 wsdl:binding 요소, wsdl:service 요소 또는 wsdl:port 요소의 자식으로 배치할 수 있습니다. SOAP/JMS 요소의 상위는 다음 중 구성이 배치되는 범위를 결정합니다.

바인딩 범위
wsdl: binding 요소 내에 확장 요소를 배치하여 바인딩 범위 에서 JMS 전송을 구성할 수 있습니다. 이 범위의 요소는 이 바인딩을 사용하는 모든 엔드포인트에 대한 기본 구성을 정의합니다. 바인딩 범위의 설정은 서비스 범위 또는 포트 범위에서 재정의할 수 있습니다.
서비스 범위
wsdl: service 요소 내에 확장 요소를 배치하여 서비스 범위 에서 JMS 전송을 구성할 수 있습니다. 이 범위의 요소는 이 서비스의 모든 엔드포인트에 대한 기본 구성을 정의합니다. 서비스 범위의 모든 설정은 포트 범위에서 재정의할 수 있습니다.
포트 범위
wsdl: port 요소 내에 확장 요소를 배치하여 포트 범위 에서 JMS 전송을 구성할 수 있습니다. 포트 범위의 요소는 이 포트에 대한 구성을 정의합니다. 서비스 범위 또는 바인딩 범위에서 정의된 동일한 확장 요소의 기본값을 재정의합니다.

13.3.5. 예제

예 13.9. “WSDL과 SOAP/JMS 구성의 계약” SOAP/JMS 서비스에 대한 WSDL 계약을 보여줍니다. 바인딩 범위, 서비스 범위에서 메시지 전달 세부 정보 및 포트 범위의 응답 대상에서 JNDI 계층을 구성합니다.

예 13.9. WSDL과 SOAP/JMS 구성의 계약

<wsdl:definitions ...
    xmlns:soapjms="http://www.w3.org/2010/soapjms/"
  ... >
  ...
  <wsdl:binding name="JMSGreeterPortBinding" type="tns:JMSGreeterPortType">
    ...
    <soapjms:jndiInitialContextFactory>
      org.apache.activemq.jndi.ActiveMQInitialContextFactory
    </soapjms:jndiInitialContextFactory>
    <soapjms:jndiURL>tcp://localhost:61616</soapjms:jndiURL>
    <soapjms:jndiConnectionFactoryName>
      ConnectionFactory
    </soapjms:jndiConnectionFactoryName>
    ...
  </wsdl:binding>
  ...
  <wsdl:service name="JMSGreeterService">
    ...
    <soapjms:deliveryMode>NON_PERSISTENT</soapjms:deliveryMode>
    <soapjms:timeToLive>60000</soapjms:timeToLive>
    ...
    <wsdl:port binding="tns:JMSGreeterPortBinding" name="GreeterPort">
      <soap:address location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue" />
      <soapjms:replyToName>
        dynamicQueues/greeterReply.queue
      </soapjms:replyToName>
      ...
    </wsdl:port>
    ...
  </wsdl:service>
  ...
</wsdl:definitions>

예 13.9. “WSDL과 SOAP/JMS 구성의 계약” 의 WSDL은 다음을 수행합니다.

SOAP/JMS 확장의 네임스페이스를 선언합니다.

바인딩 범위에서 JNDI 연결을 구성합니다.

JMS 전달 스타일을 비영구로 설정하고 각 메시지를 1분 동안 활성으로 설정합니다.

대상 대상을 지정합니다.

응답 메시지가 greeterReply.queue 큐에 전송되도록 JMS 전송을 구성합니다.

14장. 일반 JMS 사용

초록

Apache CXF는 JMS 전송의 일반적인 구현을 제공합니다. 일반 JMS 전송은 SOAP 메시지 사용으로 제한되지 않으며 JMS를 사용하는 모든 애플리케이션에 연결할 수 있습니다.

참고: CXF 3.0에서는 JMS 1.0.2 API에 대한 지원이 제거되었습니다. RedHat JBoss Fuse 6.2 이상을 사용하는 경우(CXF 3.0 포함) JMS 공급자는 JMS 1.1 API를 지원해야 합니다.

14.1. JMS 구성 방법

Apache CXF 일반 JMS 전송은 모든 JMS 공급자에 연결하고 JMS 메시지를 TextMessage 또는 ByteMessage 의 본문과 교환하는 애플리케이션으로 작업할 수 있습니다.

JMS 전송을 활성화하고 구성하는 방법에는 두 가지가 있습니다.

14.2. JMS 구성 빈 사용

14.2.1. 개요

JMS 구성을 단순화하고 더 강력하게 만들기 위해 Apache CXF는 단일 JMS 구성 빈을 사용하여 JMS 끝점을 구성합니다. 빈은 org.apache.cxf.transport.jms.JMSConfiguration 클래스에서 구현됩니다. 끝점을 직접 구성하거나 JMS 구성 및 대상을 구성하는 데 사용할 수 있습니다.

14.2.2. 구성 네임스페이스

JMS 구성 빈에서는 Spring p-namespace 를 사용하여 구성을 최대한 간단하게 만듭니다. 이 네임스페이스를 사용하려면 예 14.1. “Spring p-namespace 선언” 과 같이 구성의 루트 요소에 선언해야 합니다.

예 14.1. Spring p-namespace 선언

<beans ...
  xmlns:p="http://www.springframework.org/schema/p"
  ... >
  ...
</beans>

14.2.3. 설정 지정

org.apache.cxf.transport.jms.JMSConfiguration 클래스의 빈을 정의하여 JMS 구성을 지정합니다. 빈의 속성은 전송에 대한 구성 설정을 제공합니다.

중요

CXF 3.0에서는 JMS 전송에 더 이상 Spring JMS에 종속되지 않으므로 일부 Spring JMS 관련 옵션이 제거되었습니다.

표 14.1. “일반 JMS 구성 속성” 공급자와 소비자에게 공통된 속성을 나열합니다.

표 14.1. 일반 JMS 구성 속성
속성기본값설명

connectionFactory

 

[필수] JMS ConnectionFactory를 정의하는 빈에 대한 참조를 지정합니다.

wrapInSingleConnectionFactory

true [pre v3.0]

CXF 3.0에서 삭제

CXF 3.0 pre CXF 3.0 은 Spring SingleConnectionFactory 로 ConnectionFactory를 래핑할지 여부를 지정합니다.

연결을 풀링하지 않는 ConnectionFactory를 사용할 때 JMS 전송의 성능이 향상되므로 이 속성을 활성화합니다. JMS 전송에서 각 메시지에 대한 새 연결을 생성하고 연결을 캐시하려면 SingleConnectionFactory 가 필요하므로 재사용할 수 있습니다.

reconnectOnException

false

CXF 3.0에서 더 이상 사용되지 않는 CXF는 예외가 발생할 때 항상 다시 연결합니다.

pre CXF 3.0 예외 발생 시 새 연결을 만들지 여부를 지정합니다.

Spring SingleConnectionFactory 를 사용하여 ConnectionFactory를 래핑하는 경우:

  • True easingon an exception, create a new connection

    PooledConnectionFactory를 사용할 때는 이 옵션을 활성화하지 마십시오. 이 옵션은 pooled 연결만 반환하지만 다시 연결하지 않기 때문입니다.

  •  - 예외로, 다시 연결을 시도하지 마십시오.

targetDestination

 

대상의 JNDI 이름 또는 공급자별 이름을 지정합니다.

replyDestination

 

응답이 전송되는 JMS 대상의 JMS 이름을 지정합니다. 이 속성을 사용하면 응답에 사용자 정의 대상을 사용할 수 있습니다. 자세한 내용은 14.6절. “이름이 지정된 Reply Destination 사용” 에서 참조하십시오.

destinationResolver

DynamicDestinationResolver

Spring DestinationResolver 에 대한 참조를 지정합니다.

이 속성을 사용하면 대상 이름이 JMS 대상으로 확인되는 방법을 정의할 수 있습니다. 유효한 값은 다음과 같습니다.

  • DynamicDestinationResolver JMS 공급자의 기능을 사용하여 대상 이름 확인.
  • JndiDestinationResolver JNDI를 사용하여 대상 이름을 확인.

transactionManager

 

Spring 트랜잭션 관리자에 대한 참조를 지정합니다. 이를 통해 서비스는 JTA 트랜잭션에 참여할 수 있습니다.

taskExecutor

SimpleAsyncTaskExecutor

CXF 3.0에서 삭제

CXF 3.0 preCXF 3.0 Spring TaskExecutor에 대한 참조를 지정합니다. 이는 리스너에서 수신되는 메시지를 처리하는 방법을 결정하는 데 사용됩니다.

useJms11

false

CXF 3.0에서 제거된 CXF 3.0에서는 JMS 1.1 기능만 지원합니다.

pre CXF 3.0 에서는 JMS 1.1 기능이 사용되는지 여부를 지정합니다. 유효한 값은 다음과 같습니다.

  • 정한 JMS 1.1 기능
  • false — JMS 1.0.2 features

messageIdEnabled

true

CXF 3.0에서 삭제

pre CXF 3.0 은 JMS 전송에서 JMS 브로커가 메시지 ID를 제공할지 여부를 지정합니다. 유효한 값은 다음과 같습니다.

  • True databind-broker는 메시지 ID를 제공해야 합니다.
  • false ECDHE-ECDHEbroker에 메시지 ID를 제공할 필요가 없습니다.

    이 경우 끝점은 메시지 생산자의 setDisableMessageID() 메서드를 true 로 호출합니다. 그러면 브로커에 메시지 ID를 생성하거나 엔드포인트의 메시지에 추가할 필요가 없다는 힌트가 제공됩니다. 브로커는 힌트를 수락하거나 무시합니다.

messageTimestampEnabled

true

CXF 3.0에서 삭제

CXF 3.0 pre CXF 3.0 은 JMS 전송에서 JMS 브로커가 메시지 타임스탬프를 제공할지 여부를 지정합니다. 유효한 값은 다음과 같습니다.

  • True ep-Progressbroker는 메시지 타임스탬프를 제공해야 합니다.
  • false databind-ECDHEbroker는 메시지 타임스탬프를 제공할 필요가 없습니다.

    이 경우 끝점은 메시지 생산자의 setDisableMessageTimestamp() 메서드를 true 로 호출합니다. 그러면 브로커가 타임스탬프를 생성하거나 엔드포인트의 메시지에 추가할 필요가 없다는 힌트가 제공됩니다. 브로커는 힌트를 수락하거나 무시합니다.

cacheLevel

-1( 기능 비활성화)

CXF 3.0에서 삭제

pre CXF 3.0 JMS 리스너 컨테이너가 적용할 수 있는 캐싱 수준을 지정합니다. 유효한 값은 다음과 같습니다.

  • 0 — CACHE_NONE
  • 1 — CACHE_CONNECTION
  • 2 — CACHE_SESSION
  • 3 — CACHE_CONSUMER
  • 4 — CACHE_AUTO

자세한 내용은 Class DefaultMessageListenerContainer를 참조하십시오.

pubSubNoLocal

false

주제를 사용할 때 자체 메시지를 수신할지 여부를 지정합니다.

  • True databind-Do not receive your own messages
  •  짓 - 자신의 메시지를 받을 수 있습니다.

receiveTimeout

60000

응답 메시지를 대기하는 시간(밀리초)을 지정합니다.

explicitQosEnabled

false

각 메시지(true)에 대해 QoS 설정(예: 우선 순위, 지속성, 시간)이 명시적으로 설정되는지 또는 기본값(false)을 사용할지 여부를 지정합니다.

deliveryMode

2

메시지가 영구적인지 여부를 지정합니다. 유효한 값은 다음과 같습니다.

  • 1 (NON_PERSISTENT)-messages는 메모리만 유지
  • 2 (PERSISTENT) - 디스크에 유지됨

priority

4

메시지 우선 순위를 지정합니다. JMS 우선 순위 값의 범위는 0 (최저)에서 9 (최고)입니다. 자세한 내용은 JMS 공급자 설명서를 참조하십시오.

timeToLive

0 (Indefinitely)

전송된 메시지가 삭제되기 전의 시간(밀리초)을 지정합니다.

sessionTransacted

false

JMS 트랜잭션이 사용되는지 여부를 지정합니다.

concurrentConsumers

1

CXF 3.0에서 삭제

pre CXF 3.0 은 리스너에 대한 최소 동시 소비자 수를 지정합니다.

maxConcurrentConsumers

1

CXF 3.0에서 삭제

pre CXF 3.0 은 리스너에 대한 최대 동시 소비자 수를 지정합니다.

messageSelector

 

들어오는 메시지를 필터링하는 데 사용되는 선택기의 문자열 값을 지정합니다. 이 속성을 사용하면 여러 개의 연결이 큐를 공유할 수 있습니다. 메시지 선택기를 지정하는 데 사용되는 구문에 대한 자세한 내용은 JMS 1.1 사양 을 참조하십시오.

subscriptionDurable

false

서버가 내구성 있는 서브스크립션을 사용하는지 여부를 지정합니다.

durableSubscriptionName

 

내구성 서브스크립션을 등록하는 데 사용되는 이름(문자열)을 지정합니다.

messageType

text

메시지 데이터를 JMS 메시지로 패키징하는 방법을 지정합니다. 유효한 값은 다음과 같습니다.

  • 텍스트: 데이터가 TextMessage로 패키징됨을 나타냅니다.
  • 바이트 배열( byte [] )으로 데이터가 패키징됨을 나타냅니다.Indicates that the data will be packaged as an array of bytes (byte[])
  • 바이너리 - 데이터가 ByteMessage로 패키지됨을 나타냅니다.

pubSubDomain

false

대상 대상이 항목 또는 큐인지 여부를 지정합니다.Specifies whether the target destination is a topic or a queue. 유효한 값은 다음과 같습니다.

  • true additionaltopic
  • false — queue

jmsProviderTibcoEms

false

JMS 공급자가 Tibco EMS인지 여부를 지정합니다.

true 로 설정하면 보안 컨텍스트의 보안 주체가 JMS_TIBCO_SENDER 헤더에서 채워집니다.

useMessageIDAsCorrelationID

false

CXF 3.0에서 삭제

JMS에서 메시지 ID를 사용하여 메시지의 상관 관계를 유지할지 여부를 지정합니다.

클라이언트는 true 로 설정하면 클라이언트는 생성된 상관관계 ID를 설정합니다.

maxSuspendedContinuations

-1( 기능 비활성화)

CXF 3.0 JMS 대상이 보유할 수 있는 최대 중단된 연속 수를 지정합니다. 현재 숫자가 지정된 최대값을 초과하면 JMSListenerContainer가 중지됩니다.

reconnectPercentOfMax

70

CXF 3.0maxSuspendedContinuations 를 초과하기 위해 JMSListenerContainer를 다시 시작할 시기를 지정합니다.

현재 일시 중단된 연속 수가 (maxSuspendedContinuations * reconnectPercentOfMax/100) 이하인 경우 리스너 컨테이너가 재시작됩니다.

예 14.2. “JMS 구성 빈” 에 표시된 대로 빈의 속성은 빈 요소에 대한 속성으로 지정됩니다. 모두 Spring p 네임스페이스에 선언됩니다.

예 14.2. JMS 구성 빈

<bean id="jmsConfig"
      class="org.apache.cxf.transport.jms.JMSConfiguration"
      p:connectionFactory="jmsConnectionFactory"
      p:targetDestination="dynamicQueues/greeter.request.queue"
      p:pubSubDomain="false" />

14.2.4. 끝점에 구성 적용

JMSConfiguration 빈은 Apache CXF 기능 메커니즘을 사용하여 서버 및 클라이언트 끝점 모두에 직접 적용할 수 있습니다. 이렇게 하려면 다음을 수행합니다.

  1. 끝점의 address 속성을 jms:// 로 설정합니다.
  2. jaxws:feature 요소를 엔드포인트의 구성에 추가합니다.
  3. 유형 org.apache.cxf.transport.jms.JMSConfigFeature 의 빈을 기능에 추가합니다.
  4. 요소의 p:jmsConfig-ref 속성을 JMSConfiguration 빈의 ID로 설정합니다.

예 14.3. “JAX-WS 클라이언트에 JMS 구성 추가”예 14.2. “JMS 구성 빈” 의 JMS 구성을 사용하는 JAX-WS 클라이언트를 표시합니다.

예 14.3. JAX-WS 클라이언트에 JMS 구성 추가

<jaxws:client id="CustomerService"
              xmlns:customer="http://customerservice.example.com/"
              serviceName="customer:CustomerServiceService"
              endpointName="customer:CustomerServiceEndpoint"
              address="jms://"
              serviceClass="com.example.customerservice.CustomerService">
  <jaxws:features>
    <bean xmlns="http://www.springframework.org/schema/beans"
          class="org.apache.cxf.transport.jms.JMSConfigFeature"
          p:jmsConfig-ref="jmsConfig"/>
  </jaxws:features>
</jaxws:client>

14.2.5. 전송에 구성 적용

JMSConfiguration 빈은 jms:jmsConfig-ref 요소를 사용하여 JMS 구성 및 JMS 대상에 적용할 수 있습니다. jms:jmsConfig-ref 요소의 값은 JMSConfiguration 빈의 ID입니다.

예 14.4. “JMS 구성에 JMS 구성 추가”예 14.2. “JMS 구성 빈” 의 JMS 구성을 사용하는 JMS 구성을 보여줍니다.

예 14.4. JMS 구성에 JMS 구성 추가

<jms:conduit name="{http://cxf.apache.org/jms_conf_test}HelloWorldQueueBinMsgPort.jms-conduit">
  ...
  <jms:jmsConfig-ref>jmsConf</jms:jmsConfig-ref>
</jms:conduit>

14.3. 클라이언트-Side JMS 성능 최적화

14.3.1. 개요

두 가지 주요 설정은 풀링 및 동기 수신이라는 클라이언트의 JMS 성능에 영향을 미칩니다.

14.3.2. 풀링

클라이언트 측에서 CXF는 각 메시지에 대해 새로운 JMS 세션 및 JMS 생산자를 생성합니다. 이는 세션과 생산자 오브젝트가 모두 스레드 안전하지 않기 때문입니다. 생산자 생성은 서버와 통신해야 하므로 특히 시간이 많이 사용됩니다.

연결 팩토리를 풀링하면 연결, 세션 및 생산자를 캐시하여 성능이 향상됩니다.

ActiveMQ의 경우 풀링을 구성하는 것이 간단합니다. 예를 들면 다음과 같습니다.

import org.apache.activemq.ActiveMQConnectionFactory;
import org.apache.activemq.pool.PooledConnectionFactory;

ConnectionFactory cf = new ActiveMQConnectionFactory("tcp://localhost:61616");
PooledConnectionFactory pcf = new PooledConnectionFactory();

//Set expiry timeout because the default (0) prevents reconnection on failure
pcf.setExpiryTimeout(5000);
pcf.setConnectionFactory(cf);

JMSConfiguration jmsConfig = new JMSConfiguration();

jmsConfig.setConnectionFactory(pdf);

풀링에 대한 자세한 내용은 Red Hat JBoss Fuse 트랜잭션 가이드의 "Appendix A Optimizing Performance of JMS Single- and Multiple-Resource Transactions"를 참조하십시오.

14.3.3. 동기 수신 방지

요청/복합의 경우 JMS 전송에서 요청을 보낸 다음 응답을 기다립니다. 가능한 경우 요청/응답 메시징은 JMS MessageListener 를 사용하여 비동기적으로 구현됩니다.

그러나 엔드포인트 간에 큐를 공유해야 하는 경우 CXF는 동기 소비자.receive() 메서드를 사용해야 합니다. 이 시나리오에서는 메시지 선택기를 사용하여 메시지를 필터링하기 위해 MessageListener 가 필요합니다. 메시지 선택기를 사전에 알고 있어야 하므로 MessageListener 는 한 번만 열립니다.

메시지 선택기를 사전에 알 수 없는 두 가지 경우는 피해야 합니다.

  • JMSMessageIDJMSCorrelationID로 사용되는 경우

    JMS 속성이 ConduitIdSelector 및 conduitSelectorPrefix 를 사용하는 경우 클라이언트는 JMSCorrelationId 를 설정하지 않습니다. 이로 인해 서버에서 요청 메시지의 JMSMessageIdJMSCorrelationId 로 사용합니다. JMSMessageID 를 사전에 알 수 없기 때문에 클라이언트는 synchronous Consumer.receive() 메서드를 사용해야 합니다.

    IBM JMS 엔드포인트(기본값 )에서 consumers.receive() 메서드를 사용해야 합니다.

  • 사용자는 요청 메시지에 JMStype 을 설정한 다음 사용자 지정 JMSCorrelationID 를 설정합니다.

    사용자 지정 JMSCorrelationID 를 사전에 알 수 없기 때문에 클라이언트는 동기 소비자.receive() 메서드를 사용해야 합니다.

따라서 일반적인 규칙은 동기 수신을 사용해야 하는 설정을 사용하지 않는 것입니다.

14.4. JMS 트랜잭션 구성

14.4.1. 개요

CXF 3.0은 단방향 메시징을 사용할 때 CXF 끝점에서 로컬 JMS 트랜잭션과 JTA 트랜잭션을 모두 지원합니다.

14.4.2. 로컬 트랜잭션

로컬 리소스를 사용하는 트랜잭션은 예외가 발생하는 경우에만 JMS 메시지를 롤백합니다. 데이터베이스 트랜잭션과 같은 다른 리소스를 직접 조정하지 않습니다.

로컬 트랜잭션을 설정하려면 일반적으로 끝점을 구성하고 속성 sessionTrasnsactedtrue 로 설정합니다.

참고

트랜잭션 및 풀링에 대한 자세한 내용은 Red Hat JBoss Fuse 트랜잭션 가이드를 참조하십시오.

14.4.3. JTA 트랜잭션

JTA 트랜잭션을 사용하면 모든 XA 리소스를 조정할 수 있습니다. CXF 끝점이 JTA 트랜잭션용으로 구성된 경우 서비스 구현을 호출하기 전에 트랜잭션을 시작합니다. 예외가 발생하지 않으면 트랜잭션이 커밋됩니다. 그렇지 않으면 롤백됩니다.

JTA 트랜잭션에서는 JMS 메시지가 사용되고 데이터베이스에 기록된 데이터를 사용합니다. 예외가 발생하면 두 리소스가 모두 롤백되므로 메시지가 소비되고 데이터가 데이터베이스에 기록되거나 메시지가 롤백되고 데이터가 데이터베이스에 기록되지 않습니다.

JTA 트랜잭션을 구성하려면 다음 두 단계가 필요합니다.

  1. 트랜잭션 관리자 정의

    • 빈 메서드

      • 트랜잭션 관리자 정의

        <bean id="transactionManager"
           class="org.apache.geronimo.transaction.manager.GeronimoTransactionManager"/>
      • JMS URI에서 트랜잭션 관리자의 이름을 설정합니다.

        jms:queue:myqueue?jndiTransactionManager=TransactionManager

        이 예에서는 ID TransactionManager 가 있는 빈을 찾습니다.

    • OSGi 참조 방법

      • Blueprint를 사용하여 OSGi 서비스로 트랜잭션 관리자를 조회합니다.

        <reference id="TransactionManager" interface="javax.transaction.TransactionManager"/>
      • JMS URI에서 트랜잭션 관리자의 이름을 설정합니다.

        jms:jndi:myqueue?jndiTransactionManager=java:comp/env/TransactionManager

        이 예에서는 JNDI에서 트랜잭션 관리자를 조회합니다.

  2. JCA 풀링 연결 팩토리 구성

    Spring을 사용하여 JCA 풀링 연결 팩토리를 정의합니다.

    <bean id="xacf" class="org.apache.activemq.ActiveMQXAConnectionFactory">
      <property name="brokerURL" value="tcp://localhost:61616" />
    </bean>
    
    <bean id="ConnectionFactory" class="org.apache.activemq.jms.pool.JcaPooledConnectionFactory">
      <property name="transactionManager" ref="transactionManager" />
      <property name="connectionFactory" ref="xacf" />
    </bean>

    이 예에서 첫 번째 빈은 JcaPooledConnectionFactory 에 제공되는 ActiveMQ XA 연결 팩토리를 정의합니다. 그런 다음 JcaPooledConnectionFactory 가 id ConnectionFactory 와 기본 빈으로 제공됩니다.

    JcaPooledConnectionFactory 는 일반 ConnectionFactory처럼 보입니다. 그러나 새 연결 및 세션이 열리면 XA 트랜잭션을 확인하고 있는 경우 JMS 세션을 XA 리소스로 자동으로 등록합니다. 이를 통해 JMS 세션이 JMS 트랜잭션에 참여할 수 있습니다.

    중요

    JMS 전송에서 XA ConnectionFactory를 직접 설정하는 것은 작동하지 않습니다!

14.5. WSDL을 사용하여 JMS 구성

14.5.1. JMSWS Extension Namespance

JMS 엔드포인트를 정의하는 WSDL 확장 기능은 네임스페이스 http://cxf.apache.org/transports/jms 에 정의되어 있습니다. JMS 확장을 사용하려면 예 14.5. “JMS WSDL 확장 네임스페이스” 에 표시된 줄을 계약의 정의 요소에 추가해야 합니다.

예 14.5. JMS WSDL 확장 네임스페이스

xmlns:jms="http://cxf.apache.org/transports/jms"

14.5.2. 기본 JMS 구성

14.5.2.1. 개요

JMS 주소 정보는 jms:address 요소 및 해당 하위인 jms:JMSNamingProperties 요소를 사용하여 제공됩니다. jms:address 요소의 속성은 JMS 브로커와 대상을 식별하는 데 필요한 정보를 지정합니다. jms:JMSNamingProperties 요소는 JNDI 서비스에 연결하는 데 사용되는 Java 속성을 지정합니다.

중요

JMS 기능을 사용하여 지정된 정보는 끝점의 WSDL 파일의 정보를 재정의합니다.

14.5.2.2. JMS 주소 지정

JMS 엔드포인트에 대한 기본 구성은 jms:address 요소를 서비스 포트 요소의 자식으로 사용하여 수행됩니다. WSDL에 사용된 jms:address 요소는 구성 파일에서 사용된 것과 동일합니다. 해당 속성은 표 14.2. “JMS 끝점 속성” 에 나열됩니다.

표 14.2. JMS 끝점 속성
속성설명

destinationStyle

JMS 대상이 JMS 대기열 또는 JMS 주제인지 여부를 지정합니다.

jndiConnectionFactoryName

JMS 대상에 연결할 때 사용할 JMS 연결 팩토리에 바인딩된 JNDI 이름을 지정합니다.

jmsDestinationName

전송되는 JMS 대상의 JMS 이름을 지정합니다.

jmsReplyDestinationName

응답이 전송되는 JMS 대상의 JMS 이름을 지정합니다. 이 특성을 사용하면 응답에 대해 사용자 정의 대상을 사용할 수 있습니다. 자세한 내용은 14.6절. “이름이 지정된 Reply Destination 사용” 에서 참조하십시오.

jndiDestinationName

전송되는 JMS 대상에 바인딩된 JNDI 이름을 지정합니다.

jndiReplyDestinationName

응답이 전송되는 JMS 대상에 바인딩된 JNDI 이름을 지정합니다. 이 특성을 사용하면 응답에 대해 사용자 정의 대상을 사용할 수 있습니다. 자세한 내용은 14.6절. “이름이 지정된 Reply Destination 사용” 에서 참조하십시오.

connectionUserName

JMS 브로커에 연결할 때 사용할 사용자 이름을 지정합니다.

connectionPassword

JMS 브로커에 연결할 때 사용할 암호를 지정합니다.

jms:address WSDL 요소는 jms:JMSNamingProperties 하위 요소를 사용하여 JNDI 공급자에 연결하는 데 필요한 추가 정보를 지정합니다.

14.5.2.3. JNDI 속성 지정

JMS 및 JNDI 공급자와의 상호 운용성을 높이기 위해 jms:address 요소에는 JNDI 공급자에 연결할 때 사용되는 속성을 채우는 데 사용되는 값을 지정할 수 있는 하위 요소 jms:JMSNamingProperties 가 있습니다. jms:JMSNamingProperties 요소에는 namevalue 의 두 가지 속성이 있습니다. name 은 설정할 속성의 이름을 지정합니다. value 속성은 지정된 속성의 값을 지정합니다. JMS:JMSNamingProperties 요소는 공급자별 속성의 사양에도 사용할 수 있습니다.

다음은 설정할 수 있는 공통 JNDI 속성 목록입니다.

  1. java.naming.factory.initial
  2. java.naming.provider.url
  3. java.naming.factory.object
  4. java.naming.factory.state
  5. java.naming.factory.url.pkgs
  6. java.naming.dns.url
  7. java.naming.authoritative
  8. java.naming.batchsize
  9. java.naming.referral
  10. java.naming.security.protocol
  11. java.naming.security.authentication
  12. java.naming.security.principal
  13. java.naming.security.credentials
  14. java.naming.language
  15. java.naming.applet

이러한 속성에서 사용할 정보에 대한 자세한 내용은 JNDI 공급자의 설명서를 확인하고 Java API 참조 자료를 참조하십시오.

14.5.2.4. 예제

예 14.6. “JMS WSDL 포트 사양” 는 JMS WSDL 포트 사양의 예를 보여줍니다.

예 14.6. JMS WSDL 포트 사양

<service name="JMSService">
  <port binding="tns:Greeter_SOAPBinding" name="SoapPort">
    <jms:address jndiConnectionFactoryName="ConnectionFactory"
                 jndiDestinationName="dynamicQueues/test.Celtix.jmstransport" >
      <jms:JMSNamingProperty name="java.naming.factory.initial"
                             value="org.activemq.jndi.ActiveMQInitialContextFactory" />
      <jms:JMSNamingProperty name="java.naming.provider.url"
                             value="tcp://localhost:61616" />
    </jms:address>
  </port>
</service>

14.5.3. JMS 클라이언트 구성

14.5.3.1. 개요

JMS 소비자 엔드포인트는 사용하는 메시지 유형을 지정합니다. JMS 소비자 끝점은 JMS ByteMessage 또는 JMS TextMessage 를 사용할 수 있습니다.

ByteMessage 를 사용할 때 소비자 엔드포인트는 JMS 메시지 본문에 데이터를 저장하고 데이터를 검색하는 방법으로 byte[] 를 사용합니다. 메시지가 전송될 때, 포맷된 정보를 포함하는 메시지 데이터는 바이트[] 로 패키지되고, 그 메시지가 전선에 배치되기 전에 메시지 본문에 배치된다. 메시지가 수신되면 소비자 끝점은 바이트[] 에 패키징된 것처럼 메시지 본문에 저장된 데이터를 매끄럽게 표시하려고 합니다.

TextMessage 를 사용하는 경우 소비자 엔드포인트는 메시지 본문에서 데이터를 저장하고 검색하는 방법으로 문자열을 사용합니다. 메시지가 전송되면 모든 형식별 정보를 포함하는 메시지 정보가 문자열로 변환되어 JMS 메시지 본문에 배치됩니다. 메시지가 수신되면 소비자 끝점은 JMS 메시지 본문에 저장된 데이터를 문자열로 패딩하려고 합니다.

네이티브 JMS 애플리케이션이 Apache CXF 소비자와 상호 작용할 때 JMS 애플리케이션은 메시지 및 형식 정보를 해석해야 합니다. 예를 들어 Apache CXF 계약이 JMS 끝점에 사용되는 바인딩이 SOAP임을 지정하고 메시지가 TextMessage 로 패키징된 경우 수신 JMS 애플리케이션은 모든 SOAP 봉투 정보가 포함된 텍스트 메시지를 받습니다.

14.5.3.2. 메시지 유형 지정

JMS 소비자 끝점에서 허용하는 메시지 유형은 선택적 jms:client 요소를 사용하여 구성됩니다. jms:client 요소는 WSDL 포트 요소의 자식이며 하나의 특성을 갖습니다.

표 14.3. JMS Client WSDL Extensions

messageType

메시지 데이터를 JMS 메시지로 패키징하는 방법을 지정합니다. text 는 데이터가 TextMessage 로 패키징되도록 지정합니다. 바이너리 는 데이터가 ByteMessage 로 패키징되도록 지정합니다.

14.5.3.3. 예제

예 14.7. “JMS 소비자 엔드 포인트의 WSDL” 는 JMS 소비자 엔드 포인트를 구성하기 위한 WSDL을 보여줍니다.

예 14.7. JMS 소비자 엔드 포인트의 WSDL

<service name="JMSService">
  <port binding="tns:Greeter_SOAPBinding" name="SoapPort">
    <jms:address jndiConnectionFactoryName="ConnectionFactory"
                 jndiDestinationName="dynamicQueues/test.Celtix.jmstransport" >
      <jms:JMSNamingProperty name="java.naming.factory.initial"
                             value="org.activemq.jndi.ActiveMQInitialContextFactory" />
      <jms:JMSNamingProperty name="java.naming.provider.url"
                             value="tcp://localhost:61616" />
    </jms:address>
    <jms:client messageType="binary" />
  </port>
</service>

14.5.4. JMS 공급자 구성

14.5.4.1. 개요

JMS 공급자 끝점에는 구성 가능한 여러 동작이 있습니다. 여기에는 다음이 포함됩니다.

  • 메시지가 상호 작용하는 방법
  • 내구성 서브스크립션 사용
  • 서비스가 로컬 JMS 트랜잭션을 사용하는 경우
  • 끝점에서 사용하는 메시지 선택기

14.5.4.2. 설정 지정

공급자 끝점 동작은 선택적 jms:server 요소를 사용하여 구성됩니다. jms:server 요소는 WSDL wsdl:port 요소의 하위이며 다음 속성이 있습니다.

표 14.4. JMS 공급자 끝점 WSDL 확장
속성설명

useMessageIDAsCorrealationID

JMS에서 메시지 ID를 사용하여 메시지의 상관 관계를 유지할지 여부를 지정합니다. 기본값은 false입니다.

durableSubscriberName

내구성 서브스크립션을 등록하는 데 사용되는 이름을 지정합니다.

messageSelector

사용할 메시지 선택기의 문자열 값을 지정합니다. 메시지 선택기를 지정하는 데 사용되는 구문에 대한 자세한 내용은 JMS 1.1 사양을 참조하십시오.

transactional

로컬 JMS 브로커가 메시지 처리와 관련된 트랜잭션을 생성할지 여부를 지정합니다. 기본값은 false입니다.[a]

[a] 현재 트랜잭션 특성을 true 로 설정하는 것은 런타임에서 지원되지 않습니다.

14.5.4.3. 예제

예 14.8. “JMS 공급자 끝점의 WSDL” 는 JMS 공급자 끝점 구성을 위한 WSDL을 보여줍니다.

예 14.8. JMS 공급자 끝점의 WSDL

<service name="JMSService">
  <port binding="tns:Greeter_SOAPBinding" name="SoapPort">
    <jms:address jndiConnectionFactoryName="ConnectionFactory"
                 jndiDestinationName="dynamicQueues/test.Celtix.jmstransport" >
      <jms:JMSNamingProperty name="java.naming.factory.initial"
                             value="org.activemq.jndi.ActiveMQInitialContextFactory" />
      <jms:JMSNamingProperty name="java.naming.provider.url"
                             value="tcp://localhost:61616" />
    </jms:address>
    <jms:server messageSelector="cxf_message_selector"
                useMessageIDAsCorrelationID="true"
                transactional="true"
                durableSubscriberName="cxf_subscriber" />
  </port>
</service>

14.6. 이름이 지정된 Reply Destination 사용

14.6.1. 개요

기본적으로 JMS를 사용하는 Apache CXF 엔드포인트는 응답을 백으로 전송하기 위한 임시 대기열을 생성합니다. 명명된 대기열을 사용하려면 엔드포인트의 JMS 구성의 일부로 응답을 보내는 데 사용되는 큐를 구성할 수 있습니다.

14.6.2. 응답 대상 이름 설정

끝점의 JMS 구성에서 jmsReplyDestinationName 속성 또는 jndiReplyDestinationName 속성을 사용하여 응답 대상을 지정합니다. 클라이언트 끝점은 지정된 대상에 대한 응답을 수신 대기하며 나가는 모든 요청의 ReplyTo 필드에 속성 값을 지정합니다. 서비스 끝점은 요청의 ReplyTo 필드에 지정된 대상이 없는 경우 응답 배치 위치로 jndiReplyDestinationName 속성 값을 사용합니다.

14.6.3. 예제

예 14.9. “명명된 응답 대기열을 사용하여 JMS 소비자 사양” 는 JMS 클라이언트 끝점의 구성을 표시합니다.

예 14.9. 명명된 응답 대기열을 사용하여 JMS 소비자 사양

<jms:conduit name="{http://cxf.apache.org/jms_endpt}HelloWorldJMSPort.jms-conduit">
    <jms:address destinationStyle="queue"
                 jndiConnectionFactoryName="myConnectionFactory"
                 jndiDestinationName="myDestination"
                 jndiReplyDestinationName="myReplyDestination" >
      <jms:JMSNamingProperty name="java.naming.factory.initial"
                             value="org.apache.cxf.transport.jms.MyInitialContextFactory" />
      <jms:JMSNamingProperty name="java.naming.provider.url"
                             value="tcp://localhost:61616" />
    </jms:address>
  </jms:conduit>

15장. Apache ActiveMQ와 통합

15.1. 개요

Apache ActiveMQ를 JMS 공급자로 사용하는 경우 대상의 JNDI 이름을 큐 또는 토픽에 대해 동적으로 JNDI 바인딩을 생성하는 특수 형식으로 지정할 수 있습니다. 즉, 대기열 또는 토픽에 대한 JNDI 바인딩을 사용하여 JMS 공급자를 미리 구성할 필요가 없습니다.

15.2. 초기 컨텍스트 팩토리

Apache ActiveMQ를 JNDI와 통합하는 핵심은 ActiveMQInitialContextFactory 클래스입니다. 이 클래스는 JNDI InitialContext 인스턴스를 생성하는 데 사용되며 JMS 브로커의 JMS 대상에 액세스할 수 있습니다.

예 15.1. “Apache ActiveMQ에 연결하는 SOAP/JMS WSDL” 는 Apache ActiveMQ와 통합된 JNDI InitialContext 를 생성하는 SOAP/JMS WSDL 확장 기능을 보여줍니다.

예 15.1. Apache ActiveMQ에 연결하는 SOAP/JMS WSDL

<soapjms:jndiInitialContextFactory>
  org.apache.activemq.jndi.ActiveMQInitialContextFactory
</soapjms:jndiInitialContextFactory>
<soapjms:jndiURL>tcp://localhost:61616</soapjms:jndiURL>

예 15.1. “Apache ActiveMQ에 연결하는 SOAP/JMS WSDL” 에서 Apache ActiveMQ 클라이언트는 tcp://localhost:61616 에 있는 브로커 포트에 연결합니다.

15.3. 연결 팩토리 검색

JNDI InitialContext 인스턴스를 생성하고 javax.jms.ConnectionFactory 인스턴스에 바인딩된 JNDI 이름을 지정해야 합니다. Apache ActiveMQ의 경우 JNDI 이름 ConnectionFactoryActiveMQConnectionFactory 인스턴스에 매핑하는 InitialContext 인스턴스에 사전 정의된 바인딩이 있습니다. 예 15.2. “Apache ActiveMQ 연결 팩토리 지정을 위한 SOAP/JMS WSDL” Apache ActiveMQ 연결 팩토리를 지정하기 위한 SOAP/JMS 확장 요소.

예 15.2. Apache ActiveMQ 연결 팩토리 지정을 위한 SOAP/JMS WSDL

<soapjms:jndiConnectionFactoryName>
  ConnectionFactory
</soapjms:jndiConnectionFactoryName>

15.4. 동적 대상의 구문

대기열 또는 토픽에 동적으로 액세스하려면 대상의 JNDI 이름을 다음 형식 중 하나로 JNDI 복합 이름으로 지정합니다.

dynamicQueues/QueueName
dynamicTopics/TopicName

QueueNameTopicName 은 Apache ActiveMQ 브로커가 사용하는 이름입니다. JNDI 이름은 추상화 되지 않습니다.

예 15.3. “동적으로 생성된 큐를 사용한 WSDL 포트 사양” 동적으로 생성된 큐를 사용하는 WSDL 포트를 표시합니다.

예 15.3. 동적으로 생성된 큐를 사용한 WSDL 포트 사양

<service name="JMSService">
  <port binding="tns:GreeterBinding" name="JMSPort">
    <jms:address jndiConnectionFactoryName="ConnectionFactory"
                 jndiDestinationName="dynamicQueues/greeter.request.queue" >
      <jms:JMSNamingProperty name="java.naming.factory.initial"
                             value="org.activemq.jndi.ActiveMQInitialContextFactory" />
      <jms:JMSNamingProperty name="java.naming.provider.url"
                             value="tcp://localhost:61616" />
    </jms:address>
  </port>
</service>

애플리케이션이 JMS 연결을 열려고 하면 Apache ActiveMQ는 JNDI 이름 greeter.request.queue 가 있는지 확인합니다. 존재하지 않는 경우 새 큐를 생성하고 JNDI 이름 greeter.request.queue 에 바인딩합니다.

16장. 구성 요소

초록

conduits는 아웃바운드 연결을 구현하는 데 사용되는 낮은 수준의 전송 아키텍처입니다. 해당 동작 및 라이프사이클은 시스템 성능 및 처리 로드에 영향을 미칠 수 있습니다.

16.1. 개요

Conduits는 Apache CXF 런타임의 클라이언트 측 또는 아웃바운드 정보를 관리합니다. 포트 열기, 아웃바운드 연결 설정, 메시지 전송, 애플리케이션 및 단일 외부 끝점 간의 모든 응답을 수신 대기해야 합니다. 애플리케이션이 여러 끝점에 연결하는 경우 각 끝점에 대해 하나의 구성 인스턴스가 있습니다.

각 전송 유형은 Conduit 인터페이스를 사용하여 자체 conduit을 구현합니다. 이를 통해 애플리케이션 수준 기능과 전송 간의 표준화된 인터페이스가 가능합니다.

일반적으로 클라이언트 측 전송 세부 정보를 구성할 때 애플리케이션에서 사용 중인 문제에 대해 우려할 필요가 있습니다. 런타임에서 유추를 처리하는 방식의 근본적인 의미는 일반적으로 개발자가 걱정해야 하는 것이 아닙니다.

그러나 영영을 이해하는 것이 도움이 될 수있는 경우가 있습니다.

  • 사용자 정의 전송 구현
  • 제한된 리소스 관리를 위한 고급 애플리케이션 튜닝

16.2. Conduit 라이프 사이클

Conduits는 클라이언트 구현 개체에 의해 관리됩니다. 만든 후 클라이언트 구현 개체의 기간 동안 제한이 있습니다.Once created, a conduit lives for the duration of the client implementation object. 클러스터의 라이프 사이클은 다음과 같습니다.

  1. 클라이언트 구현 개체가 생성되면 ConduitSelector 오브젝트에 대한 참조가 제공됩니다.
  2. 클라이언트가 메시지를 전송해야 하는 경우, 요청의 요청자(Conduit selector)의 구성 요소에 대한 참조입니다.

    메시지가 새 끝점에 대한 경우 구성 선택기는 새 conduit을 생성하여 클라이언트 구현에 전달합니다. 그렇지 않으면 대상 끝점에 대한 참조를 클라이언트에 전달합니다.

  3. 필요한 경우 구성 요소는 메시지를 보냅니다.
  4. 클라이언트 구현 개체를 삭제하면 연결된 모든 구성 요소가 삭제됩니다.

16.3. 유도 가중치

conduit 오브젝트의 가중치는 전송 구현에 따라 다릅니다. HTTP 고무는 매우 가벼운 무게입니다. JMS는 JMS Session 오브젝트 및 하나 이상의 JMSListenerContainer 오브젝트와 연관되므로 많은 경우가 많습니다.

IV 부. 웹 서비스 엔드 포인트 구성

이 가이드에서는 Red Hat Fuse에서 Apache CXF 엔드포인트를 생성하는 방법을 설명합니다.

17장. JAX-WS 엔드포인트 구성

초록

JAX-WS 엔드포인트는 3개의 Spring 구성 요소 중 하나를 사용하여 구성됩니다. 올바른 요소는 구성할 끝점 유형 및 사용하려는 기능에 따라 달라집니다. 소비자의 경우 jaxws:client 요소를 사용합니다. 서비스 공급자의 경우 jaxws:endpoint 요소 또는 jaxws:server 요소를 사용할 수 있습니다.

끝점을 정의하는 데 사용되는 정보는 일반적으로 끝점의 계약에 정의되어 있습니다. 구성 요소의 를 사용하여 계약의 정보를 재정의할 수 있습니다. 구성 요소를 사용하여 계약에 제공되지 않는 정보를 제공할 수도 있습니다.

구성 요소를 사용하여 WS-RM과 같은 고급 기능을 활성화해야 합니다. 이 작업은 하위 요소를 엔드포인트의 구성 요소에 제공하여 수행됩니다. Java 우선 접근 방식을 사용하여 끝점을 사용하여 개발된 경우 끝점 계약 역할을 하는 SEI에 사용할 바인딩 및 전송 유형에 대한 정보가 부족할 수 있습니다.

17.1. 서비스 공급자 구성

17.1.1. 서비스 공급자 구성을 위한 요소

Apache CXF에는 서비스 공급자를 구성하는 데 사용할 수 있는 두 가지 요소가 있습니다.

두 요소 간의 차이점은 대부분 런타임 내부에 있습니다. jaxws:endpoint 요소는 서비스 끝점을 지원하기 위해 생성된 org.apache.cxf.jaxws.EndpointImpl 오브젝트에 속성을 주입합니다. jaxws:server 요소는 끝점을 지원하기 위해 생성된 org.apache.cxf.jaxws.support.JaxWsServerFactoryBean 오브젝트에 속성을 삽입합니다. EndpointImpl 오브젝트는 구성 데이터를 JaxWsServerFactoryBean 오브젝트에 전달합니다. JaxWsServerFactoryBean 오브젝트는 실제 서비스 오브젝트를 생성하는 데 사용됩니다. 두 구성 요소는 서비스 끝점을 구성하기 때문에 원하는 구문에 따라 선택할 수 있습니다.

17.1.2. jaxws:endpoint Element 사용

17.1.2.1. 개요

jaxws:endpoint 요소는 JAX-WS 서비스 공급자를 구성하기 위한 기본 요소입니다. 특성 및 자식은 서비스 공급자를 인스턴스화하는 데 필요한 모든 정보를 지정합니다. 많은 속성은 서비스 계약의 정보에 매핑됩니다. 하위 항목은 인터셉터 및 기타 고급 기능을 구성하는 데 사용됩니다.

17.1.2.2. 구성되는 끝점 식별

런타임에서 적절한 서비스 공급자에 구성을 적용하려면 해당 구성을 식별할 수 있어야 합니다. 서비스 공급자를 식별하는 기본 방법은 끝점을 구현하는 클래스를 지정하는 것입니다. 이 작업은 jaxws:endpoint 요소의 구현자를 사용하여 수행됩니다.

서로 다른 엔드포인트가 공통 구현을 공유하는 인스턴스의 경우 각 엔드포인트에 대해 서로 다른 구성을 제공할 수 있습니다. 구성에서 특정 끝점을 구분하는 방법은 다음 두 가지입니다.

  • serviceName 속성 및 endpointName 속성의 조합

    serviceName 속성은 서비스의 엔드포인트를 정의하는 wsdl:service 요소를 지정합니다. endpointName 속성은 서비스의 엔드포인트를 정의하는 특정 wsdl:port 요소를 지정합니다. 두 속성 모두 ns:name 형식을 사용하여 QNames로 지정됩니다. NS 는 요소의 네임스페이스이고 name 은 요소의 name 특성 값입니다.

    참고

    wsdl:service 요소에 하나의 wsdl:port 요소만 있는 경우 endpointName 속성을 생략할 수 있습니다.

  • name 속성

    name 속성은 서비스의 엔드포인트를 정의하는 특정 wsdl:port 요소의 QName을 지정합니다. QName은 {ns}localPart 형식으로 제공됩니다. NSwsdl:port 요소의 네임스페이스이고 localPartwsdl:port 요소의 name 속성 값입니다.

17.1.2.3. 속성

jaxws:endpoint 요소의 속성은 끝점의 기본 속성을 구성합니다. 이러한 속성에는 끝점 주소, 엔드포인트를 구현하는 클래스 및 엔드포인트를 호스팅하는 버스 가 포함됩니다.

표 17.1. “jaxws:endpoint Element를 사용하여 JAX-WS 서비스 공급자 구성 특성” jaxws:endpoint 요소의 속성을 설명합니다.

표 17.1. jaxws:endpoint Element를 사용하여 JAX-WS 서비스 공급자 구성 특성
속성설명

id

다른 구성 요소에서 끝점을 참조하는 데 사용할 수 있는 고유 식별자를 지정합니다.Specifies a unique identifier that other configuration elements can use to refer to the endpoint.

구현자

서비스를 구현하는 클래스를 지정합니다. 구현 클래스를 구성하는 Spring 빈에 대한 클래스 이름 또는 ID 참조를 사용하여 구현 클래스를 지정할 수 있습니다. 이 클래스는 classpath에 있어야 합니다.

implementorClass

서비스를 구현하는 클래스를 지정합니다. 이 속성은 구현 자 속성에 제공된 값이 Spring AOP를 사용하여 래핑된 빈에 대한 참조인 경우에 유용합니다.

주소

HTTP 끝점의 주소를 지정합니다. 이 값은 서비스 계약에 지정된 값을 재정의합니다.

wsdlLocation

끝점의 WSDL 계약의 위치를 지정합니다. WSDL 계약의 위치는 서비스가 배포되는 폴더를 기준으로 합니다.

endpointName

서비스의 wsdl:port 요소의 name 특성 값을 지정합니다. ns:name 형식을 사용하여 QName으로 지정됩니다. 여기서 nswsdl:port 요소의 네임스페이스입니다.

serviceName

서비스의 wsdl:service 요소의 name 특성 값을 지정합니다. ns:name 형식을 사용하여 QName으로 지정됩니다. 여기서 nswsdl:service 요소의 네임스페이스입니다.

publish

서비스가 자동으로 게시되어야 하는지 여부를 지정합니다. 이 값이 false 로 설정되면 개발자는 31장. 서비스 게시 에 설명된 엔드포인트를 명시적으로 게시해야 합니다.

bus

서비스 엔드포인트를 관리하는 데 사용되는 버스를 구성하는 Spring 빈의 ID를 지정합니다. 이 기능은 공통 기능 세트를 사용하도록 여러 끝점을 구성할 때 유용합니다.

bindingUri

서비스에서 사용하는 메시지 바인딩의 ID를 지정합니다. 유효한 바인딩 ID 목록은 23장. Apache CXF 바인딩 ID 에서 제공됩니다.

name

서비스의 wsdl:port 요소의 stringified QName을 지정합니다. {ns}localPart 형식을 사용하여 QName으로 지정됩니다. NSwsdl:port 요소의 네임스페이스이고 localPartwsdl:port 요소의 name 속성 값입니다.

abstract

빈이 추상 빈인지 여부를 지정합니다. 추상화 빈은 구체적인 빈 정의를 위해 부모 역할을 하며 인스턴스화되지 않습니다. 기본값은 false입니다. 이 값을 true 로 설정하면 빈 공장이 빈을 인스턴스화하지 않도록 지시합니다.

depends-on

끝점이 인스턴스화되기 전에 종속되는 빈 목록을 지정합니다.

createdFromAPI

Endpoint.publish() 또는 Service.getPort() 와 같은 Apache CXF API를 사용하여 빈을 만들도록 지정합니다.

기본값은 false입니다.

이 값을 true 로 설정하면 다음이 수행됩니다.

  • ID에 .jaxws-endpoint 를 추가하여 빈의 내부 이름을 변경합니다.
  • 빈을 추상적으로 만듭니다.

publishedEndpointUrl

생성된 WSDL의 address 요소에 배치된 URL입니다. 이 값을 지정하지 않으면 address 특성 값이 사용됩니다. 이 속성은 "public" URL이 서비스가 배포된 URL과 같지 않은 경우 유용합니다.

표 17.1. “jaxws:endpoint Element를 사용하여 JAX-WS 서비스 공급자 구성 특성” 에 나열된 속성 외에도 여러 xmlns:shortName속성을 사용하여 endpointNameserviceName 속성에 사용되는 네임스페이스를 선언해야 할 수 있습니다.

17.1.2.4. 예제

예 17.1. “Simple JAX-WS Endpoint 구성” 엔드포인트가 게시되는 주소를 지정하는 JAX-WS 끝점의 구성을 보여줍니다. 이 예제에서는 다른 모든 값에 기본값을 사용하거나 구현에서 주석에 값을 지정했다고 가정합니다.

예 17.1. Simple JAX-WS Endpoint 구성

<beans ...
  xmlns:jaxws="http://cxf.apache.org/jaxws"
  ...
  schemaLocation="...
    http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
    ...">
  <jaxws:endpoint id="example"
                  implementor="org.apache.cxf.example.DemoImpl"
                  address="http://localhost:8080/demo" />
</beans>

예 17.2. “서비스 이름을 사용한 JAX-WS Endpoint 구성” 계약에 두 개의 서비스 정의가 포함된 JAX-WS 엔드포인트의 구성을 보여줍니다. 이 경우 serviceName 특성을 사용하여 인스턴스화할 서비스 정의를 지정해야 합니다.

예 17.2. 서비스 이름을 사용한 JAX-WS Endpoint 구성

<beans ...
  xmlns:jaxws="http://cxf.apache.org/jaxws"
  ...
  schemaLocation="...
    http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
    ...">

  <jaxws:endpoint id="example2"
                  implementor="org.apache.cxf.example.DemoImpl"
                  serviceName="samp:demoService2"
                  xmlns:samp="http://org.apache.cxf/wsdl/example" />

</beans>

xmlns:samp 속성은 WSDL 서비스 요소가 정의된 네임스페이스를 지정합니다.

예 17.3. “HTTP/2가 활성화된 JAX-WS Endpoint Configuration” HTTP/2가 활성화된 주소를 지정하는 JAX-WS 끝점의 구성을 보여줍니다.

Apache CXF의 HTTP/2 구성

Apache Karaf에서 독립 실행형 Apache CXF Undertow 전송(http-undertow)을 사용하는 경우 HTTP/2가 지원됩니다. HTTP/2 프로토콜을 활성화하려면 jaxws:endpoint 요소의 address 속성을 절대 URL로 설정하고 org.apache.cxf.transports.http_undertow.EnableHttp2 속성을 true 로 설정해야 합니다.

참고

이 HTTP/2 구현은 일반 HTTP 또는 HTTPS와 함께 서버 측 HTTP/2 전송만 지원합니다.

예 17.3. HTTP/2가 활성화된 JAX-WS Endpoint Configuration

<beans ...
  xmlns:jaxws="http://cxf.apache.org/jaxws"
  ...
  schemaLocation="...
  http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
  ...">

  <cxf:bus>
    <cxf:properties>
        <entry key="org.apache.cxf.transports.http_undertow.EnableHttp2" value="true"/>
    </cxf:properties>
  </cxf:bus>

  <jaxws:endpoint id="example3"
                implementor="org.apache.cxf.example.DemoImpl"
                address="http://localhost:8080/demo" />
  </jaxws:endpoint>

</beans>
참고

성능 향상을 위해 Red Hat은 Apache Karaf(pax-web-undertow)의 서블릿 전송을 사용하여 웹 컨테이너의 중앙 집중식 구성 및 튜닝을 지원하지만 pax-web-undertow 는 HTTP/2 전송 프로토콜을 지원하지 않습니다.

17.1.3. jaxws:server 요소 사용

17.1.3.1. 개요

jaxws:server 요소는 JAX-WS 서비스 공급자를 구성하기 위한 요소입니다. 구성 정보를 org.apache.cxf.jaxws.support.JaxWsServerFactoryBean 에 삽입합니다. Apache CXF 특정 오브젝트입니다. 서비스를 구축하기 위해 순수 Spring 접근법을 사용하는 경우 Apache CXF 특정 API를 사용하여 서비스와 상호 작용할 필요가 없습니다.

jaxws:server 요소의 속성과 하위 요소는 서비스 공급자를 인스턴스화하는 데 필요한 모든 정보를 지정합니다. 속성은 엔드포인트를 인스턴스화하는 데 필요한 정보를 지정합니다. 하위 항목은 인터셉터 및 기타 고급 기능을 구성하는 데 사용됩니다.

17.1.3.2. 구성되는 끝점 식별

런타임에서 적절한 서비스 공급자에 구성을 적용하려면 해당 구성을 식별할 수 있어야 합니다. 서비스 공급자를 식별하는 기본 방법은 끝점을 구현하는 클래스를 지정하는 것입니다. 이 작업은 jaxws:server 요소의 serviceBean 속성을 사용하여 수행됩니다.

서로 다른 엔드포인트가 공통 구현을 공유하는 인스턴스의 경우 각 엔드포인트에 대해 서로 다른 구성을 제공할 수 있습니다. 구성에서 특정 끝점을 구분하는 방법은 다음 두 가지입니다.

  • serviceName 속성 및 endpointName 속성의 조합

    serviceName 속성은 서비스의 엔드포인트를 정의하는 wsdl:service 요소를 지정합니다. endpointName 속성은 서비스의 엔드포인트를 정의하는 특정 wsdl:port 요소를 지정합니다. 두 속성 모두 ns:name 형식을 사용하여 QNames로 지정됩니다. NS 는 요소의 네임스페이스이고 name 은 요소의 name 특성 값입니다.

    참고

    wsdl:service 요소에 하나의 wsdl:port 요소만 있는 경우 endpointName 속성을 생략할 수 있습니다.

  • name 속성

    name 속성은 서비스의 엔드포인트를 정의하는 특정 wsdl:port 요소의 QName을 지정합니다. QName은 {ns}localPart 형식으로 제공됩니다. NSwsdl:port 요소의 네임스페이스이고 localPartwsdl:port 요소의 name 속성 값입니다.

17.1.3.3. 속성

jaxws:server 요소의 속성은 끝점의 기본 속성을 구성합니다. 이러한 속성에는 끝점 주소, 엔드포인트를 구현하는 클래스 및 엔드포인트를 호스팅하는 버스 가 포함됩니다.

표 17.2. “jaxws:server Element를 사용하여 JAX-WS 서비스 공급자 구성 특성” jaxws:server 요소의 속성을 설명합니다.

표 17.2. jaxws:server Element를 사용하여 JAX-WS 서비스 공급자 구성 특성
속성설명

id

다른 구성 요소에서 끝점을 참조하는 데 사용할 수 있는 고유 식별자를 지정합니다.Specifies a unique identifier that other configuration elements can use to refer to the endpoint.

serviceBean

서비스를 구현하는 클래스를 지정합니다. 구현 클래스를 구성하는 Spring 빈에 대한 클래스 이름 또는 ID 참조를 사용하여 구현 클래스를 지정할 수 있습니다. 이 클래스는 classpath에 있어야 합니다.

serviceClass

서비스를 구현하는 클래스를 지정합니다. 이 속성은 구현 자 속성에 제공된 값이 Spring AOP를 사용하여 래핑된 빈에 대한 참조인 경우에 유용합니다.

주소

HTTP 끝점의 주소를 지정합니다. 이 값은 서비스 계약에 지정된 값을 재정의합니다.

wsdlLocation

끝점의 WSDL 계약의 위치를 지정합니다. WSDL 계약의 위치는 서비스가 배포되는 폴더를 기준으로 합니다.

endpointName

서비스의 wsdl:port 요소의 name 특성 값을 지정합니다. ns:name 형식을 사용하여 QName으로 지정됩니다. 여기서 nswsdl:port 요소의 네임스페이스입니다.

serviceName

서비스의 wsdl:service 요소의 name 특성 값을 지정합니다. ns:name 형식을 사용하여 QName으로 지정됩니다. 여기서 nswsdl:service 요소의 네임스페이스입니다.

publish

서비스가 자동으로 게시되어야 하는지 여부를 지정합니다. 이 값이 false 로 설정되면 개발자는 31장. 서비스 게시 에 설명된 엔드포인트를 명시적으로 게시해야 합니다.

bus

서비스 엔드포인트를 관리하는 데 사용되는 버스를 구성하는 Spring 빈의 ID를 지정합니다. 이 기능은 공통 기능 세트를 사용하도록 여러 끝점을 구성할 때 유용합니다.

bindingId

서비스에서 사용하는 메시지 바인딩의 ID를 지정합니다. 유효한 바인딩 ID 목록은 23장. Apache CXF 바인딩 ID 에서 제공됩니다.

name

서비스의 wsdl:port 요소의 stringified QName을 지정합니다. {ns}localPart 형식을 사용하여 QName으로 지정됩니다. 여기서 nswsdl:port 요소의 네임스페이스이고 localPartwsdl:port 요소의 name 속성 값입니다.

abstract

빈이 추상 빈인지 여부를 지정합니다. 추상화 빈은 구체적인 빈 정의를 위해 부모 역할을 하며 인스턴스화되지 않습니다. 기본값은 false입니다. 이 값을 true 로 설정하면 빈 공장이 빈을 인스턴스화하지 않도록 지시합니다.

depends-on

끝점을 인스턴스화하기 전에 끝점이 인스턴스화되는 데 의존하는 빈 목록을 지정합니다.

createdFromAPI

Endpoint.publish() 또는 Service.getPort() 와 같은 Apache CXF API를 사용하여 빈을 만들도록 지정합니다.

기본값은 false입니다.

이 값을 true 로 설정하면 다음이 수행됩니다.

  • ID에 .jaxws-endpoint 를 추가하여 빈의 내부 이름을 변경합니다.
  • 빈을 추상적으로 만듭니다.

표 17.2. “jaxws:server Element를 사용하여 JAX-WS 서비스 공급자 구성 특성” 에 나열된 속성 외에도 여러 xmlns:shortName속성을 사용하여 endpointNameserviceName 속성에 사용되는 네임스페이스를 선언해야 할 수 있습니다.

17.1.3.4. 예제

예 17.4. “simple JAX-WS Server 구성” 엔드포인트가 게시되는 주소를 지정하는 JAX-WS 끝점의 구성을 보여줍니다.

예 17.4. simple JAX-WS Server 구성

<beans ...
  xmlns:jaxws="http://cxf.apache.org/jaxws"
  ...
  schemaLocation="...
    http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
    ...">
  <jaxws:server id="exampleServer"
                  serviceBean="org.apache.cxf.example.DemoImpl"
                  address="http://localhost:8080/demo" />
</beans>

17.1.4. 서비스 공급자에 기능 추가

17.1.4.1. 개요

jaxws:endpointjaxws:server 요소는 서비스 공급자를 인스턴스화하는 데 필요한 기본 구성 정보를 제공합니다. 서비스 공급자에 기능을 추가하거나 고급 구성을 수행하려면 구성에 하위 요소를 추가해야 합니다.

자식 요소를 사용하면 다음을 수행할 수 있습니다.

17.1.4.2. 요소

표 17.3. “JAX-WS 서비스 공급자 구성에 사용되는 요소” jaxws:endpoint 에서 지원하는 하위 요소에 대해 설명합니다.

표 17.3. JAX-WS 서비스 공급자 구성에 사용되는 요소
요소설명

jaxws:handlers

메시지 처리를 위한 JAX-WS Handler 구현 목록을 지정합니다. JAX-WS Handler 구현에 대한 자세한 내용은 43장. 핸들러 작성 을 참조하십시오.

jaxws:inInterceptors

인바운드 요청을 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxws:inFaultInterceptors

인바운드 오류 메시지를 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxws:outInterceptors

아웃바운드 응답을 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxws:outFaultInterceptors

아웃바운드 오류 메시지를 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxws:binding

끝점에서 사용하는 메시지 바인딩을 구성하는 빈을 지정합니다. 메시지 바인딩은 org.apache.cxf.binding.BindingFactory 인터페이스의 구현을 사용하여 구성됩니다.[a]

jaxws:dataBinding [b]

끝점에서 사용하는 데이터 바인딩을 구현하는 클래스를 지정합니다.Specifies the class implementing the data binding used by the endpoint. 이는 포함된 빈 정의를 사용하여 지정합니다.

jaxws:executor

서비스에 사용되는 Java executor를 지정합니다. 이는 포함된 빈 정의를 사용하여 지정합니다.

jaxws:features

Apache CXF의 고급 기능을 구성하는 빈 목록을 지정합니다. 빈 참조 목록 또는 포함된 빈 목록을 제공할 수 있습니다.

jaxws:invoker

서비스에서 사용하는 org.apache.cxf.service. invoker 인터페이스의 구현을 지정합니다.[c]

jaxws:properties

끝점에 전달되는 속성의 Spring 맵을 지정합니다. 이러한 속성은 MTOM 지원 활성화와 같은 기능을 제어하는 데 사용할 수 있습니다.

jaxws:serviceFactory

서비스를 인스턴스화하는 데 사용되는 JaxWsServiceFactoryBean 오브젝트를 구성하는 빈을 지정합니다.

[a] SOAP 바인딩은 soap:soapBinding 빈을 사용하여 구성됩니다.
[b] jaxws:endpoint 요소는 jaxws:dataBinding 요소를 지원하지 않습니다.
[c] invoker 구현은 서비스가 호출되는 방법을 제어합니다. 예를 들어 서비스 구현의 새 인스턴스에서 각 요청을 처리했는지 또는 상태가 호출 간에 보존되는지 여부를 제어합니다.

17.1.5. JAX-WS 끝점에서 스키마 유효성 검사 활성화

17.1.5.1. 개요

schema-validation-enabled 속성을 설정하여 jaxws:endpoint 요소 또는 jaxws:server 요소에서 스키마 유효성 검사를 활성화할 수 있습니다. 스키마 유효성 검사가 활성화되면 클라이언트와 서버 간에 전송된 메시지가 스키마 준수 여부를 확인합니다. 기본적으로 스키마 유효성 검사는 성능에 큰 영향을 미치기 때문에 해제됩니다.By default, schema validation is turned off, because it has a significant impact on performance.

17.1.5.2. 예제

JAX-WS 끝점에서 스키마 유효성 검사를 활성화하려면 jaxws:endpoint 요소 또는 jaxws:server 요소의 jaxws:properties 하위 요소에서 schema-validation-enabled 속성을 설정합니다. 예를 들어 jaxws:endpoint 요소에 스키마 검증을 활성화하려면 다음을 수행합니다.

<jaxws:endpoint name="{http://apache.org/hello_world_soap_http}SoapPort"
    wsdlLocation="wsdl/hello_world.wsdl"
    createdFromAPI="true">
    <jaxws:properties>
        <entry key="schema-validation-enabled" value="BOTH" />
    </jaxws:properties>
</jaxws:endpoint>

schema-validation-enabled 속성의 허용되는 값 목록은 24.3.4.7절. “스키마 유효성 검사 유형 값” 을 참조하십시오.

17.2. 소비자 엔드 포인트 구성

17.2.1. 개요

JAX-WS 소비자 엔드포인트는 jaxws:client 요소를 사용하여 구성됩니다. 요소의 특성은 소비자를 생성하는 데 필요한 기본 정보를 제공합니다.

WS-RM과 같은 다른 기능을 사용자에게 jaxws:client 요소에 자식을 추가합니다. 하위 요소는 또한 끝점의 로깅 동작을 구성하고 엔드포인트의 구현에 다른 속성을 삽입하는 데 사용됩니다.

17.2.2. 기본 설정 속성

표 17.4. “JAX-WS Consumer를 구성하는 데 사용되는 속성” 에 설명된 속성은 JAX-WS 소비자를 구성하는 데 필요한 기본 정보를 제공합니다. 구성하려는 특정 속성에 대한 값만 제공해야 합니다. 대부분의 속성은 합리적인 기본값이 있거나, 끝점의 계약에서 제공하는 정보에 의존합니다.

표 17.4. JAX-WS Consumer를 구성하는 데 사용되는 속성
속성설명

주소

소비자가 요청할 끝점의 HTTP 주소를 지정합니다. 이 값은 계약에 설정된 값을 재정의합니다.

bindingId

소비자가 사용하는 메시지 바인딩의 ID를 지정합니다. 유효한 바인딩 ID 목록은 23장. Apache CXF 바인딩 ID 에서 제공됩니다.

bus

엔드포인트를 관리하는 버스를 구성하는 Spring 빈의 ID를 지정합니다.

endpointName

소비자가 요청하는 서비스에 대한 wsdl:port 요소의 name 속성 값을 지정합니다. ns:name 형식을 사용하여 QName으로 지정됩니다. 여기서 nswsdl:port 요소의 네임스페이스입니다.

serviceName

소비자가 요청하는 서비스에 대한 wsdl:service 요소의 name 속성 값을 지정합니다. ns:name 형식을 사용하여 QName으로 지정됩니다. 여기서 nswsdl:service 요소의 네임스페이스입니다.

사용자 이름

간단한 사용자 이름/암호 인증에 사용되는 사용자 이름을 지정합니다.

암호

간단한 사용자 이름/암호 인증에 사용되는 암호를 지정합니다.

serviceClass

서비스 엔드포인트 인터페이스(SEI)의 이름을 지정합니다.

wsdlLocation

끝점의 WSDL 계약의 위치를 지정합니다. WSDL 계약의 위치는 클라이언트가 배포된 폴더를 기준으로 합니다.

name

소비자가 요청하는 서비스에 대한 wsdl:port 요소의 stringified QName을 지정합니다. {ns}localPart 형식을 사용하여 QName으로 지정됩니다. 여기서 nswsdl:port 요소의 네임스페이스이고 localPartwsdl:port 요소의 name 속성 값입니다.

abstract

빈이 추상 빈인지 여부를 지정합니다. 추상화 빈은 구체적인 빈 정의를 위해 부모 역할을 하며 인스턴스화되지 않습니다. 기본값은 false입니다. 이 값을 true 로 설정하면 빈 공장이 빈을 인스턴스화하지 않도록 지시합니다.

depends-on

끝점이 인스턴스화되기 전에 종속되는 빈 목록을 지정합니다.

createdFromAPI

Service.getPort() 와 같은 Apache CXF API를 사용하여 빈을 만들도록 지정합니다.

기본값은 false입니다.

이 값을 true 로 설정하면 다음이 수행됩니다.

  • .jaxws-client 를 해당 ID에 추가하여 빈의 내부 이름을 변경합니다.
  • 빈을 추상적으로 만듭니다.

표 17.4. “JAX-WS Consumer를 구성하는 데 사용되는 속성” 에 나열된 속성 외에도 여러 xmlns:shortName특성을 사용하여 endpointNameserviceName 속성에 사용되는 네임스페이스를 선언해야 할 수 있습니다.

17.2.3. 기능 추가

사용자에게 기능을 추가하거나 고급 구성을 수행하려면 구성에 하위 요소를 추가해야 합니다.

자식 요소를 사용하면 다음을 수행할 수 있습니다.

표 17.5. “Consumer Endpoint 구성을 위한 요소” JAX-WS 소비자를 구성하는 데 사용할 수 있는 자식 요소에 대해 설명합니다.

표 17.5. Consumer Endpoint 구성을 위한 요소
요소설명

jaxws:binding

끝점에서 사용하는 메시지 바인딩을 구성하는 빈을 지정합니다. 메시지 바인딩은 org.apache.cxf.binding.BindingFactory 인터페이스의 구현을 사용하여 구성됩니다.[a]

jaxws:dataBinding

끝점에서 사용하는 데이터 바인딩을 구현하는 클래스를 지정합니다.Specifies the class implementing the data binding used by the endpoint. 포함된 빈 정의를 사용하여 이 값을 지정합니다. JAXB 데이터 바인딩을 구현하는 클래스는 org.apache.cxf.jaxb.JAXBDataBinding 입니다.

jaxws:features

Apache CXF의 고급 기능을 구성하는 빈 목록을 지정합니다. 빈 참조 목록 또는 포함된 빈 목록을 제공할 수 있습니다.

jaxws:handlers

메시지 처리를 위한 JAX-WS Handler 구현 목록을 지정합니다. JAX-WS Handler 구현 방법에 대한 자세한 내용은 43장. 핸들러 작성 을 참조하십시오.

jaxws:inInterceptors

인바운드 응답을 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxws:inFaultInterceptors

인바운드 오류 메시지를 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxws:outInterceptors

아웃바운드 요청을 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxws:outFaultInterceptors

아웃바운드 오류 메시지를 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxws:properties

끝점으로 전달되는 속성의 맵을 지정합니다.

jaxws:conduitSelector

클라이언트가 사용할 org.apache.cxf.endpoint.ConduitSelector 구현을 지정합니다. ConduitSelector 구현은 아웃바운드 요청을 처리하는 데 사용되는 Conduit Selector 개체를 선택하는 데 사용되는 기본 프로세스를 재정의합니다.

[a] SOAP 바인딩은 soap:soapBinding 빈을 사용하여 구성됩니다.

17.2.4. 예제

예 17.5. “간단한 소비자 구성” 간단한 소비자 구성을 보여줍니다.

예 17.5. 간단한 소비자 구성

<beans ...
  xmlns:jaxws="http://cxf.apache.org/jaxws"
  ...
  schemaLocation="...
    http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
    ...">
  <jaxws:client id="bookClient"
                serviceClass="org.apache.cxf.demo.BookClientImpl"
                address="http://localhost:8080/books"/>
  ...
</beans>

17.2.5. JAX-WS 소비자에 대한 스키마 유효성 검사 활성화

JAX-WS 소비자에서 스키마 유효성 검사를 활성화하려면 jaxws:client 요소(예:)의 jaxws:properties 하위 요소에서 schema-validation-enabled 속성을 설정합니다.

<jaxws:client name="{http://apache.org/hello_world_soap_http}SoapPort"
    createdFromAPI="true">
    <jaxws:properties>
        <entry key="schema-validation-enabled" value="BOTH" />
    </jaxws:properties>
</jaxws:client>

schema-validation-enabled 속성의 허용되는 값 목록은 24.3.4.7절. “스키마 유효성 검사 유형 값” 을 참조하십시오.

18장. JAX-RS 엔드포인트 구성

초록

이 장에서는 Blueprint XML과 Spring XML에서 JAX-RS 서버 엔드포인트를 인스턴스화하고 구성하는 방법과 XML에서 JAX-RS 클라이언트 엔드포인트(클라이언트 프록시 빈)를 인스턴스화하고 구성하는 방법도 설명합니다.

18.1. JAX-RS Server 엔드 포인트 구성

18.1.1. JAX-RS Server Endpoint 정의

18.1.1.1. 기본 서버 끝점 정의

XML에서 JAX-RS 서버 끝점을 정의하려면 최소한 다음을 지정해야 합니다.

  1. XML에서 끝점을 정의하는 데 사용되는 jaxrs:server 요소. jaxrs: 네임스페이스 접두사는 Blueprint 및 Spring의 다양 한 네임스페이스에 각각 매핑됩니다.
  2. jaxrs:server 요소의 address 특성을 사용하여 JAX-RS 서비스의 기본 URL입니다. 끝점 배포 방법에 영향을 주는 주소 URL을 지정하는 두 가지 다른 방법이 있습니다.

    • 상대 URL- 예를 들어 /customers. 이 경우 끝점은 기본 HTTP 컨테이너에 배포되며 엔드포인트의 기본 URL은 CXF 서블릿 기본 URL을 지정된 상대 URL과 결합하여 암시적으로 가져옵니다.

      예를 들어, JAX-RS 엔드포인트를 Fuse 컨테이너에 배포하는 경우 지정된 /customers URL이 URL로 확인됩니다. http://Hostname:8181/cxf/customers(컨테이너가 기본 8181 포트를 사용하고 있다고 가정함).

    • 절대 URL인 경우 (예: http://0.0.0.0:8200/cxf/customers ) 이 경우 JAX-RS 엔드포인트에 대해 새 HTTP 리스너 포트가 열립니다(아직 열려 있지 않은 경우). 예를 들어 Fuse의 컨텍스트에서 JAX-RS 엔드포인트를 호스트하기 위해 새 Undertow 컨테이너가 암시적으로 생성됩니다. 특수 IP 주소 0.0.0.0 은 와일드카드 역할을 하며 현재 호스트에 할당된 호스트 이름(Multi-homed 호스트 시스템에서 유용할 수 있음)과 일치합니다.
  3. JAX-RS 서비스의 구현을 제공하는 하나 이상의 JAX-RS 루트 리소스 클래스입니다. 리소스 클래스를 지정하는 가장 간단한 방법은 jaxrs:serviceBeans 요소 내에 나열하는 것입니다.

18.1.1.2. Blueprint 예

다음 Blueprint XML 예제에서는 상대 주소를 지정하는 JAX-RS 엔드포인트를 정의하는 방법을 보여줍니다. /customers (기본 HTTP 컨테이너로 배포 가능)는 service.CustomerService 리소스 클래스에 의해 구현됩니다.

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs"
    xmlns:cxf="http://cxf.apache.org/blueprint/core"
    xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0 https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://cxf.apache.org/blueprint/jaxrs http://cxf.apache.org/schemas/blueprint/jaxrs.xsd
http://cxf.apache.org/blueprint/core http://cxf.apache.org/schemas/blueprint/core.xsd
">

    <cxf:bus>
        <cxf:features>
            <cxf:logging/>
        </cxf:features>
    </cxf:bus>

     <jaxrs:server id="customerService" address="/customers">
        <jaxrs:serviceBeans>
           <ref component-id="serviceBean" />
        </jaxrs:serviceBeans>
     </jaxrs:server>

     <bean id="serviceBean" class="service.CustomerService"/>
</blueprint>

18.1.1.3. Blueprint XML 네임스페이스

Blueprint에서 JAX-RS 엔드포인트를 정의하려면 일반적으로 다음과 같은 XML 네임스페이스가 필요합니다.

접두사네임스페이스

(기본값)

http://www.osgi.org/xmlns/blueprint/v1.0.0

cxf

http://cxf.apache.org/blueprint/core

jaxrs

http://cxf.apache.org/blueprint/jaxrs

18.1.1.4. Spring 예

다음 Spring XML 예제에서는 상대 주소 /customers (기본 HTTP 컨테이너에 배포)를 지정하고 service.CustomerService 리소스 클래스에 의해 구현되는 JAX-RS 엔드포인트를 정의하는 방법을 보여줍니다.

<beans xmlns="http://www.springframework.org/schema/beans"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:jaxrs="http://cxf.apache.org/jaxrs"
      xsi:schemaLocation="
         http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
         http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd">

     <jaxrs:server id="customerService" address="/customers">
        <jaxrs:serviceBeans>
           <ref bean="serviceBean"/>
        </jaxrs:serviceBeans>
     </jaxrs:server>

     <bean id="serviceBean" class="service.CustomerService"/>
</beans>

18.1.1.5. XML 네임스페이스 스프링

Spring에서 JAX-RS 엔드포인트를 정의하려면 일반적으로 다음과 같은 XML 네임스페이스가 필요합니다.

접두사네임스페이스

(기본값)

http://www.springframework.org/schema/beans

cxf

http://cxf.apache.org/core

jaxrs

http://cxf.apache.org/jaxrs

18.1.1.6. Spring XML 자동 검색

(spring only) JAX-RS 루트 리소스 클래스를 명시적으로 지정하는 대신 Spring XML을 사용하면 자동 검색을 구성할 수 있으므로 특정 Java 패키지가 리소스 클래스( @Path에서 주석이 달린 클래스) 및 모든 검색된 리소스 클래스가 자동으로 엔드포인트에 연결됩니다. 이 경우 jaxrs:server 요소에서 address 속성과 basePackages 속성만 지정해야 합니다.

예를 들어 a.b.c Java 패키지에서 모든 JAX-RS 리소스 클래스를 사용하는 JAX-RS 엔드포인트를 정의하려면 다음과 같이 Spring XML에서 엔드포인트를 정의할 수 있습니다.

<jaxrs:server address="/customers" basePackages="a.b.c"/>

자동 검색 메커니즘은 지정된 Java 패키지에서 찾은 모든 JAX-RS 공급자 클래스도 엔드포인트에 검색하고 설치합니다.

18.1.1.7. Spring XML의 라이프사이클 관리

(spring only) Spring XML을 사용하면 빈 요소에서 scope 속성을 설정하여 빈의 라이프사이클을 제어할 수 있습니다. Spring에서 다음 범위 값을 지원합니다.

singleton
(기본값) 모든 곳에서 사용되며 Spring 컨테이너의 전체 수명 동안 지속되는 단일 빈 인스턴스를 생성합니다.
prototype
빈이 다른 빈에 삽입될 때마다 또는 빈 레지스트리에서 getBean() 을 호출하여 빈을 가져올 때 새 빈 인스턴스를 생성합니다.
요청
(웹 인식 컨테이너에서만 사용 가능) 빈에서 호출되는 모든 요청에 대해 새 빈 인스턴스를 생성합니다.
session
(웹 인식 컨테이너에서만 사용 가능) 단일 HTTP 세션의 수명 동안 새 빈을 생성합니다.
globalSession
(웹 인식 컨테이너에서만 사용 가능) 포 틀릿 간에 공유되는 단일 HTTP 세션의 수명 동안 새 빈을 생성합니다.

Spring 범위에 대한 자세한 내용은 빈 범위에 대한 Spring 프레임워크 설명서 를 참조하십시오.

jaxrs:serviceBeans 요소를 통해 JAX-RS 리소스 빈을 지정하는 경우 Spring 범위가 제 대로 작동하지 않습니다. 이 경우 리소스 빈에 scope 속성을 지정하면 scope 속성이 효과적으로 무시됩니다.

빈 범위가 JAX-RS 서버 끝점 내에서 제대로 작동하도록 하려면 서비스 팩토리에서 제공하는 간접 수준이 필요합니다. 빈 범위를 구성하는 가장 간단한 방법은 다음과 같이 jaxrs:server 요소의 bean 특성을 사용하여 리소스 빈을 지정하는 것입니다.

<beans ... >
  <jaxrs:server id="customerService" address="/service1"
    beanNames="customerBean1 customerBean2"/>

  <bean id="customerBean1" class="demo.jaxrs.server.CustomerRootResource1" scope="prototype"/>
  <bean id="customerBean2" class="demo.jaxrs.server.CustomerRootResource2"  scope="prototype"/>
</beans>

위 예제에서는 두 개의 리소스 빈, customerBean1customerBean2 를 구성합니다. beanNames 특성은 리소스 빈 ID의 공백으로 구분된 목록으로 지정됩니다.

궁극적인 수준의 유연성을 위해 jaxrs:serviceFactories 요소를 사용하여 JAX-RS 서버 엔드포인트를 구성할 때 서비스 팩토리 개체를 명시적으로 정의할 수 있습니다. 이러한 보다 자세한 접근 방식은 기본 서비스 팩토리 구현을 사용자 지정 구현으로 교체할 수 있다는 이점이 있으므로 빈 라이프사이클을 궁극적으로 제어할 수 있습니다. 다음 예제에서는 다음 방법을 사용하여 두 리소스 빈인 customerBean1customerBean2 를 구성하는 방법을 보여줍니다.

<beans ... >
  <jaxrs:server id="customerService" address="/service1">
    <jaxrs:serviceFactories>
      <ref bean="sfactory1" />
      <ref bean="sfactory2" />
    </jaxrs:serviceFactories>
  </jaxrs:server>

  <bean id="sfactory1" class="org.apache.cxf.jaxrs.spring.SpringResourceFactory">
     <property name="beanId" value="customerBean1"/>
  </bean>
  <bean id="sfactory2" class="org.apache.cxf.jaxrs.spring.SpringResourceFactory">
     <property name="beanId" value="customerBean2"/>
  </bean>

  <bean id="customerBean1" class="demo.jaxrs.server.CustomerRootResource1" scope="prototype"/>
  <bean id="customerBean2" class="demo.jaxrs.server.CustomerRootResource2"  scope="prototype"/>
</beans>
참고

단일턴 라이프사이클이 아닌 경우 org.apache.cxf.service. invoker bean을 구현하고 등록하는 것이 좋습니다( jaxrs:server/jaxrs:invoker 요소에서 참조하여 인스턴스를 등록할 수 있음).

18.1.1.8. WADL 문서 연결

jaxrs:server 요소의 docLocation 속성을 사용하여 WADL 문서를 JAX-RS 서버 끝점과 선택적으로 연결할 수 있습니다. 예를 들면 다음과 같습니다.

<jaxrs:server address="/rest" docLocation="wadl/bookStore.wadl">
   <jaxrs:serviceBeans>
      <bean class="org.bar.generated.BookStore"/>
   </jaxrs:serviceBeans>
</jaxrs:server>

18.1.1.9. 스키마 검증

JAX-B 형식의 메시지 콘텐츠를 설명하는 외부 XML 스키마가 있는 경우 jaxrs:schemaLocations 요소를 통해 이러한 외부 스키마를 JAX-RS 서버 끝점과 연결할 수 있습니다.

예를 들어 서버 끝점과 WADL 문서를 연결하고 수신되는 메시지에 대해 스키마 유효성 검사를 활성화하려면 다음과 같이 연결된 XML 스키마 파일을 지정할 수 있습니다.

<jaxrs:server address="/rest"
              docLocation="wadl/bookStore.wadl">
   <jaxrs:serviceBeans>
     <bean class="org.bar.generated.BookStore"/>
   </jaxrs:serviceBeans>
   <jaxrs:schemaLocations>
     <jaxrs:schemaLocation>classpath:/schemas/a.xsd</jaxrs:schemaLocation>
     <jaxrs:schemaLocation>classpath:/schemas/b.xsd</jaxrs:schemaLocation>
   </jaxrs:schemaLocations>
</jaxrs:server>

또는 지정된 디렉토리에 모든 스키마 파일 *.xsd 를 포함하려는 경우 다음과 같이 디렉터리 이름만 지정할 수 있습니다.

<jaxrs:server address="/rest"
              docLocation="wadl/bookStore.wadl">
   <jaxrs:serviceBeans>
     <bean class="org.bar.generated.BookStore"/>
   </jaxrs:serviceBeans>
   <jaxrs:schemaLocations>
     <jaxrs:schemaLocation>classpath:/schemas/</jaxrs:schemaLocation>
   </jaxrs:schemaLocations>
</jaxrs:server>

이러한 방식으로 스키마를 지정하는 것은 일반적으로 JAX-B 스키마에 액세스해야 하는 모든 종류의 기능에 유용합니다.

18.1.1.10. 데이터 바인딩 지정

jaxrs:dataBinding 요소를 사용하여 메시지 본문을 요청 및 응답 메시지에서 인코딩하는 데이터 바인딩을 지정할 수 있습니다. 예를 들어 JAX-B 데이터 바인딩을 지정하려면 다음과 같이 JAX-RS 끝점을 구성할 수 있습니다.

<jaxrs:server id="jaxbbook" address="/jaxb">
  <jaxrs:serviceBeans>
    <ref bean="serviceBean" />
  </jaxrs:serviceBeans>
  <jaxrs:dataBinding>
    <bean class="org.apache.cxf.jaxb.JAXBDataBinding"/>
  </jaxrs:dataBinding>
</jaxrs:server>>

Aegis 데이터 바인딩을 지정하려면 다음과 같이 JAX-RS 끝점을 구성할 수 있습니다.

<jaxrs:server id="aegisbook" address="/aegis">
  <jaxrs:serviceBeans>
    <ref bean="serviceBean" />
  </jaxrs:serviceBeans>
  <jaxrs:dataBinding>
    <bean class="org.apache.cxf.aegis.databinding.AegisDatabinding">
      <property name="aegisContext">
        <bean class="org.apache.cxf.aegis.AegisContext">
          <property name="writeXsiTypes" value="true"/>
        </bean>
      </property>
    </bean>
  </jaxrs:dataBinding>
</jaxrs:server>

18.1.1.11. JMS 전송 사용

HTTP 대신 JMS 메시징 라이브러리를 전송 프로토콜로 사용하도록 JAX-RS를 구성할 수 있습니다. JMS 자체는 전송 프로토콜이 아니 므로 실제 메시징 프로토콜은 사용자가 구성하는 특정 JMS 구현에 따라 다릅니다.

예를 들어 다음 Spring XML 예제에서는 JMS 전송 프로토콜을 사용하도록 JAX-RS 서버 엔드포인트를 구성하는 방법을 보여줍니다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jms="http://cxf.apache.org/transports/jms"
       xmlns:jaxrs="http://cxf.apache.org/jaxrs"
       xsi:schemaLocation="
http://cxf.apache.org/transports/jms http://cxf.apache.org/schemas/configuration/jms.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd">

    <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/>
    <bean id="ConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL" value="tcp://localhost:${testutil.ports.EmbeddedJMSBrokerLauncher}" />
    </bean>

    <jaxrs:server xmlns:s="http://books.com"
    	serviceName="s:BookService"
    	transportId= "http://cxf.apache.org/transports/jms"
    	address="jms:queue:test.jmstransport.text?replyToName=test.jmstransport.response">
        <jaxrs:serviceBeans>
            <bean class="org.apache.cxf.systest.jaxrs.JMSBookStore"/>
        </jaxrs:serviceBeans>
    </jaxrs:server>

</beans>

이전 예제에 대한 다음 사항에 유의하십시오.

  • JMS 구현- JMS 구현은 Apache ActiveMQ 연결 팩토리 개체를 인스턴스화하는 ConnectionFactory 빈에서 제공합니다. 연결 팩토리를 인스턴스화한 후에는 자동으로 기본 JMS 구현 계층으로 설치됩니다.
  • JMS 구성 또는 대상 개체-Apache CXF는 JMS 대상 개체( JMS 소비자를 나타내는) 또는 JMS 대상 오브젝트를 암시적으로 인스턴스화합니다. 이 오브젝트는 setttings xmlns:s="http://books.com" 속성(네임 스페이스 접두사 정의) 및 serviceName="s:BookService" (QName 정의)를 통해 정의된 QName으로 고유하게 식별되어야 합니다.
  • 전송 ID-에서 JMS 전송을 선택하려면 transportId 특성을 http://cxf.apache.org/transports/jms 로 설정해야 합니다.
  • JMS address-the jaxrs:server/@address 속성은 표준화된 구문을 사용하여 보낼 JMS 대기열 또는 JMS 주제를 지정합니다. 이 구문에 대한 자세한 내용은 https://tools.ietf.org/id/draft-merrick-jms-uri-06.txt 에서 참조하십시오.

18.1.1.12. 확장 매핑 및 언어 매핑

JAX-RS 서버 끝점은 파일 접미사(URL에서 표시됨)를 MIME 콘텐츠 유형 헤더에 자동으로 매핑하도록 구성하고 언어 접미사를 언어 유형 헤더에 매핑할 수 있습니다. 예를 들어 다음 형식의 HTTP 요청을 고려하십시오.For example, consider a HTTP request of the following form:

GET /resource.xml

다음과 같이 .xml 접미사를 자동으로 매핑하도록 JAX-RS 서버 끝점을 구성할 수 있습니다.

<jaxrs:server id="customerService" address="/">
  <jaxrs:serviceBeans>
    <bean class="org.apache.cxf.jaxrs.systests.CustomerService" />
  </jaxrs:serviceBeans>
  <jaxrs:extensionMappings>
    <entry key="json" value="application/json"/>
    <entry key="xml" value="application/xml"/>
  </jaxrs:extensionMappings>
</jaxrs:server>

이전 서버 끝점에서 HTTP 요청을 수신하면 type, application/xml 의 새 콘텐츠 유형 헤더를 자동으로 생성하고 리소스 URL에서 .xml 접미사를 제거합니다.

언어 매핑의 경우 다음 형식의 HTTP 요청을 고려하십시오.For the language mapping, consider a HTTP request of the following form:

GET /resource.en

다음과 같이 JAX-RS 서버 끝점을 구성하여 .en 접미사가 자동으로 매핑할 수 있습니다.

<jaxrs:server id="customerService" address="/">
  <jaxrs:serviceBeans>
    <bean class="org.apache.cxf.jaxrs.systests.CustomerService" />
  </jaxrs:serviceBeans>
  <jaxrs:languageMappings>
     <entry key="en" value="en-gb"/>
  </jaxrs:languageMappings>
</jaxrs:server>

이전 서버 끝점에서 HTTP 요청을 수신하면 값이 en-gb 인 새 허용 언어 헤더를 자동으로 생성하고 리소스 URL에서 .en 접미사를 제거합니다.

18.1.2. jaxrs:server 속성

18.1.2.1. 속성

표 18.1. “JAX-RS Server Endpoint Attributes” jaxrs:server 요소에서 사용 가능한 특성을 설명합니다.

표 18.1. JAX-RS Server Endpoint Attributes
속성설명

id

다른 구성 요소에서 끝점을 참조하는 데 사용할 수 있는 고유 식별자를 지정합니다.Specifies a unique identifier that other configuration elements can use to refer to the endpoint.

주소

HTTP 끝점의 주소를 지정합니다. 이 값은 서비스 계약에 지정된 값을 재정의합니다.

basePackages

(spring only) JAX-RS 루트 리소스 클래스 및/또는 JAX-RS 공급자 클래스를 검색하도록 검색되는 Java 패키지 목록을 쉼표로 구분하여 지정하여 자동 검색을 활성화합니다.

beanNames

JAX-RS 루트 리소스 빈의 공백으로 구분된 빈 ID 목록을 지정합니다. Spring XML의 컨텍스트에서 루트 리소스 빈 요소에 scope 속성을 설정하여 루트 리소스 빈의 라이프사이클을 정의할 수 있습니다.

bindingId

서비스에서 사용하는 메시지 바인딩의 ID를 지정합니다. 유효한 바인딩 ID 목록은 23장. Apache CXF 바인딩 ID 에서 제공됩니다.

bus

서비스 엔드포인트를 관리하는 데 사용되는 버스를 구성하는 Spring 빈의 ID를 지정합니다. 이 기능은 공통 기능 세트를 사용하도록 여러 끝점을 구성할 때 유용합니다.

docLocation

외부 WADL 문서의 위치를 지정합니다.

modelRef

모델 스키마를 classpath 리소스로 지정합니다(예: classpath:/path/to/model.xml). JAX-RS 모델 스키마를 정의하는 방법에 대한 자세한 내용은 18.3절. “모델 스키마를 사용하여 REST 서비스 정의” 을 참조하십시오.

publish

서비스가 자동으로 게시되어야 하는지 여부를 지정합니다. false 로 설정하면 개발자가 엔드포인트를 명시적으로 게시해야 합니다.

publishedEndpointUrl

자동 생성된 WADL 인터페이스의 wadl:resources/@base 속성에 삽입되는 URL 기본 주소를 지정합니다.

serviceAnnotation

(spring only) Spring 에서 자동 검색에 대한 서비스 주석 클래스 이름을 지정합니다. 이 옵션을 basePackages 속성과 함께 사용하면 이 주석 유형에 따라 주석이 달린 클래스 포함하도록 자동 검색 클래스 컬렉션을 제한합니다. 이 맞습니까?

serviceClass

JAX-RS 서비스를 구현하는 JAX-RS 루트 리소스 클래스의 이름을 지정합니다. 이 경우 클래스는 Blueprint 또는 Spring이 아닌 Apache CXF에 의해 인스턴스화됩니다. Blueprint 또는 Spring에서 클래스를 인스턴스화하려면 대신 jaxrs:serviceBeans 하위 요소를 사용하십시오.

serviceName

JMS 전송이 사용되는 특수한 경우 JAX-RS 엔드포인트에 대한 서비스 QName( ns:이름형식 사용)을 지정합니다. 자세한 내용은 “JMS 전송 사용”의 내용을 참조하십시오.

staticSubresourceResolution

true 인 경우 정적 하위 리소스의 동적 확인을 비활성화합니다. 기본값은 false 입니다.

transportId

비표준 전송 계층(HTTP 대신)을 선택하기 위한 것입니다. 특히 이 속성을 http://cxf.apache.org/transports/jms 로 설정하여 JMS 전송을 선택할 수 있습니다. 자세한 내용은 “JMS 전송 사용”의 내용을 참조하십시오.

abstract

(spring only) 빈이 추상 빈인지 여부를 지정합니다. 추상화 빈은 구체적인 빈 정의를 위해 부모 역할을 하며 인스턴스화되지 않습니다. 기본값은 false입니다. 이 값을 true 로 설정하면 빈 공장이 빈을 인스턴스화하지 않도록 지시합니다.

depends-on

(spring only) 끝점을 인스턴스화하기 전에 끝점을 인스턴스화하는 데 의존하는 빈 목록을 지정합니다.

18.1.3. jaxrs:server 하위 요소

18.1.3.1. 하위 요소

표 18.2. “JAX-RS Server Endpoint Child Elements” jaxrs:server 요소의 하위 요소에 대해 설명합니다.

표 18.2. JAX-RS Server Endpoint Child Elements
요소설명

jaxrs:executor

서비스에 사용되는 Java Executor (스레드 풀 구현)를 지정합니다. 이는 포함된 빈 정의를 사용하여 지정합니다.

jaxrs:features

Apache CXF의 고급 기능을 구성하는 빈 목록을 지정합니다. 빈 참조 목록 또는 포함된 빈 목록을 제공할 수 있습니다.

jaxrs:binding

사용되지 않음.

jaxrs:dataBinding

끝점에서 사용하는 데이터 바인딩을 구현하는 클래스를 지정합니다.Specifies the class implementing the data binding used by the endpoint. 이는 포함된 빈 정의를 사용하여 지정합니다. 자세한 내용은 “데이터 바인딩 지정” 에서 참조하십시오.

jaxrs:inInterceptors

인바운드 요청을 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxrs:inFaultInterceptors

인바운드 오류 메시지를 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxrs:outInterceptors

아웃바운드 응답을 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxrs:outFaultInterceptors

아웃바운드 오류 메시지를 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxrs:invoker

서비스에서 사용하는 org.apache.cxf.service. invoker 인터페이스의 구현을 지정합니다.[a]

jaxrs:serviceFactories

이 끝점과 연결된 JAX-RS 루트 리소스의 라이프사이클에 대한 최대 제어 수준을 제공합니다. 이 요소의 하위 항목( org.apache.cxf.jaxrs.lifecycle.ResourceProvider 유형의 인스턴스)은 JAX-RS 루트 리소스 인스턴스를 생성하는 데 사용됩니다.

jaxrs:properties

끝점에 전달되는 속성의 Spring 맵을 지정합니다. 이러한 속성은 MTOM 지원 활성화와 같은 기능을 제어하는 데 사용할 수 있습니다.

jaxrs:serviceBeans

이 요소의 하위 항목은 요소의 인스턴스 또는 (ref 요소) JAX-RS 루트 리소스에 대한 참조입니다. 이 경우 요소에 있는 경우 scope 속성 (Spring만 해당) 은 무시됩니다.

jaxrs:modelBeans

리소스 모델의 기본 요소( jaxrs:resource 요소에 해당)인 하나 이상의 org.apache.cxf.jaxrs.model.UserResource bean에 대한 참조 목록으로 구성됩니다. 자세한 내용은 18.3절. “모델 스키마를 사용하여 REST 서비스 정의”의 내용을 참조하십시오.

jaxrs:model

이 엔드포인트에서 직접 리소스 모델을 정의합니다(즉, 이 jaxrs:model 요소는 하나 이상의 jaxrs:resource 요소를 포함할 수 있음). 자세한 내용은 18.3절. “모델 스키마를 사용하여 REST 서비스 정의”의 내용을 참조하십시오.

jaxrs:providers

이 끝점에 하나 이상의 사용자 지정 JAX-RS 공급자를 등록할 수 있습니다. 이 요소의 자식은 요소의 인스턴스 또는 (ref 요소) JAX-RS 공급자에 대한 참조입니다.

jaxrs:extensionMappings

REST 호출의 URL이 파일 확장으로 종료되면 이 요소를 사용하여 특정 콘텐츠 유형과 자동으로 연결할 수 있습니다. 예를 들어 .xml 파일 확장자는 application/xml 콘텐츠 유형과 연관될 수 있습니다. 자세한 내용은 “확장 매핑 및 언어 매핑”의 내용을 참조하십시오.

jaxrs:languageMappings

REST 호출의 URL이 언어 접미사로 끝나는 경우 이 요소를 사용하여 특정 언어에 매핑할 수 있습니다. 예를 들어 .en 언어 접미사는 en-GB 언어와 연결할 수 있습니다. 자세한 내용은 “확장 매핑 및 언어 매핑”의 내용을 참조하십시오.

jaxrs:schemaLocations

XML 메시지 콘텐츠 유효성 검사에 사용되는 하나 이상의 XML 스키마를 지정합니다.Specifies one or more XML schemas used for validating XML message content. 이 요소에는 하나 이상의 jaxrs:schemaLocation 요소가 포함될 수 있으며, 각 요소는 XML 스키마 파일의 위치를 지정합니다(일반적으로 classpath URL). 자세한 내용은 “스키마 검증”의 내용을 참조하십시오.

jaxrs:resourceComparator

들어오는 URL 경로를 특정 리소스 클래스 또는 메서드에 일치시키는 데 사용되는 알고리즘을 구현하는 사용자 지정 리소스 비교기를 등록할 수 있습니다.

jaxrs:resourceClasses

클래스 이름에서 여러 리소스를 만들려면 jaxrs:server/@serviceClass 속성 대신 사용할 수 있습니다. jaxrs:resourceClasses 의 하위 항목은 리소스 클래스 이름으로 설정된 name 속성이 있는 클래스 요소여야 합니다. 이 경우 클래스는 Blueprint 또는 Spring이 아닌 Apache CXF에 의해 인스턴스화됩니다.

[a] invoker 구현은 서비스가 호출되는 방법을 제어합니다. 예를 들어 서비스 구현의 새 인스턴스에서 각 요청을 처리했는지 또는 상태가 호출 간에 보존되는지 여부를 제어합니다.

18.2. JAX-RS 클라이언트 엔드 포인트 구성

18.2.1. JAX-RS Client Endpoint 정의

18.2.1.1. 클라이언트 프록시 삽입

XML 언어(Blueprint XML 또는 Spring XML)에서 클라이언트 프록시 빈을 인스턴스화하는 기본 방법은 클라이언트 프록시를 사용하여 REST 서비스를 호출할 수 있는 다른 빈에 삽입하는 것입니다. XML에서 클라이언트 프록시 빈을 생성하려면 jaxrs:client 요소를 사용합니다.

18.2.1.2. 네임스페이스

JAX-RS 클라이언트 끝점은 서버 끝점의 다른 XML 네임스페이스를 사용하여 정의합니다. 다음 표에서는 어떤 XML 언어에 사용할 네임스페이스를 보여줍니다.

XML 언어클라이언트 끝점의 네임스페이스

Blueprint

http://cxf.apache.org/blueprint/jaxrs-client

Spring

http://cxf.apache.org/jaxrs-client

18.2.1.3. 기본 클라이언트 끝점 정의

다음 예제에서는 Blueprint XML 또는 Spring XML에서 클라이언트 프록시 빈을 생성하는 방법을 보여줍니다.

<jaxrs:client id="restClient"
       address="http://localhost:8080/test/services/rest"
       serviceClass="org.apache.cxf.systest.jaxrs.BookStoreJaxrsJaxws"/>

기본 클라이언트 끝점을 정의하려면 다음 속성을 설정해야 하는 위치입니다.

id
클라이언트 프록시의 빈 ID를 사용하여 XML 구성의 다른 빈에 클라이언트 프록시를 삽입할 수 있습니다.
주소
address 속성은 REST 호출의 기본 URL을 지정합니다.
serviceClass
serviceClass 속성은 루트 리소스 클래스를 지정하여 REST 서비스에 대한 설명을 제공합니다( @Path에서 주석 처리됨). 실제로 이 클래스는 서버 클래스이지만 클라이언트에서 직접 사용하지는 않습니다. 지정된 클래스는 클라이언트 프록시를 동적으로 구성하는 데 사용되는 해당 메타데이터(Java 리플렉션 및 JAX-RS 주석을 통해)에만 사용됩니다.

18.2.1.4. 헤더 지정

다음과 같이 jaxrs:headers 하위 요소를 사용하여 클라이언트 프록시의 호출에 HTTP 헤더를 추가할 수 있습니다.

<jaxrs:client id="restClient"
       address="http://localhost:8080/test/services/rest"
       serviceClass="org.apache.cxf.systest.jaxrs.BookStoreJaxrsJaxws"
       inheritHeaders="true">
       <jaxrs:headers>
           <entry key="Accept" value="text/xml"/>
       </jaxrs:headers>
</jaxrs:client>

18.2.2. jaxrs:client 속성

18.2.2.1. 속성

표 18.3. “JAX-RS 클라이언트 끝점 속성” jaxrs:client 요소에서 사용 가능한 특성을 설명합니다.

표 18.3. JAX-RS 클라이언트 끝점 속성
속성설명

주소

소비자가 요청할 끝점의 HTTP 주소를 지정합니다. 이 값은 계약에 설정된 값을 재정의합니다.

bindingId

소비자가 사용하는 메시지 바인딩의 ID를 지정합니다. 유효한 바인딩 ID 목록은 23장. Apache CXF 바인딩 ID 에서 제공됩니다.

bus

엔드포인트를 관리하는 버스를 구성하는 Spring 빈의 ID를 지정합니다.

inheritHeaders

이 프록시에서 하위 리소스 프록시가 생성되는 경우 이 프록시에 설정된 헤더가 상속되는지 여부를 지정합니다. 기본값은 false 입니다.

사용자 이름

간단한 사용자 이름/암호 인증에 사용되는 사용자 이름을 지정합니다.

암호

간단한 사용자 이름/암호 인증에 사용되는 암호를 지정합니다.

modelRef

모델 스키마를 classpath 리소스로 지정합니다(예: classpath:/path/to/model.xml). JAX-RS 모델 스키마를 정의하는 방법에 대한 자세한 내용은 18.3절. “모델 스키마를 사용하여 REST 서비스 정의” 을 참조하십시오.

serviceClass

서비스 인터페이스 또는 리소스 클래스( @PATH로 주석이 추가됨)의 이름을 지정하고 JAX-RS 서버 구현에서 다시 사용합니다. 이 경우 지정된 클래스가 직접 호출 되지 않습니다 (실제 서버 클래스). 지정된 클래스는 클라이언트 프록시를 동적으로 구성하는 데 사용되는 해당 메타데이터(Java 리플렉션 및 JAX-RS 주석을 통해)에만 사용됩니다.

serviceName

JMS 전송이 사용되는 특수한 경우 JAX-RS 엔드포인트에 대한 서비스 QName( ns:이름형식 사용)을 지정합니다. 자세한 내용은 “JMS 전송 사용”의 내용을 참조하십시오.

threadSafe

클라이언트 프록시가 스레드로부터 안전한지 여부를 지정합니다.Specifies whether the client proxy is thread-safe. 기본값은 false 입니다.

transportId

비표준 전송 계층(HTTP 대신)을 선택하기 위한 것입니다. 특히 이 속성을 http://cxf.apache.org/transports/jms 로 설정하여 JMS 전송을 선택할 수 있습니다. 자세한 내용은 “JMS 전송 사용”의 내용을 참조하십시오.

abstract

(spring only) 빈이 추상 빈인지 여부를 지정합니다. 추상화 빈은 구체적인 빈 정의를 위해 부모 역할을 하며 인스턴스화되지 않습니다. 기본값은 false입니다. 이 값을 true 로 설정하면 빈 공장이 빈을 인스턴스화하지 않도록 지시합니다.

depends-on

(spring only) 끝점이 인스턴스화되기 전에 의존하는 빈 목록을 지정합니다.

18.2.3. jaxrs: 클라이언트 하위 요소

18.2.3.1. 하위 요소

표 18.4. “JAX-RS 클라이언트 끝점 하위 요소” jaxrs:client 요소의 하위 요소에 대해 설명합니다.

표 18.4. JAX-RS 클라이언트 끝점 하위 요소
요소설명

jaxrs:executor

 

jaxrs:features

Apache CXF의 고급 기능을 구성하는 빈 목록을 지정합니다. 빈 참조 목록 또는 포함된 빈 목록을 제공할 수 있습니다.

jaxrs:binding

사용되지 않음.

jaxrs:dataBinding

끝점에서 사용하는 데이터 바인딩을 구현하는 클래스를 지정합니다.Specifies the class implementing the data binding used by the endpoint. 이는 포함된 빈 정의를 사용하여 지정합니다. 자세한 내용은 “데이터 바인딩 지정” 에서 참조하십시오.

jaxrs:inInterceptors

인바운드 응답을 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxrs:inFaultInterceptors

인바운드 오류 메시지를 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxrs:outInterceptors

아웃바운드 요청을 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxrs:outFaultInterceptors

아웃바운드 오류 메시지를 처리하는 인터셉터 목록을 지정합니다. 자세한 내용은 VII 부. Apache CXF 인터셉터 개발 에서 참조하십시오.

jaxrs:properties

끝점으로 전달되는 속성의 맵을 지정합니다.

jaxrs:providers

이 끝점에 하나 이상의 사용자 지정 JAX-RS 공급자를 등록할 수 있습니다. 이 요소의 자식은 요소의 인스턴스 또는 (ref 요소) JAX-RS 공급자에 대한 참조입니다.

jaxrs:modelBeans

리소스 모델의 기본 요소( jaxrs:resource 요소에 해당)인 하나 이상의 org.apache.cxf.jaxrs.model.UserResource bean에 대한 참조 목록으로 구성됩니다. 자세한 내용은 18.3절. “모델 스키마를 사용하여 REST 서비스 정의”의 내용을 참조하십시오.

jaxrs:model

이 엔드포인트에서 직접 리소스 모델을 정의합니다(즉, jaxrs:resource 요소가 하나 이상 포함된 jaxrs:model 요소). 자세한 내용은 18.3절. “모델 스키마를 사용하여 REST 서비스 정의”의 내용을 참조하십시오.

jaxrs:headers

발신 메시지에 헤더를 설정하는 데 사용됩니다. 자세한 내용은 “헤더 지정”의 내용을 참조하십시오.

jaxrs:schemaLocations

XML 메시지 콘텐츠 유효성 검사에 사용되는 하나 이상의 XML 스키마를 지정합니다.Specifies one or more XML schemas used for validating XML message content. 이 요소에는 하나 이상의 jaxrs:schemaLocation 요소가 포함될 수 있으며, 각 요소는 XML 스키마 파일의 위치를 지정합니다(일반적으로 classpath URL). 자세한 내용은 “스키마 검증”의 내용을 참조하십시오.

18.3. 모델 스키마를 사용하여 REST 서비스 정의

18.3.1. 주석이 없는 RESTful 서비스

JAX-RS 모델 스키마를 사용하면 Java 클래스에 주석을 달지 않고 RESTful 서비스를 정의할 수 있습니다. 즉, @Path , @Path Param,@Consumes, @Consumes ,@ Consumes , @tentSourcePolicy 등과 같은 주석을 Java 클래스(또는 인터페이스)에 직접 추가하는 대신, 모델 스키마를 사용하여 모든 관련 REST 메타데이터를 별도의 XML 파일에 제공할 수 있습니다. 예를 들어 서비스를 구현하는 Java 소스를 수정할 수 없는 경우 유용합니다.

18.3.2. 모델 스키마 예

예 18.1. “샘플 JAX-RS 모델 스키마” BookStoreNoAnnotations 루트 리소스 클래스에 대한 서비스 메타데이터를 정의하는 모델 스키마의 예를 보여줍니다.

예 18.1. 샘플 JAX-RS 모델 스키마

<model xmlns="http://cxf.apache.org/jaxrs">
  <resource name="org.apache.cxf.systest.jaxrs.BookStoreNoAnnotations" path="bookstore"
    produces="application/json" consumes="application/json">
    <operation name="getBook" verb="GET" path="/books/{id}" produces="application/xml">
       <param name="id" type="PATH"/>
    </operation>
    <operation name="getBookChapter" path="/books/{id}/chapter">
       <param name="id" type="PATH"/>
    </operation>
    <operation name="updateBook" verb="PUT">
       <param name="book" type="REQUEST_BODY"/>
    </operation>
  </resource>
  <resource name="org.apache.cxf.systest.jaxrs.ChapterNoAnnotations">
    <operation name="getItself" verb="GET"/>
    <operation name="updateChapter" verb="PUT" consumes="application/xml">
        <param name="content" type="REQUEST_BODY"/>
    </operation>
  </resource>
</model>

18.3.3. 네임스페이스

모델 스키마를 정의하는 데 사용하는 XML 네임스페이스는 Blueprint XML에서 해당 JAX-RS 엔드포인트를 정의하는지 또는 Spring XML에서 정의하는지에 따라 달라집니다. 다음 표에서는 어떤 XML 언어에 사용할 네임스페이스를 보여줍니다.

XML 언어네임스페이스

Blueprint

http://cxf.apache.org/blueprint/jaxrs

Spring

http://cxf.apache.org/jaxrs

18.3.4. 끝점에 모델 스키마를 연결하는 방법

모델 스키마를 끝점에 정의하고 연결하려면 다음 단계를 수행합니다.

  1. 선택한 주입 플랫폼(Blueprint XML 또는 Spring XML)에 적합한 XML 네임스페이스를 사용하여 모델 스키마를 정의합니다.
  2. 모델 스키마 파일을 프로젝트의 리소스에 추가하여 스키마 파일을 최종 패키지(JAR, WAR 또는 OSGi 번들 파일)의 classpath에서 사용할 수 있도록 합니다.

    참고

    또는 엔드포인트의 jaxrs:model 하위 요소를 사용하여 모델 스키마를 JAX-RS 엔드포인트에 직접 포함할 수도 있습니다.

  3. 엔드포인트의 model 스키마를 classpath의 모델 스키마 위치로 설정하여 모델 스키마를 사용하도록 엔드포인트를 구성합니다(classpath URL 사용).
  4. 필요한 경우 jaxrs:serviceBeans 요소를 사용하여 루트 리소스를 명시적으로 인스턴스화합니다. 모델 스키마에서 루트 리소스 클래스를 직접 참조하는 경우(기본 인터페이스 참조 대신) 이 단계를 건너뛸 수 있습니다.

18.3.5. 클래스를 참조하는 모델 스키마 구성

모델 스키마가 루트 리소스 클래스에 직접 적용되는 경우 모델 스키마가 루트 리소스 빈을 자동으로 인스턴스화하므로 jaxrs:serviceBeans 요소를 사용하여 루트 리소스 빈을 정의할 필요가 없습니다.

예를 들어 customer-resources.xml 이 메타데이터를 고객 리소스 클래스와 연결하는 모델 스키마로 설정된 경우 다음과 같이 customerService 서비스 끝점을 인스턴스화할 수 있습니다.

<jaxrs:server id="customerService"
              address="/customers"
              modelRef="classpath:/org/example/schemas/customer-resources.xml" />

18.3.6. 인터페이스를 참조하는 모델 스키마 구성

모델 스키마가 루트 리소스의 기본 인터페이스인 Java 인터페이스에 적용되는 경우 엔드포인트에서 jaxrs:serviceBeans 요소를 사용하여 루트 리소스 클래스를 인스턴스화해야 합니다.

예를 들어 customer-interfaces.xml 이 메타데이터를 고객 인터페이스와 연결하는 모델 스키마라고 가정하면 다음과 같이 customerService 서비스 엔드 포인트를 인스턴스화할 수 있습니다.

<jaxrs:server id="customerService"
              address="/customers"
              modelRef="classpath:/org/example/schemas/customer-interfaces.xml">
    <jaxrs:serviceBeans>
       <ref component-id="serviceBean" />
    </jaxrs:serviceBeans>
</jaxrs:server>

<bean id="serviceBean" class="service.CustomerService"/>

18.3.7. 모델 스키마 참조

모델 스키마는 다음 XML 요소를 사용하여 정의됩니다.A model schema is defined using the following XML elements:

model
모델 스키마의 루트 요소입니다. model 스키마를 참조해야 하는 경우(예: modelRef 특성을 사용하는 JAX-RS 끝점에서 이 요소에 대한 id 특성을 설정해야 합니다.
model/resource

리소스 요소는 메타데이터를 특정 루트 리소스 클래스(또는 해당 인터페이스와 연결)하는 데 사용됩니다. 리소스 요소에서 다음 속성을 정의할 수 있습니다.

속성description +

name

이 리소스 모델이 적용되는 리소스 클래스(또는 해당 인터페이스)의 이름입니다.

+

path

이 리소스에 매핑되는 REST URL 경로의 구성 요소입니다.

+

consumes

이 리소스에서 사용하는 콘텐츠 유형(인터넷 미디어 유형)을 지정합니다(예: application/xml 또는 application/json ).

+

produces

이 리소스에서 생성한 콘텐츠 유형(인터넷 미디어 유형)을 지정합니다(예: application/xml 또는 application/json ).

+

model/resource/operation

작업 요소는 메타데이터를 Java 메서드와 연결하는 데 사용됩니다. 작업 요소에서 다음 특성을 정의할 수 있습니다.

속성description +

name

이 요소가 적용되는 Java 메서드의 이름입니다.

+

path

이 메서드에 매핑되는 REST URL 경로의 구성 요소입니다. 이 특성 값에는 매개변수 참조(예: path="/books/{id}/chapter" )가 포함될 수 있으며, 여기서 {id} 는 경로에서 id 매개 변수 값을 추출합니다.

+

verb

이 메서드에 매핑되는 HTTP 동사를 지정합니다. 일반적으로 GET,POST,PUT 또는 DELETE 중 하나입니다. HTTP 동사를 지정하지 않으면 Java 메서드가 하위 리소스 오브젝트에 대한 참조를 반환하는 하위 리소스 locater 이라고 가정합니다(sub- resource 클래스는 리소스 요소를 사용하는 메타데이터도 제공해야 함).

+

consumes

이 작업에서 사용하는 콘텐츠 유형(인터넷 미디어 유형)을 지정합니다(예: application/xml 또는 application/json ).

+

produces

이 작업에서 생성한 콘텐츠 유형(인터넷 미디어 유형)을 지정합니다(예: application/xml 또는 application/json ).

+

oneWay

true 인 경우 작업을 단방향 으로 구성합니다. 즉 응답 메시지가 필요하지 않습니다. 기본값은 false입니다.

+

model/resource/operation/param

param 요소는 REST URL에서 값을 추출하여 메서드 매개변수 중 하나에 삽입합니다. param 요소에서 다음 속성을 정의할 수 있습니다.

속성description +

name

이 요소가 적용되는 Java 메서드 매개 변수의 이름입니다.

+

type

REST URL 또는 메시지에서 매개변수 값을 추출하는 방법을 지정합니다. PATH,QUERY,MATRIX,HEADER,COOKIE,FORM,CONTEXT,REQUEST_BODY 값 중 하나로 설정할 수 있습니다.

+

defaultValue

REST URL 또는 메시지에서 값을 추출할 기본값입니다.

+

인코딩

true 인 경우 매개 변수 값이 URI 인코딩 형식으로 삽입됩니다(즉, %nn 인코딩 사용). 기본값은 false 입니다. 예를 들어, URL 경로에서 매개 변수를 추출하는 경우, 인코딩이 true 로 설정된 /name/Joe%20Bloggs 에서 매개 변수를 추출할 때 매개 변수가 Joe%20Bloggs 로 삽입되고, 그렇지 않으면 매개 변수가 Joe Bloggs 로 삽입됩니다.

+

19장. Apache CXF Logging

초록

이 장에서는 Apache CXF 런타임에서 로깅을 구성하는 방법을 설명합니다.

19.1. Apache CXF 로깅 개요

19.1.1. 개요

Apache CXF는 Java 로깅 유틸리티인 java.util.logging 을 사용합니다. 로깅은 표준 java.util.Properties 형식을 사용하여 작성된 로깅 구성 파일로 구성됩니다. 애플리케이션에서 로깅을 실행하려면 프로그래밍 방식으로 로깅을 지정하거나 애플리케이션을 시작할 때 로깅 구성 파일을 가리키는 명령에서 속성을 정의하여 지정할 수 있습니다.

19.1.2. 기본 속성 파일

Apache CXF에는 InstallDir/etc 디렉토리에 있는 기본 logging.properties 파일이 제공됩니다. 이 파일은 로그 메시지의 출력 대상과 게시된 메시지 수준을 모두 구성합니다. 기본 구성은 WARNING 수준으로 플래그가 지정된 로거를 콘솔에 인쇄하도록 설정합니다. 구성 설정을 변경하지 않고 기본 파일을 사용하거나 특정 애플리케이션에 맞게 구성 설정을 변경할 수 있습니다.

19.1.3. 로깅 기능

Apache CXF에는 로깅을 활성화하기 위해 클라이언트 또는 서비스에 연결할 수 있는 로깅 기능이 포함되어 있습니다. 예 19.1. “로깅 활성화를 위한 구성” 로깅 기능을 활성화하는 구성을 보여줍니다.

예 19.1. 로깅 활성화를 위한 구성

<jaxws:endpoint...>
  <jaxws:features>
    <bean class="org.apache.cxf.feature.LoggingFeature"/>
  </jaxws:features>
</jaxws:endpoint>

자세한 내용은 19.6절. “메시지 콘텐츠 로깅”의 내용을 참조하십시오.

19.1.4. 어디서 시작할 수 있습니까?

간단한 로깅 예제를 실행하려면 19.2절. “로깅 사용의 간단한 예” 에 설명된 지침을 따릅니다.

Apache CXF에서 로깅이 작동하는 방법에 대한 자세한 내용은 이 전체 장을 참조하십시오.

19.1.5. java.util.logging에 대한 추가 정보

java.util.logging 유틸리티는 가장 널리 사용되는 Java 로깅 프레임워크 중 하나입니다. 이 프레임워크를 사용하고 확장하는 방법을 설명하는 온라인으로 사용 가능한 많은 정보가 있습니다. 그러나 다음 문서는 java.util.logging 에 대한 좋은 개요를 제공합니다.

19.2. 로깅 사용의 간단한 예

19.2.1. 로그 수준 및 출력 대상 변경

wsdl_first 샘플 애플리케이션에서 로그 메시지의 로그 수준 및 출력 대상을 변경하려면 다음 단계를 완료합니다.

  1. InstallDir/samples/wsdl_first 디렉터리에 있는 README.txt 파일의 java 섹션을 사용하여 데모 실행에 설명된 대로 샘플 서버를 실행합니다. server start 명령은 다음과 같이 기본 logging.properties 파일을 지정합니다.

    플랫폼명령 +

    Windows

    Java -Djava.util.config.file=%CXF_HOME%\etc\logging.properties demo.hw.server.Server를 시작합니다.

    +

    UNIX

    java -Djava.util.logging.config.file=$CXF_HOME/etc/logging.properties demo.hw.server.Server &

    +

    기본 logging.properties 파일은 InstallDir/etc 디렉터리에 있습니다. Apache CXF 로거를 구성하여 WARNING 수준 로그 메시지를 콘솔에 인쇄합니다. 따라서 콘솔에 거의 인쇄되지 않습니다.

  2. README.txt 파일에 설명된 대로 서버를 중지합니다.
  3. 기본 logging.properties 파일의 사본을 만들고 mylogging.properties 파일의 이름을 지정하고 기본 logging.properties 파일과 동일한 디렉토리에 저장합니다.
  4. 다음 구성 행을 편집하여 글로벌 로깅 수준 및 mylogging.properties 파일의 콘솔 로깅 수준을 INFO 로 변경합니다.

    .level= INFO
    java.util.logging.ConsoleHandler.level = INFO
  5. 다음 명령을 사용하여 서버를 다시 시작합니다.

    플랫폼명령 +

    Windows

    Java -Djava.util.config.file=%CXF_HOME%\etc\mylogging.properties demo.hw.server.Server를 시작합니다.

    +

    UNIX

    Java -Djava.util.config.file=$CXF_HOME/etc/mylogging.properties demo.hw.server.Server &

    +

    수준 INFO 의 메시지를 기록하도록 글로벌 로깅 및 콘솔 로거를 구성했기 때문에 콘솔에 인쇄된 더 많은 로그 메시지가 표시됩니다.

19.3. 기본 로깅 구성 파일

19.3.1. 로깅 구성 개요

기본 로깅 구성 파일 logging.propertiesInstallDir/etc 디렉터리에 있습니다. Apache CXF 로거를 구성하여 경고 수준 메시지를 콘솔에 인쇄합니다. 이 수준의 로깅이 애플리케이션에 적합한 경우 사용하기 전에 파일을 변경할 필요가 없습니다. 그러나 로그 메시지의 세부 수준을 변경할 수 있습니다. 예를 들어 로그 메시지가 콘솔로 전송되는지, 파일 또는 둘 다로 전송되는지 여부를 변경할 수 있습니다. 또한 개별 패키지 수준에서 로깅을 지정할 수 있습니다.

참고

이 섹션에서는 기본 logging.properties 파일에 표시되는 구성 속성에 대해 설명합니다. 그러나 설정할 수 있는 다른 많은 java.util.logging 구성 속성이 있습니다. java.util.logging API에 대한 자세한 내용은 java.util.logging javadoc at: http://download.oracle.com/javase/1.5/docs/api/java/util/logging/package-summary.html 을 참조하십시오.

19.3.2. 로깅 출력 구성

19.3.2.1. 개요

Java 로깅 유틸리티인 java.util.logging 은 핸들러 클래스를 사용하여 로그 메시지를 출력합니다. 표 19.1. “java.util.logging Handler 클래스” 는 기본 logging.properties 파일에 구성된 핸들러를 보여줍니다.

표 19.1. java.util.logging Handler 클래스
처리기 클래스다음에 대한 출력

ConsoleHandler

콘솔에 로그 메시지 출력

FileHandler

파일에 로그 메시지 출력

중요

처리기 클래스는 시작될 때 Java VM에 의해 설치되려면 시스템 클래스 경로에 있어야 합니다. 이 작업은 Apache CXF 환경을 설정할 때 수행됩니다.

19.3.2.2. 콘솔 핸들러 구성

예 19.2. “콘솔 핸들러 구성” 콘솔 로거를 구성하는 코드를 보여줍니다.

예 19.2. 콘솔 핸들러 구성

handlers= java.util.logging.ConsoleHandler

콘솔 처리기는 예 19.3. “콘솔 핸들러 속성” 에 표시된 구성 속성도 지원합니다.

예 19.3. 콘솔 핸들러 속성

java.util.logging.ConsoleHandler.level = WARNING
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

예 19.3. “콘솔 핸들러 속성” 에 표시된 구성 속성은 다음과 같이 설명할 수 있습니다.

콘솔 핸들러는 별도의 로그 수준 구성 속성을 지원합니다. 이를 통해 글로벌 로깅 설정이 다를 수 있는 동안 콘솔에 인쇄된 로그 메시지를 제한할 수 있습니다( 19.3.3절. “로깅 수준 구성”참조). 기본 설정은 WARNING 입니다.

콘솔 처리기 클래스에서 로그 메시지를 포맷하는 데 사용하는 java.util.logging formatter 클래스를 지정합니다. 기본 설정은 java.util.logging.SimpleFormatter 입니다.

19.3.2.3. 파일 핸들러 구성

예 19.4. “파일 핸들러 구성” 파일 핸들러를 구성하는 코드를 보여줍니다.

예 19.4. 파일 핸들러 구성

handlers= java.util.logging.FileHandler

파일 핸들러는 예 19.5. “파일 핸들러 구성 속성” 에 표시된 구성 속성도 지원합니다.

예 19.5. 파일 핸들러 구성 속성

java.util.logging.FileHandler.pattern = %h/java%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter

예 19.5. “파일 핸들러 구성 속성” 에 표시된 구성 속성은 다음과 같이 설명할 수 있습니다.

출력 파일의 위치 및 패턴을 지정합니다. 기본 설정은 홈 디렉토리입니다.

로거가 하나의 파일에 쓰는 최대 양을 바이트 단위로 지정합니다. 기본 설정은 50000 입니다. 이를 0으로 설정하면 로거가 하나의 파일에 쓰는 양에 제한이 없습니다.

사이클할 출력 파일 수를 지정합니다. 기본 설정은 1 입니다.

파일 처리기 클래스에서 로그 메시지를 포맷하는 데 사용하는 java.util.logging formatter 클래스를 지정합니다. 기본 설정은 java.util.logging.XMLFormatter 입니다.

19.3.2.4. 콘솔 핸들러와 파일 핸들러 모두 구성

콘솔 처리기와 파일 핸들러를 콘솔 로깅 및 파일 모두 구성 와 같이 쉼표로 구분하여 지정하여 콘솔 및 파일에 로그 메시지를 출력하도록 logging 유틸리티를 설정할 수 있습니다.

콘솔 로깅 및 파일 모두 구성

Logging

handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler

19.3.3. 로깅 수준 구성

19.3.3.1. 로깅 수준

java.util.logging 프레임워크는 최소 세부 정보에서 가장 자세한 정보까지 다음과 같은 로깅 수준을 지원합니다.

  • SEVERE
  • WARNING
  • INFO
  • CONFIG
  • FINE
  • FINER
  • FINEST

19.3.3.2. 글로벌 로깅 수준 구성

모든 로거에 기록된 이벤트 유형을 구성하려면 예 19.6. “글로벌 로깅 수준 구성” 에 표시된 대로 글로벌 로깅 수준을 구성합니다.

예 19.6. 글로벌 로깅 수준 구성

.level= WARNING

19.3.3.3. 개별 패키지에서 로깅 구성

level

java.util.logging 프레임워크는 개별 패키지 수준에서 로깅 구성을 지원합니다. 예를 들어 예 19.7. “패키지 수준에서 로깅 구성” 에 표시된 코드 줄은 com.xyz.foo 패키지의 클래스의 SEVERE 수준에서 로깅을 구성합니다.

예 19.7. 패키지 수준에서 로깅 구성

com.xyz.foo.level = SEVERE

19.4. 명령줄에서 로깅 활성화

19.4.1. 개요

애플리케이션을 시작할 때 java.util.logging.config.file 속성을 정의하여 애플리케이션에서 로깅 유틸리티를 실행할 수 있습니다. 기본 logging.properties 파일 또는 해당 애플리케이션에 고유한 logging.properties 파일을 지정할 수 있습니다.

19.4.2. 애플리케이션에서 로그 구성 파일 지정

start-up

애플리케이션 시작 시 로깅을 지정하려면 애플리케이션을 시작할 때 예 19.8. “명령줄에서 로깅 시작 플래그” 에 표시된 플래그를 추가합니다.

예 19.8. 명령줄에서 로깅 시작 플래그

-Djava.util.logging.config.file=myfile

19.5. 하위 시스템 및 서비스에 대한 로깅

19.5.1. 개요

“개별 패키지에서 로깅 구성” 에 설명된 com.xyz.foo.level 구성 속성을 사용하여 지정된 Apache CXF 로깅 하위 시스템에 대한 세분화된 로깅을 설정할 수 있습니다.

19.5.2. Apache CXF 로깅 하위 시스템

표 19.2. “Apache CXF 로깅 하위 시스템” 사용 가능한 Apache CXF 로깅 하위 시스템 목록을 표시합니다.

표 19.2. Apache CXF 로깅 하위 시스템
하위 시스템설명

org.apache.cxf.aegis

Aegis 바인딩

org.apache.cxf.binding.coloc

공동 배치 바인딩

org.apache.cxf.binding.http

HTTP 바인딩

org.apache.cxf.binding.jbi

JBI 바인딩

org.apache.cxf.binding.object

Java 오브젝트 바인딩

org.apache.cxf.binding.soap

SOAP 바인딩

org.apache.cxf.binding.xml

XML 바인딩

org.apache.cxf.bus

Apache CXF 버스

org.apache.cxf.configuration

구성 프레임워크

org.apache.cxf.endpoint

서버 및 클라이언트 끝점

org.apache.cxf.interceptor

인터셉터

org.apache.cxf.jaxws

JAX-WS 스타일 메시지 교환, JAX-WS 핸들러 처리, JAX-WS 및 구성과 관련된 인터셉터

org.apache.cxf.jbi

JBI 컨테이너 통합 클래스

org.apache.cxf.jca

JCA 컨테이너 통합 클래스

org.apache.cxf.js

JavaScript 프론트 엔드

org.apache.cxf.transport.http

HTTP 전송

org.apache.cxf.transport.https

HTTPS를 사용하여 HTTP 전송의 보안 버전

org.apache.cxf.transport.jbi

JBI 전송

org.apache.cxf.transport.jms

JMS 전송

org.apache.cxf.transport.local

로컬 파일 시스템을 사용하는 전송 구현

org.apache.cxf.transport.servlet

JAX-WS 엔드포인트를 서블릿 컨테이너에 로드하기 위한 HTTP 전송 및 서블릿 구현

org.apache.cxf.ws.addressing

WS-Addressing 구현

org.apache.cxf.ws.policy

WS-Policy 구현

org.apache.cxf.ws.rm

WS-ReliableMessaging (WS-RM) 구현

org.apache.cxf.ws.security.wss4j

WSS4J 보안 구현

19.5.3. 예제

WS-Addressing 샘플은 InstallDir/samples/ws_addressing 디렉터리에 포함되어 있습니다. 로깅은 해당 디렉터리에 있는 logging.properties 파일에서 구성됩니다. 관련 구성 행은 예 19.9. “WS-Addressing에 대한 로깅 구성” 에 표시되어 있습니다.

예 19.9. WS-Addressing에 대한 로깅 구성

java.util.logging.ConsoleHandler.formatter = demos.ws_addressing.common.ConciseFormatter
...
org.apache.cxf.ws.addressing.soap.MAPCodec.level = INFO

예 19.9. “WS-Addressing에 대한 로깅 구성” 의 구성은 WS-Addressing 헤더와 관련된 로그 메시지를 스누핑할 수 있으며 콘솔에 간결한 형식으로 표시할 수 있습니다.

이 샘플 실행에 대한 자세한 내용은 InstallDir/samples/ws_addressing 디렉터리에 있는 README.txt 파일을 참조하십시오.

19.6. 메시지 콘텐츠 로깅

19.6.1. 개요

서비스와 소비자 간에 전송되는 메시지의 콘텐츠를 기록할 수 있습니다. 예를 들어 서비스와 소비자 간에 전송되는 SOAP 메시지의 콘텐츠를 로깅할 수 있습니다.For example, you might want to log the contents of SOAP messages that are being sent between a service and a consumer.

19.6.2. 메시지 콘텐츠 로깅 구성

서비스와 소비자 간에 전송되는 메시지를 로깅하고 그 반대의 경우도 마찬가지이면 다음 단계를 완료합니다.

19.6.3. 끝점에 로깅 기능 추가

예 19.10. “끝점 구성에 로깅 추가” 에 표시된 대로 엔드 포인트의 구성에 로깅 기능을 추가합니다.

예 19.10. 끝점 구성에 로깅 추가

<jaxws:endpoint ...>
  <jaxws:features>
    <bean class="org.apache.cxf.feature.LoggingFeature"/>
  </jaxws:features>
</jaxws:endpoint>

예 19.10. “끝점 구성에 로깅 추가” 에 표시된 XML 예제를 사용하면 SOAP 메시지 로깅을 사용할 수 있습니다.

19.6.4. 소비자에게 로깅 기능 추가

클라이언트 구성이 예 19.11. “클라이언트 구성에 로깅 추가” 와 같이 로깅 기능을 추가합니다.

예 19.11. 클라이언트 구성에 로깅 추가

<jaxws:client ...>
   <jaxws:features>
      <bean class="org.apache.cxf.feature.LoggingFeature"/>
    </jaxws:features>
</jaxws:client>

예 19.11. “클라이언트 구성에 로깅 추가” 에 표시된 XML 예제를 사용하면 SOAP 메시지 로깅을 사용할 수 있습니다.

19.6.5. 로깅을 log INFO 수준 메시지로 설정

서비스와 관련된 logging.properties 파일이 예 19.12. “로깅 수준을 INFO로 설정” 와 같이 INFO 수준 메시지를 기록하도록 구성되어 있는지 확인합니다.

예 19.12. 로깅 수준을 INFO로 설정

.level= INFO
java.util.logging.ConsoleHandler.level = INFO

19.6.6. SOAP 메시지 로깅

SOAP 메시지의 로깅을 보려면 InstallDir/samples/wsdl_first 디렉터리에 있는 wsdl_first 샘플 애플리케이션을 다음과 같이 수정합니다.

  1. 예 19.13. “로깅에 대한 엔드 포인트 구성 SOAP 메시지” 에 표시된 jaxws:features 요소를 wsdl_first 샘플 디렉터리에 있는 cxf.xml 구성 파일에 추가합니다.

    예 19.13. 로깅에 대한 엔드 포인트 구성 SOAP 메시지

    <jaxws:endpoint name="{http://apache.org/hello_world_soap_http}SoapPort"
                    createdFromAPI="true">
      <jaxws:properties>
        <entry key="schema-validation-enabled" value="true" />
      </jaxws:properties>
      <jaxws:features>
        <bean class="org.apache.cxf.feature.LoggingFeature"/>
      </jaxws:features>
    </jaxws:endpoint>
  2. 샘플은 InstallDir/etc 디렉터리에 있는 기본 logging.properties 파일을 사용합니다. 이 파일의 사본을 만들고 이름을 mylogging.properties 로 지정합니다.
  3. mylogging.properties 파일에서 .level 및 java.util.logging.ConsoleHandler .level 구성 속성을 다음과 같이 편집하여 로깅 수준을 INFO 로 변경합니다.

    .level= INFO
    java.util.logging.ConsoleHandler.level = INFO
  4. 다음과 같이 cxf.xml 파일과 mylogging.properties 파일의 새 구성 설정을 사용하여 서버를 시작합니다.

    플랫폼명령 +

    Windows

    Java -Djava.util.config.file=%CXF_HOME%\etc\mylogging.properties demo.hw.server.Server를 시작합니다.

    +

    UNIX

    Java -Djava.util.config.file=$CXF_HOME/etc/mylogging.properties demo.hw.server.Server &

    +

  5. 다음 명령을 사용하여 hello world 클라이언트를 시작합니다.

    플랫폼명령 +

    Windows

    Java -Djava.util.config.file=%CXF_HOME%\etc\mylogging.properties demo.hw.client.Client .\wsdl\hello_world.wsdl

    +

    UNIX

    Java -Djava.util.config.file=$CXF_HOME/etc/mylogging.properties demo.hw.client.Client ./wsdl/hello_world.wsdl

    +

SOAP 메시지는 콘솔에 기록됩니다.

20장. WS-Addressing 배포

초록

Apache CXF는 JAX-WS 애플리케이션에 대해 WS-Addressing을 지원합니다. 이 장에서는 Apache CXF 런타임 환경에 WS-Addressing을 배포하는 방법을 설명합니다.

20.1. WS-Addressing 소개

20.1.1. 개요

WS-Addressing은 서비스가 전송 중립적인 방식으로 주소 지정 정보를 통신할 수 있도록 하는 사양입니다. 그것은 두 부분으로 구성되어 있습니다:

  • 웹 서비스 끝점에 참조를 전달하는 구조
  • 특정 메시지와 주소 지정 정보를 연결하는 MAP(Message Addressing Properties) 세트

20.1.2. 지원되는 사양

Apache CXF는 WS-Addressing 2004/08 사양과 WS-Addressing 2005/03 사양을 모두 지원합니다.

20.1.3. 더 많은 정보

WS-Addressing에 대한 자세한 내용은 2004/08 제출 ( http://www.w3.org/Submission/ws-addressing/ 참조하십시오.

20.2. WS-Addressing Interceptors

20.2.1. 개요

Apache CXF에서는 WS-Addressing 기능이 인터셉터로 구현됩니다. Apache CXF 런타임은 인터셉터를 사용하여 전송 및 수신되는 원시 메시지를 가로채고 작업합니다. 전송에서 메시지를 수신하면 메시지 오브젝트를 생성하고 인터셉터 체인을 통해 해당 메시지를 전송합니다. 애플리케이션 인터셉터 체인에 WS-Addressing 인터셉터가 추가되면 메시지에 포함된 WS-Addressing 정보가 처리됩니다.

20.2.2. WS-Addressing Interceptors

WS-Addressing 구현은 표 20.1. “WS-Addressing Interceptors” 에 설명된 대로 두 개의 인터셉터로 구성됩니다.

표 20.1. WS-Addressing Interceptors
인터셉터설명

org.apache.cxf.ws.addressing.MAPAggregator

발신 메시지의MAP(Message Addressing Properties)를 집계하는 논리 인터셉터입니다.

org.apache.cxf.ws.addressing.soap.MAPCodec

메시지 주소 지정 속성(MAP)을 SOAP 헤더로 인코딩하고 디코딩해야 하는 프로토콜별 인터셉터입니다.

20.3. WS-Addressing 활성화

20.3.1. 개요

WS-Addressing 인터셉터를 활성화하려면 인바운드 및 아웃바운드 인터셉터 체인에 WS-Addressing 인터셉터를 추가해야 합니다. 이 작업은 다음 방법 중 하나로 수행됩니다.

  • Apache CXF 기능
  • RMAssertion 및 WS-Policy Framework
  • WS-Addressing 기능에서 Policy assertionion 사용

20.3.2. WS-Addressing을 기능으로 추가

WS-Addressing은 각각 예 20.1. “client.xml 및 클라이언트 구성에 WS-Addressing 기능 추가”예 20.2. “server.xml 및 서버 구성에 WS-Addressing 기능 추가” 과 같이 클라이언트 및 서버 구성에 WS-Addressing 기능을 추가하여 활성화할 수 있습니다.

예 20.1. client.xml 및 클라이언트 구성에 WS-Addressing 기능 추가

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jaxws="http://cxf.apache.org/jaxws"
       xmlns:wsa="http://cxf.apache.org/ws/addressing"
       xsi:schemaLocation="
          http://www.springframework.org/schema/beans
          http://www.springframework.org/schema/beans/spring-beans.xsd
          http://cxf.apache.org/ws/addressing
          http://cxf.apache.org/schemas/ws-addr-conf.xsd">

    <jaxws:client ...>
        <jaxws:features>
            <wsa:addressing/>
        </jaxws:features>
    </jaxws:client>
</beans>

예 20.2. server.xml 및 서버 구성에 WS-Addressing 기능 추가

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jaxws="http://cxf.apache.org/jaxws"
       xmlns:wsa="http://cxf.apache.org/ws/addressing"
       xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <jaxws:endpoint ...>
        <jaxws:features>
            <wsa:addressing/>
        </jaxws:features>
    </jaxws:endpoint>
</beans>

20.4. WS-Addressing Attributes 구성

20.4.1. 개요

Apache CXF WS-Addressing 기능 요소는 네임스페이스 http://cxf.apache.org/ws/addressing. 표 20.2. “WS-Addressing Attributes” 에 설명된 두 가지 속성을 지원합니다.

표 20.2. WS-Addressing Attributes
특성 이름

allowDuplicates

중복 MessageID가 허용되는지 여부를 결정하는 부울입니다. 기본 설정은 true 입니다.

usingAddressingAdvisory

WSDL에 UsingAddressing 요소의 존재 여부를 나타내는 부울은 권고만 합니다. 즉, WS-Addressing 헤더의 인코딩을 방지하지 않습니다.

20.4.2. WS-Addressing 속성 구성

서버 또는 클라이언트 구성 파일의 WS-Addressing 기능으로 설정하려는 속성 및 값을 추가하여 WS-Addressing 특성을 구성합니다. 예를 들어 다음 구성 추출에서는 서버 끝점에서 allowDuplicates 특성을 false 로 설정합니다.

<beans ... xmlns:wsa="http://cxf.apache.org/ws/addressing" ...>
    <jaxws:endpoint ...>
        <jaxws:features>
            <wsa:addressing allowDuplicates="false"/>
        </jaxws:features>
    </jaxws:endpoint>
</beans>

20.4.3. 기능에 포함된 WS-Policy 어설션 사용

예 20.3. “정책을 사용하여 WS-Addressing 구성” 에서 비익명 응답을 활성화하는 주소 지정 정책 어설션이 정책 요소에 포함됩니다.

예 20.3. 정책을 사용하여 WS-Addressing 구성

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:wsa="http://cxf.apache.org/ws/addressing"
        xmlns:wsp="http://www.w3.org/2006/07/ws-policy"
        xmlns:policy="http://cxf.apache.org/policy-config"
        xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
        xmlns:jaxws="http://cxf.apache.org/jaxws"
        xsi:schemaLocation="
http://www.w3.org/2006/07/ws-policy http://www.w3.org/2006/07/ws-policy.xsd
http://cxf.apache.org/ws/addressing http://cxf.apache.org/schema/ws/addressing.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <jaxws:endpoint name="{http://cxf.apache.org/greeter_control}GreeterPort"
                    createdFromAPI="true">
        <jaxws:features>
            <policy:policies>
                <wsp:Policy xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata">
                    <wsam:Addressing>
                        <wsp:Policy>
                            <wsam:NonAnonymousResponses/>
                        </wsp:Policy>
                    </wsam:Addressing>
                </wsp:Policy>
            <policy:policies>
        </jaxws:features>
    </jaxws:endpoint>
</beans>

21장. 신뢰할 수 있는 메시징 활성화

초록

Apache CXF는 WS-Reliable Messaging(WS-RM)을 지원합니다. 이 장에서는 Apache CXF에서 WS-RM을 활성화하고 구성하는 방법을 설명합니다.

21.1. WS-RM 소개

21.1.1. 개요

WS-ReliableMessaging (WS-RM)은 분산된 환경에서 메시지의 안정적인 전달을 보장하는 프로토콜입니다. 이를 통해 소프트웨어, 시스템 또는 네트워크 오류가 발생할 경우 분산 애플리케이션 간에 메시지를 안정적으로 전달할 수 있습니다.

예를 들어 WS-RM을 사용하면 올바른 메시지가 정확하게 한 번 올바르게 네트워크에 전달되었는지 확인할 수 있습니다.

21.1.2. WS-RM의 작동 방식

WS-RM은 소스와 대상 끝점 간 메시지의 안정적인 전달을 보장합니다. 소스는 메시지의 초기 발신자이고 대상은 그림 21.1. “웹 서비스 신뢰할 수 있는 메시징” 에 표시된 대로 궁극적인 수신자입니다.

그림 21.1. 웹 서비스 신뢰할 수 있는 메시징

신뢰할 수 있는 메시지 교환

WS-RM 메시지 흐름은 다음과 같이 설명될 수 있습니다.

  1. RM 소스는 CreateSequence 프로토콜 메시지를 RM 대상으로 보냅니다. 여기에는 승인을 받는 끝점에 대한 참조( wsrm:AcksTo 끝점)가 포함되어 있습니다.
  2. RM 대상은 CreateSequenceResponse 프로토콜 메시지를 다시 RM 소스로 보냅니다. 이 메시지에는 RM 시퀀스 세션의 시퀀스 ID가 포함되어 있습니다.
  3. RM 소스는 애플리케이션 소스에서 보낸 각 메시지에 RM Sequence 헤더를 추가합니다. 이 헤더에는 시퀀스 ID와 고유한 메시지 ID가 포함됩니다.
  4. RM 소스는 각 메시지를 RM 대상으로 전송합니다.
  5. RM 대상은 RM SequenceAcknowledgement 헤더가 포함된 메시지를 전송하여 RM 소스에서 메시지 수신을 확인합니다.
  6. RM 대상은 정확히 순서 방식으로 애플리케이션 대상에 메시지를 전달합니다.
  7. RM 소스는 아직 승인을 받지 못한 메시지를 다시 전송합니다.

    첫 번째 재전송 시도는 기본 재전송 간격 후에 수행됩니다. 연속 재전송 시도는 기본적으로 기하급수 백오프 간격 또는 고정된 간격으로 수행됩니다. 자세한 내용은 21.5절. “WS-RM 구성” 에서 참조하십시오.

이 전체 프로세스는 요청 및 응답 메시지에 대해 대칭적으로 발생합니다. 즉, 응답 메시지의 경우 서버는 RM 소스의 역할을 하고 클라이언트는 RM 대상의 역할을 합니다.

21.1.3. WS-RM 제공 보장

WS-RM은 사용된 전송 프로토콜에 관계없이 분산된 환경에서 안정적인 메시지 전달을 보장합니다. 신뢰할 수 있는 전달을 보장할 수 없는 경우 소스 또는 대상 끝점에서 오류를 기록합니다.

21.1.4. 지원되는 사양

Apache CXF는 다음 버전의 WS-RM 사양을 지원합니다.

WS-ReliableMessaging 1.0

(기본값) 2005년 2월의 후보 접수 버전을 종료했으며, 현재 출시되지 않았습니다. 그러나 이전 버전과의 호환성을 이유로 이 버전은 기본값으로 사용됩니다.

WS-RM 버전 1.0에서는 다음 네임스페이스를 사용합니다.

http://schemas.xmlsoap.org/ws/2005/02/rm/

WS-RM의 이 버전은 다음 WS-Addressing 버전 중 하나와 함께 사용할 수 있습니다.

http://schemas.xmlsoap.org/ws/2004/08/addressing (default)
http://www.w3.org/2005/08/addressing

WS-RM의 2005년 2월 릴리스 버전을 준수하기 위해 이러한 WS-Addressing 버전(Apache CXF의 기본값) 중 첫 번째 버전을 사용해야 합니다. 그러나 대부분의 다른 웹 서비스 구현에서는 최근에 WS-Addressing 사양으로 전환되어 Apache CXF를 사용하면 WS-A 버전을 선택하여 상호 운용성을 원활하게 수행할 수 있습니다. 21.4절. “런타임 제어”

WS-ReliableMessaging 1.1/1.2

1.1/1.2 Web Services Reliable Messaging 사양에 해당합니다.

WS-RM 버전 1.1 및 1.2에서는 다음 네임스페이스를 사용합니다.

http://docs.oasis-open.org/ws-rx/wsrm/200702

WS-RM의 1.1 및 1.2 버전에서는 다음 WS-Addressing 버전을 사용합니다.

http://www.w3.org/2005/08/addressing

21.1.5. WS-RM 버전 선택

다음과 같이 사용할 WS-RM 사양 버전을 선택할 수 있습니다.

서버 측
공급자 측면에서 Apache CXF는 클라이언트에서 WS-ReliableMessaging을 사용하는 모든 버전에 적응하고 적절하게 응답합니다.
고객 측면
클라이언트 측에서 WS-RM 버전은 클라이언트 구성에서 사용하는 네임스페이스에 의해 결정되거나( 21.5절. “WS-RM 구성”참조) 런타임 제어 옵션을 사용하여 런타임에 WS-RM 버전을 재정의하여 결정됩니다( 21.4절. “런타임 제어”참조).

21.2. WS-RM 인터셉터

21.2.1. 개요

Apache CXF에서는 WS-RM 기능이 인터셉터로 구현됩니다. Apache CXF 런타임은 인터셉터를 사용하여 전송 및 수신되는 원시 메시지를 가로채고 작업합니다. 전송에서 메시지를 수신하면 메시지 오브젝트를 생성하고 인터셉터 체인을 통해 해당 메시지를 전송합니다. 애플리케이션의 인터셉터 체인에 WS-RM 인터셉터가 포함된 경우 애플리케이션은 신뢰할 수 있는 메시징 세션에 참여할 수 있습니다. WS-RM 인터셉터는 메시지 청크의 수집 및 집계를 처리합니다. 또한 모든 승인 및 재전송 논리를 처리합니다.

21.2.2. Apache CXF WS-RM 인터셉터

Apache CXF WS-RM 구현은 4개의 인터셉터로 구성되어 있으며, 이는 표 21.1. “Apache CXF WS-ReliableMessaging Interceptors” 에 설명되어 있습니다.

표 21.1. Apache CXF WS-ReliableMessaging Interceptors
인터셉터설명

org.apache.cxf.ws.rm.RMOutInterceptor

발신 메시지에 대한 신뢰성 보장을 제공하는 논리적인 측면을 다룹니다.

CreateSequence 요청을 보내고 CreateSequenceResponse 응답을 기다립니다.

애플리케이션 메시지의 시퀀스 속성-ID 및 메시지 번호 집계를 담당합니다.Also responsible for agggregating the sequence properties-ID and message number-for an application message.

org.apache.cxf.ws.rm.RMInInterceptor

애플리케이션 메시지에서 금지된 RM 프로토콜 메시지 및 시퀀스Acknowledgement 메시지를 가로채기 및 처리할 책임이 있습니다.

org.apache.cxf.ws.rm.RMCaptureInInterceptor

영구 스토리지의 수신 메시지를 캐싱합니다.

org.apache.cxf.ws.rm.RMDeliveryInterceptor

애플리케이션에 대한 InOrder 메시지 제공.

org.apache.cxf.ws.rm.soap.RMSoapInterceptor

신뢰성 속성을 SOAP 헤더로 인코딩 및 디코딩해야 합니다.

org.apache.cxf.ws.rm.RetransmissionInterceptor

나중에 다시 전송할 수 있도록 애플리케이션 메시지의 복사본을 생성합니다.

21.2.3. WS-RM 활성화

인터셉터 체인에 WS-RM 인터셉터가 있으면 필요한 경우 WS-RM 프로토콜 메시지가 교환됩니다. 예를 들어 아웃바운드 인터셉터 체인에서 첫 번째 애플리케이션 메시지를 가로채는 경우 RMOutInterceptorCreateSequence 요청을 보내고 CreateSequenceResponse 응답을 수신할 때까지 원래 애플리케이션 메시지를 처리하도록 기다립니다. 또한 WS-RM 인터셉터는 애플리케이션 메시지에 시퀀스 헤더를 추가하고 대상 측에서 메시지를 추출합니다. 메시지를 안정적으로 교환하기 위해 애플리케이션 코드를 변경할 필요가 없습니다.

WS-RM을 활성화하는 방법에 대한 자세한 내용은 21.3절. “WS-RM 활성화” 을 참조하십시오.

21.2.4. WS-RM 속성 구성

구성을 통해 시퀀스 분리 및 신뢰할 수 있는 교환의 다른 측면을 제어합니다. 예를 들어 기본적으로 Apache CXF는 시퀀스의 수명을 최대화하려고 하므로 대역 외 WS-RM 프로토콜 메시지로 인한 오버헤드가 감소합니다. 애플리케이션 메시지당 별도의 시퀀스를 사용하도록 하려면 WS-RM 소스의 시퀀스 종료 정책(최대 시퀀스 길이를 1로 설정)을 구성합니다.

WS-RM 동작 구성에 대한 자세한 내용은 21.5절. “WS-RM 구성” 을 참조하십시오.

21.3. WS-RM 활성화

21.3.1. 개요

안정적인 메시징을 활성화하려면 인바운드 및 아웃바운드 메시지 및 결함 모두에 대해 인터셉터 체인에 WS-RM 인터셉터를 추가해야 합니다. WS-RM 인터셉터는 WS-Addressing 인터셉터를 사용하므로 인터셉터 체인에 WS-Addressing 인터셉터도 있어야 합니다.

다음 두 가지 방법 중 하나로 이러한 인터셉터가 있는지 확인할 수 있습니다.

  • 명시적으로 Spring 빈을 사용하여 디스패치 체인에 추가하여
  • 암시적 으로 WS-Policy 어설션을 사용하여 Apache CXF 런타임이 사용자를 대신하여 인터셉터를 투명하게 추가합니다.

21.3.2. Spring bean: 인터셉터를 명시적으로 추가합니다.

WS-RM을 활성화하려면 Apache CXF 버스 또는 Spring 빈 구성을 사용하여 소비자 또는 서비스 엔드포인트에 WS-RM 및 WS-Addressing 인터셉터를 추가합니다. 이 방법은 InstallDir/samples/ws_rm 디렉터리에 있는 WS-RM 샘플에서 가져온 접근 방식입니다. 구성 파일 ws-rm.cxf 는 Spring 빈으로 일대일로 추가된 WS-RM 및 WS-Addressing 인터셉터를 보여줍니다( 예 21.1. “Spring Bean을 사용하여 WS-RM 활성화”참조).

예 21.1. Spring Bean을 사용하여 WS-RM 활성화

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/
   beans http://www.springframework.org/schema/beans/spring-beans.xsd">
   <bean id="mapAggregator" class="org.apache.cxf.ws.addressing.MAPAggregator"/>
   <bean id="mapCodec" class="org.apache.cxf.ws.addressing.soap.MAPCodec"/>
   <bean id="rmLogicalOut" class="org.apache.cxf.ws.rm.RMOutInterceptor">
        <property name="bus" ref="cxf"/>
   </bean>
   <bean id="rmLogicalIn" class="org.apache.cxf.ws.rm.RMInInterceptor">
        <property name="bus" ref="cxf"/>
   </bean>
   <bean id="rmCodec" class="org.apache.cxf.ws.rm.soap.RMSoapInterceptor"/>
   <bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
        <property name="inInterceptors">
            <list>
                <ref bean="mapAggregator"/>
                <ref bean="mapCodec"/>
                <ref bean="rmLogicalIn"/>
                <ref bean="rmCodec"/>
            </list>
        </property>
        <property name="inFaultInterceptors">
            <list>
                <ref bean="mapAggregator"/>
                <ref bean="mapCodec"/>
                <ref bean="rmLogicalIn"/>
                <ref bean="rmCodec"/>
            </list>
        </property>
        <property name="outInterceptors">
            <list>
                <ref bean="mapAggregator"/>
                <ref bean="mapCodec"/>
                <ref bean="rmLogicalOut"/>
                <ref bean="rmCodec"/>
            </list>
        </property>
        <property name="outFaultInterceptors">
            <list>
                <ref bean="mapAggregator">
                <ref bean="mapCodec"/>
                <ref bean="rmLogicalOut"/>
                <ref bean="rmCodec"/>
            </list>
        </property>
    </bean>
</beans>

예 21.1. “Spring Bean을 사용하여 WS-RM 활성화” 에 표시된 코드는 다음과 같이 설명될 수 있습니다.

Apache CXF 구성 파일은 Spring XML 파일입니다. 빈 요소에서 캡슐화된 하위 요소 의 네임스페이스 및 스키마 파일을 선언하는 여는 Spring 빈 요소를 포함해야 합니다.

각 WS-Addressing 인터셉터-MAPAggregatorMAPCodec 를 구성합니다. WS-Addressing에 대한 자세한 내용은 20장. WS-Addressing 배포 을 참조하십시오.

각 WS-RM 인터셉터-RMOutInterceptor,RMInInterceptorRMSoapInterceptor 를 설정합니다.

인바운드 메시지의 인터셉터 체인에 WS-Addressing 및 WS-RM 인터셉터를 추가합니다.

인바운드 결함을 위해 WS-Addressing 및 WS-RM 인터셉터를 인터셉터 체인에 추가합니다.

아웃바운드 메시지의 인터셉터 체인에 WS-Addressing 및 WS-RM 인터셉터를 추가합니다.

아웃바운드 결함의 인터셉터 체인에 WS-Addressing 및 WS-RM 인터셉터를 추가합니다.

21.3.3. WS-Policy 프레임워크: 암시적으로 인터셉터 추가

WS-Policy 프레임워크는 WS-Policy를 사용할 수 있는 인프라 및 API를 제공합니다. 이는 2006년 11월 Web Services Policy 1.5-FrameworkWeb Services Policy 1.5-Attachment 사양의 초안 발행물과 호환됩니다.

Apache CXF WS-Policy 프레임워크를 사용하여 WS-RM을 활성화하려면 다음을 수행합니다.

  1. 정책 기능을 클라이언트 및 서버 엔드포인트에 추가합니다. 예 21.2. “WS-Policy를 사용하여 WS-RM 구성” jaxws:feature 요소에 중첩된 참조 빈을 표시합니다. 참조 빈에서는 동일한 구성 파일 내의 별도의 요소로 정의된 AddressingPolicy 를 지정합니다.

    예 21.2. WS-Policy를 사용하여 WS-RM 구성

    <jaxws:client>
        <jaxws:features>
          <ref bean="AddressingPolicy"/>
        </jaxws:features>
    </jaxws:client>
    <wsp:Policy wsu:Id="AddressingPolicy" xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata">
        <wsam:Addressing>
          <wsp:Policy>
            <wsam:NonAnonymousResponses/>
          </wsp:Policy>
        </wsam:Addressing>
    </wsp:Policy>
  2. 예 21.3. “귀하의 WSDL 파일에 RM 정책 추가” 에 표시된 대로 정책 또는 정책 참조 요소의 연결 지점으로 사용할 수 있는 wsdl:service 요소 또는 기타 WSDL 요소에 안정적인 메시징 정책을 추가합니다.

    예 21.3. 귀하의 WSDL 파일에 RM 정책 추가

    <wsp:Policy wsu:Id="RM"
       xmlns:wsp="http://www.w3.org/2006/07/ws-policy"
       xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
        <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata">
            <wsp:Policy/>
        </wsam:Addressing>
        <wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
            <wsrmp:BaseRetransmissionInterval Milliseconds="10000"/>
        </wsrmp:RMAssertion>
    </wsp:Policy>
    ...
    <wsdl:service name="ReliableGreeterService">
        <wsdl:port binding="tns:GreeterSOAPBinding" name="GreeterPort">
            <soap:address location="http://localhost:9020/SoapContext/GreeterPort"/>
            <wsp:PolicyReference URI="#RM" xmlns:wsp="http://www.w3.org/2006/07/ws-policy"/>
        </wsdl:port>
    </wsdl:service>

21.4. 런타임 제어

21.4.1. 개요

런타임 시 WS-RM을 제어하기 위해 클라이언트 코드에서 여러 메시지 컨텍스트 속성 값을 설정할 수 있으며, org.apache.cxf.ws.rm.RMManager 클래스에 공용 상수로 정의된 키 값을 사용할 수 있습니다.

21.4.2. 런타임 제어 옵션

다음 표에는 org.apache.cxf.ws.rm.RMManager 클래스에서 정의된 키가 나열되어 있습니다.

설명

WSRM_VERSION_PROPERTY

string WS-RM 버전 네임스페이스(http://schemas.xmlsoap.org/ws/2005/02/rm/ 또는 http://docs.oasis-open.org/ws-rx/wsrm/200702).

WSRM_WSA_VERSION_PROPERTY

문자열 WS-Addressing 버전 네임스페이스(http://schemas.xmlsoap.org/ws/2004/08/addressing 또는 http://www.w3.org/2005/08/addressing) - http://schemas.xmlsoap.org/ws/2005/02/rm/ RM 네임스페이스를 사용하지 않는 한 이 속성은 무시됩니다.

WSRM_LAST_MESSAGE_PROPERTY

WS-RM 코드에서 마지막 메시지가 전송되고 있음을 나타내기 위해 true 로 설정하면 코드가 WS-RM 시퀀스 및 릴리스 리소스를 종료할 수 있습니다(CXF의 3.0.0 버전인 경우 WS-RM은 클라이언트를 닫을 때 기본적으로 RM 시퀀스를 종료합니다.)

WSRM_INACTIVITY_TIMEOUT_PROPERTY

비활성 기간(밀리초)입니다.

WSRM_RETRANSMISSION_INTERVAL_PROPERTY

긴 기본 재전송 간격(밀리초)입니다.

WSRM_EXPONENTIAL_BACKOFF_PROPERTY

부울 지수 백오프 플래그입니다.

WSRM_ACKNOWLEDGEMENT_INTERVAL_PROPERTY

장기 승인 간격(밀리초)입니다.

21.4.3. JMX를 통한 WS-RM 제어

Apache CXF의 JMX 관리 기능을 사용하여 WS-RM의 여러 측면을 모니터링하고 제어할 수도 있습니다. JMX 작업의 전체 목록은 org.apache.cxf.ws.ManagedRMManager 및 org. apache.cxf.ws.rm.ManagedRMEndpoint 에 의해 정의되지만 이러한 작업에는 현재 RM 상태를 개별 메시지 수준으로 보는 작업이 포함됩니다. JXM을 사용하여 WS-RM 시퀀스를 종료하거나 종료하고 이전에 전송된 메시지가 원격 RM 끝점에 의해 승인될 때 알림을 받을 수도 있습니다.

21.4.4. JMX 제어의 예

예를 들어 클라이언트 구성에 JMX 서버가 활성화된 경우 다음 코드를 사용하여 수신된 마지막 승인 번호를 추적할 수 있습니다.

// Java
private static class AcknowledgementListener implements NotificationListener {
    private volatile long lastAcknowledgement;

    @Override
    public void handleNotification(Notification notification, Object handback) {
        if (notification instanceof AcknowledgementNotification) {
            AcknowledgementNotification ack = (AcknowledgementNotification)notification;
            lastAcknowledgement = ack.getMessageNumber();
        }
    }

    // initialize client
...
    // attach to JMX bean for notifications
    //  NOTE: you must have sent at least one message to initialize RM before executing this code
    Endpoint ep = ClientProxy.getClient(client).getEndpoint();
    InstrumentationManager im = bus.getExtension(InstrumentationManager.class);
    MBeanServer mbs = im.getMBeanServer();
    RMManager clientManager = bus.getExtension(RMManager.class);
    ObjectName name = RMUtils.getManagedObjectName(clientManager, ep);
    System.out.println("Looking for endpoint name " + name);
    AcknowledgementListener listener = new AcknowledgementListener();
    mbs.addNotificationListener(name, listener, null, null);

    // send messages using RM with acknowledgement status reported to listener
...

21.5. WS-RM 구성

21.5.1. Apache CXF-Specific WS-RM 속성 구성

21.5.1.1. 개요

Apache CXF별 속성을 구성하려면 rmManager Spring 빈을 사용합니다. 설정 파일에 다음을 추가합니다.

예 21.4. “Apache CXF-Specific WS-RM 속성 구성” 간단한 예를 보여줍니다.

예 21.4. Apache CXF-Specific WS-RM 속성 구성

&lt;beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:wsrm-mgr="http://cxf.apache.org/ws/rm/manager"
      xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
 http://cxf.apache.org/ws/rm/manager http://cxf.apache.org/schemas/configuration/wsrm-manager.xsd"&gt;
...
&lt;wsrm-mgr:rmManager&gt;
&lt;!--
  ...Your configuration goes here
--&gt;
&lt;/wsrm-mgr:rmManager&gt;

21.5.1.2. rmManager Spring 빈의 하위 항목

표 21.2. “rmManager Spring Bean의 하위” http://cxf.apache.org/ws/rm/manager 네임스페이스에 정의된 rmManager Spring 빈의 하위 요소를 보여줍니다.

표 21.2. rmManager Spring Bean의 하위
요소설명

RMAsertion

RMAssertion유형의 요소

deliveryAssurance

적용할 전달 보장을 설명하는 Type DeliveryAssuranceType 의 요소

sourcePolicy

RM 소스의 세부 정보를 구성할 수 있는 SourcePolicyType 유형의 요소

destinationPolicy

RM 대상에 대한 세부 정보를 구성할 수 있는 DestinationPolicyType 유형의 요소

21.5.1.3. 예제

예를 들어 “확인되지 않은 최대 메시지 임계값” 에서 참조하십시오.

21.5.2. 표준 WS-RM 정책 속성 구성

21.5.2.1. 개요

다음 방법 중 하나로 표준 WS-RM 정책 속성을 구성할 수 있습니다.

21.5.2.2. WS-Policy RMAsertion Children

표 21.3. “WS-Policy RMAsertion Element의 하위 항목” http://schemas.xmlsoap.org/ws/2005/02/rm/policy 네임스페이스에 정의된 요소를 표시합니다.

표 21.3. WS-Policy RMAsertion Element의 하위 항목
이름설명

InactivityTimeout

비활성으로 인해 RM 시퀀스를 종료하기 전에 메시지를 수신하지 않고 전달해야 하는 시간을 지정합니다.

BaseRetransmissionInterval

지정된 메시지에 대해 RM Source가 승인을 받아야 하는 간격을 설정합니다. BaseRetransmissionInterval 에 의해 설정된 시간 내에 승인이 수신되지 않으면 RM Source가 메시지를 다시 전송합니다.

ExponentialBackoff

일반적으로 알려진 지수 백오프 알고리즘(Tanenbaum)을 사용하여 재전송 간격이 조정됨을 나타냅니다.

자세한 내용은 Computer Networks, Andrew S. Tanenbaum, Prentice Hall PTR, 2003을 참조하십시오.

AcknowledgementInterval

WS-RM에서 승인은 반환 메시지로 전송되거나 독립형으로 전송됩니다. 반환 메시지를 사용하여 승인을 보낼 수 없는 경우 RM Destination은 독립형 승인을 보내기 전에 승인 간격까지 기다릴 수 있습니다. 확인되지 않은 메시지가 없으면 RM Destination은 승인 메시지를 보내지 않도록 선택할 수 있습니다.

21.5.2.3. 자세한 참조 정보

각 요소의 하위 요소 및 특성에 대한 설명을 포함한 자세한 참조 정보는 http://schemas.xmlsoap.org/ws/2005/02/rm/wsrm-policy.xsd 에서 참조하십시오.

21.5.2.4. rmManager Spring bean의 RMAsertion

Apache CXF rmManager Spring bean에 RMAssertion 을 추가하여 표준 WS-RM 정책 속성을 구성할 수 있습니다. 동일한 구성 파일에 모든 WS-RM 구성을 유지하려면 이 방법이 가장 좋습니다. 즉, 동일한 파일에서 Apache CXF 특정 속성과 표준 WS-RM 정책 속성을 구성하려면 가장 좋은 방법입니다.

예를 들어 예 21.5. “rmManager Spring Bean에서 RMAssertion을 사용하여 WS-RM 속성 구성” 의 구성은 다음과 같습니다.

  • rmManager Spring 빈 내에서 RMAssertion 을 사용하여 구성된 표준 WS-RM 정책 속성 BaseRetransmissionInterval.
  • 동일한 구성 파일에 구성된 Apache CXF별 RM 속성인 intraMessageThreshold.

예 21.5. rmManager Spring Bean에서 RMAssertion을 사용하여 WS-RM 속성 구성

<beans xmlns:wsrm-policy="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
       xmlns:wsrm-mgr="http://cxf.apache.org/ws/rm/manager"
...>
<wsrm-mgr:rmManager id="org.apache.cxf.ws.rm.RMManager">
    <wsrm-policy:RMAssertion>
        <wsrm-policy:BaseRetransmissionInterval Milliseconds="4000"/>
    </wsrm-policy:RMAssertion>
    <wsrm-mgr:destinationPolicy>
        <wsrm-mgr:acksPolicy intraMessageThreshold="0" />
    </wsrm-mgr:destinationPolicy>
</wsrm-mgr:rmManager>
</beans>

21.5.2.5. 기능 내에서 정책

예 21.6. “WS-RM 특성을 기능 내에서 정책으로 구성” 과 같이 기능 내에서 표준 WS-RM 정책 특성을 구성할 수 있습니다.

예 21.6. WS-RM 특성을 기능 내에서 정책으로 구성

<xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:wsa="http://cxf.apache.org/ws/addressing"
        xmlns:wsp="http://www.w3.org/2006/07/ws-policy"
        xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
        xmlns:jaxws="http://cxf.apache.org/jaxws"
        xsi:schemaLocation="
http://www.w3.org/2006/07/ws-policy http://www.w3.org/2006/07/ws-policy.xsd
http://cxf.apache.org/ws/addressing http://cxf.apache.org/schema/ws/addressing.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <jaxws:endpoint name="{http://cxf.apache.org/greeter_control}GreeterPort" createdFromAPI="true">
        <jaxws:features>
               <wsp:Policy>
                   <wsrm:RMAssertion xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
                     <wsrm:AcknowledgementInterval Milliseconds="200" />
                   </wsrm:RMAssertion>
                   <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata">
                       <wsp:Policy>
                            <wsam:NonAnonymousResponses/>
                       </wsp:Policy>
                   </wsam:Addressing>
              </wsp:Policy>
        </jaxws:features>
    </jaxws:endpoint>
</beans>

21.5.2.6. WSDL 파일

WS-Policy 프레임워크를 사용하여 WS-RM을 활성화하는 경우 WSDL 파일에서 표준 WS-RM 정책 속성을 구성할 수 있습니다. 이 방법은 서비스에서 기타 정책 인식 웹 서비스 스택에 배포된 소비자와 함께 WS-RM을 원활하게 사용하고자 하는 경우에 적합합니다.

예를 들어, “WS-Policy 프레임워크: 암시적으로 인터셉터 추가” 기본 재전송 간격이 WSDL 파일에 구성된 위치를 참조하십시오.

21.5.2.7. 외부 첨부 파일

외부 연결 파일에서 표준 WS-RM 정책 속성을 구성할 수 있습니다. 이 방법은 WSDL 파일을 변경할 수 없거나 원하지 않는 경우 좋은 방법입니다.

예 21.7. “외부 연결에서 WS-RM 구성” 특정 EPR에 대해 WS-A 및 WS-RM(기본 재전송 간격 30초)을 둘 다 활성화하는 외부 연결을 보여줍니다.

예 21.7. 외부 연결에서 WS-RM 구성

<attachments xmlns:wsp="http://www.w3.org/2006/07/ws-policy" xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <wsp:PolicyAttachment>
        <wsp:AppliesTo>
           <wsa:EndpointReference>
                <wsa:Address>http://localhost:9020/SoapContext/GreeterPort</wsa:Address>
            </wsa:EndpointReference>
        </wsp:AppliesTo>
        <wsp:Policy>
            <wsam:Addressing xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata">
                <wsp:Policy/>
            </wsam:Addressing>
            <wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
                <wsrmp:BaseRetransmissionInterval Milliseconds="30000"/>
            </wsrmp:RMAssertion>
        </wsp:Policy>
    </wsp:PolicyAttachment>
</attachments>/

21.5.3. WS-RM 구성 사용 사례

21.5.3.1. 개요

이 하위 섹션에서는 사용 사례 관점에서 WS-RM 속성을 구성하는 데 중점을 둡니다. 속성이 http://schemas.xmlsoap.org/ws/2005/02/rm/policy/ 네임스페이스에 정의된 표준 WS-RM 정책 특성인 경우 rmManager Spring 빈 내의 RMAssertion 에서 설정하는 예제만 표시됩니다. 기능 내에서 정책과 같은 속성을 설정하는 방법에 대한 자세한 내용은 WSDL 파일 또는 외부 연결에서 참조하십시오. 21.5.2절. “표준 WS-RM 정책 속성 구성”

다음 사용 사례에 대해 설명합니다.

21.5.3.2. 기본 재전송 간격

BaseRetransmissionInterval 요소는 RM 소스가 아직 확인되지 않은 메시지를 다시 전송하는 간격을 지정합니다. http://schemas.xmlsoap.org/ws/2005/02/rm/wsrm-policy.xsd 스키마 파일에 정의되어 있습니다. 기본값은 3000밀리초입니다.

예 21.8. “WS-RM 기본 재전송 간격 설정” WS-RM 기본 재전송 간격을 설정하는 방법을 보여줍니다.

예 21.8. WS-RM 기본 재전송 간격 설정

<beans xmlns:wsrm-policy="http://schemas.xmlsoap.org/ws/2005/02/rm/policy
...>
<wsrm-mgr:rmManager id="org.apache.cxf.ws.rm.RMManager">
    <wsrm-policy:RMAssertion>
        <wsrm-policy:BaseRetransmissionInterval Milliseconds="4000"/>
    </wsrm-policy:RMAssertion>
</wsrm-mgr:rmManager>
</beans>

21.5.3.3. 다시 전송 시 지수 백오프

ExponentialBackoff 요소는 검증되지 않은 메시지에 대한 연속 재전송 시도가 지수 간격으로 수행되는지 여부를 결정합니다.

ExponentialBackoff 요소의 존재로 인해 이 기능을 사용할 수 있습니다. 기본적으로 2 의 지수 백오프 비율이 사용됩니다. ExponentialBackoff 는 플래그입니다. 요소가 있으면 exponential 백오프가 활성화됩니다. 요소가 없으면 exponential 백오프가 비활성화됩니다. 값이 필요하지 않습니다.

예 21.9. “WS-RM Exponential Backoff 속성 설정” 는 재전송을 위해 WS-RM exponential 백오프를 설정하는 방법을 보여줍니다.

예 21.9. WS-RM Exponential Backoff 속성 설정

<beans xmlns:wsrm-policy="http://schemas.xmlsoap.org/ws/2005/02/rm/policy
...>
<wsrm-mgr:rmManager id="org.apache.cxf.ws.rm.RMManager">
    <wsrm-policy:RMAssertion>
        <wsrm-policy:ExponentialBackoff/>
    </wsrm-policy:RMAssertion>
</wsrm-mgr:rmManager>
</beans>

21.5.3.4. 승인 간격

AcknowledgementInterval 요소는 WS-RM 대상이 비동기 승인을 보내는 간격을 지정합니다. 이는 수신 메시지의 수신 시 보내는 동기 확인에도 추가됩니다. 기본 비동기 승인 간격은 0 밀리초입니다. 즉, AcknowledgementInterval 이 특정 값으로 구성되지 않은 경우 승인은 즉시 전송됩니다(즉, 첫 번째 사용 가능한 기회에서).

비동기 승인은 다음 두 조건이 모두 충족되는 경우에만 RM 대상에 의해 전송됩니다.

  • RM 대상은 비익명 wsrm:acksTo 끝점을 사용합니다.
  • 승인 간격이 만료되기 전에 응답 메시지에 대한 승인이 발생하지 않습니다.

예 21.10. “WS-RM 인식 간격 설정” 는 WS-RM 승인 간격을 설정하는 방법을 보여줍니다.

예 21.10. WS-RM 인식 간격 설정

<beans xmlns:wsrm-policy="http://schemas.xmlsoap.org/ws/2005/02/rm/policy
...>
<wsrm-mgr:rmManager id="org.apache.cxf.ws.rm.RMManager">
    <wsrm-policy:RMAssertion>
        <wsrm-policy:AcknowledgementInterval Milliseconds="2000"/>
    </wsrm-policy:RMAssertion>
</wsrm-mgr:rmManager>
</beans>

21.5.3.5. 확인되지 않은 최대 메시지 임계값

maxUnacknowledged 특성은 시퀀스가 종료되기 전에 시퀀스당 누적할 수 있는 최대 메시지 수를 설정합니다.

예 21.11. “WS-RM Maximum Unackledged Message Threshold 설정” WS-RM 최대 확인되지 않은 메시지 임계값을 설정하는 방법을 보여줍니다.

예 21.11. WS-RM Maximum Unackledged Message Threshold 설정

<beans xmlns:wsrm-mgr="http://cxf.apache.org/ws/rm/manager
...>
<wsrm-mgr:reliableMessaging>
    <wsrm-mgr:sourcePolicy>
        <wsrm-mgr:sequenceTerminationPolicy maxUnacknowledged="20" />
    </wsrm-mgr:sourcePolicy>
</wsrm-mgr:reliableMessaging>
</beans>

21.5.3.6. RM 시퀀스의 최대 길이

maxLength 속성은 WS-RM 시퀀스의 최대 길이를 설정합니다. 기본값은 0 이며, 이는 WS-RM 시퀀스의 길이가 바인딩되지 않음을 의미합니다.

이 속성이 설정되면 RM 끝점이 제한에 도달하면 새 RM 시퀀스를 생성하고 이전에 보낸 메시지에 대한 모든 승인을 받습니다. 새 메시지는 newsequence를 사용하여 전송됩니다.

예 21.12. “WS-RM 메시지 시퀀스의 최대 길이 설정” RM 시퀀스의 최대 길이를 설정하는 방법을 보여줍니다.

예 21.12. WS-RM 메시지 시퀀스의 최대 길이 설정

<beans xmlns:wsrm-mgr="http://cxf.apache.org/ws/rm/manager
...>
<wsrm-mgr:reliableMessaging>
    <wsrm-mgr:sourcePolicy>
        <wsrm-mgr:sequenceTerminationPolicy maxLength="100" />
    </wsrm-mgr:sourcePolicy>
</wsrm-mgr:reliableMessaging>
</beans>

21.5.3.7. 메시지 전달 보장 정책

다음과 같은 전달 보장 정책을 사용하도록 RM 대상을 구성할 수 있습니다.

  • At mostOnce - RM 대상은 한 번만 애플리케이션 목적지로 메시지를 전달합니다. 메시지가 두 번 이상 발생하는 경우 오류가 발생합니다. 시퀀스의 일부 메시지가 전달되지 않을 수 있습니다.
  • AtLeastOnce - RM 대상은 적어도 한 번 이상 애플리케이션 대상으로 메시지를 전달합니다. 전송된 모든 메시지가 전송되거나 오류가 발생합니다. 일부 메시지는 한 번 이상 배달될 수 있습니다.
  • InOrder - RM 대상은 전송된 순서대로 애플리케이션 대상에 메시지를 전달합니다. 이 전달 보장은 At most Once 또는 AtLeastOnce 보증과 결합할 수 있습니다.

예 21.13. “WS-RM 메시지 전달 보장 정책 설정” 는 WS-RM 메시지 전달 보증을 설정하는 방법을 보여줍니다.

예 21.13. WS-RM 메시지 전달 보장 정책 설정

<beans xmlns:wsrm-mgr="http://cxf.apache.org/ws/rm/manager
...>
<wsrm-mgr:reliableMessaging>
    <wsrm-mgr:deliveryAssurance>
        <wsrm-mgr:AtLeastOnce />
    </wsrm-mgr:deliveryAssurance>
</wsrm-mgr:reliableMessaging>
</beans>

21.6. WS-RM 지속성 구성

21.6.1. 개요

이 장에 이미 설명된 Apache CXF WS-RM 기능은 네트워크 실패와 같은 경우에 대한 신뢰성을 제공합니다. WS-RM 지속성은 RM 소스 또는 RM 대상 충돌과 같은 다른 유형의 실패에 걸쳐 안정성을 제공합니다.

WS-RM 지속성에는 다양한 RM 엔드포인트의 상태를 영구 스토리지에 저장하는 작업이 포함됩니다. 이를 통해 엔드포인트가 다시 시작될 때 계속 메시지를 보내고 받을 수 있습니다.

Apache CXF는 구성 파일에서 WS-RM 지속성을 활성화합니다. 기본 WS-RM 지속성 저장소는 JDBC 기반입니다. 편의를 위해 Apache CXF에는 기본 제공 배포를 위한 Derby가 포함되어 있습니다. 또한 Java API를 사용하여 영구 저장소도 노출됩니다. 자체 지속성 메커니즘을 구현하기 위해 기본 DB와 함께 이 API를 사용하여 하나를 구현할 수 있습니다.

중요

WS-RM 지속성은 oneway 호출에만 지원되며 기본적으로 비활성화되어 있습니다.

21.6.2. 작동 방식

Apache CXF WS-RM 지속성은 다음과 같이 작동합니다.

  • RM 소스 끝점에서 전송 전에 발신 메시지가 유지됩니다. 승인이 수신된 후 영구 저장소에서 제거됩니다.
  • 충돌에서 복구한 후 모든 메시지가 승인될 때까지 지속된 메시지를 복구하고 다시 전송합니다. 이 시점에서 RM 시퀀스가 닫힙니다.
  • RM 대상 끝점에서 들어오는 메시지가 유지되고 성공적으로 저장되면 승인이 전송됩니다. 메시지를 성공적으로 디스패치하면 영구 저장소에서 제거됩니다.
  • 충돌에서 복구한 후 지속적인 메시지를 복구하고 디스패치합니다. 또한 새 메시지가 수락, 승인 및 전달되는 상태로 RM 시퀀스를 제공합니다.

21.6.3. WS-persistence 활성화

WS-RM 지속성을 활성화하려면 WS-RM용 영구 저장소를 구현하는 오브젝트를 지정해야 합니다. 직접 개발하거나 Apache CXF와 함께 제공되는 JDBC 기반 저장소를 사용할 수 있습니다.

예 21.14. “기본 WS-RM Persistence 저장소에 대한 구성” 에 표시된 구성은 Apache CXF와 함께 제공되는 JDBC 기반 저장소를 활성화합니다.

예 21.14. 기본 WS-RM Persistence 저장소에 대한 구성

<bean id="RMTxStore" class="org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore"/>
<wsrm-mgr:rmManager id="org.apache.cxf.ws.rm.RMManager">
    <property name="store" ref="RMTxStore"/>
</wsrm-mgr:rmManager>

21.6.4. WS-persistence 구성

Apache CXF와 함께 제공되는 JDBC 기반 저장소는 표 21.4. “JDBC 저장소 속성” 에 표시된 속성을 지원합니다.

표 21.4. JDBC 저장소 속성
특성 이름유형기본 설정

driverClassName

문자열

org.apache.derby.jdbc.EmbeddedDriver

userName

문자열

null

passWord

문자열

null

url

문자열

jdbc:derby:rmdb;create=true

예 21.15. “WS-RM Persistence용 JDBC 저장소 구성” 에 표시된 설정을 사용하면 Apache CXF와 함께 제공되는 JDBC 기반 저장소를 드라이버 ClassName 및 url 을 기본값이 아닌 값으로 설정할 수 있습니다.

예 21.15. WS-RM Persistence용 JDBC 저장소 구성

<bean id="RMTxStore" class="org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore">
    <property name="driverClassName" value="com.acme.jdbc.Driver"/>
    <property name="url" value="jdbc:acme:rmdb;create=true"/>
</bean>

22장. 고가용성 활성화

초록

이 장에서는 Apache CXF 런타임에서 고가용성을 활성화하고 구성하는 방법을 설명합니다.

22.1. 고가용성 소개

22.1.1. 개요

확장 가능하고 안정적인 애플리케이션은 분산 시스템에서 단일 장애 지점을 방지하기 위해 고가용성이 필요합니다. 를 사용하여 시스템을 단일 장애 지점으로부터 보호할 수 있습니다. 복제된 서비스.

복제된 서비스는 동일한 서비스의 여러 인스턴스 또는 복제본 으로 구성됩니다. 이러한 기능을 함께 단일 논리 서비스로 작동합니다. 클라이언트는 복제된 서비스에서 요청을 호출하고 Apache CXF는 멤버 복제본 중 하나에 요청을 제공합니다. 복제본 라우팅은 클라이언트에 투명합니다.

22.1.2. 고정 페일오버가 있는 HA

Apache CXF는 복제본 세부 정보가 service WSDL 파일에 인코딩되는 정적 페일오버와 함께 HA(고가용성)를 지원합니다. WSDL 파일에는 여러 포트가 포함되어 있으며 동일한 서비스에 대해 여러 호스트를 포함할 수 있습니다. WSDL 파일이 변경되지 않는 한 클러스터의 복제본 수는 정적으로 유지됩니다. 클러스터 크기를 변경하려면 WSDL 파일을 편집해야 합니다.

22.2. 고정 장애 조치(Stic Failover)를 사용하여 HA 활성화

22.2.1. 개요

정적 페일오버를 사용하여 HA를 활성화하려면 다음을 수행해야 합니다.

22.2.2. 서비스 WSDL 파일에서 복제본 세부 정보 인코딩

서비스 WSDL 파일에서 클러스터의 복제본 세부 정보를 인코딩해야 합니다. 예 22.1. “고정 장애 조치 (Failover)를 사용하여 HA 활성화: WSDL 파일” 는 세 개의 복제본의 서비스 클러스터를 정의하는 WSDL 파일 추출을 보여줍니다.

예 22.1. 고정 장애 조치 (Failover)를 사용하여 HA 활성화: WSDL 파일

<wsdl:service name="ClusteredService">
    <wsdl:port binding="tns:Greeter_SOAPBinding" name="Replica1">
        <soap:address location="http://localhost:9001/SoapContext/Replica1"/>
    </wsdl:port>

    <wsdl:port binding="tns:Greeter_SOAPBinding" name="Replica2">
        <soap:address location="http://localhost:9002/SoapContext/Replica2"/>
    </wsdl:port>

    <wsdl:port binding="tns:Greeter_SOAPBinding" name="Replica3">
        <soap:address location="http://localhost:9003/SoapContext/Replica3"/>
    </wsdl:port>

</wsdl:service>

예 22.1. “고정 장애 조치 (Failover)를 사용하여 HA 활성화: WSDL 파일” 에 표시된 WSDL 추출은 다음과 같이 설명할 수 있습니다.

세 개의 포트에 노출되는 서비스 ClusterService 를 정의합니다.

  1. Replica1
  2. Replica2
  3. Replica3

포트 9001 에서 HTTP 끝점을 통해 SOAP로 ClusterService 를 노출하도록 Replica1 을 정의합니다.

포트 9002 에서 ClusterService 를 HTTP 끝점을 통해 SOAP로 노출하도록 Replica2 를 정의합니다.

포트 9003 에서 HTTP 끝점을 통해 SOAP로 ClusterService 를 노출하도록 Replica3 를 정의합니다.

22.2.3. 클라이언트 구성에 클러스터링 기능 추가

클라이언트 구성 파일에서 예 22.2. “정적 장애 조치(Failover)를 사용하여 HA 활성화: 클라이언트 구성” 과 같이 클러스터링 기능을 추가합니다.

예 22.2. 정적 장애 조치(Failover)를 사용하여 HA 활성화: 클라이언트 구성

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jaxws="http://cxf.apache.org/jaxws"
       xmlns:clustering="http://cxf.apache.org/clustering"
         xsi:schemaLocation="http://cxf.apache.org/jaxws
         http://cxf.apache.org/schemas/jaxws.xsd
         http://www.springframework.org/schema/beans
         http://www.springframework.org/schema/beans/spring-beans.xsd">

    <jaxws:client name="{http://apache.org/hello_world_soap_http}Replica1"
                  createdFromAPI="true">
        <jaxws:features>
            <clustering:failover/>
        </jaxws:features>
    </jaxws:client>

    <jaxws:client name="{http://apache.org/hello_world_soap_http}Replica2"
                  createdFromAPI="true">
        <jaxws:features>
            <clustering:failover/>
        </jaxws:features>
    </jaxws:client>

    <jaxws:client name="{http://apache.org/hello_world_soap_http}Replica3"
                  createdFromAPI="true">
        <jaxws:features>
            <clustering:failover/>
        </jaxws:features>
    </jaxws:client>

</beans>

22.3. 정적 장애 조치(Failover)를 사용하여 HA 구성

22.3.1. 개요

기본적으로 정적 페일오버를 사용하는 HA는 클라이언트가 통신할 원본 서비스를 사용할 수 없거나 실패하는 경우 복제본 서비스를 선택할 때 순차적 전략을 사용합니다. 순차적 전략은 사용할 때마다 동일한 순차순으로 복제본 서비스를 선택합니다. 선택 사항은 Apache CXF의 내부 서비스 모델에 따라 결정되며, 그 결과 결정적인 페일오버 패턴을 제공합니다.

22.3.2. 임의의 전략 구성

복제본을 선택할 때 순차적 전략 대신 임의의 전략을 사용하도록 정적 장애 조치로 HA를 구성할 수 있습니다. random 전략은 서비스를 사용할 수 없게 되거나 실패할 때마다 임의의 복제본 서비스를 선택합니다. 클러스터의 생존 멤버에서 페일오버 대상을 선택하는 것은 완전히 무작위로 선택됩니다.

임의의 전략을 구성하려면 예 22.3. “정적 장애 조치(Failover)를 위한 Random 전략 구성” 에 표시된 구성을 클라이언트 구성 파일에 추가합니다.

예 22.3. 정적 장애 조치(Failover)를 위한 Random 전략 구성

<beans ...>
    <bean id="Random" class="org.apache.cxf.clustering.RandomStrategy"/>

    <jaxws:client name="{http://apache.org/hello_world_soap_http}Replica3"
                  createdFromAPI="true">
        <jaxws:features>
            <clustering:failover>
                <clustering:strategy>
                    <ref bean="Random"/>
                </clustering:strategy>
            </clustering:failover>
        </jaxws:features>
    </jaxws:client>
</beans>

예 22.3. “정적 장애 조치(Failover)를 위한 Random 전략 구성” 에 표시된 구성은 다음과 같이 설명할 수 있습니다.

임의의 전략을 구현하는 Random 빈 및 구현 클래스를 정의합니다.

복제본을 선택할 때 임의의 전략이 사용되도록 지정합니다.

23장. Apache CXF 바인딩 ID

23.1. 바인딩 ID 테이블

표 23.1. Message Bindings의 바인딩 ID
바인딩ID

CORBA

http://cxf.apache.org/bindings/corba

HTTP/REST

http://apache.org/cxf/binding/http

SOAP 1.1

http://schemas.xmlsoap.org/wsdl/soap/http

SOAP 1.1 w/ MTOM

http://schemas.xmlsoap.org/wsdl/soap/http?mtom=true

SOAP 1.2

http://www.w3.org/2003/05/soap/bindings/HTTP/

SOAP 1.2 w/ MTOM

http://www.w3.org/2003/05/soap/bindings/HTTP/?mtom=true

XML

http://cxf.apache.org/bindings/xformat

부록 A. Maven OSGi 툴 사용

초록

대규모 프로젝트의 번들 또는 번들 컬렉션을 수동으로 생성하는 것은 번거로울 수 있습니다. Maven 번들 플러그인을 사용하면 프로세스를 자동화하고 번들 매니페스트의 콘텐츠를 지정하기 위한 여러 바로 가기를 제공하여 작업을 더 쉽게 수행할 수 있습니다.

A.1. Maven Bundle 플러그인

Red Hat Fuse OSGi 툴링은 Apache Felix의 Maven 번들 플러그인 을 사용합니다. bundle 플러그인은 Peter Kriens의 B nd 툴을 기반으로 합니다. 번들에 패키지되는 클래스의 콘텐츠를 검사하여 OSGi 번들 매니페스트의 구성을 자동화합니다. 번들에 포함된 클래스에 대한 지식을 사용하여 플러그인은 번들 매니페스트에서 Import-PackagesExport-Package 속성을 채우기 위해 적절한 값을 계산할 수 있습니다. 플러그인에는 번들 매니페스트의 다른 필수 속성에 사용되는 기본값도 있습니다.

bundle 플러그인을 사용하려면 다음을 수행합니다.

  1. A.2절. “Red Hat Fuse OSGi 프로젝트 설정” 프로젝트의 POM 파일에 대한 번들 플러그인입니다.
  2. A.3절. “번들 플러그인 구성” 번들 매니페스트를 올바르게 채우는 플러그인입니다.

A.2. Red Hat Fuse OSGi 프로젝트 설정

A.2.1. 개요

OSGi 번들을 빌드하기 위한 Maven 프로젝트는 간단한 단일 수준 프로젝트일 수 있습니다. 하위 프로젝트는 필요하지 않습니다. 그러나 다음을 수행해야 합니다.However, it does that you do the following:

  1. POM에 bundle 플러그인을 추가 합니다.
  2. Maven에서 결과를 OSGi 번들로 패키징하도록 지시 합니다.
참고

적절한 설정으로 프로젝트를 설정하는 데 사용할 수 있는 여러 Maven archetypes이 있습니다.

A.2.2. 디렉토리 구조

OSGi 번들을 구성하는 프로젝트는 단일 수준 프로젝트일 수 있습니다. 최상위 POM 파일과 src 폴더가 있어야만 합니다. 모든 Maven 프로젝트에서와 마찬가지로 src/java 폴더에 모든 Java 소스 코드를 배치하고 src/resources 폴더에 Java가 아닌 리소스를 배치합니다.

Java가 아닌 리소스에는 Spring 구성 파일, JBI 엔드포인트 구성 파일, WSDL 계약이 포함됩니다.

참고

Apache CXF, Apache Camel 또는 다른 Spring 구성된 빈을 사용하는 Red Hat Fuse OSGi 프로젝트에는 src/resources/META-INF/spring 폴더에 있는 beans.xml 파일도 포함되어 있습니다.

A.2.3. 번들 플러그인 추가

번들 플러그인을 사용하려면 먼저 Apache Felix에 종속 항목을 추가해야 합니다. 종속성을 추가한 후 POM의 플러그인 부분에 bundle 플러그인을 추가할 수 있습니다.

예 A.1. “POM에 OSGi 번들 플러그인 추가” 프로젝트에 번들 플러그인을 추가하는 데 필요한 POM 항목을 표시합니다.

예 A.1. POM에 OSGi 번들 플러그인 추가

...
<dependencies>
  <dependency>
    <groupId>org.apache.felix</groupId>
    <artifactId>org.osgi.core</artifactId>
    <version>1.0.0</version>
  </dependency>
...
</dependencies>
...
<build>
  <plugins>
    <plugin>
      <groupId>org.apache.felix</groupId>
      <artifactId>maven-bundle-plugin</artifactId>
      <configuration>
        <instructions>
          <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
          <Import-Package>*,org.apache.camel.osgi</Import-Package>
          <Private-Package>org.apache.servicemix.examples.camel</Private-Package>
        </instructions>
      </configuration>
    </plugin>
  </plugins>
</build>
...

예 A.1. “POM에 OSGi 번들 플러그인 추가” 의 항목은 다음을 수행합니다.

Apache Felix에 대한 종속성 추가

프로젝트에 bundle 플러그인 추가

프로젝트의 아티팩트 ID를 번들의 기호 이름으로 사용하도록 플러그인을 구성합니다.

번들 클래스에서 가져온 모든 Java 패키지를 포함하도록 플러그인을 구성합니다. 또한 org.apache.camel.osgi 패키지도 가져옵니다.

나열된 클래스를 번들로 플러그인을 구성하지만 내보낸 패키지 목록에 포함하지 않도록 구성합니다.

참고

프로젝트의 요구 사항을 충족하도록 구성을 편집합니다.

번들 플러그인 구성에 대한 자세한 내용은 A.3절. “번들 플러그인 구성” 을 참조하십시오.

A.2.4. 번들 플러그인 활성화

Maven이 bundle 플러그인을 사용하도록 하려면 프로젝트의 결과를 번들로 패키징하도록 지시합니다. POM 파일의 packaging 요소를 번들로 설정하여 이 작업을 수행합니다.

A.2.5. 유용한 Maven archetypes

bundle 플러그인을 사용하도록 사전 구성된 프로젝트를 생성하는 데 사용할 수 있는 여러 Maven archetypes가 있습니다.

A.2.6. Spring OSGi archetype

Spring OSGi archetype은 다음과 같이 Spring DM을 사용하여 OSGi 프로젝트를 빌드하기 위한 일반 프로젝트를 생성합니다.

org.springframework.osgi/spring-bundle-osgi-archetype/1.1.2

다음 명령을 사용하여 archetype을 호출합니다.

mvn archetype:generate -DarchetypeGroupId=org.springframework.osgi -DarchetypeArtifactId=spring-osgi-bundle-archetype -DarchetypeVersion=1.1.2 -DgroupId=groupId -DartifactId=artifactId -Dversion=version

A.2.7. Apache CXF 코드 우선 archetype

Apache CXF 코드 우선 archetype은 다음과 같이 Java에서 서비스를 빌드하는 프로젝트를 생성합니다.

org.apache.servicemix.tooling/servicemix-osgi-cxf-code-first-archetype/2010.02.0-fuse-02-00

다음 명령을 사용하여 archetype을 호출합니다.

mvn archetype:generate -DarchetypeGroupId=org.apache.servicemix.tooling -DarchetypeArtifactId=servicemix-osgi-cxf-code-first-archetype -DarchetypeVersion=2010.02.0-fuse-02-00 -DgroupId=groupId -DartifactId=artifactId -Dversion=version

A.2.8. Apache CXF wsdl-first archetype

Apache CXF wsdl-first archetype은 다음과 같이 WSDL에서 서비스를 생성하는 프로젝트를 생성합니다.

org.apache.servicemix.tooling/servicemix-osgi-cxf-wsdl-first-archetype/2010.02.0-fuse-02-00

다음 명령을 사용하여 archetype을 호출합니다.

mvn archetype:generate -DarchetypeGroupId=org.apache.servicemix.tooling -DarchetypeArtifactId=servicemix-osgi-cxf-wsdl-first-archetype -DarchetypeVersion=2010.02.0-fuse-02-00 -DgroupId=groupId -DartifactId=artifactId -Dversion=version

A.2.9. Apache Camel archetype

Apache Camel archetype은 다음과 같이 Red Hat Fuse에 배포된 경로를 구축하기 위한 프로젝트를 생성합니다.

org.apache.servicemix.tooling/servicemix-osgi-camel-archetype/2010.02.0-fuse-02-00

다음 명령을 사용하여 archetype을 호출합니다.

mvn archetype:generate -DarchetypeGroupId=org.apache.servicemix.tooling -DarchetypeArtifactId=servicemix-osgi-camel-archetype -DarchetypeVersion=2010.02.0-fuse-02-00 -DgroupId=groupId -DartifactId=artifactId -Dversion=version

A.3. 번들 플러그인 구성

A.3.1. 개요

번들 플러그인에는 기능하기 위해 정보가 거의 필요하지 않습니다. 모든 필수 속성은 기본 설정을 사용하여 유효한 OSGi 번들을 생성합니다.

기본값만 사용하여 유효한 번들을 생성할 수 있지만 일부 값을 수정할 수도 있습니다. 플러그인의 instructions 요소 내부에서 대부분의 속성을 지정할 수 있습니다.

A.3.2. 구성 속성

일반적으로 사용되는 구성 속성 중 일부는 다음과 같습니다.

A.3.3. 번들의 심볼릭 이름 설정

기본적으로 bundle 플러그인은 Bundle-SymbolicName 속성 값을 groupId + "." + artifactId 로 설정합니다.

  • groupId 에 하나의 섹션만 있는 경우 클래스가 있는 첫 번째 패키지 이름이 반환됩니다.

    예를 들어 Id 그룹이 commons-logging:commons-logging 이면 번들의 심볼릭 이름은 org.apache.commons.logging 입니다.

  • artifactIdgroupId 의 마지막 섹션과 같은 경우 groupId 가 사용됩니다.

    예를 들어 POM에서 그룹 ID와 아티팩트 ID를 org.apache.maven:maven 로 지정하는 경우 번들의 심볼릭 이름은 org.apache.maven 입니다.

  • artifactIdgroupId 의 마지막 섹션으로 시작되면 해당 부분이 제거됩니다.

    예를 들어 POM에서 그룹 ID와 아티팩트 ID를 org.apache.maven:maven-core 로 지정하는 경우 번들의 심볼릭 이름은 org.apache.maven.core 입니다.

번들의 심볼릭 이름에 대한 자체 값을 지정하려면 예 A.2. “번들의 심볼릭 이름 설정” 과 같이 플러그인의 instructions 요소에 Bundle-SymbolicName 하위 항목을 추가합니다.

예 A.2. 번들의 심볼릭 이름 설정

<plugin>
  <groupId>org.apache.felix</groupId>
  <artifactId>maven-bundle-plugin</artifactId>
  <configuration>
   <instructions>
     <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
     ...
    </instructions>
  </configuration>
</plugin>

A.3.4. 번들 이름 설정

기본적으로 번들 이름은 ${project.name} 으로 설정됩니다.

번들 이름에 대한 자체 값을 지정하려면 예 A.3. “번들 이름 설정” 과 같이 플러그인의 instructions 요소에 Bundle-Name 하위를 추가합니다.

예 A.3. 번들 이름 설정

<plugin>
  <groupId>org.apache.felix</groupId>
  <artifactId>maven-bundle-plugin</artifactId>
  <configuration>
   <instructions>
     <Bundle-Name>JoeFred</Bundle-Name>
     ...
    </instructions>
  </configuration>
</plugin>

A.3.5. 번들 버전 설정

기본적으로 번들 버전은 ${project.version} 으로 설정됩니다. 모든 대시(-)는 점(.)으로 교체되고 숫자는 최대 4자리까지 채워집니다. 예를 들어 4.2-SNAPSHOT4.2.0.SNAPSHOT 가 됩니다.

번들 버전에 대한 자체 값을 지정하려면 예 A.4. “번들 버전 설정” 에서와 같이 번들 버전 하위를 플러그인의 instructions 요소에 추가합니다.

예 A.4. 번들 버전 설정

<plugin>
  <groupId>org.apache.felix</groupId>
  <artifactId>maven-bundle-plugin</artifactId>
  <configuration>
   <instructions>
     <Bundle-Version>1.0.3.1</Bundle-Version>
     ...
    </instructions>
  </configuration>
</plugin>

A.3.6. 내보낸 패키지 지정

기본적으로 OSGi 매니페스트의 Export-Package 목록은 기본 패키지, .. 및 .internal 이 포함된 패키지를 제외하고 로컬 Java 소스 코드의 모든 패키지로 채워집니다.

중요

플러그인 구성에서 Private-Package 요소를 사용하고 내보낼 패키지 목록을 지정하지 않으면 기본 동작은 번들의 Private-Package 요소에 나열된 패키지만 포함합니다. 내보낸 패키지가 없습니다.

기본 동작은 매우 큰 패키지로 발생하며 비공개로 유지해야 하는 패키지를 내보낼 수 있습니다. 내보낸 패키지 목록을 변경하려면 플러그인의 instructions 요소에 Export-Package 하위를 추가할 수 있습니다.

Export-Package 요소는 번들에 포함할 패키지 목록을 지정하고 내보낼 패키지 목록을 지정합니다. 패키지 이름은 * 와일드카드 기호를 사용하여 지정할 수 있습니다. 예를 들어 com.fuse.demo.* 항목에 com.fuse.demo.*로 시작하는 프로젝트의 classpath의 모든 패키지가 포함되어 있습니다.

항목을 접두사로 지정할 패키지를 지정할 수 있습니다 !. 예를 들어 !com.fuse.demo.private 항목은 com.fuse.demo.private 패키지를 제외합니다.

패키지를 제외할 때 목록의 항목 순서가 중요합니다. 목록은 처음부터 순서대로 처리되며 이후의 충돌 항목은 무시됩니다.

예를 들어 com.fuse.demo.private 패키지를 제외한 com.fuse.demo.demo로 시작하는 모든 패키지를 포함하려면 다음을 사용하여 패키지를 나열하십시오.

!com.fuse.demo.private,com.fuse.demo.*

그러나 com.fuse.demo.*,!com.fuse.demo.private 를 사용하여 패키지를 나열하는 경우 첫 번째 패턴과 일치하므로 번들에 com.fuse.demo.private 이 포함됩니다.

A.3.7. 개인 패키지 지정

내보내 지 않고 번들에 포함할 패키지 목록을 지정하려면 번들 플러그인 구성에 Private-Package 명령을 추가할 수 있습니다. 기본적으로 Private-Package 명령을 지정하지 않으면 로컬 Java 소스의 모든 패키지가 번들에 포함됩니다.

중요

패키지가 Private-Package 요소 및 Export-Package 요소 둘 다의 항목과 일치하는 경우 Export-Package 요소가 우선합니다. 패키지가 번들에 추가되고 내보내집니다.

Private-Package 요소는 번들에 포함할 패키지 목록을 지정하는 데 사용되는 Export-Package 요소와 유사하게 작동합니다. bundle 플러그인은 목록을 사용하여 번들에 포함할 프로젝트의 classpath에서 모든 클래스를 찾습니다. 이러한 패키지는 번들에 패키지되지만 내보내지지 않습니다( Export-Package 명령어에서도 선택하지 않는 한).

예 A.5. “번들에 개인 패키지 포함” 번들에 개인 패키지를 포함하는 구성을 보여줍니다.

예 A.5. 번들에 개인 패키지 포함

<plugin>
  <groupId>org.apache.felix</groupId>
  <artifactId>maven-bundle-plugin</artifactId>
  <configuration>
   <instructions>
     <Private-Package>org.apache.cxf.wsdlFirst.impl</Private-Package>
     ...
    </instructions>
  </configuration>
</plugin>

A.3.8. 가져온 패키지 지정

기본적으로 번들 플러그인은 OSGi 매니페스트의 Import-Package 속성을 번들 콘텐츠로 참조하는 모든 패키지 목록으로 채웁니다.

기본 동작은 일반적으로 대부분의 프로젝트에 충분하지만 목록에 자동으로 추가되지 않는 패키지를 가져오려는 인스턴스를 찾을 수 있습니다. 기본 동작으로 인해 원치 않는 패키지를 가져올 수도 있습니다.

번들에서 가져올 패키지 목록을 지정하려면 플러그인의 instructions 요소에 Import-Package 하위 항목을 추가합니다. 패키지 목록의 구문은 Export-Package 요소 및 Private-Package 요소에 대해 동일합니다.

중요

Import-Package 요소를 사용하는 경우 플러그인은 번들의 콘텐츠를 자동으로 검사하여 필요한 가져오기가 있는지 여부를 확인하지 않습니다. 번들의 콘텐츠를 스캔하려면 패키지 목록에 * 를 마지막 항목으로 배치해야 합니다.

예 A.6. “번들에서 가져온 패키지 지정” 번들에서 가져온 패키지를 지정하기 위한 구성을 표시합니다.

예 A.6. 번들에서 가져온 패키지 지정

<plugin>
  <groupId>org.apache.felix</groupId>
  <artifactId>maven-bundle-plugin</artifactId>
  <configuration>
   <instructions>
     <Import-Package>javax.jws, javax.wsdl, org.apache.cxf.bus, org.apache.cxf.bus.spring, org.apache.cxf.bus.resource, org.apache.cxf.configuration.spring, org.apache.cxf.resource, org.springframework.beans.factory.config, * </Import-Package>
     ...
   </instructions>
  </configuration>
</plugin>

A.3.9. 더 알아보기

번들 플러그인 구성에 대한 자세한 내용은 다음을 참조하십시오.

V 부. JAX-WS를 사용하여 애플리케이션 개발

이 가이드에서는 표준 JAX-WS API를 사용하여 웹 서비스를 개발하는 방법을 설명합니다.

24장. 하이 업 서비스 개발

초록

Java 코드가 이미 서비스 지향 애플리케이션의 일부로 노출하려는 기능 집합을 구현하는 많은 인스턴스가 있습니다. 인터페이스를 정의하기 위해 WSDL을 사용하지 않도록 할 수도 있습니다. JAX-WS 주석을 사용하면 Java 클래스를 활성화하는 데 필요한 정보를 추가할 수 있습니다. 또한 WSDL 계약 대신 사용할 수 있는 Service Endpoint Interface (SEI)를 만들 수도 있습니다. WSDL 계약을 원하는 경우 Apache CXF는 주석이 달린 Java 코드에서 계약을 생성하는 도구를 제공합니다.

24.1. JAX-WS 서비스 개발 소개

Java에서 시작하는 서비스를 생성하려면 다음을 수행해야 합니다.

  1. 24.2절. “SEI 생성” 서비스로 노출하려는 방법을 정의하는 SEI(Service Endpoint Interface)입니다.

    참고

    Java 클래스에서 직접 작업할 수 있지만 인터페이스에서 작업하는 것이 좋습니다. 인터페이스는 서비스를 사용하는 애플리케이션 개발을 담당하는 개발자와 공유하는 데 더 적합합니다. 인터페이스는 더 작으며 서비스의 구현 세부 정보를 제공하지 않습니다.

  2. 24.3절. “코드 주석 달기” 코드에 필요한 주석입니다.
  3. 24.4절. “WSDL 생성” 서비스에 대한 WSDL 계약입니다.

    참고

    SEI를 서비스의 계약으로 사용하려는 경우 WSDL 계약을 생성할 필요가 없습니다.

  4. 31장. 서비스 게시 서비스는 서비스 공급자입니다.

24.2. SEI 생성

24.2.1. 개요

서비스 엔드포인트 인터페이스 (SEI)는 서비스 구현과 해당 서비스에 대한 요청을 수행하는 소비자 간에 공유되는 Java 코드의 일부입니다. SEI는 서비스에서 구현하는 방법을 정의하고 서비스를 엔드포인트로 노출하는 방법에 대한 세부 정보를 제공합니다. WSDL 계약을 시작할 때 SEI는 코드 생성기에 의해 생성됩니다. 그러나 Java에서 시작할 때 개발자는 SEI를 생성해야 할 책임이 있습니다. SEI를 생성하기 위한 두 가지 기본 패턴이 있습니다.

  • 녹색 필드 개발 - 이 패턴에서는 기존 Java 코드 또는 WSDL 없이 새로운 서비스를 개발하고 있습니다. SEI를 만들어 시작하는 것이 가장 좋습니다. 그런 다음 SEI를 사용하는 서비스 공급자 및 소비자를 구현하는 데 책임이 있는 모든 개발자에게 SEI를 배포할 수 있습니다.

    참고

    녹색 필드 서비스 개발을 수행하는 권장 방법은 서비스 및 해당 인터페이스를 정의하는 WSDL 계약을 생성하여 시작하는 것입니다. 26장. Starting Point WSDL 계약 을 참조하십시오.

  • 서비스 활성화 - 이 패턴에서는 일반적으로 Java 클래스로 구현되는 기존 기능 세트가 있으며 서비스 활성화를 원합니다. 즉, 두 가지를 해야 합니다.

    1. 서비스의 일부로 노출되는 작업 포함하는 SEI를 만듭니다.
    2. SEI를 구현하도록 기존 Java 클래스를 수정합니다.

      참고

      JAX-WS 주석을 Java 클래스에 추가할 수 있지만 권장되지는 않습니다.

24.2.2. 인터페이스 작성

SEI는 표준 Java 인터페이스입니다. 클래스에서 구현하는 메서드 집합을 정의합니다. 구현 클래스에서 액세스 권한이 있는 여러 멤버 필드와 상수를 정의할 수도 있습니다.It can also define a number of member fields and constants to which the implementing class has access.

SEI의 경우 정의된 메서드는 서비스에서 노출하는 작업에 매핑되도록 설계되었습니다. SEI는 wsdl:portType 요소에 해당합니다. SEI에서 정의한 방법은 wsdl:portType 요소의 wsdl:operation 요소에 해당합니다.

참고

JAX-WS는 서비스의 일부로 노출되지 않는 메서드를 지정할 수 있는 주석을 정의합니다. 그러나 이러한 방법을 SEI에서 벗어나는 것이 가장 좋습니다.

예 24.1. “간단한 SEI” 는 주식 업데이트 서비스에 대한 간단한 SEI를 보여줍니다.

예 24.1. 간단한 SEI

package com.fusesource.demo;

public interface quoteReporter
{
  public Quote getQuote(String ticker);
}

24.2.3. 인터페이스 구현

SEI는 표준 Java 인터페이스이므로 구현하는 클래스는 표준 Java 클래스입니다. Java 클래스로 시작하는 경우 인터페이스를 구현하도록 수정해야 합니다. SEI로 시작하는 경우 구현 클래스는 SEI를 구현합니다.

예 24.2. “간단한 구현 클래스”예 24.1. “간단한 SEI” 에서 인터페이스를 구현하는 클래스를 보여줍니다.

예 24.2. 간단한 구현 클래스

package com.fusesource.demo;

import java.util.*;

public class stockQuoteReporter implements quoteReporter
{
  ...
public Quote getQuote(String ticker)
  {
    Quote retVal = new Quote();
    retVal.setID(ticker);
    retVal.setVal(Board.check(ticker));[1]
    Date retDate = new Date();
    retVal.setTime(retDate.toString());
    return(retVal);
  }
}


[1] Board is an assumed class whose implementation is left to the reader.

24.3. 코드 주석 달기

24.3.1. JAX-WS 주석 개요

JAX-WS 주석은 SEI를 완전히 지정된 서비스 정의에 매핑하는 데 사용되는 메타데이터를 지정합니다. 주석에 제공된 정보 중 하나는 다음과 같습니다.

  • 서비스의 대상 네임스페이스입니다.
  • 요청 메시지를 보유하는 데 사용되는 클래스의 이름입니다.
  • 응답 메시지를 보유하는 데 사용되는 클래스의 이름입니다.
  • 작업을 한 가지 방법으로 수행 하는 경우If an operation is a one way
  • 서비스에서 사용하는 바인딩 스타일
  • 사용자 지정 예외에 사용되는 클래스의 이름입니다.
  • 서비스에서 사용하는 유형이 정의된 네임스페이스
참고

대부분의 주석에는 적절한 기본값이 있으며 해당 주석에 값을 제공할 필요가 없습니다. 그러나 주석에 제공하는 정보가 많을수록 서비스 정의가 더 잘 지정됩니다. 잘 지정되어 있는 서비스 정의는 분산 애플리케이션의 모든 부분이 함께 작동할 가능성이 높아집니다.

24.3.2. 필수 주석

24.3.2.1. 개요

Java 코드에서 서비스를 생성하려면 코드에 주석을 하나만 추가해야 합니다. SEI 및 구현 클래스 모두에 @WebService 주석을 추가해야 합니다.

24.3.2.2. @WebService 주석

@WebService 주석은 javax.jws.WebService 인터페이스에서 정의되며 인터페이스 또는 서비스로 사용할 클래스에 배치됩니다. @WebService 에 설명 된 속성이 있습니다. 표 24.1. “@WebService 속성”

표 24.1. @WebService 속성
속성설명

name

서비스 인터페이스의 이름을 지정합니다. 이 속성은 WSDL 계약에서 서비스 인터페이스를 정의하는 wsdl:portType 요소의 name 속성에 매핑됩니다. 기본값은 구현 클래스 이름에 PortType 을 추가하는 것입니다.[a]

targetNamespace

서비스가 정의된 대상 네임스페이스를 지정합니다. 이 속성을 지정하지 않으면 대상 네임스페이스는 패키지 이름에서 파생됩니다.If this property is not specified, the target namespace is derived from the package name.

serviceName

게시된 서비스의 이름을 지정합니다. 이 속성은 게시된 서비스를 정의하는 wsdl:service 요소의 name 속성에 매핑됩니다. 기본값은 서비스 구현 클래스의 이름을 사용하는 것입니다.

wsdlLocation

서비스의 WSDL 계약이 저장되는 URL을 지정합니다. 상대 URL을 사용하여 지정해야 합니다. 기본값은 서비스가 배포되는 URL입니다.

endpointInterface

구현 클래스에서 구현하는 SEI의 전체 이름을 지정합니다. 이 속성은 서비스 구현 클래스에서 특성이 사용되는 경우에만 지정됩니다.

portName

서비스가 게시되는 끝점의 이름을 지정합니다. 이 속성은 게시된 서비스의 끝점 세부 정보를 지정하는 wsdl:port 요소의 name 속성에 매핑됩니다. 기본값은 서비스 구현 클래스 이름에 추가 포트입니다.

[a] SEI에서 WSDL을 생성할 때 구현 클래스 이름 대신 인터페이스의 이름이 사용됩니다.
참고

@WebService 주석 속성의 값을 제공할 필요가 없습니다. 그러나 가능한 한 많은 정보를 제공하는 것이 좋습니다.

24.3.2.3. SEI에 주석 달기

SEI에서는 @WebService 주석을 추가해야 합니다. SEI는 서비스를 정의하는 계약이므로 @WebService 주석 속성에서 서비스에 대해 가능한 한 자세히 지정해야 합니다.

예 24.3. “@WebService 주석과 인터페이스”@WebService 주석을 사용하여 예 24.1. “간단한 SEI” 에 정의된 인터페이스를 표시합니다.

예 24.3. @WebService 주석과 인터페이스

package com.fusesource.demo;

import javax.jws.*;

@WebService(name="quoteUpdater",
            targetNamespace="http://demos.redhat.com",
	        serviceName="updateQuoteService",
            wsdlLocation="http://demos.redhat.com/quoteExampleService?wsdl",
            portName="updateQuotePort")
public interface quoteReporter
{
  public Quote getQuote(String ticker);
}

예 24.3. “@WebService 주석과 인터페이스”@WebService 주석은 다음과 같습니다.

서비스 인터페이스를 정의하는 wsdl:portType 요소의 name 속성 값이 quoteUpdater 임을 지정합니다.

서비스의 대상 네임스페이스가 http://demos.redhat.com 임을 지정합니다.

게시된 서비스를 정의하는 wsdl:service 요소의 값이 updateQuoteService 임을 지정합니다.

서비스가 http://demos.redhat.com/quoteExampleService?wsdl 에서 WSDL 계약을 게시하도록 지정합니다.

서비스를 노출하는 엔드포인트를 정의하는 wsdl:port 요소의 name 속성 값이 updateQuotePort 임을 지정합니다.

24.3.2.4. 서비스 구현에 주석 달기

@WebService 주석으로 SEI에 주석을 추가하는 것 외에도 @WebService 주석을 사용하여 서비스 구현 클래스에 주석을 달아야 합니다. 서비스 구현 클래스에 주석을 추가할 때 endpointInterface 속성만 지정해야 합니다. 예 24.4. “주석이 달린 서비스 구현 클래스” 에 표시된 대로 속성은 SEI의 전체 이름으로 설정해야 합니다.

예 24.4. 주석이 달린 서비스 구현 클래스

package org.eric.demo;

import javax.jws.*;

@WebService(endpointInterface="com.fusesource.demo.quoteReporter")
public class stockQuoteReporter implements quoteReporter
{
public Quote getQuote(String ticker)
  {
  ...
  }
}

24.3.3. 선택적 주석

초록

@WebService 주석은 Java 인터페이스 또는 Java 클래스를 활성화하는 서비스에 충분하지만 서비스 공급자로 서비스가 노출되는 방법을 완전히 설명하지는 않습니다. JAX-WS 프로그래밍 모델은 사용하는 바인딩과 같이 서비스에 대한 세부 정보를 Java 코드에 추가하는 데 다양한 선택적 주석을 사용합니다. 이러한 주석을 서비스의 SEI에 추가합니다.

SEI에 제공하는 세부 정보가 많을수록 개발자가 정의하는 기능을 사용할 수 있는 애플리케이션을 더 쉽게 구현할 수 있습니다. 또한 도구에서 생성된 WSDL 문서를 보다 구체적으로 만듭니다.

24.3.3.1. 개요

주석을 사용하여 바인딩 속성 정의

서비스에 SOAP 바인딩을 사용하는 경우 JAX-WS 주석을 사용하여 여러 바인딩 속성을 지정할 수 있습니다. 이러한 속성은 서비스의 WSDL 계약에 지정할 수 있는 속성에 직접 해당합니다. 매개 변수 스타일과 같은 일부 설정은 메서드를 구현하는 방법을 제한할 수 있습니다. 이러한 설정은 메서드 매개 변수에 주석을 달 때 사용할 수 있는 주석에도 영향을 미칠 수 있습니다.

24.3.3.2. @SOAPBinding 주석

@SOAPBinding 주석은 javax.jws.soap.SOAPBinding 인터페이스에서 정의됩니다. 배포 시 서비스에서 사용하는 SOAP 바인딩에 대한 세부 정보를 제공합니다. @SOAPBinding 주석을 지정하지 않으면 래핑된 doc/literal SOAP 바인딩을 사용하여 서비스가 게시됩니다.

SEI 및 SEI의 메서드에 @SOAPBinding 주석을 넣을 수 있습니다. 메서드에서 사용하는 경우 메서드의 @SOAPBinding 주석이 설정됩니다.

표 24.2. “@SOAPBinding 속성” @SOAPBinding 주석의 속성을 표시합니다.

표 24.2. @SOAPBinding 속성
속성설명

style

style.DOCUMENT(기본값)

Style.RPC

SOAP 메시지의 스타일을 지정합니다. RPC 스타일을 지정하면 SOAP 본문 내의 각 메시지 부분이 매개변수 또는 반환 값이며 soap:body 요소 내의 래퍼 요소 내에 표시됩니다. 래퍼 요소 내의 메시지 부분은 작업 매개 변수에 해당하며 작업의 매개변수와 동일한 순서로 표시되어야 합니다. DOCUMENT 스타일을 지정 하는 경우 SOAP 본문의 내용은 유효한 XML 문서 여야 하지만 폼이 엄격한 제한 되지 않습니다.If DOCUMENT style is specified, the contents of the SOAP body must be a valid XML document, but its form is not as tightly constrained.

Use

use.LITERAL(기본값)

Use.ENCODED[a]

SOAP 메시지의 데이터를 스트리밍하는 방법을 지정합니다.Specifies how the data of the SOAP message is streamed.

parameterStyle [b]

ParameterStyle.BARE

ParameterStyle.WRAPPED (기본값)

WSDL 계약의 메시지 부분에 해당하는 메서드 매개 변수가 SOAP 메시지 본문에 배치되는 방법을 지정합니다.Specifies how the method parameters, which correspond to message parts in a WSDL contract, are placed into the SOAP message body. BARE를 지정하면 각 매개 변수가 메시지 본문에 메시지 루트의 하위 요소로 배치됩니다. WRAPPED를 지정하면 모든 입력 매개 변수가 요청 메시지의 단일 요소로 래핑되고 모든 출력 매개 변수는 응답 메시지의 단일 요소로 래핑됩니다.

[a] Use.ENCODED는 현재 지원되지 않습니다.
[b] 스타일 을 RPC로 설정하는 경우 WRAPPED 매개변수 스타일을 사용해야 합니다.

24.3.3.3. 문서 베어 스타일 매개변수

문서 베어 스타일은 Java 코드 간의 가장 직접적인 매핑이며 서비스의 결과 XML 표현입니다. 이 스타일을 사용하면 작업의 매개 변수 목록에 정의된 입력 및 출력 매개변수에서 스키마 유형이 직접 생성됩니다.

style 속성이 Style.DOCUMENT로 설정된 @SOAPBinding 주석을 사용하여 베어 문서\literal 스타일 을 사용하고 해당 parameterStyle 속성을 ParameterStyle.BARE로 설정하도록 지정합니다.

베어 매개 변수를 사용할 때 문서 스타일 사용 제한 사항을 위반하지 않도록 하려면 작업이 다음 조건을 준수해야 합니다.

  • 작업에는 입력 또는 입력/출력 매개변수가 두 개 이상 있어야 합니다.
  • 작업에 void 이외의 반환 유형이 있는 경우 출력 또는 입력/출력 매개변수가 없어야 합니다.
  • 작업에 void 의 반환 유형이 있는 경우 출력 또는 입력/출력 매개 변수가 없어야 합니다.
참고

@WebParam 주석 또는 @WebResult 주석을 사용하여 SOAP 헤더에 배치된 모든 매개변수는 허용된 매개 변수 수에 대해 계산되지 않습니다.

24.3.3.4. 래핑된 매개변수 문서

문서 래핑 스타일을 사용하면 Java 코드 간 매핑과 서비스의 결과 XML 표현과 같은 더 많은 RPC를 사용할 수 있습니다. 이 스타일을 사용하면 메서드의 매개 변수 목록의 매개 변수가 바인딩에 의해 단일 요소로 래핑됩니다. 이 문제의 단점은 Java 구현 간의 간접 계층과 메시지가 유선에 배치되는 방식을 도입한다는 것입니다.

래핑된 document\literal 스타일을 사용하도록 지정하려면 style 속성이 Style.DOCUMENT로 설정된 @SOAPBinding 주석을 사용하고 해당 parameterStyle 속성을 ParameterStyle.WRAPPED로 설정합니다.

“@RequestWrapper 주석” 주석 및 “@ResponseWrapper 주석” 주석을 사용하여 래퍼를 생성하는 방법을 제어할 수 있습니다.

24.3.3.5. 예제

예 24.5. “SOAP Binding Annotation을 사용하여 문서 Bare SOAP 바인딩 지정” 문서 베어 SOAP 메시지를 사용하는 SEI를 보여줍니다.

예 24.5. SOAP Binding Annotation을 사용하여 문서 Bare SOAP 바인딩 지정

package org.eric.demo;

import javax.jws.*;
import javax.jws.soap.*;
import javax.jws.soap.SOAPBinding.*;

@WebService(name="quoteReporter")
@SOAPBinding(parameterStyle=ParameterStyle.BARE)
public interface quoteReporter
{
  ...
}

24.3.3.6. 개요

주석을 사용하여 작업 속성 정의

런타임이 Java 메서드 정의를 XML 작업 정의에 매핑하면 다음과 같은 세부 정보를 제공합니다.

  • 교환된 메시지는 XML에서 어떻게 보이는지
  • 메시지를 한 가지 방법으로 최적화할 수 있는 경우
  • 메시지가 정의된 네임스페이스

24.3.3.7. @WebMethod 주석

@WebMethod 주석은 javax.jws.WebMethod 인터페이스에서 정의됩니다. SEI의 메서드에 배치됩니다. @WebMethod 주석은 메서드가 연결된 작업을 설명하는 wsdl:operation 요소에 일반적으로 표시되는 정보를 제공합니다.

표 24.3. “@WebMethod Properties” @WebMethod 주석의 속성을 설명합니다.

표 24.3. @WebMethod Properties
속성설명

operationName

관련 wsdl:operation 요소의 이름 의 값을 지정합니다. 기본값은 메서드의 이름입니다.

작업

메서드에 대해 생성된 soap:operation 요소의 soapAction 특성 값을 지정합니다. 기본값은 빈 문자열입니다.

exclude

메서드를 서비스 인터페이스에서 제외해야 하는지 여부를 지정합니다. 기본값은 false입니다.

24.3.3.8. @RequestWrapper 주석

@RequestWrapper 주석은 javax.xml.ws.RequestWrapper 인터페이스에서 정의됩니다. SEI의 메서드에 배치됩니다. @RequestWrapper 주석은 메시지 교환을 시작하는 요청 메시지의 메서드 매개변수에 래퍼 빈을 구현하는 Java 클래스를 지정합니다. 또한 요청 메시지를 마샬링 및 해제할 때 런타임에서 사용하는 요소 이름과 네임스페이스를 지정합니다.

표 24.4. “@RequestWrapper 속성” @RequestWrapper 주석의 속성을 설명합니다.

표 24.4. @RequestWrapper 속성
속성설명

localName

요청 메시지의 XML 표현에 래퍼 요소의 로컬 이름을 지정합니다.Specifies the local name of the wrapper element in the XML representation of the request message. 기본값은 메서드의 이름 또는 “@WebMethod 주석” 주석의 operationName 속성 값입니다.

targetNamespace

XML 래퍼 요소가 정의된 네임스페이스를 지정합니다. 기본값은 SEI의 대상 네임스페이스입니다.

className

래퍼 요소를 구현하는 Java 클래스의 전체 이름을 지정합니다.

참고

className 속성만 필요합니다.

중요

메서드에 @SOAPBinding 주석을 추가하고 해당 parameterStyle 속성이 ParameterStyle.BARE 로 설정된 경우 이 주석은 무시됩니다.

24.3.3.9. @ResponseWrapper 주석

@ResponseWrapper 주석은 javax.xml.ws.ResponseWrapper 인터페이스에서 정의됩니다. SEI의 메서드에 배치됩니다. @ResponseWrapper 는 메시지 교환의 응답 메시지에 메서드 매개 변수에 대한 래퍼 빈을 구현하는 Java 클래스를 지정합니다. 또한 응답 메시지를 마샬링 및 해제할 때 런타임에서 사용하는 요소 이름 및 네임스페이스를 지정합니다.

표 24.5. “@ResponseWrapper 속성” @ResponseWrapper 주석의 속성을 설명합니다.

표 24.5. @ResponseWrapper 속성
속성설명

localName

응답 메시지의 XML 표현에 래퍼 요소의 로컬 이름을 지정합니다.Specifies the local name of the wrapper element in the XML representation of the response message. 기본값은 Response가 추가된 메서드의 이름 또는 Response가 추가된 “@WebMethod 주석” 주석의 operationName 속성 값입니다.

targetNamespace

XML 래퍼 요소가 정의된 네임스페이스를 지정합니다. 기본값은 SEI의 대상 네임스페이스입니다.

className

래퍼 요소를 구현하는 Java 클래스의 전체 이름을 지정합니다.

참고

className 속성만 필요합니다.

중요

@SOAPBinding 주석에도 메서드에 주석이 추가되고 해당 parameterStyle 속성이 ParameterStyle.BARE 로 설정된 경우 이 주석은 무시됩니다.

24.3.3.10. @WebFault 주석

@WebFault 주석은 javax.xml.ws.WebFault 인터페이스에서 정의됩니다. SEI에서 throw되는 예외에 적용됩니다. @WebFault 주석은 Java 예외를 wsdl:fault 요소에 매핑하는 데 사용됩니다. 이 정보는 서비스 및 소비자 둘 다 처리할 수 있는 표현으로 예외를 마샬링하는 데 사용됩니다.

표 24.6. “@WebFault Properties” @WebFault 주석의 속성을 설명합니다.

표 24.6. @WebFault Properties
속성설명

name

fault 요소의 로컬 이름을 지정합니다.

targetNamespace

fault 요소가 정의된 네임스페이스를 지정합니다.Specifies the namespace under which the fault element is defined. 기본값은 SEI의 대상 네임스페이스입니다.

faultName

예외를 구현하는 Java 클래스의 전체 이름을 지정합니다.

중요

name 속성이 필요합니다.

24.3.3.11. @Oneway 주석

@Oneway 주석은 javax.jws.Oneway 인터페이스에서 정의됩니다. 서비스의 응답이 필요하지 않은 SEI의 메서드에 배치됩니다. @Oneway 주석은 응답을 기다리지 않고 응답을 처리하는 리소스를 예약하지 않고 메서드 실행을 최적화할 수 있음을 런타임에 지시합니다.

이 주석은 다음 기준을 충족하는 방법에서만 사용할 수 있습니다.

  • void를 반환합니다.
  • holder 인터페이스를 구현하는 매개 변수가 없습니다.
  • 소비자로 다시 전달할 수 있는 예외는 throw되지 않습니다.

24.3.3.12. 예제

예 24.6. “Annotated methods가 있는 SEI” 주석이 달린 메서드가 포함된 SEI를 표시합니다.

예 24.6. Annotated methods가 있는 SEI

package com.fusesource.demo;

import javax.jws.*;
import javax.xml.ws.*;

@WebService(name="quoteReporter")
public interface quoteReporter
{
  @WebMethod(operationName="getStockQuote")
  @RequestWrapper(targetNamespace="http://demo.redhat.com/types",
                  className="java.lang.String")
  @ResponseWrapper(targetNamespace="http://demo.redhat.com/types",
                   className="org.eric.demo.Quote")
  public Quote getQuote(String ticker);
}

24.3.3.13. 개요

주석을 사용하여 매개 변수 속성 정의

SEI의 메서드 매개 변수는 wsdl:message 요소와 wsdl:part 요소에 해당합니다. JAX-WS는 메서드 매개 변수에 대해 생성된 wsdl:part 요소를 설명할 수 있는 주석을 제공합니다.

24.3.3.14. @WebParam 주석

@WebParam 주석은 javax.jws.WebParam 인터페이스에서 정의됩니다. SEI에 정의된 메서드의 매개 변수에 배치됩니다. @WebParam 주석을 사용하면 매개 변수가 SOAP 헤더에 배치될 경우 매개 변수의 방향을 지정하고 생성된 wsdl:part 의 기타 속성을 지정할 수 있습니다.

표 24.7. “@WebParam 속성” @WebParam 주석의 속성을 설명합니다.

표 24.7. @WebParam 속성
속성설명

name