작업 클래스를 사용하여 정책을 요청에 적용하는 요청을 분류합니다. 요청에 적용되는 정책에는 라우팅과 서비스의 두 가지 유형이 있습니다. HTTP 및 SOAP 요청에 대한 라우팅 정책을 작성할 수 있습니다. HTTP, IIOP, SOAP 및 JMS 요청에 대한 서비스 정책을 작성할 수 있습니다. 이와 함께 작업 클래스에는 JMS를 제외한 두 가지 정책 유형에 대한 분류 규칙이 포함될 수 있습니다. 분류 규칙은 JMS 작업 클래스을 지원하지 않습니다. 작업 클래스에 대한 라우팅 및 서비스 정책은 z/OS에 전개된 응용프로그램의 IIOP 및 JMS를 지원하지 않습니다. WebSphere Application Server z/OS에서는 IIOP 및 JMS 서비스 분류를 제공합니다.
라우팅 정책 | 설명 |
---|---|
permit:<application_name> | 이 라우팅 정책에서 application_name은 선택적 에디션 지정자를 사용하여 라우트할 응용프로그램 이름입니다. 이를 통해 요청을 정상적으로 계속 진행할 수 있습니다. |
permitsticky:<application_name> | permitsticky 라우팅 정책은 On Demand Router가 동일한 클라이언트에서 오는 이후 요청의 서버 유사성에 따라 클라이언트를 유지보수한다는 점을 제외하면 permit 라우팅 정책과 동일합니다. 이 경우 ODR은 클라이언트에 응답을 전송하기 전에 먼저 응답에 SET-COOKIE 헤더를 추가합니다. |
reject:<HTTP_error_code> | 이 라우팅 정책으로 인해 ODR은 지정한 HTTP 오류 코드가 있는 모든 요청을 거부합니다. 예를 들어 reject:503은 503 서비스 사용 불가능 오류를 리턴합니다. |
redirect:<URL> | 이 라우팅 정책에서는 ODR이 지정된 URL로 요청 경로를 재지정합니다. URL의 패턴은 protocol:// ;입니다. 유효한 URL 예제는 http://w3.ibm.com입니다. |
유효한 서비스 정책는 단순히 트랜잭션 클래스 이름 목록입니다. 트랜잭션 클래스는 단일 서비스 클래스를 참조합니다.
작업 클래스에는 네 개의 유형이 있습니다.
작업 클래스 | 설명 |
---|---|
응용프로그램 라우팅 정책 | WebSphere Extended Deployment에 설치된 응용프로그램에 대한 요청의 라우팅 정책을 판별하는 방법을 지정합니다. |
응용프로그램 서비스 정책 | WebSphere Extended Deployment에 설치된 응용프로그램에 대한 요청의 서비스 정책을 판별하는 방법을 지정합니다. |
일반 서버 클러스터 라우팅 정책 | 일반 서버 클러스터에 대한 요청의 라우팅 정책을 판별하는 방법을 지정합니다. |
일반 서버 클러스터 서비스 정책 | 일반 서버 클러스터에 대한 요청의 서비스 정책을 판별하는 방법을 지정합니다. |
다음 다이어그램에서는 WebSphere Extended Deployment에 설치된 응용프로그램을 대상으로 지정한 요청 플로우를 설명합니다. 요청은 응용프로그램 라우팅 정책 작업 클래스에 적용되어 라우팅 정책을 판별합니다. 결과 라우팅 정책이 permit 또는 permitsticky인 경우 응용프로그램 서비스 정책 작업 클래스에 대한 요청은 계속해서 서비스 정책 및 트랜잭션 클래스 이름을 판별합니다.
각 응용프로그램에는 기존 응용프로그램 라우팅 및 응용프로그램 서비스 정책 작업 클래스가 포함됩니다. 또한 기본이 아닌 추가 작업 클래스를 작성할 수도 있습니다. 각 작업 클래스에는 기본 대응 조치가 있습니다. 응용프로그램의 기본 라우팅 정책은 permit:<application_name>입니다. 기본 서비스 정책은 Default_TC, 기본 트랜잭션 클래스입니다.
각 작업 클래스는 해당 요청의 정책을 판별하도록 특정 요청에서 평가하는, 선택적으로 정렬된 규칙 목록을 포함합니다. 각 규칙은 부울 표현식 및 정책 값으로 구성됩니다. 특정 요청의 표현식을 true로 평가하면 해당 규칙에 연관된 정책을 사용합니다.
규칙의 부울 표현식에 대한 구문과 시멘틱은 SQL(Structured Query Language) 표현식의 WHERE절과 비슷합니다. 더 정확히 말하면 표현식 구문은 JMS(Java Message Service) 1.1 스펙에서 정의됩니다. 자세한 정보는 ODR 규칙 기반 요청 분류를 참조하십시오.
JMS 스펙에서 ID는 요청에 연관될 수 있는 다양한 속성(예: 특정 조회 매개변수, 쿠키 또는 HTTP 헤더)을 참조합니다. JMS ID는 요청 변수나 피연산자로 간주될 수 있습니다. 이 피연산자는 프로토콜에만 한정될 수 있습니다. 예를 들어 SOAP 서비스 이름은 SOAP 작업 클래스에서만 유효한 피연산자입니다.
피연산자 목록은 동적이지만 여기에 나열된 피연산자는 기본적인 피연산자입니다. 좀 더 학습하려면 확장 목록을 지원하는 제품의 문서를 검토하십시오. 다음 테이블에서는 피연산자 및 연관 프로토콜을 나열합니다.
요청 변수 | 유효한 프로토콜 | 설명 |
---|---|---|
|
IIOP | EJB가 포함되는 엔터프라이즈 응용프로그램의 이름. |
clienthost | HTTP SOAP
|
완전한 클라이언트 호스트 이름. IP(Internet Protocol) 명령 호스트 이름의 값입니다. 이 피연산자는 >, >=, <, <=와 같은 숫자 연산자는 지원하지 않습니다. |
|
IIOP | 클라이언트 포트 이름. |
clientipv4 | HTTP SOAP |
인터넷 프로토콜 버전 4(IPv4)의 네 개 숫자를 점으로 분리한 주소 유형(n.n.n.n)을 사용하는 클라이언트 시스템의 IP 주소. |
clientipv6 | HTTP SOAP |
클라이언트 시스템의 RFC 1924 뒤에 나오는 인터넷 프로토콜 버전 6(IPv6) 128비트 주소 유형(x:x:x:x:x:x:x:x). |
cookie$<name> | HTTP SOAP |
쿠키 이름. 예를 들어 표현식
cookie$My_Cookie_Name='My_Cookie_Value'는 이름이 My_Cookie_Name이고
값이 My_Cookie_Value인 쿠키를 포함하는지 파악하기 위한 요청을 테스트합니다. 특정 쿠키의 존재 여부를
테스트하려면 다음 표현식 중 하나를 사용하십시오. cookie$MyCookieName IS NOT NULL cookie$MyCookieName IS NULL |
|
IIOP | EJB의 모듈 이름. |
|
IIOP | EJB 이름. |
|
IIOP | EJB 내에 있는 메소드 이름. |
gid | HTTP SOAP |
요청 전송자의 그룹 ID. |
header $<name> | HTTP SOAP |
헤더 이름 및 값. 예를 들어 표현식
header$Host='localhost'는 값이 localhost인 HTTP 호스트 헤더를
포함하는지 파악하기 위한 요청을 테스트합니다. 호스트 헤더의 존재 여부를 테스트하려면 다음 표현식 중 하나를 사용하십시오. cookie$Host IS NOT NULL cookie$Host IS NULL |
HTTPMethod | HTTP SOAP |
요청의 HTTP 메소드. 가능한 값은 POST, GET, PUT 및 DELETE입니다. |
MIMEType | HTTP SOAP |
요청의 MIME 유형. |
operation | SOAP | 웹 서비스 조작 이름. |
port | HTTP SOAP IIOP |
요청을 수신하는 청취 포트. |
protocol | HTTP SOAP |
요청을 전송하는 통신 프로토콜. 현재 지원되는 프로토콜은 HTTP, HTTPS, SOAP 및 SOAPS입니다. |
queryparm$<name> | HTTP SOAP |
헤더 이름 및 값. 예를 들어 표현식
queryparm$timezone='EST'는 이름이 timezone이고 값이 EST인
HTTP 조회 매개변수를 포함하는지 파악하기 위한 요청을 테스트합니다. 조회 매개변수의 존재 여부를
테스트하려면 다음 양식 중 하나를 사용하십시오. queryparm$timezone IS NOT NULL queryparm$timezone IS NULL |
serverhost | HTTP SOAP
|
서버의 완전한 호스트 이름. 이 피연산자는 >, >=, <, <=와 같은 숫자 연산자는 지원하지 않습니다. |
serveripv4 | HTTP SOAP |
IPv4의 네 개 숫자를 점으로 분리한 주소 유형(n.n.n.n)을 사용하는 서버 시스템의 IP 주소. |
serveripv6 | HTTP SOAP |
서버 시스템의 RFC 1924 뒤에 나오는 IPv6 128비트 주소 유형( x:x:x:x:x:x:x:x). |
service | SOAP |
웹 서비스 이름. |
uid | HTTP SOAP |
요청 전송자의 사용자 ID. |
clienthost LIKE '%.ibm.com''%.ibm.com'은 요청의 클라이언트 호스트 이름을 비교할 때 사용하는 리터럴입니다. 이 표현식은 ibm.com 도메인의 시스템에서 나온 모든 요청을 true로 평가합니다. 문자열 리터럴를 작은 따옴표로 묶으십시오. 숫자 리터럴은 작은 따옴표로 묶지 마십시오. AND, OR 및 NOT 연산자를 묶는 괄호는 복합 부울 표현식을 구성할 때 사용할 수 있습니다. 자세한 설명은 JMS 1.1 스펙을 참조하십시오.
WebSphere Extended Deployment는 규칙 표현식에서 아래 연산자를 지원합니다. 이 연산자는 WHERE 또는 HAVING 절 내부에 표시되므로 SQL 용어에서 술부로 참조되기도 합니다. 연산자는 대소문자를 구분하지 않습니다.
연산자 | 설명 |
---|---|
OR | OR 논리 연산자. |
AND | AND 논리 연산자. |
NOT | 부정 연산자. |
IN | 단일 표현식에서 여러 값을 포함하는 피연산자를
표현합니다. 이 연산자의 의미는 연산자의 SQL 표준 의미와
일관됩니다. 예를 들어, port라는 피연산자가 있고
사용자가 port 값을 9080, 9090, 9091 값 중 일부 또는 모두로 표시하려는 경우
표현식 단편은 다음과 같습니다 . port IN (9080,9090,9091) SQL에서
대괄호 안의 값이 표현되는 방법은 port의 데이터 유형에 따라
다릅니다. port가 정수이면 작은 따옴표(')로 묶지 않은 값이 올바른 구문입니다.
포트가 문자열인 경우 올바른 표현식은 다음과 같습니다.
port IN (‘9080’, ‘9090’, ‘9091’) |
LIKE | 문자열 피연산자 값 및 그 의미와 일치하는 패턴을 표현하며 사용법은 SQL 언어에서
정의한 사용법과 일치합니다.
값은 패턴이 일치하기 시작하는 예상 위치에 와일드 카드(%)를 포함해야
합니다. 예를 들어
host LIKE %blanca표현식은 blanca 단어나 blanca로 끝나는 다른 단어와 일치하며, host LIKE blanca%표현식은 blanca 또는 blanca로 시작하는 다른 단어와 일치합니다. host LIKE %blanca%표현식은 blanca 단어나 blanca 토큰이 들어 있는 단어와 일치합니다. 코드 구현 관점에서 java.util.regex.Pattern 클래스가 사용됩니다. |
= | 대소문자 구분 방식으로 일치를 표현하는 등호 연산자. |
> | 숫자 피연산자와 함께 사용되어 초과를 표시하는 연산자. |
>= | 숫자 피연산자와 함께 사용되어 이상을 표시하는 연산자. |
< | 숫자 피연산자와 함께 사용되어 미만을 표시하는 연산자. |
<= | 숫자 피연산자와 함께 사용되어 이하를 표시하는 연산자. |
< > | 같지 않음 연산자. |
BETWEEN | AND와 함께 사용되어 첫 번째 값(낮은 값)과 마지막(높은 값) 값의 경계를 포함하는 값 범위를 선택합니다. 이 두 개의 연산자를 함께 사용하면 숫자 및 날짜 값으로 작동합니다. |
IS NULL | 피연산자에 NULL 값이 들어 있는지 테스트합니다. |
IS NOT NULL | 피연산자에 NULL 이외의 값이 들어 있는지 테스트합니다. |
Related concepts
ODR 규칙 기반 요청 분류
Related tasks
서비스 정책 정의
동시 에디션 활성화
에디션 유효성 검증