Bắt đầu Media Extender với WebSphere Process Server, Phần 2: Các tính năng mới: Có gì mới trong phiên bản Media Extender 7.0

Loạt bài này mô tả các tính năng mới và nâng cao trong Media Extender (Bộ mở rộng truyền thông) cho WebSphere Process Server 7.0 (phiên bản Máy chủ qui trình WebSphere 7.0), bao gồm cả sự phát triển của Hub truyền thông (Media Hub), cải tiến MxEndpointLookup và MxRules hỗ trợ ASD và siêu dữ liệu truyền thông cụ thể của người dù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 với WebSphere Process Server (gọi tắt là Media Extender) cung cấp các phương tiện trung gian của dịch vụ mở rộng, các phương tiện này có thể được sử dụng như là các thành phần trong dòng công việc xử lý nội dung truyền thông. Nó cho phép tích hợp các hệ thống nghiệp vụ và nội dung với nhau để quản lý nội dung phong phú động và hiệu quả. So sánh với phiên bản Media Extender 6.2, phiên bản 7.0 đã triển khai thực hiện nhiều tính năng mới để kết hợp tốt hơn với hồ sơ năng lực BPM&C của WebSphere và cải thiện khả năng định tuyến và quản lý nhận thức-nội dung.

Bài viết này trình bày các tính năng và các hàm mới trong phiên bản Media Extender 7.0, bao gồm cả việc chấp nhận các giao diện dịch vụ truyền thông của ASD (Abstract Service Definition-Định nghĩa dịch vụ trừu tượng), Giải pháp Hub truyền thông, cải tiến MxLookup, khả năng kiểm soát các yêu cầu chất lượng dịch vụ (QoS) của dịch vụ chèn vào, hỗ trợ siêu dữ liệu truyền thông cụ thể của người dùng trong việc ra quyết định về dòng công việc của qui trình truyền thông và tác động đến việc định tuyến dịch vụ.

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. Hãy hiểu rõ bài viết "Bắt đầu với Media Extender cho WebSphere Process Server, Phần 1: Tổng quan" được giả định.


Cách sử dụng ASD trong Media Extender

Giới thiệu ASD

ASD (Định nghĩa dịch vụ trừu tượng) cho Media Services (Các dịch vụ Truyền thông) cung cấp một cơ chế linh hoạt và mở rộng để truy cập độc lập vào các lớp của các dịch vụ truyền thông từ việc thực hiện cụ thể của từng dịch vụ ở một mức trừu tượng thích hợp. Điều này cho phép thực hiện các nguyên tắc SOA, làm đơn giản hoá việc phối hợp hoạt động của dịch vụ web và cung cấp sự dàn xếp thích hợp có tính đến sự phức tạp của các hoạt động truyền thông và siêu dữ liệu liên quan đến truyền thông. Bằng cách sử dụng ASD, ISV (Independent software vendor- Nhà cung cấp phần mềm độc lập) có thể tập trung vào việc thực hiện dịch vụ để cung cấp các hàm truyền thông mong muốn. ASD cho phép kết nối dễ dàng hơn với Bus của Media Service, hoạt động qua lại với ISV hoặc dịch vụ khách hàng khác và khả năng mở rộng và xử lý hư hỏng/lỗi tốt hơn.

Có 11 định nghĩa giao diện dịch vụ trình bày các hoạt động truyền thông điển hình:

  • Bộ chuyển mã (Transcoder) - để thực hiện chuyển đổi định dạng truyền thông này sang định dạng truyền thông khác hoặc để mã hóa từ nguồn tương tự (analog) sang định dạng truyền thông số.
  • Hình mờ (Watermark) - để nhúng một hình mờ duy nhất trong một tệp truyền thông số.
  • Vận chuyển (Transport) - để thực hiện dịch chuyển dữ liệu của tệp truyền thông lớn từ một máy chủ này sang máy chủ khác.
  • Kho lưu trữ (Repository) (Digital Asset Management-Quản lý tài sản số) - để thêm tài sản mới, lấy ra hoặc quản lý tài sản số hiện có của một danh mục hoặc kho lưu trữ.
  • Xác nhận hợp lệ truyền thông (Media Verification) - để thực hiện phân tích hoặc xác nhận hợp lệ các đặc điểm cụ thể của tệp truyền thông số, thường là một phần của qui trình bảo đảm chất lượng.
  • Dấu vân tay (Fingerprint) - để thực hiện phân tích lấy dấu vân tay pháp y của một tệp truyền thông số.
  • Quản lý tài sản vật lý (Physical Asset Management - PAM) - để thêm mới hoặc quản lý tài sản vật lý hiện có (ví dụ, các băng video hoặc các băng âm thanh) trong danh mục hoặc kho lưu trữ.
  • Trình lập biểu tài nguyên (Resource scheduler) - để lập biểu lịch tài nguyên mới hoặc quản lý tài nguyên hiện có sẵn.
  • Xuất bản (Publish) - để thực hiện đóng gói và xuất bản truyền thông số tới một hoặc nhiều kênh phân phối.
  • Chỉnh sửa (Edit) - để giúp quản lý qui trình NLE (Non-Linear Editing -Chỉnh sửa phi tuyến) của truyền thông số.
  • Quản lý bản quyền số (DRM-Digital Rights Management) - để quản lý bản quyền trí tuệ của tài sản truyền thông giúp ngăn chặn việc sao chép hoặc trao đổi về định dạng khác bất hợp pháp

ASD được chấp nhận trong Media Extender v7.0

SubProcessBP và dòng công việc trung gian không phải cổng dịch vụ 2 mẫu đi kèm với Media Extender cung cấp sự hỗ trợ cho ASD.

Trong SubProcessBP, việc xử lý dịch vụ chèn vào dựa vào định nghĩa ASD. SubprocessBP sẽ trích ra "didl: Container" của MPEG-21 từ cấu trúc thông báo do ASD xác định và ánh xạ nó tới thông báo yêu cầu của các dịch vụ chèn vào. Mỗi một trong các dịch vụ chèn vào sẽ xác nhận hợp lệ và truyền tới nhánh qui trình phù hợp dựa trên việc phân loại dịch vụ, kiểu cổng, vùng tên của kiểu cổng và kiểu cuộc gọi được quy định trong ASD. Mỗi thông báo yêu cầu của dịch vụ chèn vào được tổ chức như ASD đã quy định. Và việc xử lý lỗi của cuộc gọi dịch vụ sẽ gói thông báo lỗi/ngoại lệ tiếp sau ASD đã giới thiệu.

Trên thực tế SubprocessBP cũng hỗ trợ dịch vụ chèn vào mà dịch vụ không-ASD đã hỗ trợ. Khi khách hàng sử dụng dịch vụ bộ chuyển mã và vận chuyển được dịch vụ dịch vụ không-ASD hỗ trợ, cần có một ánh xạ giữa các dịch vụ không-ASD và dịch vụ ASD. Việc lắp ghép mô đun SCA (Service Component Architecture-Kiến trúc thành phần dịch vụ) mẫu được chỉ ra trong Hình 1.

Hình 1. Ánh xạ dịch vụ ASD và không ASD
Ánh xạ dịch vụ ASD và không ASD

Dòng công việc trung gian (không phải cổng dịch vụ) của dịch vụ cụ thể 2 đang sử dụng giao diện dịch vụ Kho lưu trữ (Repository) của ASD giải thích cách lắp ghép các nguyên hàm do Media Extender và WESB cơ sở cung cấp để thực hiện tìm kiếm Kho lưu trữ truyền thông và xây dựng kế hoạch thực hiện để gọi Kho lưu trữ nếu có định dạng truyền thông hoặc vị trí không khớp.

Mỗi giao diện được quy định trong ASD tồn tại theo hai phiên bản:

  • Yêu cầu/Đáp ứng (RR), ở đây một yêu cầu dịch vụ có một thông báo đáp ứng đơn giản. Phong cách này của các giao diện rất đơn giản để sử dụng trong các dòng công việc nghiệp vụ.
  • Yêu cầu/Đáp ứng đồng bộ với mô hình khai báo không đồng bộ (RRN) ở đây đáp ứng ban đầu là một xác nhận về yêu cầu và đáp ứng dịch vụ thực được phân phối như là một cuộc gọi lại. Phong cách này của giao diện có thể đơn giản hơn nữa để sử dụng như là thực hiện dịch vụ.

Một bộ điều hợp có thể được sử dụng để chuyển đổi giữa hai phong cách của giao diện, và một ví dụ về bộ điều hợp này được đưa ra trong dự án ASDRRtoRRN đi kèm trong gói Media Extender. Dự án ASDRRtoRRN có một liên kết SCA có thể được các qui trình nghiệp vụ khách sử dụng và có một qui trình BPEL đại diện cho một Kho lưu trữ ủy quyền có thể gọi cả hai trung gian mẫu, tùy thuộc vào hệ thống đấu nối tham chiếu đến một trong các phần nhập khẩu trong lắp ghép đó. Và ứng dụng ASDRRtoRRN làm một bộ điều hợp, xử lý chuyển đổi phong cách Yêu cầu/Đáp ứng thành phong cách Yêu cầu/Đáp ứng có khai báo. Nó có thể được sử dụng như một tài liệu tham khảo cho việc biến đổi giao diện dịch vụ khác.

Các tệp wsdl mẫu của ASD và các tệp mô tả dịch vụ (*. Descr.xml) cũng có trong hình ảnh Media Extender. Nó có thể được sử dụng cho đăng ký dịch vụ dựa vào hệ thống tệp.


Tiến triển của giải pháp Media Hub

Để khai thác Media Extender, một hệ thống cần phải có khả năng hoạt động như một dịch vụ để chấp nhận và dịch các thông báo đầu ra từ các dòng trung gian của Media Extender. Tài sản các dịch vụ của trình xây dựng dòng công việc Hub truyền thông (Media Hub Workflow Builder Services Asset- gọi tắt là Workflow Builder) cung cấp sự hỗ trợ này trong phiên bản đầu tiên của Media Extender chẳng hạn như phiên bản 6.2. Dòng công việc khách đã được tạo ra trong trình soạn thảo của Workflow Builder và Kế hoạch thực hiện được dịch trong máy thời gian chạy của Workflow Builder.

Phiên bản Media Extender v7.0 đã loại bỏ sự phụ thuộc rất cao này với tài sản dịch vụ, để cho phép sản phẩm được tích hợp tốt hơn vào hồ sơ năng lực BPM&C của WebSphere. Dòng công việc khách có thể được mô hình hóa trong WBM (WebSphere Business Modeler –Trình mô hình hóa nghiệp vụ WebSphere) và được xây dựng trong WID (Các nhà phát triển WebSphere) này. Việc phân tích cú pháp kế hoạch thực hiện và kiểm soát cuộc gọi dịch vụ có thể được hoàn thành trong SubProcessBP mẫu, đây là một ứng dụng BPEL chạy trên WPS (Máy chủ qui trình WebSphere).

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

Bài viết này sẽ cung cấp một giới thiệu ngắn gọn về cơ chế làm việc của SubProcessBP, biểu đồ dòng công việc được chỉ ra trong Hình 2, ở đây chúng ta chỉ cho thấy qui trình dịch vụ đích và vận chuyển chèn vào để đơn giản hóa câu lệnh (nó cũng phù hợp với việc xử lý bộ chuyển mã chèn vào).

Hình 2. Dòng công việc SubProcessBP
Dòng công việc SubProcessBP

Trong bước 1, kế hoạch thực hiện sẽ được trích xuất từ thông báo để kiểm soát trình tự cuộc gọi dịch vụ. Thùng chứa MPEG-21 mang siêu dữ liệu truyền thông sẽ được trích xuất và các thành phần của nó sẽ được 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 và cập nhật mô tả MPEG-21. Số lượng các cá thể dịch vụ trong kế hoạch thực hiện sẽ được sử dụng để kiểm soát vòng lặp qui trình được chỉ ra trong bước 2. SubProcessBP sẽ kiểm tra cá thể dịch vụ hiện tại và tìm ra nhánh xử lý phù hợp trong bước 3. Trong bước 4, nó hoàn thành việc chuẩn bị cuộc gọi của dịch vụ chèn vào: thùng chứa DID ban đầu được ánh xạ tới tham số đầu vào DID của thông báo yêu cầu của dịch vụ chèn vào; các tham số gọi lại được thiết lập chính xác cho kiểu dịch vụ RRN; địa chỉ điểm cuối dịch vụ cũng sẵn sàng cho cuộc gọi động của dịch vụ chèn vào trong bước này. Thông báo yêu cầu sẽ được gửi đến dịch vụ chèn vào trong bước 5. Trong bước này, việc xử lý lỗi sẽ giải quyết lỗi nghiệp vụ và lỗi thời gian chạy trong khi dịch vụ gọi và trả về thông báo lỗi đến dòng công việc khách để phân tích thêm nữa. Đối với kiểu dịch vụ RRN, một bộ tương quan sẽ được sử dụng để xác định thông báo gọi lại và bước bổ sung chọn lấy cuộc gọi lại cần thiết. Sử dụng các kết quả từ các dịch vụ chèn vào để cập nhật thùng chứa DID đ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 sẽ được hoàn thành trong bước 6. Khi tất cả các dịch vụ chèn vào đã được xử lý, cuộc gọi dịch vụ đích sẽ được thực hiện trong bước 7-8 và đáp trả kết quả tới dòng công việc khách thông qua dòng trung gian gọi SubProcessBP này.

Dòng trung gian của cổng dịch vụ để thực hiện ESB hướng truyền thông

Để triển khai thực hiện ESB hướng truyền thông thực, Media Extender có kèm theo dòng trung gian của Cổng dịch vụ mẫu để xử lý yêu cầu từ dòng công việc khách. Đây là sự phát triển thứ hai cho Giải pháp Hub truyền thông. Nó dựa vào tính năng mới của cổng dịch vụ WESB, sử dụng chỉ một giao diện cổng duy nhất để chấp nhận nhiều yêu cầu và hoàn thành lựa chọn nhận thức truyền thông, định tuyến dựa trên nội dung và cuộc gọi động dịch vụ. Việc lắp ghép mô đun truyền thông và dòng truyền thông được thể hiện trong Hình 3.

Hình 3. Biểu đồ lắp ghép dòng trung gian của cổng dịch vụ
Biểu đồ lắp ghép dòng trung gian của cổng dịch vụ

Mô đun trung gian chấp nhận đầu vào liên kết JMS và định hướng thông báo nhằm vào cuộc gọi dịch vụ đích hay xử lý kế hoạch thực hiện SubProcessBP. Dòng trung gian bao gồm việc lựa chọn điểm cuối của dịch vụ truyền thông, định tuyến dựa vào kế hoạch thực hiện, trình bày các khả năng tìm kiếm điểm cuối nâng cao và QoS chèn vào sẽ được thảo luận trong các phần sau.

Hai MxEndpointLookup "LocateTarget" (Định vị đích) hỗ trợ tìm kiếm riêng rẽ DID và không-DID của mô tả MPEG-21, được sử dụng để chọn sẵn dịch vụ đích. Các tiêu chuẩn được nới lỏng cho việc tìm kiếm điểm cuối không-DID, ví dụ, chỉ sử dụng mã định danh (ID) hoặc porttype (kiểu cổng) và phân loại dịch vụ. Nếu có ít nhất một dịch vụ ứng cử viên, thông báo sẽ dịch chuyển dịch vụ chèn vào của bộ lọc nhờ các tham số QoS, ở đây chúng ta sử dụng Transport (Vận chuyển) với ưu tiên chuyển dịch cần thiết làm ví dụ. Bước này chọn sẵn một tập hợp các dịch vụ chèn vào đáp ứng yêu cầu QoS cụ thể. Sau đó, thông báo sẽ được truyền tới nguyên hàm có tên là Lập kế hoạch thực hiện (Execution Planning). Hướng ra ngoài hoặc kế hoạch thực hiện được xây dựng bằng dịch vụ đích và dịch vụ chèn vào có hạn chế QoS sẽ là đầu ra kết quả. Cuối cùng thông báo sẽ gửi tới nút Callout thích hợp cho bước tiếp theo.

Khi không thể tìm ra đích hoặc kế hoạch thực hiện ứng cử viên, thông báo sẽ được truyền đến nguyên hàm máy khách xử lý lỗi và trả về dòng công việc khách nhờ nút Fault (lỗi). Tại dòng đáp ứng trung gian, thông tin về đáp ứng bình thường và thông tin lỗi của dịch vụ đích hoặc SubProcessBP cũng sẽ được giải quyết nhờ việc xử lý lỗi trung gian và trả về dòng công việc khách. Mã trong nguyên hàm tùy chỉnh xử lý lỗi được chỉ ra trong Liệt kê 1.

Liệt kê 1. Mã mẫu của việc xử lý lỗi trong dòng trung gian của cổng dịch vụ
      //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);

Trong dòng trung gian của Cổng dịch vu (Service Gateway), người dùng có thể quy định xpath của các đặc tính của nguyên hàm Media Extender như là biểu thức xpath ký tự đại diện để bỏ qua kiểu thông báo đầu vào cụ thể. Cả hai "/body/*/RequestDID/Container.0" và "/body/message/RequestDID/Container.0" đều được hỗ trợ.


Cải tiến MxEndpointLookup

Người dùng cuối phải sử dụng nguyên hàm tìm kiếm điểm cuối ESB cho thông báo không-DID. Trong phiên bản 7.0, MxEndpointLookup cũng hỗ trợ tìm kiếm điểm cuối DID và không-DID từ WSRR (Kho lưu trữ và Đăng ký dịch vụ WebSphere) hoặc đăng ký dịch vụ dựa vào hệ thống tệp. Khi những người dùng cuối giữ cho Xpath Digital rỗng, MxEndpointLookup có thể được xử lý như tìm kiếm không-DID, portType, vùng tên portType, phân loại và các đặc tính của người dùng sẽ được sử dụng để xây dựng câu lệnh truy vấn đăng ký dịch vụ. Nếu không, các đặc tính mục Xpath Digital, đầu ra đích và giao thức Đầu vào (Input) sẽ được thêm vào truy vấn. Các đặc tính của nguyên hàm MxEndpointLookup được minh họa trong Hình 4.

Hình 4. Các đặc tính của nguyên hàm MxEndpointLookup
Các đặc tính của nguyên hàm MxEndpointLookup

Khả năng kiểm soát các yêu cầu QoS của dịch vụ

Trong môi trường sản phẩm tùy chỉnh, có dịch vụ khác cung cấp mức QoS khác nhau để đáp ứng yêu cầu nghiệp vụ cụ thể. Ví dụ, các băng video độ nét cao do khách hàng VIP đăng ký đòi hỏi bộ chuyển mã chất lượng/có độ phân giải cao để chuyển đổi truyền thông ban đầu. Ví dụ khác, một dịch vụ vận chuyển nhanh là cần thiết để xuất bản tin khẩn cấp. Trong Media Extender V7.0, một tùy chọn mới trong nguyên hàm được gọi là "Cho phép QoS của dịch vụ chèn vào" cung cấp khả năng kiểm soát yêu cầu QoS trong việc tạo kế hoạch thực hiện. Bài viết này sử dụng dòng trung gian của Hình 3 để giải thích cơ chế làm việc.

Đầu tiên, một MxEndpointLookup được sử dụng để chọn sẵn dịch vụ đích ứng cử viên nếu cần QoS của dịch vụ đích. Thông báo đầu vào có thể mang các tham số QoS và các tiêu chuẩn truy vấn liên quan có thể được định nghĩa như là "User Properties" (Các đặc tính của người dùng) của nguyên hàm MxEndpointLookup. MxEndpointLookup sẽ tìm ra dịch vụ phù hợp và thiết lập thông tin các điểm cuối trong "/headers/SMOHeader/Target/address" cho một cá thể phù hợp duy nhất hay "/context/primitiveContext/EndpointLookupContext" cho nhiều cá thể phù hợp.

Thứ hai, các nguyên hàm MxEndpointLookup thêm vào được sử dụng để chọn sẵn dịch vụ chèn vào với các tham số QoS cụ thể, ví dụ như chất lượng cho dịch vụ bộ chuyển mã và tốc độ cho dịch vụ vận chuyển. Việc thiết lập giá trị của nguyên hàm giống như trên. Kết quả sẽ đưa vào "/context/primitiveContext/EndpointLookupContext" (phải chỉ rõ chính sách phù hợp để "trả về tất cả các điểm cuối phù hợp").

Trong MxRules, kế hoạch thực hiện sẽ được các dịch vụ chèn vào và dịch vụ đích đã chọn sẵn (nhóm dịch vụ) lọc. Chỉ có kế hoạch thực hiện được xây dựng bằng các dịch vụ trong nhóm dịch vụ sẽ được trả về làm kết quả. Nếu kế hoạch thực hiện chứa bất kỳ dịch vụ nào bị loại khỏi nhóm dịch vụ sẽ bị bỏ qua.

Tất cả các tiêu chuẩn QoS ở trên có thể là các đặc tính nâng cấp nguyên hàm có thể thay đổi giá trị trong thời gian chạy bằng cách thêm nguyên hàm WESB của PolicyResolution trong dòng truyền thông như trong Hình 5. Nó có thể làm cho có khả năng dùng lại dòng trung gian nhiều hơn. Để có nhiều thông tin hơn nữa về thay đổi động các đặc tính nâng cấp nguyên hàm hãy tham khảo Trung tâm thông tin WESB (WESB infoCenter).

Hình 5. Thay đổi động các đặc tính nâng cấp nguyên hàm
Thay đổi động các đặc tính nâng cấp nguyên hàm

Hỗ trợ siêu dữ liệu cụ thể của người dùng

Media Extender xử lý truyền thông nhờ sử dụng nội dung được chuyển qua bằng công nghệ tham chiếu có sử dụng siêu dữ liệu truyền thông không phải là truyền thông thực. Siêu dữ liệu truyền thông được chứa trong "didl:Component" của DID của mô tả MPEG-21. Ví dụ về cấu trúc DID được chỉ ra trên đầu Hình 6 là phức tạp và lặp lại. Trong phiên bản Media Extender trước đó, có rất nhiều hạn chế về qui trình DID như trong phần dưới cùng của Hình 6.

  • (1) Một "didl: Item" duy nhất: hỗ trợ cấu trúc không lặp lại, chỉ có thể đặt một "didl: Item" trong "didl:Container".
  • (2) Cấu trúc cố định: đặt siêu dữ liệu truyền thông phải trong "Container.0/Item.0/Component.0"
  • (3) Một tài nguyên và bộ mô tả có liên quan duy nhất tại vị trí đã định sẵn: "Container.0/Item.0/Component.0/Resource.0"
  • (4) Không có siêu dữ liệu cụ thể của người dùng nào có thể được mang trong thông báo: chỉ chấp nhận siêu dữ liệu được định nghĩa như là "md:MediaDescriptor"

Trong phiên bản 7.0, Media Extender hỗ trợ:

  • (1) Hỗ trợ cấu trúc lặp lại với một số hạn chế: "didl:Resources" phải có thuộc tính "@ ref" và một phần tử "didl: Descriptor" anh em trước đó phải có một "didl:Statement/md:MediaDescriptor". Trong Hình 6, Resource 2 và 3 không khớp với tiêu chuẩn này nên chúng sẽ bị bỏ qua với thông tin cảnh báo trong quá trình xử lý của Media Extender.
  • (2) Cho phép mang siêu dữ liệu cụ thể của người dùng.
    Trong kịch bản tùy chỉnh, thông báo gửi đến có lẽ chỉ chứa siêu dữ liệu cụ thể của người dùng, ví dụ, MXF hoặc MPEG 7, để biểu thị các đặc tính truyền thông. Nếu thông báo gửi đến không theo định dạng DID của mô tả MPEG-21, thì dòng công việc khách cần ánh xạ nó vào một thông báo DID mới của mô tả MPEG-21. Nếu thông báo gửi đến sử dụng DID của mô tả MPEG-21 để mang siêu dữ liệu, thì dòng công việc khách cần phải ánh xạ siêu dữ liệu truyền thông vào siêu dữ liệu hỗ trợ Media Extender "md:MediaDescriptor" và tạo ra một "didl: Descriptor" mới trong cùng một "didl:Component" để mang nó. Md:MediaDescriptor mới có thể được bắt nguồn từ siêu dữ liệu hiện có hoặc trực tiếp được trích ra từ tệp truyền thông như trong Resource 4 trong "Container.0/Container.0/Item.1/Component.0". Có MPEG 7 và "md: MediaDescriptor" ánh xạ đã tồn tại trong cùng một "Container.0/Container.0/Item.1/Component.0"
    Nếu siêu dữ liệu khác như là logic nghiệp vụ hoặc dịch vụ truyền thông cần thiết cũng có thể được biểu thị trong thông báo DID của mô tả MPEG-21 như trong "Container.0" và "Container.0/Container.0/Item.1". Tất cả siêu dữ liệu cụ thể của người sử dụng sẽ được giữ lại trong khi xử lý Media Extender.
  • (3) Nếu thông báo đầu vào có nhiều hơn một "didl:Resource" như trong Hình 6, Media Extender v7.0 có thể phân tích tất cả các tiêu chuẩn phù hợp của Resource được liệt kê trong (1). Nhưng chỉ xử lý "didl:Resource" đầu tiên trong "didl:Container" cụ thể của người dùng.
    Ví dụ, khi người dùng xác định "didl: Container.0", MxLookup hoặc MxRules có thể phân tích tất cả xpath của Resource và MediaDescriptor trong "didl: Container.0" này, nhưng chỉ tìm kiếm dịch vụ đích hoặc tính toán kế hoạch thực hiện cho Resource1 (trong "Container.0/Item.0/Component.0"), các Resource khác (Resource 4 trong "Container.0/Container.0/Item.1/Component.0", Resource 2/3 trong "Container.0/Container.0/Item.0/Component.0" sẽ bị bỏ qua nhưng vẫn còn lưu giữ trong thông báo. Khi thông báo được truyền vào SubProcessBP, chỉ có Resource 1 ( trong "Container.0/Item.0/Component.0") sẽ được dựng thông báo yêu cầu của dịch vụ chèn vào, việc cập nhật DID dựa vào Trả lời/Đáp ứng của dịch vụ chèn vào sẽ chỉ là Resource 1 đã xảy ra, trong khi các nội dung DID của Resource khác sẽ không bị thay đổi. Cuối cùng, DID kết hợp được chuyển tới dịch vụ đích.
Hình 6. Ví dụ về DID của MPEG-21
Ví dụ về DID của MPEG-21

Tóm tắt

Bài viết này trình bày các tính năng mới có trong Media Extender v7.0. Được xây dựng trên đề xuất ESB hiện có, các hàm mới sẽ cải thiện khả định tuyến nhận thức truyền thông và tốt hơn nữa cho phép các dịch vụ truyền thông phong phú và các ứng dụng Quản lý tài sản số (DAM-Digital Asset Management) kết nối như là các dịch vụ đích thực trong môi trường dòng công việc động linh hoạt, đem lại sức mạnh của SOA cho các nghiệp vụ truyền thông.

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


Tải về

Mô tảTênKích thước
The sample service gateway mediation flow1WemxRulesServiceGatewayMd.zip83KB

Ghi chú

  1. Dòng trung gian cổng dịch vụ mẫu cho bus hướng truyền thông.

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=661164
ArticleTitle=Bắt đầu Media Extender với WebSphere Process Server, Phần 2: Các tính năng mới: Có gì mới trong phiên bản Media Extender 7.0
publish-date=05282011