Viết các mã tuyệt vời với các API P8 FileNet của IBM, Phần 2: Thám thính công việc của chính bạn

Viết các mã tuyệt vời với các API P8 FileNet của IBM, Phần 2: Thám thính công việc của chính bạn Giới thiệu Nếu bạn đang sử dụng các API của P8, thì nhiều khả năng là bạn tham gia vào việc viết các ứng dụng mức doanh nghiệp. Nếu bạn tham gia vào việc viết các ứng dụng mức doanh nghiệp, thì sớm hay muộn, hiệu năng cũng sẽ trở thành mục cao nhất trong danh sách ưu tiên của bạn. Ngay cả khi hiệu năng đã rất tuyệt trong môi trường phát triển cô lập của bạn, thì đôi khi vẫn rất khó để dự đoán những gì sẽ xảy ra khi ứng dụng của bạn được triển khai dưới áp lực tải thực tế của nhiều người sử dụng. Các bài viết tới sẽ bàn về một số kỹ thuật mã hóa cụ thể để có hiệu năng tốt nhất. Bài viết này đặt nền tảng cho việc đó bằng cách bàn về một số công cụ và kỹ thuật để biết bạn đang đưa lên mạng những dữ liệu gì. Nó có vẻ như tạm thời chệch hướng khỏi những điều căn bản thiết thực khi mã hóa, nhưng bạn sẽ có các thông tin có giá trị khi bạn đọc các bài viết tới của loạt bài viết này và khi bạn phát triển các ứng dụng của riêng mình. Đối với rất nhiều ứng dụng, có hai nhân tố then chốt điều khiển hiệu năng:  Trước hết, hiệu suất tổng thể thường bị chi phối bởi số lượng các cuộc gọi mạng mà các ứng dụng khách của bạn gọi vào các máy chủ P8. Tùy thuộc vào bạn hỏi ai, các cuộc gọi mạng có thể là: cuộc gọi khứ hồi (R/Ts), gọi thủ tục từ xa (RPCs), truy cập máy chủ và nhiều tên tương tự khác. Tất cả những tên gọi khác nhau ấy đều cùng chỉ một việc: mạng đường ống dính líu đến việc truyền yêu cầu từ máy khách đến máy chủ và việc máy chủ tính toán và truyền về đáp ứng. Trong môi trường phát triển, cuộc gọi RPC có thể chỉ cần vài chục hoặc vài trăm mili giây. Thực vậy, hiếm khi một cuộc gọi RPC của P8 cần đến một phần đáng kể của một giây trong một môi trường cô lập. Trong môi trường chịu tải đầy đủ, khoảng thời gian này tăng nhanh vì phải ganh đua với nhau trên mạng, tại máy chủ và trong một số trường hợp, tại máy khách. Khi mọi thứ bị khuyếch đại, việc loại bỏ hoặc giảm quá tải đến hết mức có thể là đáng công làm. Đối với hai công việc riêng biệt cần phải được thực hiện trên máy chủ P8, thì luôn rẻ hơn (ngoại trừ các trường hợp khó khăn thực sự) nếu bạn có thể thực hiện chúng bằng một RPC duy nhất thay vì hai RPC.  Thứ hai, hiệu năng bị ảnh hưởng bởi số lượng dữ liệu – tức là số lượng byte – thực sự được truyền đi trên mạng trong một cuộc gọi RPC. Đây không chỉ là vấn đề của bộ định tuyến mạng có thể xử lý các bit nhanh như thế nào. Các dữ liệu được truyền đi càng nhiều, thì các API trình khách và các đối tác máy chủ của chúng càng cần phải làm việc nhiều hơn để lắp ráp và diễn giải các yêu cầu. Trong môi trường P8, hầu như kích thước của các yêu cầu luôn luôn chỉ là một phần nhỏ của kích thước của các đáp ứng, vì vậy việc cố gắng để điều chỉnh kích thước các yêu cầu hiếm khi đáng công. Việc điều chỉnh kích thước của các đáp ứng RPC thường có thể có tác động đáng kể về hiệu năng, và nó luôn đáng được ít nhất là nghiên cứu. Bài viết này chỉ bàn về một số điều, chúng sẽ giúp bạn có nhận thức về những gì mà ứng dụng của bạn đang làm ở cả hai lĩnh vực đó.  Công cụ dò tìm trên mạng giúp bạn tra tìm dữ liệu ở mức thấp đang truyền trên mạng. Mặc dù nghe có vẻ phức tạp, nhưng các công cụ hiện đại trong lĩnh vực này khá dễ vận hành, và chúng có thể làm đơn giản việc khoan sâu vào các vùng cụ thể.  Bằng cách ghi nhật ký API Java nội dung của P8, bạn có thể lệnh cho API cho bạn biết những gì nó đang thực hiện tại các điểm khác nhau. Đây là một kỹ thuật tốt để đánh giá cả về số lượng và kích thước của các RPC.  Bạn có thể sử dụng cá thể ObjectDumper trong mã phát triển của riêng bạn để chụp nhanh những gì có ở bên trong một đối tượng API của P8. Đây là việc hữu ích để đánh giá số lượng dữ liệu mà một đối tượng đang chuyên chở ở sau hậu trường và cũng để thấy sự khác biệt của các hoạt động khác nhau với dữ liệu đó. Sử dụng công cụ dò vết trên mạng mạng Trình thám thính (sniffer) là gì? Dò vết trên mạng có hàm ý chung là việc bắt giữ các dữ liệu thô truyền trên mạng. Các công cụ này đôi khi được gọi là bộ phân tích mạng, bộ thám thính mạng (được đặt theo tên của ông Sniffer - nhà phân tích mạng), hoặc là bộ thám thính gói. Các bộ thám thính ban đầu là các bộ phận chuyên dùng của thiết bị độc lập có thể được gắn kết vật lý tới một phân đoạn mạng. Các thiết bị như vậy vẫn còn tồn tại, nhưng hiện nay có các phần mềm tương đương với chúng để sử dụng hàng ngày. Mặc dù công dụng chính ban đầu của các bộ thám thính là để chẩn đoán các vấn đề mạng ở mức độ khá thấp, đôi khi chúng cũng có thể được sử dụng rất hiệu quả để có được bức tranh về truyền thông giữa các thành phần của một ứng dụng phân tán. Dò vết trên mạng nghe có vẻ là một chủ đề phức tạp và khó nắm bắt cho bất kỳ ai, trừ các chuyên gia, nhưng nó rất dễ tiếp cận đối với các nhà phát triển trung bình. Các công cụ có sẵn ngày nay thường có giao diện người dùng tốt và tài liệu hướng dẫn khá dễ hiểu. Bên cạnh việc bắt và phân tích luồng lưu thông mạng đang hoạt động, các trình thám thính cũng có thể được sử dụng để ghi lưu các luồng lưu thông thành một tệp tin hoặc để đọc tệp tin các luồng lưu thông đã được ghi lưu. Tệp tin như vậy thường được gọi là các tệp tin nắm bắt. Có các định dạng tệp tin bắt luồng lưu thông theo chuẩn thực tế của ngành công nghiệp, do vậy nhiều cơ hội (nhưng không dám chắc) rằng một tệp tin bắt luồng lưu thông do một ứng dụng thám thính tạo ra có thể đọc được bằng một trình thám thính khác. Nếu bạn chưa có công cụ dò vết trên mạng, thì bằng việc tìm kiếm Web theo bất kỳ một thuật ngữ nào đề cập ở trên sẽ nhận được một số lựa chọn thay thế phổ biến, bao gồm các công cụ mã nguồn mở hoặc miễn phí. Nhằm mục đích minh họa, bài viết này sử dụng Wireshark, một trình thám thính mã nguồn mở mạnh mẽ và phổ biến có sẵn tại trang Wireshark.org. Wireshark phiên bản 1.0.5 được sử dụng cho bài viết này, nhưng nếu bạn sử dụng phiên bản cũ hơn hoặc một công cụ hoàn toàn khác, thì các khái niệm được thảo luận vẫn có thể áp dụng được và bạn không gặp rắc rối nào. Mục tiêu của bài viết không phải là giúp bạn trở thành một chuyên gia về bất kỳ công cụ thám thính cụ thể nào. Thay vào đó, bài viết này cung cấp cho bạn một cái nhìn lướt qua các khả năng để bạn có thể tự mình tiếp tục khám phá. Bắt giữ kết quả dò vết trên mạng Mục đích chính của trình thám thính (sniffer) phần mềm là lắng nghe luồng lưu thông qua chồng giao thức nối mạng trên một máy tính mà không can thiệp vào luồng lưu thông đó. Điều này không hoàn toàn giống như lắng nghe chính trên mạng, nhưng cũng gần như thế nếu nói về những gì bạn sẽ làm. Bởi vì trình thám thính cũng là một chương trình chạy trên máy tính, điều đầu tiên bạn phải nghĩ đến là bạn sẽ chạy nó trên máy tính nào. Đôi khi điều này bị chi phối về mặt chức năng bởi những điều bạn đang cố gắng để kiểm tra. Trình thám thính chỉ nhìn thấy những thứ theo quan điểm của máy tính đang chạy nó, và nó thường không thể nhìn thấy lưu thông mạng giữa hai hoặc nhiều máy tính khác. Thực vậy, trong nhiều trường hợp phức tạp hơn, đôi khi cần phải chạy trình thám thính trên nhiều máy tính cùng một lúc để các hoạt động có thể tương quan với nhau. Tuy nhiên, điều đó không cần thiết cho kịch bản này, bởi vì bạn chỉ phải theo dõi các cuộc gọi điểm tới điểm. Sự lựa chọn của bạn rút lại chỉ còn là máy tính nơi mà API máy khách của bạn đang chạy hoặc là máy tính nơi mà máy chủ P8 đang chạy. Giả sử bạn có quyền truy cập như nhau vào cả hai máy tính, thì việc chạy nó trên máy tính khách của bạn có ý nghĩa hơn. Điều đó cho phép bạn tránh các hỗn loạn nhỏ của các yêu cầu từ các máy khách khác nếu máy chủ P8 của bạn được chia sẻ. Nếu máy chủ P8 của bạn không được chia sẻ hoặc có rất ít hoạt động trên đó, thì sự lựa chọn chỉ là vấn đề sao cho tiện cho bạn mà thôi. Đối với các loại tác vụ thường nhật trong kịch bản của bài viết này, thì trình thám thính phần mềm nói chung đặt thêm một tải công việc tối thiểu lên máy chạy nó. Bài viết này giả sử bạn đang chạy trình thám thính trên máy khách, nhưng nếu không phải như vậy thì cũng khá dễ thấy bạn phải làm khác đi những gì. Giả sử bạn có một ứng dụng đang chạy và muốn quan sát và điều chỉnh các nhân tố liên quan đến hiệu năng được mô tả ở trên. Nếu bạn chưa có ứng dụng của mình và chỉ muốn có một ứng dụng đơn giản để chạy để xem các kỹ thuật trong bài viết này làm việc như thế nào, thì bạn có thể tải về ứng dụng mẫu HelloDocument tại bài viết đầu tiên của loạt bài viết này. Có một số lưu ý mà bạn nên xem xét khi chạy một trình thám thính cùng với ứng dụng của bạn:  Hãy sử dụng truyền tải WSI thay vì truyền tải EJB. Truyền tải WSI sử dụng các XML được truyền bằng cách sử dụng HTTP. Mặt khác, truyền tải EJB sử dụng các định dạng và giao thức quyết định bởi máy chủ ứng dụng đang được sử dụng. Nói chung, truyền tải EJB sử dụng các định dạng nhị phân nén hoặc ngắn gọn. Các định dạng này rất tuyệt vời cho truyền thông khách/chủ, nhưng chúng khó xử lý khi giám sát luồng lưu thông mạng một cách trực quan.  Đừng sử dụng kiểu bảo vệ TLS/SSL trên các kết nối của bạn. Chính vì mục đích của nó, bảo vệ TLS/SSL làm cho không thể nhìn vào bên trong luồng lưu thông đón bắt được. Ngay cả nếu một bên thứ ba nghe toàn bộ cuộc đối thoại thiết lập kết nối TLS/SSL, thì nó sẽ không thể giải mã được luồng lưu thông được bảo vệ tiếp nối sau. Trình thám thính không có bất kỳ sức mạnh huyền diệu nào để nhìn xuyên qua tấm màn che TLS/SSL. Chạy không có bảo vệ TLS/SSL sẽ để lộ luồng lưu thông và các mật khẩu chưa mã hóa cho những kẻ nghe lén tiềm năng, vì vậy bạn sẽ muốn sử dụng thông tin và các tài khoản không nhạy cảm trong khi bạn chạy các thử nghiệm về trình thám thính của mình. Bởi vì nhiều khả năng là bạn làm điều này trong một môi trường phát triển hoặc thử nghiệm, nên rất dễ dàng để thu xếp. Nếu như còn chưa đủ rõ ràng, những điểm nêu trên kết hợp cùng nhau có nghĩa là URI kết nối của Máy nội dung của bạn phải là một URI HTTP (không phải là HTTPS và không phải là URI không HTTP). Cách làm chung là bật trình thám thính lên, chạy ứng dụng, tắt trình thám thính và phân tích luồng lưu thông mạng. Hình 1 cho thấy bắt đầu phiên đón bắt. Mỗi dòng trong cửa sổ trên cùng là một gói tin IP đơn lẻ đã đón bắt được. Trong thuật ngữ của trình thám thính, các gói còn được gọi là khung tin. Chỉ là nói nhẹ đi khi nói rằng đây là một màn hình phức tạp và bận rộn với người còn bỡ ngỡ. Đâu là dữ liệu đáng chú ý của RPC P8 mà bạn đang tìm? Trên thực tế, chúng không có trong hình 1. Hình 1 cho thấy chưa đầy một giây đầu tiên của hoạt động mạng, thậm chí chưa đủ thời gian để đổi sang cửa sổ khác và nhìn thấy ứng dụng của bạn đã bắt đầu. Hình 1. Thông tin dò vết trên mạng dạng thô, chưa được lọc Tất nhiên, bạn có thể cuộn xuống danh sách gói tin để tìm gói tin mà bạn cần tìm. Tuy nhiên, có phải là tốt hơn không nếu có cách nào để bỏ đi những thông tin mà bạn không quan tâm? Tất nhiên là có. Có hai cách tiếp cận để làm việc đó: bạn có thể ra lệnh cho công cụ thám thính ẩn đi, không hiển thị các khung tin không liên quan, hoặc bạn có thể ra lệnh cho công cụ thám thính bỏ qua các khung tin không liên quan trong khi nó đón bắt luồng lưu thông. Với cách tiếp cận đầu tiên, bạn có thể thay đổi ý định của bạn sau này và hiển thị lại các khung tin ẩn. Với cách thứ hai, các khung tin biến mất mãi mãi. Ưu điểm của phương pháp thứ hai là dung lượng các tệp tin chụp được nhỏ đi tương ứng. Điều này tạo ra sự khác biệt nếu bạn chạy với thời gian dài hơn. Vì bạn chủ yếu dò vết trên mạng trong các phiên làm việc ngắn và có thể chạy lại toàn bộ phiên làm việc nếu bạn bỏ sót một cái gì đó, nên sự lựa chọn gần như là vấn đề sao cho thuận tiện cho riêng bạn mà thôi. Nếu bạn bắt giữ dấu vết trên mạng để gửi cho người khác, thì người đó có thể có những ưu tiên về cách lọc (hoặc không lọc) thông tin trong khi bắt giữ luồng lưu thông mạng. Mỗi trình thám thính có giao diện người dùng của riêng mình và các phương thức để thiết lập điều kiện lọc. Đối với một số trình thám thính, có sự khác biệt về cách thực hiện việc lọc trong hai phương pháp tiếp cận đó. Hầu hết các trình thám thính làm cho việc lọc trở nên khá dễ dàng, mặc dù có một số thuật ngữ phải làm quen trước khi bạn biết chính xác công cụ đó là gì. Dưới đây là một số tiêu chí cần thiết cho việc lọc khung tin. Các con số này đơn giản là tinh chỉnh các dữ liệu được hiển thị trong hình 1.  Chỉ lấy TCP. Đối với truyền tải WSI, tất cả luồng lưu thông của P8 truyền qua các kết nối TCP. Do đó việc lọc tất cả luồng lưu thông UDP là cần thiết. Có một trường hợp mà việc giữ lại luồng lưu thông UDP có thể hữu ích. Nếu bạn đang xử lý sự cố DNS (bài viết này giả định không phải là như thế), thì bạn thấy hầu hết luồng lưu thông DNS truyền qua UDP. Mạng cục bộ của bạn cũng thường có những thứ lạc lõng, không phải là TCP hay UDP. Trong thực tế, trừ khi bạn đang ở trên một mạng rất cô lập, có thể bạn sẽ ngạc nhiên khi thấy khá nhều những thứ lạc lõng đó. Ta có thể giải trí và học được nhiều khi xem các gói đó và tìm hiểu xem chúng là gì, nhưng chúng không liên quan gì tới kịch bản này. Hình 2 cho thấy cùng kết quả dò vết trên mạng như trong hình 1 nhưng chỉ hiển thị các khung tin TCP. Hình 2. Dò theo mạng được lọc theo TCP  Chỉ lấy máy chủ đích. Ngay cả bằng cách hạn chế dò vết trên mạng, chỉ lấy các khung tin TCP, bạn vẫn thấy nhiều khung tin không liên quan. Thực vậy, trong hình 2, không có khung tin nào liên quan, và bạn vẫn chỉ thấy chưa đầy hai giây đầu tiên của luồng lưu thông trên màn hình đầu tiên. Cuộc hội thoại màn hình bạn muốn bắt giữ là cuộc hội thoại điểm đến điểm. Do bạn đang chạy trình thám thính trên máy khách, hãy lọc để hiển thị chỉ các khung tin từ máy chủ. Bạn phải cẩn thận khi thiết lập bộ lọc này là bao gồm các gói tin cả đến và đi từ máy chủ đích. Nếu không, bạn sẽ chỉ thấy một nửa cuộc hội thoại. Đối với kịch bản ví dụ này, máy chủ đích có địa chỉ IP là 9.39.109.62. Hình 3 cho thấy kết quả dò vết trên mạng được tiếp tục lọc theo địa chỉ IP đích. Tùy thuộc vào công cụ thám thính và các thiết lập của mình, bạn có thể có thể làm điều tương tự bằng cách sử dụng tên máy chủ thay vì địa chỉ IP. Hình 3. Theo dõi mạng được lọc theo máy chủ đích  Chỉ lấy cổng đích. Bạn có thể tiếp tục lọc kết quả dò vết trên mạng theo cổng đích cụ thể mà bạn đang sử dụng. Một lần nữa, bạn muốn lấy các gói tin đến hoặc đi từ cổng đích đó. Trong kịch bản ví dụ này, số cổng là 9080, đó là mặc định của WebSphere cho truyền tải WSI của P8. Hình 4 cho thấy kết quả dò vết trên mạng được tiếp tục lọc theo cổng đích. Hình 4. Dò vết trên mạng theo cổng đích Lưu ý thêm, bạn có thể tự hỏi tại sao cột Info dường như đang gọi cổng đích glrpc. Theo mặc định, Wireshark cố gắng dán nhãn mọi thứ để thuận tiện cho người sử dụng. Trong sổ đăng ký số hiệu cổng chính thức (xem Tài nguyên) mà Tổ chức cấp phát số hiệu Internet IANA (Internet Assigned Numbers Authority) duy trì, số cổng TCP 9080 được gọi là Groove GLRPC, vì vậy đó là lý do mà Wireshark dán nhãn nó như thế. Đó chỉ là một nhãn hiệu, và bạn không phải lo lắng về nó như bạn sẽ thấy trong phần tiếp theo. Tại cửa sổ ở giữa của hình 4, bạn có thể thấy rằng glrpc thực sự là cổng 9080.  Wireshark có thể thực hiện nhiều kiểu giải mã đặc thù riêng cho mỗi giao thức nếu nó biết đang xử lý giao thức nào. Bạn nhấn Analyze > Decode as để diễn giải luồng lưu thông của cổng 9080 thành HTTP. Xin xem hình 5.. Hình 5. Giải mã Wireshark Hình 6 cho thấy kết quả dò vết trên mạng khi áp dụng giải mã HTTP. Một số gói tin tiếp tục được đánh dấu là TCP mặc dù chúng liên quan đến cổng 9080. Đó là vì chúng không có bất kỳ đặc thù riêng thực sự nào về HTTP. Các gói tin này là các gói tin mạng báo đã nhận biết và kế toán giao thức TCP khác. Về mặt lý thuyết, bạn có thể đánh dấu nhầm một số gói tin với cổng nguồn 9080 thành HTTP, trong khi chỉ có cổng đích 9080 là liên quan. Trên thực tế, điều này là hiếm. Hình 6. Dò vết trên mạng được giải mã thành HTTP Bây giờ bạn có các dấu vết được lọc chỉ còn các gói tin đáng chú ý, bạn cần xem gói nào? Hình 6 làm nổi bật khung tin 295 và mở rộng hai cửa sổ phía dưới để hiển thị nhiều chi tiết hơn. Có lẽ bạn đã suy luận ra từ các thông tin hiển thị ở đây rằng bạn đang tìm kiếm một đáp ứng thành công từ trình lắng nghe dịch vụ Web trên máy chủ nội dung P8. Công cụ trình thám thính hiển thị mọi thứ ở mức gói tin, vì vậy bạn có thể thấy các giá trị của tất cả các trường tiêu đề của IP và TCP cũng như chính nội dung HTTP được chuyển tải. Điều này tiện dụng cho một số việc, nhưng cuộc thoại HTTP có thể lan ra gồm nhiều gói tin TCP. Dĩ nhiên là có ít nhất một gói tin cho yêu cầu và một gói cho đáp ứng, nhưng rất nhiều khả năng là một trong hai gói hoặc cả hai gói sẽ còn tràn vào các gói tin tiếp theo. Vì bạn quan tâm chủ yếu đến nội dung HTTP được chuyển tải, nên sẽ là tốt hơn nếu bạn chỉ thấy nó mà không kèm theo mọi gói tin kế toán khác. Cũng sẽ tốt hơn nếu bạn có thể sẵn sàng hiển thị trực quan yêu cầu cùng với đáp ứng của nó. Wireshark có tính năng làm được điều này. Nếu bạn nhấn phím phải chuột lên gói tin HTTP và chọn Follow TCP stream, thì Wireshark bật lên cửa sổ giống như cửa sổ trong hình 7. Hình 7. Cửa sổ Following TCP stream Vì hình 7 có thể khó đọc một chút, nên liệt kê 1 chứa chính các thông tin này với một số thay đổi nhỏ. Để làm cho nó vừa với chiều rộng của một trang, một số các dòng liên tục của XML và các dòng quá dài bị ngắt đoạn tại các điểm bất kỳ. Những chỗ xuống dòng nhúng trong đó được phiên dịch thành chuỗi hai ký tự ^M có thể nhìn thấy được. Liệt kê 1. Văn bản từ hình 7 POST /wsi/FNCEWS40MTOM/ HTTP/1.1^M User-Agent: IBM FileNet P8 CE Java API (X.Y.Z / dapNNN.MMM)^M Date: Sat, 24 Jan 2009 00:58:55 +0000^M Content-Type: application/soap+xml; charset=UTF-8^M Host: MyCEServer:9080^M Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2^M Connection: keep-alive^M Transfer-Encoding: chunked^M ^M 29a^M <e:Envelope xmlns:i="" xmlns="" xmlns:e="" xmlns:d=""> user1234pass9876 en-US -08:00 ^M 2^M ^M 0^M ^M HTTP/1.1 200 OK^M Server: Systinet Server for Java/6.5.4 (Java/1.5.0; Windows Server 2003/5.2 build 3790 Service Pack 2; build SSJ-6.5.4-20060829-1824)^M Content-Type: multipart/related; boundary=----------MULTIPART_BOUNDARY_11f0627864bcdb----------; type="application/xop+xml"; start-info="application/soap+xml"; start="<32bb849648573a7a-1c0d723b50a78063-2392a2760337fe0f- f87db666f64901d6>"^M Content-Language: en-US^M Transfer-Encoding: chunked^M Date: Sat, 24 Jan 2009 01:01:06 GMT^M ^M d14^M ^M ------------MULTIPART_BOUNDARY_11f0627864bcdb----------^M Content-Transfer-Encoding: binary^M Content-Type: application/xop+xml; type="application/soap+xml"; charset=UTF- 8^M X-WASP-Message-ID: 101-bcH4nI/ftBJRilNZkDiIkg==^M Content-ID: <32bb849648573a7a-1c0d723b50a78063-2392a2760337fe0f- f87db666f64901d6>^M ^M <e:Envelope xmlns:e="" xmlns:d="" xmlns:i="" xmlns:wn0=""> <GetObjectsResponse xmlns:n0="" xmlns=""> <Object i:type="ObjectValue" classId="Domain" objectId="{064735FF-3160-45D3-8258-ABA3AAE8F204}" updateSequenceNumber="5" accessAllowed="459267"><Property i:type="UnevaluatedCollection" propertyId="RenditionEngineConnections" collectionType="Enum"/> <Property i:type="UnevaluatedCollection" propertyId="ContentCacheAreas" collectionType="Enum"/><Property i:type="SingletonId" propertyId="Id">{064735FF-3160-45D3-8258-ABA3AAE8F204} <Property i:type="UnevaluatedCollection" propertyId="FixedContentDevices" collectionType="Enum"/><Property i:type="SingletonBinary" propertyId="PublicKey"> MIGfMA0GCSqGSIb3DQEB