Bắt đầu Media Extender với WebSphere Process Server, Phần 1: Tổng quan: Khái niệm và cách sử dụng cơ bản

Bộ mở rộng môi trường truyền thông cho Máy chủ qui trình WebSphere (Media Extender for WebSphere Process Server) (gọi tắt là Media Extender) được xây dựng trên SOA (Services Oriented Architecture-Kiến trúc hướng dịch vụ) và có thể tạo ra sự linh hoạt về nghiệp vụ cho ngành công nghiệp môi trường truyền thông. Bài viết này đưa ra giới thiệu cơ bản về Media Extender và mô tả cách sử dụng thành phần do sản phẩm cung cấp để thiết lập phương tiện trợ giúp mọi người trong ngành công nghiệp môi trường truyền thông quản lý nội dung truyền thông động và tự động.

Liang Rui, Kỹ sư phần mềm, IBM

Liang RuiLiang Rui là một kỹ sư phần mềm thuộc nhóm WebSphere của CDL IBM. Anh đang làm việc về phát triển máy chủ qui trình (WebSphere Process Server - WPS) và đã là nhà phát triển của Bộ mở rộng môi trường truyền thông WebSphere (WebSphere Media Extender) cho WPS (Media Extender).



28 05 2011

Mở đầu

Media Extender cung cấp một cách tiếp cận linh hoạt và mạnh mẽ để xác định các quá trình liên quan đến nội dung và các dịch vụ truyền thông. Media Extender cung cấp sự hỗ trợ để thích nghi với các định dạng truyền thông hoặc dịch chuyển nội dung thông qua việc sử dụng siêu dữ liệu truyền thông-nhạy cảm.

Bài viết này sẽ nói cho mọi người biết cách sử dụng Media Extender để thiết lập phương tiện trung gian cho việc quản lý nội dung phong phú hay truyền thông hiệu quả. Bài viết này giới thiệu hai kịch bản phổ biến: kịch bản đầu tiên cho phép mọi người trong ngành công nghiệp môi trường truyền thông định vị nhanh chóng và tự động dịch vụ ứng cử viên từ một đăng ký dịch vụ, lựa chọn những dịch vụ nào có thể tiêu thụ nội dung truyền thông đầu vào; kịch bản khác cho phép mọi người trong ngành công nghiệp truyền thông tạo ra một qui trình để chuyển đổi các định dạng của môi trường truyền thông hoặc dịch chuyển nội dung khi dịch vụ ứng cử viên bất kỳ không thể trực tiếp xử lý một tệp dữ liệu truyền thông.

Các độc giả cần phải có một số kỹ năng về WPS/WESB/WID (WPS:WebSphere Process Server- Máy chủ qui trình WebSphere/WESB: WebSphere Enterprise Service Bus - Bus dịch vụ doanh nghiệp WebSphere/WID: WebSphere Integration Developer - Các nhà phát triển WebSphere) và có một số kiến thức về các dịch vụ và nội dung truyền thông.

Tại sao là Media Extender?

Sự phát triển của các định dạng và các kênh phân phối nội dung mới (các thiết bị di động, IPTV, Web, CD/DVD) đang thúc đẩy sự phát triển của các dòng công việc để sản xuất, xử lý và phân phối truyền thông. Tuy nhiên, các nội dung truyền thông số nhận được từ những người đóng góp khác nhau lại theo nhiều định dạng và cần được xử lý và phân phối theo một loạt các định dạng phù hợp với các thiết bị của khách hàng. Cho dù việc sử dụng đã tổ chức và đã phát triển dòng công việc để hỗ trợ nhiều định dạng, các công cụ và các kênh phân phối đa phương tiện. Những thay đổi này yêu cầu các cập nhật định kỳ theo dòng công việc hoặc tạo ra các dòng công việc mới. Cách tiếp cận này cần nhiều nhân công và kéo dài thời gian đưa vào thị trường. Có thể làm giảm nhẹ các thách thức này bằng cách thông qua các chiến lược sắp xếp dòng công việc động do Media Extender giới thiệu.

Có hai mức sắp xếp dòng công việc theo cách tiếp cận SOA của Media Extender như trong Hình 1:

Hình 1. Sắp xếp dòng công việc theo hai mức trong Media Extender
TSắp xếp dòng công việc theo hai mức trong Media Extender

Mức sắp xếp tĩnh:

Một dòng công việc đang thực hiện qui trình truyền thông như là một dòng công việc trừu tượng chỉ dựa trên các yêu cầu nghiệp vụ cao cấp và không cần xem xét các yêu cầu kỹ thuật như sự thích nghi với nội dung, sự dịch chuyển nội dung. Sau đó dòng công việc trừu tượng được mở rộng trong thời gian chạy theo cách sắp xếp động.

Mức sắp xếp động:

Dòng công việc trừu tượng gọi dịch vụ đích thông qua Media Extender. Dòng trung gian tìm kiếm một dịch vụ đích có thể tiêu dùng đối tượng truyền thông hoặc áp dụng một sự phối hợp động bằng cách tạo ra một kế hoạch thực hiện để giải quyết sự không phối hợp truyền thông trước khi gọi dịch vụ đích.

Sau đó kế hoạch thực hiện được cung cấp cho máy SubProcessBP để phân tích cú pháp và thực hiện.


Quy tắc cơ bản của Media Extender

Tổng quan về kiến trúc Media Extender cao cấp được chỉ ra trong Hình 2. Dòng công việc máy khách sẽ gọi ESB hướng-truyền thông (Media-Oriented ESB) cho quá trình truyền thông. Media Extender sẽ làm việc với Đăng ký dịch vụ (Service Registry) và các nhà cung cấp dịch vụ để hoàn thành việc lựa chọn dịch vụ và định tuyến nhận thức-truyền thông.

Trong Đăng ký dịch vụ, các tệp dịch vụ wsdl và các tệp dịch vụ các đặc tính (* Descr.xml) được sử dụng để mô tả từng dịch vụ hướng-truyền thông. Các tệp wsdl cung cấp các tham số thực hiện API dịch vụ trong khi các tệp các đặc tính mô tả các đặc điểm của dịch vụ và các khả năng mà nó đã cung cấp. Mối quan hệ đã liên kết từng định nghĩa dịch vụ WSDL với siêu dữ liệu dịch vụ XML đang sử dụng thẻ rdf (Resource Description Framework - Khung công tác mô tả tài nguyên). Và kiểu đăng ký dịch vụ có thể là WSRR (WebSphere Service Registry and Repository – Kho lưu trữ và đăng ký dịch vụ WebSphere ) hoặc dựa vào hệ thống tệp.

Hình 2. Tổng quan Kiến trúc của Media Extender
Tổng quan Kiến trúc của Media Extender

Media Extender cung cấp hai khả năng để nâng cao Bus dịch vụ doanh nghiệp-Enterprise Service Bus (sau đây gọi là ESB) làm cho nó như ESB hướng-truyền thông: một khả năng là nhận thức truyền thông, còn khả năng kia là định tuyến dựa vào nội dung. Cái trước có thể được coi là phiên bản cộng của việc tìm kiếm điểm cuối dịch vụ, do ESB cung cấp. Media Extender có thể lựa chọn dịch vụ phù hợp dựa vào nội dung, siêu dữ liệu, vị trí và các chính sách truyền thông. Trong khi việc định tuyến nhận thức truyền thông cung cấp hỗ trợ chuyển đổi cho sự không khớp giữa dịch vụ truyền thông/nội dung và dịch vụ đích. Nó hỗ trợ việc chuyển mã ngầm định cần thiết và vận chuyển truyền thông nếu dịch vụ tiếp sau yêu cầu các định dạng khác hoặc dịch chuyển dữ liệu. Dịch vụ ngầm định (do đó gọi là dịch vụ chèn vào) và chuỗi lời gọi các dịch vụ đích sẽ được tổ chức như một kế hoạch thực hiện.

Truyền thông được coi như siêu dữ liệu được tham chiếu trong Media Extender, có nghĩa là dòng điều khiển truyền thông và dòng xử lý truyền thông thực được tách ra. Media Extender tập trung vào dòng điều khiển để điều khiển việc xử lý nội dung bằng cách sử dụng thông báo có chứa các đặc tính truyền thông trong khi việc xử lý truyền thông thực như là dịch chuyển và chuyển đổi định dạng được thực hiện trong Bus khác.

Các đặc tính truyền thông được trích xuất và được xây dựng như các mục số MPEG-21, sau đó được chứa trong thông báo gửi đến của Media Extender. Cấu trúc của các mục số MPEG-21 điển hình được minh họa trong Hình 3. Thông tin truyền thông được mang bởi "didl:Container/didl:Item/didl:Component/didl:Descriptor/didl:Statement/md:MediaDescriptor". Đối với định dạng siêu dữ liệu truyền thông khác, chẳng hạn như MXF hoặc Mpeg7, cũng có thể chứa trong các mục số MPEG-21 nhưng cần có một ánh xạ tới định dạng DIDL để có thể được phân loại bằng Media Extender.

Hình 3. Cấu trúc của mục số MPEG-21
Cấu trúc của mục số MPEG 21

Các thành phần Media Extender:

Toàn bộ các thành phần do Media Extender cung cấp được chỉ ra trong Hình 4: ba nguyên hàm trung gian ESB để xây dựng dòng trung gian ESB và máy Qui trình con (Subprocess) để phân tích cú pháp kế hoạch thực hiện và gọi dịch vụ xử lý.

MxEndpointLookup định tuyến động các thông báo đến các điểm cuối dịch vụ hướng-truyền thông thích hợp bằng cách tìm kiếm đăng ký các dịch vụ có thể dựa vào hệ thống tệp hoặc dựa vào WSRR.

MxRules tính toán xem lời gọi các dịch vụ khác cần cái gì để biến đổi, hoặc dịch chuyển truyền thông trước khi nó được gửi đến dịch vụ đích. Kết quả có thể là lời gọi dịch vụ trực tiếp hoặc tạo một kế hoạch thực hiện, nếu xảy ra không khớp.

MxDynSelection tính toán chi phí liên quan với mỗi một trong số các dịch vụ ứng cử viên và lựa chọn một dịch vụ có chi phí thấp nhất. Các đặc tính động sau đây được sử dụng: tải CPU, dung lượng lưu trữ có sẵn, băng thông mạng có sẵn và kích thước hàng đợi Công việc (Job).

Máy Qui trình con là ứng dụng dựa trên BPEL, nó phân tích cú pháp kế hoạch thực hiện, chuẩn bị gọi dịch vụ chèn vào, cập nhật siêu dữ liệu truyền thông dựa trên đáp ứng của dịch vụ chèn vào và cuối cùng gọi dịch vụ đích.

Hình 4. Các thành phần của Media Extender
Các thành phần của Media Extender

Sử dụng Media Extender để xử lý các kịch bản nội dung

Các kịch bản sử dụng Media Extender sẽ được giới thiệu trong phần này. Một loạt các bước tiêu biểu để phân phối truyền thông số được thể hiện trong Hình 5. Video này được tiêu dùng như một tài sản số, nó sẽ được phân tích và phân loại theo chủ đề. Sau đó, tài sản đó sẽ được lưu trữ trong một kho lưu trữ như là nguồn lực tiềm năng. Khi công ty quyết định xuất bản tài sản này, biên tập viên sẽ xem xét nội dung và thực hiện một số thay đổi cần thiết. Một khi tài sản đó đã vượt qua bước xem xét lại, nó có thể được phân phối theo nhiều kênh khác nhau tùy theo yêu cầu của khách hàng. Ở các bước trên, Media Extender có thể bao gồm việc lựa chọn kho lưu trữ, xem xét lại phần tạo quảng cáo và phân phối nhiều kênh. Phần này sẽ thảo luận riêng về chúng.

Hình 5. Các bước điển hình cho việc phân phối truyền thông
Các bước điển hình cho việc phân phối truyền thông

Kịch bản lựa chọn nhận thức truyền thông

Kịch bản này được cho là không có định dạng và không khớp vị trí giữa tài sản số và dịch vụ kho lưu trữ trong đoạn này. Nó có thể dễ dàng thể hiện khả năng của MxEndpointLookup do có thể lựa chọn trực tiếp dịch vụ đích. Việc lựa chọn kho lưu trữ đầy đủ có thể sử dụng dòng trung gian được MxEndpointLookup xây dựng như trong Hình 6.

Các đặc tính của các nguyên hàm MxEndpointLookup thường dùng để tìm kiếm điểm cuối là:

  • Kiểu cổng, vùng tên và phiên bản của dịch vụ - Thông tin WSDL dịch vụ.
  • Mục số XPath - Người dùng có thể xác định xpath của "didl: Container" trong thông báo gửi đến
  • Chính sách phù hợp - Trả về tất cả các điểm cuối phù hợp hoặc trả về các điểm cuối phù hợp đầu tiên.
  • Phân loại - Tìm kiếm các đối tượng phù hợp với một phân loại dịch vụ cụ thể.
  • Các đặc tính của người dùng - Bất kỳ người dùng đầu cuối nào muốn sử dụng truy vấn điểm cuối dịch vụ.
  • Các đặc tính đầu ra đích - Các đặc tính được sử dụng để tìm kiếm bộ chuyển mã và dịch vụ vận chuyển. "Định dạng đầu ra" và "Vị trí đầu ra" là hai tùy chọn bị hạn chế.
  • Phối hợp giao thức đầu vào - Người dùng có thể chỉ định chính sách phù hợp được thực hiện trên giao thức đầu vào của nguồn lực truyền thông được tham chiếu bởi DID. Tùy chọn "Default" (Mặc định) có nghĩa là kiểm tra về sự phù hợp, trong khi "NoHostname" (Không có tên máy chủ) có nghĩa là bỏ qua việc kiểm tra này.

Có 2 loại dịch vụ tìm kiếm:

  • dựa vào nội dung.
  • không dựa vào nội dung.

Dịch vụ tìm kiếm đầu tiên sẽ phân tích bộ mô tả truyền thông và đã tìm ra dịch vụ có thể xử lý các đặc điểm truyền thông. Địa chỉ điểm cuối của dịch vụ phù hợp sẽ là kết quả của sự lựa chọn này. Người sử dụng cuối cần xác định XPath của mục số MPEG-21 trong thông báo đầu vào, cho biết vị trí của bộ mô tả siêu dữ liệu truyền thông.

Dịch vụ tìm kiếm thứ hai dựa vào không-DIDL/nội dung. Nó giống như nguyên hàm EndpointLookup của ESB. Nhưng hãy nâng cao nó bằng cách hỗ trợ hệ thống tệp dựa vào đăng ký dịch vụ. Hơn nữa, những người dùng cuối có thể trực tiếp xác định nhận dạng dịch vụ như các đặc tính người dùng nguyên thủy để tìm kiếm tham số, ví dụ như "repositoryID" (Mã định danh kho lưu trữ) cho việc tìm kiếm dịch vụ Repository.

Dưới đây là một ví dụ để thể hiện hàm MxEndpointLookup. Thông báo đầu vào đã mang siêu dữ liệu truyền thông như trong Liệt kê 1, về toàn bộ thông báo hãy tham khảo tệp đính kèm 1-InputMessage.xml. MxEndpintLookup sẽ kiểm tra việc đăng ký dịch vụ để tìm ra Kho lưu trữ có thể lưu trữ dữ liệu đầu vào "testfile.wmv" có ID định dạng là "wmv.1", nằm trong "server1" và giao thức được hỗ trợ là "tệp". Trên thực tế tham số khác như QoS, phân loại dịch vụ , v.v cũng có thể được sử dụng để truy vấn dịch vụ dựa trên việc thiết lập các đặc tính MxEndpintLookup. Kết quả trả về có thể được điều khiển bằng việc thiết lập "Match Policy-Chính sách phù hợp". Nếu người dùng cuối thích "trả về dịch vụ phù hợp đầu tiên", kết quả sẽ được đặt trong "/headers/SMOHeader/Target/address" của thông báo SMO. Nếu người dùng chọn "trả về tất cả các điểm cuối phù hợp", một tập hợp các điểm cuối sẽ được liệt kê trong "/context/primitiveContext/EndpointLookupContext".

Lưu ý! Nếu thay đổi lựa chọn dịch vụ từ dịch vụ lưu trữ sang dịch vụ Chuyển mã hay dịch vụ Vận chuyển, "Các đặc tính đầu ra đích" trong ô cửa phía trước của các đặc tính nguyên thủy nên được thiết lập tới "Định dạng đầu ra" hoặc "Vị trí đầu ra" riêng rẽ.

Hình 6. Các bước điển hình để phân phối truyền thông
Các bước điển hình cho việc phân phối truyền thông
Liệt kê 1. The sample input media info:
<?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>

Kịch bản định tuyến dựa vào nội dung

Trong các bước để phân phối truyền thông được chỉ ra trong Hình 5, việc xem xét lại sản xuất truyền thông và phân phối đa kênh có thể sử dụng định tuyến dựa vào nội dung do Media Extender cung cấp. Nội dung ban đầu của truyền thông luôn luôn cần một số điều chỉnh trước khi tiêu dùng. Ví dụ, định dạng truyền thông xem lại quảng cáo là bản sao có độ phân giải thấp hơn của tài sản ban đầu. Và các dịch vụ phân phối/xuất bản khác nhau nằm ở các vùng khác nhau đòi hỏi phải có định dạng đầu vào khác nhau. Khả năng mạnh mẽ này của định tuyến dựa vào nội dung đang sử dụng dịch vụ chèn vào ngầm định để giải quyết sự không khớp giữa dịch vụ truyền thông và dịch vụ đích.

Định tuyến dựa vào nội dung là xương sống của sự sắp xếp động được thảo luận trong phần 1. Ở đây, chỉ sử dụng phân phối nhiều kênh làm ví dụ để giải thích cơ chế làm việc của nó. Các nghiệp vụ chuyên nghiệp không cần phải giải quyết các bước tiềm năng đang xử lý việc chuyển đổi và dịch chuyển định dạng của nội dung trong khi mô hình hóa dòng công việc phân phối nhiều kênh. Định tuyến dựa vào nội dung của Media Extender sẽ tính toán các bước qui trình bổ sung cần thiết trước cuộc gọi dịch vụ của nhà xuất bản cụ thể cuối cùng. Việc xử lý không khớp là trong suốt với dòng công việc của máy khách, có thể làm giảm nỗ lực làm việc và cải thiện việc sử dụng lại.

Việc xử lý xuất bản nhiều kênh có thể sử dụng dòng trung gian do MxRules xây dựng được chỉ ra trong Hình 7.

Các đặc tính của nguyên hàm MxRules là:

  1. Kiểu cổng, vùng tên và phiên bản của dịch vụ - Thông tin WSDL dịch vụ.
  2. Mục số XPath - người dùng có thể xác định xpath của "didl: Container" trong thông báo gửi đến.
  3. Định dạng đầu ra của XPath - Người dùng có thể xác định vị trí XPath của bộ mô tả định dạng truyền thông có chứa định dạng đầu ra đã dự kiến do dịch vụ đích (đặc biệt với dịch vụ chuyển mã) tạo ra.
  4. Phân loại - Tìm kiếm các đối tượng phù hợp với một phân loại dịch vụ cụ thể.
  5. Cho phép lựa chọn động – Cho phép tính toán chi phí với dịch vụ đích hay kế hoạch thực hiện (tính từng dịch vụ chèn vào và dịch vụ đích). Một lựa chọn có chi phí thấp nhất sẽ là kết quả cuối cùng.
  6. Cho phép Chất lượng và dịch vụ (QoS) của dịch vụ chèn vào – Hạn chế việc sử dụng dịch vụ chèn vào khớp với QoS cần thiết để xây dựng kế hoạch thực hiện.

Nguyên hàm trung gian MxRules hoạt động theo bốn giai đoạn:

  1. Thiết lập một tập hợp các dịch vụ đích tiềm năng. Tập hợp này được chuyển vào trong "/context/primitiveContext/EndpointLookupContext" của SMO đầu vào hoặc được tạo ra bằng cách sử dụng một MxEndpointLookup để chọn trước các dịch vụ. Việc lựa chọn này có thể dựa vào DID hay dựa vào không-DID ở giai đoạn này. Nếu không tìm thấy dịch vụ cụ thể nào trong đăng ký dịch vụ trong quá trình lựa chọn trước, thì một dịch vụ trừu tượng được đặc trưng bởi các đặc tính portTypeName, vùng tên và phân loại được quy định trên nguyên hàm MxRules sẽ được tạo ra như một dịch vụ đích.
  2. Căn cứ vào các đặc tính truyền thông mô tả bởi các mục số (Digital Item) và các dịch vụ đích, MxRules quyết định xem các đích có thể tiêu dùng truyền thông chưa thay đổi không hoặc nó đòi hỏi truyền thông có chuyển đổi định dạng trong lúc chuẩn bị không. Nếu cần, hãy tìm một bộ chuyển mã phù hợp trong đăng ký dịch vụ.
  3. Nếu có nhu cầu dịch chuyển dữ liệu giữa nguồn đầu vào và các bộ chuyển mã hoặc xem xét các đích, hãy căn cứ vào siêu dữ liệu dịch vụ.
  4. Các kế hoạch thực hiện có chứa các dịch vụ chèn vào và dịch vụ đích sẽ được tạo ra và được thiết lập trong SOAPHeader của SMO này. Cấu trúc mô tả kế hoạch thực hiện được chỉ ra trong Hình 8. Về toàn bộ thông báo SMO truyền từ thiết bị đầu cuối dòng con của MxRules hãy tham chiếu tệp đính kèm 2- OutputMessage.xml
Hình 7. Dòng trung gian MxRules của nhà xuất bản
Dòng trung gian MxRules của nhà xuất bản
Hình 8. Cấu trúc của Kế hoạch thực hiện
Cấu trúc của Kế hoạch thực hiện

Chúng tôi muốn thảo luận thêm một chút nữa về cấu trúc của Kế hoạch thực hiện. Vì MxRules có thể tạo ra nhiều kế hoạch thực hiện, nên thường dùng "executionPlanID" để xác định một kế hoạch thực hiện truyền tới một đầu cuối dòng con của MxRules. Giá trị của "xpathDID" cho biết xpath của "didl: Container" được xử lý bởi MxRules sẽ rất có ích cho việc sử dụng nhiều DID, để biết thêm chi tiết hãy xem phần 2 về chủ đề của loạt bài này. Giá trị của "MessageName" sẽ được sử dụng để đặt trước kiểu thông báo đầu vào cho kịch bản cổng dịch vụ. Mỗi dịch vụ (dịch vụ chèn vào và dịch vụ đích) trong Kế hoạch thực hiện được tổ chức như "ServiceInstance" (cá thể dịch vụ), nó sẽ ghi lại wsdl portType, hoạt động, địa chỉ điểm cuối, một số các đặc tính và phân loại của dịch vụ. Các đặc tính bất kỳ liên quan để việc thực hiện và logic chức năng của dịch vụ có thể được thiết lập trong trường "ServcieProperty" (Đặc tính dịch vụ). Và việc phân loại được chia thành serviceClassfication (Phân loại dịch vụ) cho biết kiểu dịch vụ, khi mà operationClassification (Phân loại hoạt động) được dùng để nhận biết hoạt động Đồng bộ hóa (RR) và Không đồng bộ hóa (RRN) bằng cách sử dụng cờ "SyncAsync".

Nếu có một tập hợp kế hoạch thực hiện do MxRules tạo ra, một kế hoạch thực hiện đầu tiên sẽ là kết quả đầu ra được truyền đến thiết bị đầu cuối "dòng con" của MxRules. Nếu những người dùng cuối chọn "Lựa chọn động" hay "QoS của dịch vụ chèn vào", thì toàn bộ số kế hoạch thực hiện do MxRules tạo ra có thể không được tính đến và chỉ có một kế hoạch thực hiện đáp ứng đúng điều kiện mới có thể xuất ra kết quả. Điều này sẽ được thảo luận như dưới đây:

Sử dụng lựa chọn động sẽ trả về kế hoạch thực hiện với chi phí thấp nhất. Việc xây dựng giá thành dựa trên chi phí của mỗi chi dịch vụ trong kế hoạch thực hiện. Tổng giá trị của các số liệu thống kê mô tả tải CPU, dung lượng lưu trữ có sẵn, băng thông mạng có sẵn và kích thước hàng đợi công việc được tính. Và chỉ có mỗi dịch vụ có đặc tính "có sẵn" được thiết lập tới điều kiện đúng sẽ được sử dụng tính toán, nếu không kế hoạch thực hiện này sẽ bị loại bỏ. Một hệ thống giám sát độc lập sẽ thu thập các ma trận được ghi lại trong đăng ký động của Media Extender.

Đặc tính Cho phép QoS của dịch vụ chèn vào sẽ loại trừ kế hoạch thực hiện mà cá thể dịch vụ của nó không thể ăn khớp với yêu cầu QoS của dịch vụ chèn vào, ví dụ như tốc độ truyền cao, chất lượng cao của đầu ra bộ chuyển mã.

Về toàn bộ thông báo SMO truyền từ đầu cuối "dòng con" của MxRules hãy tham chiếu tệp đính kèm 2- OutputMessage.xml

Máy kế hoạch thực hiện

Để hoàn thành kịch bản định tuyến dựa vào nội dung, ví dụ như phân phối nhiều kênh, kế hoạch thực hiện này sẽ được phân tích cú pháp trong SubProcessBP – máy thời gian chạy của kế hoạch thực hiện như trong Hình 9.

SubProcessBP lấy thông báo đầu vào được truyền từ dòng trung gian của Media Extender và trích xuất Thùng chứa MPEG-21 được dùng để tạo ra thông báo yêu cầu đang gửi đến các dịch vụ chèn vào để xử lý các tệp truyền thông được tham chiếu. Sau khi nhận được đáp ứng từ dịch vụ chèn vào, SubProcessBP cập nhật mô tả MPEG-21 đang chuẩn bị cho một dịch vụ chèn vào tiếp theo hoặc cho dịch vụ đích cuối cùng. Bước này sẽ xảy ra nhiều lần cho đến khi tất cả cá thể dịch vụ trong kế hoạch thực hiện đã được gọi mà không mắc lỗi.

Chẳng hạn có chuỗi dịch vụ như Transcoder1 đến Publisher1 để phân phối video cho điện thoại di động. Thùng chứa DID ban đầu được ánh xạ tới dịch vụ Transcoder1 của tham số đầu vào DID. Cuối cùng, thành phần DID được cập nhật từ Transcoder1 được ánh xạ tới thùng chứa DID của Publisher1 đích. Khi công việc của Publisher1 đích hoàn thành thì truyền thông ban đầu đã được gửi đến thiết bị cần thiết với định dạng đã xác định. Dòng công việc khách và dòng trung gian có thể được sử dụng lại cho việc phân phối kênh khác (IPTV, Web và DVD/CD) mà không thay đổi như điện thoại di động.

Hình 9. Trình tự thực hiện trong SubProcessBP
The execution sequence in SubProcessBP

Tóm tắt

Bài viết này đã cung cấp tóm tắt về khái niệm cơ bản của Media Extender. Và tác giả đã sử dụng hai kịch bản điển hình để thể hiện rằng Media Extender có thể làm giảm những nỗ lực thiết lập dòng công việc xử lý truyền thông, giúp mọi người trong ngành công nghiệp môi trường truyền hoàn thành quản lý nội dung truyền thông động và tự động.

Dòng trung gian mẫu được dùng cho kịch bản phân phối nhiều kênh trong bài viết này đã được đính kèm trong phần Tải về.


Các tải về

Mô tảTênKích thước
Sample Input Message for Media Extender1InputMessage.xml2KB
Sample Output Message from MxRules Primitve2OutputMessage.xml5KB
The sample mediation flow3WEMXRulesPublishMd.zip78KB

Các ghi chú

  1. Thông báo đầu vào mẫu cho Media Extender.
  2. Thông báo SMO mẫu truyền từ thiết bị đầu cuối dòng con MxRules.
  3. Tệp trao đổi dự án với nhau (PI) cho kịch bản phân phối nhiều kênh.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=SOA và dịch vụ Web
ArticleID=661175
ArticleTitle=Bắt đầu Media Extender với WebSphere Process Server, Phần 1: Tổng quan: Khái niệm và cách sử dụng cơ bản
publish-date=05282011