소개

Media Extender for WebSphere Process Server(Media Extender)는 매체 컨텐트를 처리하는 워크플로우에서 컴포넌트로 사용할 수 있는 확장된 서비스 중개 기능을 제공한다. 이를 통해 효율적이고 동적인 리치 컨텐트 관리를 위해 비즈니스와 컨텐트 시스템을 함께 통합할 수 있다. Media Extender 버전 6.2와 비교하여 많은 새 기능이 7.0에서 구현되어 WebSphere BPM&C 포트폴리오와 더 원활하게 통합하고 컨텐트 인식 경로 지정 및 관리의 기능을 개선한다.

이 기사는 ASD(Abstract Service Definition) 매체 서비스 인터페이스의 채택, Media Hub Solution의 진화, MxLookup의 강화, 삽입된 서비스의 Quality of Service(QoS) 요구사항의 제어 기능, 매체 프로세스 워크플로우 의사결정에서 사용자 지정 매체 메타데이터 지원 및 서비스 경로 지정에 영향 주는 것을 비롯하여 Media Extender v7.0에서의 새 기능과 함수 등을 다룬다.

독자들은 WebSphere Process Server/WebSphere Enterprise Service Bus/WebSphere Integration Developer(WPS/WESB/WID)에 대한 어느 정도의 기술 경험과 매체 컨텐트와 서비스에 대한 어느 정도의 지식이 있어야 한다. "Media Extender for WebSphere Process Server 시작하기, Part 1: 개요" 기사에 익숙하다고 가정한다.

위로

Media Extender에서 ASD 사용법

ASD 소개

ASD(Abstract Service Definition for Media Services)는 적절한 추상 레벨로 각 서비스의 특정 구현에서부터 매체 서비스의 클래스에 독립적으로 액세스하는 유연하고 확장 가능한 메커니즘을 제공한다. 이는 SOA 원칙의 인식을 허용하고, 통합을 간소화하며 매체 조작과 관련된 메타데이터의 복잡도를 고려하여 적절한 중개를 제공한다. ISV는 ASD를 사용하여 원하는 매체 기능을 제공하는 서비스 구현에 집중할 수 있다. ASD를 통해 Media Service Bus, 다른 ISV나 고객 서비스와 상호 운용에 더 쉽게 연결할 수 있으며 확장성과 결함/오류 처리가 더 원활해질 수 있다.

다음 11개의 서비스 인터페이스 정의로 일반적인 매체 조작을 다룬다.

• 트랜스코더 - 하나의 매체 형식을 다른 형식으로의 변환을 수행하거나 아날로그 소스에서부터 디지털 매체 형식으로 인코드하기
• 워터마크 - 디지털 매체 파일에서 고유의 워터마크 임베드하기
• 전송 - 하나의 서버에서부터 다른 서버로 대용량 매체 파일의 데이터 이동을 수행하기
• 저장소(디지털 자산 관리) - 새 자산을 추가, 검색하거나 카탈로그나 저장소의 기존 디지털 자산을 관리하기
• 매체 확인 - 분석을 수행하거나, 대개 품질 보증 프로세스의 일환으로 디지털 매체 파일의 구체적인 특징 확인하기
• 지문 - 디지털 매체 파일의 법적인 지문 분석 수행하기
• 실제 자산 관리(PAM) - 카탈로그 또는 저장소에서 새 자산을 추가하거나 기존 실제 자산(예: 비디오 또는 오디오 테이프)을 관리하기
• 자원 스케줄러 - 새로 스케줄하거나 현재 사용 가능한 자원을 관리하기
• 게시 - 디지털 매체를 하나 이상의 배포 채널로 패키지화하고 게시하는 것을 수행하기
• 편집 - 디지털 매체의 비선형 편집(NLE) 프로세스를 관리하도록 돕기
• 디지털 권한 관리(DRM) - 매체 자산 지적 재산권을 관리하여 불법적 복사 또는 다른 형식으로의 변환을 방지하도록 돕기

ASD가 Media Extender v7.0 채택됨

Media Extender와 함께 제공되는 2개의 비서비스(non service) 게이트웨이 중개 플로우와 샘플 SubProcessBP가 ASD를 지원하기 위해 제공된다.

SubProcessBP에서 삽입된 서비스 처리는 ASD 정의를 기반으로 한다. SubprocessBP는 ASD 정의된 메시지 구조에서부터 MPEG-21 "didl:Container"를 추출하고 이를 삽입된 서비스의 요청 메시지로 맵핑한다. 삽입된 각 서비스는 ASD에서 정의한 서비스 분류, 포트 유형, 포트 유형 네임스페이스 및 호출 유형을 기반으로 확인하고, 일치하는 프로세스 브랜치로 전파한다. 삽입된 각 서비스 요청 메시지는 ASD 정의됨으로 조직된다. 그리고 서비스 호출의 결함 처리는 ASD의 권장을 따르는 결함/예외 메시지를 패키지화할 것이다.

실제로 SubprocessBP도 비ASD 지원되는 삽입된 서비스를 지원한다. 고객이 트랜스코더를 사용하고 전송 서비스가 비ASD 지원되면, 비ASD 서비스와 ASD 서비스 사이의 맵핑이 있어야 한다. 샘플 SCA 모듈 어셈블리는 그림 1과 같다.

ASD Repository 서비스 인터페이스를 사용하는 2개의 구체적인 서비스(비서비스 게이트웨이) 중개 플로우는 매체 형식이나 위치 불일치가 있는 경우에, 매체 처리 Repository 검색을 달성하고 호출 Repository에 대한 실행 계획을 구성하도록 Media Extender와 기본 WESB로 제공되는 프리미티브를 어셈블리하는 방법을 입증한다.

ASD에 정의된 각 인터페이스는 다음 두 개의 버전으로 존재한다.

• 서비스 요청에 간단한 응답 메시지가 있는 경우의 요청/응답(RR). 인터페이스의 이 스타일은 비즈니스 워크플로우에서 사용하기에 간단하다.
• 초기 응답이 요청의 인식이고 실제 서비스 응답이 콜백으로 제공되는 비동기 알림을 통한 동기 요청/응답(RRN) 패턴. 이 인터페이스의 스타일은 서비스 구현으로 사용하기에 더 간단할 수 있다.

어댑터가 인터페이스의 두 가지 스타일 사이에 변환하는 데 사용될 수 있으며, 이에 대한 예제는 Media Extender 패키지 내에 들어있는 ASDRRtoRRN 프로젝트에 제공된다. ASDRRtoRRN 프로젝트는 클라이언트 비즈니스 프로세스로 사용될 수 있는 SCA 바인딩이 있고, 어셈블리에서 가져오기 중 하나로 참조되는 연결에 따라 샘플 중개 중 하나를 호출할 수 있는 프록시 Repository를 표현하는 BPEL 프로세스가 들어있다. ASDRRtoRRN 애플리케이션은 어댑터로 작동하며, 요청/응답 스타일의 알림을 통한 요청/응답 스타일로의 변환을 처리한다. 이는 다른 서비스 인터페이스 변환에 대한 참조로서 사용될 수 있다.

샘플 ASD wsdl 파일과 서비스 설명 파일(*.Descr.xml)도 Media Extender 이미지에 포함되어 있다. 이는 파일 시스템 기반 서비스 레지스트리에 대해 사용될 수 있다.

위로

Media Hub Solution의 진화

Media Extender를 활용하기 위해 Media Extender 중개 플로우에서부터 출력 메시지를 승인하고 해석하는 서비스로 작동할 수 있는 하나의 시스템이 필요하다. Media Hub Workflow Builder Services Asset(Workflow Builder)는 Media Extender의 6.2 버전과 같이 이전 버전에서 이러한 지원을 제공한다. 클라이언트 워크플로우는 Workflow Builder 편집기와 Workflow Builder 런타임 엔진에서 해석되는 실행 계획에서 작성된다.

Media Extender v7.0은 서비스 자산을 통해 이러한 높은 의존성을 제거하여 제품은 WebSphere BPM&C 포트폴리오와 더 원활하게 통합될 수 있다. 클라이언트 워크플로우는 WebSphere Business Modeler(WBM)에서 모델링되고 WID에서 구성될 수 있었다. 실행 계획 구문 분석 및 서비스 호출 제어는 샘플 SubProcessBP에서 완료될 수 있으며, 이는 WPS에서 BPEL 애플리케이션 실행이다.

SubProcessBP 실행 계획 엔진

이 기사는 SubProcessBP 작업 메커니즘에 대한 간략한 소개를 제공할 것이며, 워크플로우 다이어그램은 그림 2와 같다. 여기에서는 명령문을 간소화하는 삽입된 전송과 대상 서비스 프로세스만 보여준다(이는 삽입된 트랜스코더 처리에 대해서도 적합함).

1단계에서 실행 계획은 메시지에서부터 추출되어 서비스 호출 순서를 제어할 것이다. 매체 메타데이터를 전달하는 MPEG-21 Container가 추출되고, 그 컴포넌트는 참조된 매체 파일을 처리하고 MPEG-21 설명을 업데이트하는 삽입된 서비스로 전송될 것이다. 실행 계획에서 서비스 인스턴스의 수는 2단계에서 보여주는 프로세스 루프를 제어하는데 사용될 것이다. SubProcessBP는 현재 서비스 인스턴스를 확인하고 3단계에서 일치하는 처리 브랜치를 찾을 것이다. 4단계에서 이는 삽입된 서비스 호출 준비를 완료하고, 원본 DID 컨테이너가 삽입된 서비스 요청 메시지의 DID 입력 매개변수로 맵핑되며, 콜백 매개변수는 RRN 서비스 유형에 대해 올바르게 설정되며, 서비스 엔드포인트 주소도 이 단계 중에 삽입된 서비스 동적 호출에 대해 준비된 상태이다. 요청 메시지가 5단계에서 삽입된 서비스로 전송될 것이다. 이 단계에서 결함 처리는 서비스 호출 도중에 비즈니스 결함 및 런타임 결함을 처리할 것이고, 추가 분석을 위해 결함 메시지를 클라이언트 워크플로우에 리턴할 것이다. RRN 서비스 유형의 경우 상관 세트가 콜백 메시지와 콜백이 필요한지 뽑는 추가 단계를 식별하는 데 사용될 것이다. 삽입된 서비스로부터의 결과는 이어지는 삽입된 서비스 또는 6단계에서 완료되는 최종 대상 서비스에 대비하여 DID 컨테이너를 업데이트하는 데 사용된다. 모든 삽입된 서비스가 처리되면 대상 서비스 호출은 7-8단계에서 수행될 것이고, SubProcessBP를 호출하는 중개 플로우를 통해 클라이언트 워크플로우로 결과에 응답할 것이다.

매체 지향 ESB를 달성하는 서비스 게이트웨이 중개

실제 매체 지향 ESB를 구현하기 위해 Media Extender는 클라이언트 워크플로우로부터의 요청을 처리하는 샘플 Service Gateway 중개 플로우를 제공하였다. 이는 Media Hub Solution의 두 번째 진화이다. 이는 하나의 게이트웨이 인터페이스를 사용하여 여러 요청을 승인하고 매체 인식 선택, 컨텐트 기반 경로 지정 및 서비스 동적 호출을 완료하는 WESB 서비스 게이트웨이 새 기능을 기반으로 한다. 매체 모듈 및 매체 플로우 어셈블리는 그림 3과 같다.

중개 모듈은 JMS 바인딩 입력을 승인하고 메시지를 직접적인 대상 서비스 호출 또는 SubProcessBP 실행 계획 처리로 경로 지정한다. 중개 플로우는 일반적인 매체 서비스 엔드포인트 선택, 실행 계획 기반 경로 지정을 다루고, 이후 섹션에서 논의할 강화된 엔드포인트 검색 및 삽입된 QoS의 기능을 입증한다.

두 가지의 "LocateTarget" MxEndpointLookup 지원 MPEG-21 DID 및 비DID 검색은 각각 대상 서비스를 사전 선택하는 데 사용된다. 쿼리 기준은 비DID 엔드포인트 검색에 대해 완화되어, 예를 들어, 서비스 ID 또는 포트 유형 및 분류만 사용한다. 하나 이상의 후보 서비스가 있으면 메시지는 QoS 매개변수로 필터 삽입된 서비스를 이동할 것이다. 여기에서는 예제로 필수 전송 우선순위가 있는 전송을 사용한다. 이 단계는 지정된 QoS 요구사항에 부합하는 삽입된 서비스의 세트를 사전 선택한다. 그 이후에 메시지가 실행 계획이라는 이름의 MxRules 프리미티브로 전파될 것이다. QoS로 구성된 실행 계획이나 직접적인 결과는 삽입된 서비스를 제한하여, 대상 서비스가 결과 출력이 될 것이다. 마지막으로 메시지는 다음 단계를 위해 적절한 콜아웃 노드로 전송할 것이다.

후보 대상 또는 실행 계획을 찾을 수 없는 경우, 메시지는 결함 처리 사용자 정의 프리미티브로 전파되고 결함 노드에 의해 클라이언트 워크플로우로 리턴될 것이다. 중개 응답 플로우에서 대상 서비스 또는 SubProcessBP의 정상 응답 및 결함 정보도 중개 결함 처리로 고려되고 클라이언트 워크플로우로 리턴될 것이다. 결함 처리 사용자 정의 프리미티브의 코드는 목록 1과 같다.

      
      //create fault message body 
      ServiceMessageObjectFactory factory = ServiceMessageObjectFactory.INSTANCE;
      DataObject newBody = factory.createServiceMessageObjectBody(
                        new QName("http://com.ibm.wemx/SoapFault","SoapFault"));
	
      // create faultBO
      DataObject exception = DataFactory.INSTANCE.create(
                          "http://schemas.xmlsoap.org/soap/envelope/", "Fault");
      exception.set("faultcode", 
                    "http://com.ibm.wemx/WEMXRulesServiceGatewayMd#RequestPathFault");
      exception.set("faultstring", 
                    smo.getContext().getFailInfo().getFailureString());
      exception.set("faultactor", 
                    "http://com.ibm.wemx/WEMXRulesServiceGatewayMd/RequestPathFault");
      exception.set("detail", smo.getContext().getFailInfo());
      newBody.set(0, exception);
      smo.setBody(newBody);
			

Service Gateway 중개에서 사용자는 구체적인 입력 메시지 유형을 무시하기 위해 Media Extender 프리미티브 특성의 xpath를 와일드카드 xpath 표현식으로 지정할 수 있다. "/body/*/RequestDID/Container.0"과 "/body/message/RequestDID/Container.0" 둘 다 지원된다.

위로

MxEndpointLookup의 강화

Media Extender v7.0이 소개하는 다른 새 기능은 MxEndpointLookup의 강화이다. 이전 버전에서 일반 사용자는 MxEndpointLookup 특성의 Xpath 디지털 항목을 지정해야 한다. 이는 수신되는 메시지의 DID 컨테이너를 가리켜야 한다. 일반 사용자는 비DID 메시지를 위해 ESB 엔드포인트 검색 프리미티브를 사용해야 한다. 버전 7.0에서 MxEndpointLookup은 WebSphere Service Registry and Repository(WSRR) 또는 파일 시스템 기반 서비스 레지스트리에서부터 비DID 및 DID 엔드포인트 검색을 훌륭하게 지원한다. 일반 사용자는 Xpath 디지털 항목을 공백으로 유지하고, MxEndpointLookup은 비DID 검색, 포트 유형, 포트 유형 네임스페이스, 분류 및 사용자 특성으로 취급될 수 있으며, 이는 서비스 레지스트리 쿼리 명령문을 구성하는 데 사용될 것이다. 그렇지 않은 경우 Xpath 디지털 항목, 대상 출력 특성 및 입력 프로토콜은 쿼리로 추가될 것이다. 그림 4는 MxEndpointLookup 프리미티브의 특성을 입증한다.

위로

서비스의 QoS 요구사항 제어 기능

사용자 정의 제품 환경에서 특정한 비즈니스 요구사항에 부합하는 다양한 QoS 레벨이 제공되는 다른 서비스가 있다. 예를 들면, VIP 고객이 구독하는 고화질 비디오는 원본 매체를 변환하기 위해 고해상도/화질 트랜스코더가 필요하다. 다른 예제로 빠른 전송 서비스는 긴급 뉴스 게시에 필요하다. Media Extender V7.0에서 MxRules 프리미티브의 새 옵션인 "삽입된 서비스 QoS 사용"은 실행 계획 생성 도중에 QoS 요구사항을 제어하는 기능을 제공한다. 이 기사에서는 그 작업 메커니즘을 설명하기 위해 그림 3을 사용한다.

첫 번째로 하나의 MxEndpointLookup은 대상 서비스 QoS가 필요한 경우 후보 대상 서비스를 사전 선택하는 데 사용된다. QoS 매개변수는 입력 메시지로 전달할 수 있으며, 연관된 쿼리 기준은 MxEndpointLookup 프리미티브의 "사용자 특성"으로 정의될 수 있다. MxEndpointLookup은 일치하는 서비스를 찾고, 엔드포인트 정보를 하나의 일치하는 인스턴스에 대해서는 "/headers/SMOHeader/Target/address"로, 여러 개의 일치에 대해서는 "/context/primitiveContext/EndpointLookupContext"로 설정할 것이다.

두 번째로, 추가적인 MxEndpointLookup 프리미티브는 트랜스코더 서비스에 대한 품질과 전송 서비스에 대한 속도와 같이 지정된 QoS 매개변수로 삽입된 서비스를 사전 선택하는 데 사용된다. 프리미티브의 설정은 위와 동일하다. 결과는 "/context/primitiveContext/EndpointLookupContext"로 설정될 것이다(일치하는 정책을 "일치하는 엔드포인트 모두 리턴"으로 지정해야 함).

MxRules에서 실행 계획은 사전 선택된 대상 및 삽입된 서비스(서비스 풀)로 필터링될 것이다. 서비스 풀 내에서 서비스로 구성된 실행 계획만 결과로 리턴될 것이다. 실행 계획이 포함되면, 서비스 풀에서부터 배제된 서비스는 삭제될 것이다.

위의 모든 QoS 기준은 그림 5와 같이 PolicyResolution WESB 프리미티브를 매체 플로우로 추가하여 런타임 도중에 값을 수정할 수 있는 프리미티브 승격된 특성이 될 수 있다. 이는 중개 플로우의 재사용이 더 용이하게 할 수 있다. 프리미티브 승격된 특성의 동적인 변경에 대한 자세한 정보는 WESB infoCenter를 참조하자.

위로

사용자 지정 메타데이터 지원하기

Media Extender는 실제 데이터가 아니라 매체 메타데이터를 사용하는 참조 기술로 패스한 컨텐트를 사용하여 매체를 처리한다. 매체 메타데이터는 MPEG-21 DID의 "didl:Component"에서 전달된다. 그림 6의 맨 위의 DID 구조의 예제는 복잡하고 반복적이다. 이전 Media Extender 버전에서는 그림 6의 맨 아래의 DID 프로세스에 대한 제한사항이 많다.

• (1) 단일 "didl:Item": 반복적인 구조가 지원되지 않고 하나의 "didl:Item"만 "didl:Container" 아래에 위치할 수 있다.
• (2) 고정 구조: 매체 메타데이터는 "Container.0/Item.0/Component.0"에 위치해야 한다.
• (3) 사전 결정된 위치에서 단일 자원 및 관련 디스크립터: "Container.0/Item.0/Component.0/Resource.0"
• (4) 메시지로 전달할 수 있는 사용자 지정된 메타데이터가 없음: "md:MediaDescriptor"로 정의된 메타데이터만 승인한다.

버전 7.0에서 Media Extender는 다음을 지원한다.

• (1) 일부 제한이 있는 반복적인 구조 지원: "didl:Resources"는 "@ref" 속성이 있어야 하고, 선행하는 동기 "didl:Descriptor" 요소는 "didl:Statement/md:MediaDescriptor"와 함께 있어야 한다. 그림 6에서 Resource 2와 3은 이 기준과 일치하지 않기 때문에, Media Extender 처리 도중에 경고 정보로 무시될 것이다.
• (2) 사용자 지정 메타데이터 전달을 허용한다.
  사용자 정의 시나리오에서 수신되는 메시지는 아마도 매체 특성을 표현하기 위해 MXF 또는 MPEG 7의 예와 같이 사용자 지정된 메타데이터만 포함한다. 수신되는 메시지가 MPEG-21 DID 형식을 따르지 않는 경우 클라이언트 워크플로우는 이를 새 MPEG-21 DID 메시지로 맵핑해야 한다. 메타데이터를 전달하기 위해 수신되는 메시지가 MPEG-21 DID를 사용하는 경우 클라이언트 워크플로우는 매체 메타데이터를 Media Extender 지원 메타데이터 "md:MediaDescriptor"로 맵핑해야 하고, 이를 전달하기 위해 동일한 "didl:Component" 내에서 새 "didl:Descriptor"를 작성해야 한다. 새 Md:MediaDescriptor는 기존 메타데이터에서부터 파생되거나 "Container.0/Container.0/Item.1/Component.0" 아래 Resource 4와 같이 매체 파일에서부터 직접적으로 추출될 수 있다. 동일한 "Container.0/Container.0/Item.1/Component.0" 내에 MPEG 7과 맵핑된 "md:MediaDescriptor"이 존재한다.
  다른 메타데이터의 경우 비즈니스 로직이나 필수 매체 서비스로서 "Container.0" 및 "Container.0/Container.0/Item.1"과 같이 MPEG-21 DID 메시지에 표시될 수 있다. 사용자 지정된 모든 메타데이터는 Media Extender 처리 도중에 예약될 것이다.
• (3) 입력 메시지가 그림 6과 같이 둘 이상의 "didl:Resource"를 포함하는 경우, Media Extender v7.0은 (1)에 나열된 모든 Resource 일치 기준을 분석할 수 있다. 하지만 사용자 지정된 "didl:Container"에서 첫 번째 "didl:Resource"만 처리한다.
  예를 들어, 사용자가 "didl:Container.0"을 지정할 때에 MxLookup 또는 MxRules는 이 "didl:Container.0" 내에서 모든 Resource 및 MediaDescriptor의 xpath를 분석할 수 있지만, 대상 서비스만 검색하거나 Resource 1("Container.0/Item.0/Component.0" 아래)에 대한 실행 계획만 계산하고, 다른 Resources("Container.0/Container.0/Item.1/Component.0" 아래 Resource 4, "Container.0/Container.0/Item.0/Component.0" 아래 Resource 2/3)는 무시되지만 여전히 메시지에서 유지된다. 메시지가 SubProcessBP로 전파되면, Resource 1만("Container.0/Item.0/Component.0" 아래) 삽입된 서비스의 요청 메시지를 구성하며, 삽입된 서비스의 답변/응답을 기반으로 하는 DID 업데이트는 Resource 1에서만 수행되지만, 다른 Resource DID 컨텐트는 변경되지 않을 것이다. 마지막으로 병합된 DID는 대상 서비스로 패스한다.

위로

요약

이 기사는 Media Extender v7.0에 제공된 새 기능을 다룬다. 기존 ESB 오퍼링에 빌드된 새로운 기능은 매체 인식 경로 지정의 기능을 개선하고, SOA의 성능을 매체 비즈니스로 도입하는 유연한 동적 워크플로우 환경에서 진정한 서비스로 연결하는 풍부한 매체 서비스와 Digital Asset Management(DAM) 애플리케이션을 더 원활하게 사용할 것이다.

이 기사에서 서비스 게이트웨이 시나리오에 대해 사용되는 샘플 중개 플로우는 다운로드 섹션에 첨부되어 있다.

위로

다운로드 하십시오

다운로드 방식에 대한 정보

Note

1. 매체 지향 버스를 위한 샘플 서비스 게이트웨이 중개 플로우.

참고자료

교육

• "Media Extender for WebSphere Process Server 제품 페이지"
  제품 설명, 제품 뉴스, 교육 정보, 지원 정보 등을 제공한다.
  
  
• "Redbook: Abstract Service Definition for Media Services"
  디지털 매체용 ASD(Abstract Service Definition)이다. ASD는 적절한 추상 레벨로 각 서비스의 특정 구현에서부터 매체 서비스의 클래스에 독립적으로 액세스하는 유연하고 확장 가능한 메커니즘을 제공한다.
  
  
• "MPEG-21 Standard"
  MPEG-21 표준
  
  
• "What's new in WebSphere Enterprise Service Bus V6.2, Part 1: Overview"
  (developerWorks, 2009년 6월) Part 1에서는 WebSphere ESB V6.2 및 그와 관련된 툴링, WebSphere Integration Developer에 도입된 새롭거나 강화된 전송 프로토콜 바인딩, 데이터 바인딩 기능, 중개 프리미티브 및 선언적 플로우 제어에 대해 설명한다.
  
  
• "What's new in WebSphere Enterprise Service Bus V6.2, Part 2: Service gateway support"
  (developerWorks, 2009년 6월) Part 2에서는 서비스 게이트웨이와 정책 기능에 대해 설명한다.
  
  
• "What's new in WebSphere Enterprise Service Bus V6.2, Part 3: Mediation policy"
  (developerWorks, 2009년 6월) Part 3에서는 작성, 스토리지 및 중개 정책의 사용을 비롯하여 중개 플로우를 동적으로 구성하기 위해 중개 정책을 사용하는 중개 플로우의 동적 구성을 설명한다.
  
  
• "WebSphere ESB 개발자 자원 페이지"
  SOA를 지원하는 애플리케이션과 서비스를 통합하기 위해 유연한 연결 인프라로 WebSphere EST를 사용하는 데 유용한 기술적 자원.
  
  
• "WebSphere ESB Information Center"
  WebSphere ESB의 설치, 구성 및 사용하기에 대한 모든 WebSphere ESB 문서에 대해 개념적이고 태스크 및 참조 정보로 연결되는 하나의 웹 포털.
  
  
• 기술 서점에서 다양한 기술 주제와 관련된 서적을 살펴보자.
  
  

제품 및 기술 얻기

• IBM 제품 평가판을 다운로드하거나 IBM SOA Sandbox의 온라인 시험판을 살펴보고 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®의 애플리케이션 개발 도구와 미들웨어 제품을 사용해 볼 수 있다.
  
  

토론

• developerWorks 포럼 & 블로그를 통해 developerWorks 커뮤니티에 참여하자.
  
  

필자소개

Liang Rui is a software engineer on WebSphere team of IBM CDL. He is working for WebSphere Process Server development and was the developer of WebSphere Media Extender for WPS (Media Extender).

아티클 순위

의견

위로

목차

• Introduction
• ASD usage in the Media Extender
• Evolution of the Media Hub Solution
• Enhancement of MxEndpointLookup
• Capability of controlling QoS requirements of service
• Supporting user specific metadata
• Summary
• 다운로드 하십시오
• 참고자료
• 필자소개
• 의견