소개

Media Extender는 매체 컨텐트 및 서비스와 연관되는 프로세스를 정의하기 위한 유연하고 강력한 접근방식을 제공한다. Media Extender는 매체에 민감한 메타데이터의 사용을 통해 매체 형식의 조정 또는 컨텐트의 이동에 대한 지원을 제공한다.

이 기사는 효율적인 매체 또는 리치 컨텐트 관리에 대한 중개 기능을 설정하는 Media Extender를 사용하는 방법을 알려줄 것이다. 이 글에서는 두 개의 일반적인 시나리오를 소개한다. 하나는 매체 업계 사람들이 서비스 레지스트리에서부터 후보 서비스를 빠르게 자동으로 찾아 입력 매체 컨텐트를 소모할 수 있는 것을 선택할 수 있는 것이고, 또 다른 하나는 매체 파일을 후보 서비스가 직접적으로 처리할 수 없을 때에 매체 업계 사람들이 매체 형식을 변환하는 프로세스를 작성하거나 내용을 이동하도록 사용할 수 있는 것이다.

독자들은 WebSphere Process Server/WebSphere Enterprise Service Bus/WebSphere Integration Developer(WPS/WESB/WID)에 대한 어느 정도의 기술 경험과 매체 컨텐트와 서비스에 대한 어느 정도의 지식이 있어야 한다.

왜 Media Extender인가?

새 컨텐트 형식과 배포 채널(모바일 장치, IPTV, 웹, CD/DVD)의 확산은 매체 프로덕션, 처리 및 배포에 대한 워크플로우의 성장을 가속화한다. 하지만 디지털 매체 컨텐츠는 다양한 형식에서 다른 제공자로부터 획득하고 클라이언트 장치와 일치하는 다양한 형식의 배포와 처리가 필요하다. 여러 형식, 멀티미디어 도구 및 배포 채널을 지원하는 고정되고 설명적인 워크플로우를 사용하는 경우이다. 이러한 변형은 워크플로우에 업데이트를 반복하거나 새 것을 작성해야 한다. 이 접근방식은 노동 집약적이며 시장에 진입하는 시간이 늘어난다. 이러한 도전과제는 Media Extender가 도입한 동적 워크플로우 컴포지션 전략을 채택하여 경감할 수 있다.

그림 1과 같이 Media Extender SOA 접근방식에서 두 가지 레벨의 워크플로우 컴포지션이 있다.

정적 컴포지션 레벨:

추상 워크플로우로 매체 프로세스를 인식하는 워크플로우는 온전히 상위 레벨 비즈니스 요구사항을 기반으로 하여, 컨텐트 조정, 컨텐트 이동과 같은 기술적 요구사항을 고려하지 않아도 된다. 그러면 추상 워크플로우는 동적 컴포지션에 의해 런타임으로 확장된다.

동적 컴포지션 레벨:

추상 워크플로우가 Media Extender를 통해 대상 서비스를 호출한다. 중개 플로우는 매체 오브젝트를 소모할 수 있는 대상 서비스를 검색하거나, 대상 서비스를 호출하기 이전에 매체 불일치를 해결하는 실행 계획을 작성하여 동적 일치를 적용한다.

그러면 실행 계획은 구문 분석과 실행을 위해 SubProessBP 엔진에 제공된다.

위로

Media Extender 기초

상위 레벨 Media Extender 아키텍처 개요는 그림 2와 같다. 클라이언트 워크플로우는 매체를 처리하기 위해 매체 지향 ESB를 호출할 것이다. Media Extender는 서비스 선택과 매체 인식 경로 지정을 완료하도록 Service Registry 및 서비스 제공자와 함께 작업할 것이다.

Service Registry에서 서비스 wsdl 파일과 서비스 특성 파일(*Descr.xml)은 각 매체 지향 서비스를 설명하기 위해 사용된다. 특성 파일이 제공되는 서비스와 기능의 특성에 대해 설명하는 반면에, wsdl 파일은 서비스 API 구현 매개변수를 제공한다. XML 서비스 메타데이터와 연관된 각 WSDL 서비스 정의의 관계는 Resource Description Framework(rdf) 태그를 사용하는 것이다. 그리고 서비스 레지스트리 유형은 WebSphere Service Registry and Repository(WSRR) 또는 파일 시스템 기반이 될 수 있다.

Media Extender는 Enterprise Service Bus(이하 ESB)를 매체 지향 ESB로 만들도록 강화하는 두 가지 기능을 제공하는데, 하나는 매체 인식이고 나머지 하나는 컨텐트 기반 경로 지정이다. 이전 것은 ESB로 제공되는 서비스 엔드포인트 검색의 추가 버전으로 취급될 수 있다. Media Extender는 매체 컨텐트, 메타데이터, 위치 및 정책을 기반으로 하는 적절한 서비스를 선택할 수 있다. 반면에 매체 인식 경로 지정은 매체/컨텐트와 대상 서비스 사이의 불일치에 대한 변환 지원을 제공한다. 이는 필수 내장된 트랜스코딩을 지원하며 다음 서비스가 다른 형식 또는 데이터 이동이 필요한 경우 매체를 전송한다. 내장 서비스(따라서 삽입된 서비스라고 함) 및 대상 서비스 호출 순서는 실행 계획으로 조직될 것이다.

매체는 Media Extender에서 참조된 메타데이터로 처리되며, 이는 매체 제어 플로우 및 실제 매체 처리 플로우가 분리되는 것을 의미한다. Media Extender는 제어 플로우에 집중하여 매체 특성이 들어있는 메시지를 사용하여 콘텐트 처리를 처리하는 동안 이러한 이동 및 형식 변환과 같은 실제 매체 처리는 다른 버스에서 수행된다.

매체의 특성은 추출되어 MPEG-21 디지털 항목으로 구성된 다음에 Media Extender의 수신 메시지에 포함된다. 일반적인 MPEG-21 디지털 항목 구조는 그림 3에 제시되어 있다. 매체 정보는 "didl:Container/didl:Item/didl:Component/didl:Descriptor/didl:Statement/md:MediaDescriptor"가 전달한다. MXF 또는 Mpeg7과 같이 다른 매체 메타데이터 형식의 경우, MPEG-21 디지털 항목으로도 전달될 수 있지만, Media Extender로 소화될 수 있는 DIDL 형식으로의 맵핑이 필요하다.

Media Extender 컴포넌트:

Media Extender가 제공하는 전체 컴포넌트는 그림 4와 같다. ESB 중개 플로우를 구성하는 세 가지 ESB 중개 프리미티브 및 실행 계획을 구문 분석하는 서브프로세스 엔진 및 서비스 호출 처리.

MxEndpointLookup은 파일 시스템 기반 또는 WSRR 기반이 될 수 있는 서비스 레지스트리를 검색하여 적절한 매체 지향 서비스 엔드포인트로 메시지를 동적으로 경로 지정한다.

MxRules는 변환하거나 대상 서비스로 제공되기 전에 매체를 이동하기 위해 필요한 다른 서비스 호출이 무엇인지 계산한다. 결과는 직접적으로 서비스 호출이 되거나, 불일치되는 경우 실행 계획을 생성하는 것이 될 수 있다.

MxDynSelection은 후보 서비스 중 하나와 각각 연관되는 비용을 계산하여, 최저 비용이 드는 것을 선택한다. CPU 로드, 사용 가능한 스토리지 용량, 사용 가능한 네트워크 대역폭 및 작업 큐 크기 등의 동적 특성이 사용된다.

Subprocess 엔진은 BPEL 기반 애플리케이션이며, 실행 계획을 구문 분석하고 삽입된 서비스 호출을 대비하며 삽입된 서비스의 응답을 기반으로 매체 메타데이터를 업데이트하여 마지막으로 대상 서비스를 호출한다.

위로

컨텐트 시나리오를 처리하는 Media Extender 사용

Media Extender 사용 시나리오는 이 섹션에서 소개될 것이다. 디지털 매체 배포를 위한 일반적인 시리즈 단계는 그림 5에서 입증된다. 비디오가 디지털 자산으로 흡수되면, 분석되고 주제별로 분류될 것이다. 그 이후에 자산은 잠재적 자원으로 저장소에 저장될 것이다. 회사가 이 자산을 게시하려고 결정하면, 편집기는 내용을 검토하고 어느 정도의 필요한 수정을 수행할 것이다. 자산이 검토를 패스하면 이는 사용자 정의 요구사항을 기반으로 다중 채널로 제공될 수 있다. 위의 단계에서 Media extender는 저장소 선택, 검토 프로모 생성 및 다중 채널 제공에 연관될 수 있다. 이 섹션에서 이를 개별적으로 논의할 것이다.

매체 인식 선택 시나리오

그 단락에서 디지털 자산과 저장소 서비스 사이에 형식과 위치의 불일치가 없다고 생각하자. 이는 대상 서비스를 직접적으로 선택할 수 있기 때문에 MxEndpointLookup의 기능을 쉽게 입증할 수 있다. MxEndpointLookup로 구성된 중개 플로우는 그림 6과 같이 전체 저장소 선택에 사용할 수 있다.

엔드포인트 검색에 대해 사용된 MxEndpointLookup 프리미티브의 특성은 다음과 같다.

• 서비스 포트 유형, 네임스페이스 및 버전 - 서비스 WSDL 정보
• Xpath 디지털 항목 - 사용자는 수신 메시지 내에서 "didl:Container"의 xpath를 지정할 수 있다.
• 일치 정책 - 일치하는 엔드포인트를 모두 리턴하거나 첫 번째 일치하는 엔드포인트를 리턴한다.
• 분류 - 특정 서비스 분류와 일치하는 오브젝트를 검색한다.
• 사용자 특성 - 일반 사용자가 서비스 엔드포인트 쿼리에 사용하려는 특성
• 대상 출력 특성 - 트랜스코더 및 전송 서비스를 검색하는 데 사용되는 특성. "출력 형식"과 "출력 위치"는 두 가지의 제한된 옵션이다.
• 입력 프로토콜 일치 - 사용자는 DID로 참조되는 매체 자원의 입력 프로토콜에 수행되는 일치 정책을 지정할 수 있다. "기본" 옵션은 일치를 확인하는 것을 의미하며 "NoHostname"은 확인을 무시하는 것을 의미한다.

두 가지 유형의 서비스 검색이 있다.

• 컨텐트 기반
• 비컨텐트 기반

첫 번째는 매체 디스크립터를 분석하여 서비스가 매체 특성을 처리할 수 있음을 발견한다. 일치 서비스 엔드포인트 주소는 이 선택의 결과가 될 것이다. 일반 사용자는 입력 메시지에서 MPEG-21 디지털 항목의 Xpath를 지정해야 하며, 이는 매체 메타데이터 디스크립터 위치를 표시한다.

두 번째 검색 유형은 비DIDL/컨텐트 기반이다. 이는 ESB EndpointLookup 프리미티브와 유사하다. 하지만 파일 시스템 기반 서비스 레지스트리를 지원하여 이를 개선한다. 게다가 일반 사용자는 Repository 서비스 검색을 위한 "repositoryID"와 같이 검색 매개변수에 대해 프리미티브 사용자 특성으로 서비스 식별을 직접적으로 지정할 수 있다.

여기에 MxEndpointLookup 함수를 입증하는 예제가 있다. 목록 1과 같이 입력 메시지는 매체 메타데이터를 전달했다. 전체 메시지는 첨부파일 1- InputMessage.xml을 참조하자. MxEndpintLookup은 형식 ID가 "wmv.1"이며 "server1"에 있고 지원되는 프로토콜은 "file"인 입력 "testfile.wmv"를 저장할 수 있는 Repository를 찾는 서비스 레지스트리를 확인할 것이다. 실제로 QoS, 서비스 분류 등과 같이 다른 매개변수는 MxEndpintLookup 특성 설정을 기반으로 하는 서비스를 쿼리하는 데 사용될 수도 있다. 리턴 결과는 "일치 정책" 설정으로 제어할 수 있다. 일반 사용자가 "첫 번째 일치하는 서비스를 리턴하기"를 선호하는 경우, 결과는 SMO 메시지의 "/headers/SMOHeader/Target/address"에 설정될 것이다. 일반 사용자가 "일치하는 엔드포인트를 모두 리턴하기"를 선택하는 경우, 엔드포인트의 세트는 "/context/primitiveContext/EndpointLookupContext"에 나열될 것이다.

다음을 참조하자! 서비스 선택을 스토리지 서비스에서부터 트랜스코더나 전송 서비스로 변경하는 경우, 프리미티브 특성 고급 패널 아래에서 "대상 출력 특성"이 "출력 형식" 또는 "출력 위치"에 대해 개별적으로 설정되어야 한다.

        
<?xml version="1.0" encoding="UTF-8"?>
<didl:Container xmlns:didl="urn:mpeg:mpeg21:2002:02-DIDL-NS">
 <didl:Item>
  <didl:Component>
   <didl:Descriptor>
    <didl:Statement mimeType="text/xml; charset=UTF-8">
     <md:MediaDescriptor xmlns:md="http://md.wemx.ibm.com" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://md.wemx.ibm.com md.xsd ">
       <MediaFormat ID="wmv.1" extension="wmv" format="Windows Media" info="WMV Media">
        </VideoFormat>
        </AudioFormat>
       </MediaFormat>
     </md:MediaDescriptor>
    </didl:Statement>
   </didl:Descriptor>
   <didl:Resource mimeType="video/quicktime" ref="file://server1/testfile.wmv" />
  </didl:Component>
 </didl:Item>
</didl:Container>
			

컨텐트 기반 경로 지정 시나리오

그림 5와 같이 매체 배포에 대한 단계에서 매체 프로덕션 검토 및 다중 채널 제공은 Media Extender로 제공되는 컨텐트 기반 경로 지정을 활용할 수 있다. 매체의 원본 컨텐트는 소모되기 전에 항상 어느 정도의 조정이 필요하다. 예를 들면, 검토 프로모의 매체 형식은 원본 자산의 낮은 해상도의 복사본이다. 다른 영역에 위치한 다른 제공/게시 서비스는 다양한 입력 형식이 필요하다. 컨텐트 기반 경로 지정의 이러한 강력한 기능은 매체와 대상 서비스 사이의 불일치를 해결하는 내장된 삽입된 서비스를 사용하는 것이다.

컨텐트 기반 경로 지정은 섹션 1에서 논의한 동적 컴포지션의 중추이다. 여기에서는 그 작업 메커니즘을 설명하는 예제로 다중 채널 제공만 사용한다. 비즈니스 전문가는 다중 채널 제공 워크플로우 모델링 도중에 형식 변환과 컨텐트의 이동을 처리하는 잠재적인 단계를 고려하지 않아도 된다. Media Extender의 컨텐트 기반 경로 지정은 최종 구체적인 게시자 서비스 호출 이전에 필요한 추가적인 프로세스 단계를 계산할 것이다. 불일치 처리는 클라이언트 워크플로우에게 명백하여, 작업 노력을 줄이고 재사용을 개선할 수 있다.

다중 채널 게시 처리에 사용할 수 있는 MxRules로 구성된 중개 플로우는 그림 7과 같다.

MxRules 프리미티브의 특성:

• 서비스 포트 유형, 네임스페이스 및 버전 - 서비스 WSDL 정보
• Xpath 디지털 항목 - 사용자는 수신 메시지 내에서 "didl:Container"의 xpath를 지정할 수 있다.
• Xpath 출력 형식 – 사용자는 대상 서비스로 제작되도록 예상된 출력 형식이 들어있는 매체 형식 디스크립터의 xpath 위치를 지정할 수 있다(특히 트랜스코더 서비스용)
• 분류 - 특정 분류와 일치하는 오브젝트를 검색한다.
• 동적 선택 사용 – 대상 서비스나 실행 계획에 대한 비용 계산을 사용한다(각각의 삽입된 서비스와 대상 서비스 계수). 최저 비용이 드는 것이 최종 결과가 될 것이다.
• 삽입된 서비스 QoS 사용 – 실행 계획을 구성하는 데 필요한 QoS와 일치하는 삽입된 서비스의 사용을 제한한다.

MxRules 중개 프리미티브는 다음 네 가지 단계에서 작동한다.

• 1. 잠재적인 대상 서비스의 세트가 설정된다. 이 세트는 입력 SMO의 "/context/primitiveContext/EndpointLookupContext"를 패스하거나 서비스 사전 선택에 대해 MxEndpointLookup를 사용하여 작성된다. 선택은 이 단계에서 DID 기반 또는 비DID 기반이 될 수 있다. 사전 선택 도중에 서비스 레지스트리에서 찾을 수 있는 구체적인 서비스가 없는 경우, MxRules 프리미티브에서 지정된 portTypeName, 네임스페이스 및 분류 특성별로 특징화된 추상 서비스가 대상 서비스로 작성될 것이다.
• 2. 디지털 항목 및 대상 서비스로 설명되는 매체의 특성을 기반으로 하여 MxRules는 대상이 변경하지 않은 매체를 소모할 수 있는지, 아니면 매체가 이에 대비하여 형식이 변환되는지 여부를 결정한다. 필요한 경우 적합한 트랜스코더를 서비스 레지스트리에서 찾는다.
• 3. 입력 소스와 트랜스코더 사이에 데이터 이동의 필요성이 있거나 대상을 고려하는 경우 서비스 메타데이터를 기반으로 한다.
• 4. 삽입된 서비스와 대상 서비스가 들어있는 실행 계획은 SMO의 SOAPHeader에서 작성되고 설정될 것이다. 실행 계획의 구조 설명은 그림 8과 같다. 전체적인 SMO 메시지는 MxRules 서브플로우 터미널에서부터 전파된다. 첨부 파일 2- OutputMessage.xml을 참조하자.

실행 계획 구조에 대해 조금 더 자세히 논의하려고 한다. MxRules가 아마 여러 실행 계획을 생성하기 때문에, "executionPlanID"는 MxRules 서브플로우 터미널로 전파되는 것을 식별하는 데 사용된다. "xpathDID"의 값은 MxRules로 처리되는 "didl:Container"의 xpath를 표시하는데, 이는 여러 DID 사용 시 의미가 있을 것이다. 자세한 세부사항은 시리즈 주제의 Part 2를 참조하자. "messageName"의 값은 서비스 게이트웨이 시나리오에 대한 입력 메시지 유형을 예약하는데 사용될 것이다. 실행 계획 내의 각 서비스(삽입된 서비스와 대상 서비스)는 "ServiceInstance"로 조직되며, 서비스 wsdl 포트 유형, 조작, 엔드포인트 주소, 일부 특성 및 분류를 기록할 것이다. 서비스 구현 및 함수 논리와 연관된 특성은 "ServcieProperty" 필드에 설정될 수 있다. 그리고 operationClassification이 "SyncAsync" 플래그를 사용하여 동기화(RR) 및 비동기화(RRN) 조작을 식별하는 데 사용될 때에, 분류는 서비스 유형을 표시하는 serviceClassfication으로 구분된다.

MxRules로 생성되는 실행 계획 세트가 있는 경우, 첫 번째는 MxRules의 "서브플로우" 터미널로 전파되는 출력 결과가 될 것이다. 일반 사용자가 "동적 선택" 또는 "삽입된 서비스 Qos"를 사용하는 경우, MxRules로 생성되는 실행 계획의 전체 수는 할인될 수 있으며, 적절한 조건에 부합하는 것만 출력 결과가 될 수 있다. 이는 아래에서 논의될 것이다.

동적 선택을 사용하면 최저 비용 실행 계획을 리턴할 것이다. 비용의 구조는 실행 계획에서 각 서비스 비용을 기반으로 한다. CPU 로드, 사용 가능한 스토리지 용량, 사용 가능한 네트워크 대역폭 및 작업 큐 크기를 설명하는 계량의 가중치 총합이 계산된다. 그리고 그 "사용 가능한" 특성이 true 조건으로 설정된 각 서비스만 계산을 사용할 것이며, 그렇지 않은 경우에 이 실행 계획은 삭제될 것이다. 메트릭스는 독립적인 모니터링 시스템으로 수집된 Media Extender의 동적 레지스트리에 기록된다.

삽입된 서비스 Qos 사용은 그 서비스 인스턴스가 트랜스코더의 고속 전송 또는 고화질과 같이 삽입된 서비스의 QoS 요구사항을 일치할 수 없는 실행 계획을 배제할 것이다.

전체 SMO 메시지는 MxRules의 "서브플로우" 터미널에서부터 전파한다. 첨부 파일 2- OutputMessage.xml을 참조하자.

실행 계획 엔진

다중 채널 제공과 같이 컨텐트 기반 경로 지정 시나리오를 완료하기 위해 실행 계획은 SubProcessBP - 그림 9에서 입증한 실행 계획 런타임 엔진에서 구문 분석될 것이다.

SubProcessBP는 Media Extender 중개 플로우에서부터 전파된 입력 메시지를 취하고, 참조된 매체 파일을 처리하는 삽입된 서비스로 전송하는 요청 메시지를 작성하는 데 사용되는 MPEG-21 컨테이너를 추출한다. 삽입된 서비스에서부터 응답을 받은 후, SubProcessBP는 이어지는 삽입된 서비스 또는 최종 대상 서비스에 대비하여 MPEG-21 설명을 업데이트한다. 이 단계는 실행 계획 내에서 모든 서비스 인스턴스가 오류 없이 호출될 때까지 반복될 것이다.

예를 들어, 휴대전화 비디오 제공을 위해 Transcoder1에서부터 Publisher1까지의 서비스 순서가 있다고 생각하자. 원본 DID 컨테이너는 DID 입력 매개변수 Transcoder1 서비스로 맵핑된다. 마지막으로 Transcoder 1로부터 업데이트된 DID 컴포넌트는 대상 Publisher1의 DID 컨테이너로 맵핑된다. 대상 Publisher1이 작업을 완료하면 원본 매체가 지정된 형식으로 요청된 장치에 제공되었다. 클라이언트 워크플로우와 중개 플로우는 휴대전화로 변경하지 않고 다른 채널 제공(IPTV, 웹 및 DVD/CD)에 대해 재사용될 수 있다.

위로

요약

이 기사는 Media Extender 기초 개념에 대한 요약을 제공했다. 그리고 저자는 두 가지 일반적인 시나리오를 사용하여 Media Extender가 매체 처리 워크플로우를 설정하는 노력을 줄일 수 있고, 매체 업계 사람들이 동적이며 자동적인 매체 컨텐트 관리를 달성하는 데 도움을 줄 수 있다는 것을 입증한다.

이 기사에서 다중 채널 제공 시나리오에 대해 사용되는 샘플 중개 플로우는 다운로드 섹션에 첨부되어 있다.

위로

다운로드 하십시오

다운로드 방식에 대한 정보

Notes

1. Media Extender용 샘플 입력 메시지.
2. MxRules 서브플로우 터미널에서부터 전파된 샘플 SMO 메시지
3. 다중 채널(multiple channel) 제공 시나리오에 대한 프로젝트 인터체인지(PI) 파일

참고자료

교육

• "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에서는 서비스 게이트웨이와 정책 기능에 대해 설명한다.
  
  
• "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
• Why Media Extender?
• Media Extender Fundamental
• Use Media Extender to process the content scenarios
• Summary
• 다운로드 하십시오
• 참고자료
• 필자소개
• 의견