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

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

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

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

Transfer-Encoding: chunked^M
^M
29a^M
<?xml version="1.0" encoding="UTF-8"?><e:Envelope
xmlns:i="
xmlns="
xmlns:e="
xmlns:d="
<e:Header><Security><UsernameToken>
<Username>user1234</Username><Password>pass9876</Password>
</UsernameToken></Security><Localization><Locale>en-US</Locale>
<Timezone>-08:00</Timezone></Localization></e:Header>
<e:Body><GetObjectsRequest><ObjectRequest id="1" cacheAllowed="1">
<SourceSpecification i:type="ObjectReference" classId="Domain">
</SourceSpecification></ObjectRequest></GetObjectsRequest>
</e:Body></e:Envelope>^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

collectionType="Enum"/><Property i:type="SingletonBinary"
propertyId="PublicKey">
<Value>MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCshauwe2PIcNhCLGXhvL40DDFnNxcu1U
a
jWNe/KQ4+tQ5solDS+JGPcv1m9sOIaQpxGh2uq/luGvuZh9EiHdfJMlfVAxkjdc7ZHI/oCtaook4C
CYMx7Xx
ELBu4kJAkWEr324PXfHRgqlHmv7dXkO2NGvTfa+bDypnzPDEKfEDKjwIDAQAB</Value>
</Property><Property i:type="UnevaluatedCollection"
propertyId="PEConnectionPoints" collectionType="Enum"/>
<Property i:type="UnevaluatedCollection" propertyId="AddOns"
collectionType="Enum"/><Property i:type="UnevaluatedCollection"
propertyId="ObjectStores" collectionType="Enum"/><Property
i:type="SingletonString" propertyId="EncryptionAlgorithm">
<Value>RSA/NONE/PKCS1PADDING</Value></Property><Property
i:type="UnevaluatedCollection" propertyId="Sites"
collectionType="Enum"/><Property i:type="UnevaluatedCollection"
propertyId="SubsystemConfigurations" settable="1"
collectionType="List"/><Property i:type="SingletonString"
propertyId="Name" settable="1"><Value>WAS_SQL</Value>
</Property><Property i:type="UnevaluatedCollection"
propertyId="DirectoryConfigurations" settable="1" collectionType="List"/>
<Property i:type="SingletonObject" propertyId="DefaultSite"
settable="1"><Value i:type="ObjectReference" classId="Site"
objectId="{07539A4C-DD66-492B-8A0B-BC2363C9BDB9}"/></Property>
<Property i:type="SingletonObject" propertyId="VerityDomainConfiguration">
<Value i:type="Unevaluated"/></Property><Property
i:type="UnevaluatedCollection"
propertyId="IsolatedRegions" collectionType="Enum"/><Property
i:type="UnevaluatedCollection" propertyId="PermissionDescriptions"
collectionType="List"/><Property i:type="UnevaluatedCollection"

tìm kiếm (có hay không các thuộc tính cụ thể, số lượng đối tượng v.v ), thì có thể bạn sẽ thấy là
tương đối dễ dàng để chọn ra các thông tin ấy từ XML mà không cần hiểu đầy đủ tất cả các sắc
thái của tệp tin WSDL. Mặc dù vậy, bạn có thể thấy sẽ là hữu ích nếu hiển thị XML trong các
định dạng dễ đọc hơn. Nếu bạn ghi lưu nó vào một tệp tin có phần đuôi là xml, thì hầu hết các
trình duyệt web sẽ làm tốt công việc hiển thị nó trong một định dạng có cấu trúc, dễ đọc. Các
tương tác trong hình 7 và liệt kê 1 là một RPC kết quả từ cuộc gọi đến
Factory.Domain.fetchInstance không có tên miền và bộ lọc thuộc tính. Đáp ứng là một đối tượng
tên miền bao gồm một tập hợp các thuộc tính (hầu hết các thuộc tính đó là các tập hợp chưa tính
toán giá trị, chúng ta sẽ thảo luận về chúng trong bài viết tới về các bộ lọc thuộc tính).
Ưu điểm và nhược điểm của dò vết trên mạng
Ưu điểm
 Dò vết trên mạng cung cấp cho bạn một hình ảnh hoàn toàn trung thực về thông tin trên
mạng. Bạn không bao giờ phải lo lắng về việc thấy các thông tin gần đúng hoặc mất mát
một phần.
 Việc dò vết trên mạng không xâm chiếm mạng. Bạn có thể chọn chạy dò mạng bất cứ lúc
nào mà không cần giả mạo nhiều tới cấu hình ứng dụng của bạn (nhưng bạn nên xem
phần Nhược điểm).
 Tác động đến hiệu năng nói chung là không đáng kể. Mặc dù các trình thám thính phần
mềm chạy trên một trong số các máy tính có liên quan, chúng vẫn có xu hướng tiêu thụ
khá ít tài nguyên.
Nhược điểm
 Đối với trường hợp đặc biệt dò vết trên mạng các tương tác API Java và .NET của Máy
nội dung P8, bạn chỉ thực sự có cơ hội để thấy bất cứ điều gì có ý nghĩa nếu bạn sử dụng
truyền tải WSI (luôn luôn là như vậy đối với API của khung công tác .NET) và tránh
không dùng mật mã hóa TLS/SSL. Theo nghĩa này, bạn có thể sử dụng hoặc không sử
dụng cấu hình thực tế cho ứng dụng của bạn. Tuy nhiên, nhằm mục đích xem các khía
cạnh về hiệu năng mà bạn có thể tác động đến bằng các kỹ thuật mã hóa của mình, thì
những điều đó không quan trọng.
 Tương tự như vậy, do việc mật mã hóa và các yếu tố khác, bạn có thể không có khả năng
có được các kết quả dò vết trên mạng có ý nghĩa với luồng lưu thông trên mạng riêng ảo

log4j.properties. Liệt kê 2 là nội dung của tệp tin đó, được gửi kèm theo với FileNet Content
Manager phiên bản 4.5 (với một vài thay đổi không quan trọng để làm cho nó phù hợp với định
dạng của bài viết này).

Liệt kê 2. Tệp mẫu log4j.properties.client

#############################################################################
###
# Root logger
#############################################################################
###
log4j.rootLogger=off, FileNetNullAppender
#############################################################################
###
# Appenders
#############################################################################
###
#=== FileNetNullAppender
log4j.appender.FileNetNullAppender=org.apache.log4j.varia.NullAppender

#=== FileNetConsoleAppender
log4j.appender.FileNetConsoleAppender=org.apache.log4j.ConsoleAppender
log4j.appender.FileNetConsoleAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.FileNetConsoleAppender.layout.ConversionPattern=%d %5p [%t] -
%m\r\n

#=== FileNetErrorAppender
log4j.appender.FileNetErrorAppender=org.apache.log4j.FileAppender
log4j.appender.FileNetErrorAppender.File=/p8_api_error.log
log4j.appender.FileNetErrorAppender.layout=org.apache.log4j.PatternLayout

log4j.appender.FileNetTraceRollingAppender.File=/p8_api_trace.log
log4j.appender.FileNetTraceRollingAppender.MaxFileSize=100MB
log4j.appender.FileNetTraceRollingAppender.MaxBackupIndex=1
# This is the layout that the TraceLoggingConfiguration framework on the
server uses.
# To use this layout , jace.jar must be present in the classpath.
#log4j.appender.FileNetTraceRollingAppender.layout=com.filenet.apiimpl.util.T
raceLayout
# Comment out the following lines if using the FileNet TraceLayout
log4j.appender.FileNetTraceRollingAppender.layout=org.apache.log4j.PatternLay
out
log4j.appender.FileNetTraceRollingAppender.layout.ConversionPattern=%d %5p
[%t] - %m\r\n
#############################################################################
###
# Error Loggers:
#
# Set log level to either one of off/fatal/error/warn/info.
# Child logger's value overwrites parent logger's value.
# If a logger is not specified, it inherits its value from its parent.
# By default, error logging is set to level ERROR.
#############################################################################
###
# Don't comment out the following line since it has appenders.
log4j.logger.filenet_error = error, FileNetConsoleAppender, \
FileNetErrorRollingAppender, FileNetTraceRollingAppender

#=== SubSystem: api
# Uncomment to set error logging level to WARN.
#log4j.logger.filenet_error.api = warn

#
# For example:
# log4j.logger.filenet_tracing.api.detail.moderate = debug
#############################################################################
###
# Don't comment out the following line since it includes an appender.
log4j.logger.filenet_tracing = off, FileNetTraceRollingAppender

#=== SubSystem: api
# Uncomment one or more lines to enable tracing.
#log4j.logger.filenet_tracing.api = debug
#log4j.logger.filenet_tracing.api.timer = debug
# Remove the comment corresponding to the desired detail level
#log4j.logger.filenet_tracing.api.detail.moderate.summary = debug
#log4j.logger.filenet_tracing.api.detail.moderate = debug
#log4j.logger.filenet_tracing.api.detail = debug

Có lẽ bạn đoán được từ kích thước và số lượng các chi tiết rằng tệp tin cấu hình mẫu rất linh
hoạt, cho phép nhiều kịch bản ghi nhật ký. Nếu bạn muốn biết thêm về log4j, thì có thể thấy sẽ
biết được rất nhiều qua nghiên cứu các khía cạnh của cấu hình này trong các tài liệu của log4j.
Bài viết này chỉ liên quan đến một vài dạng, tất cả chúng đều được điều khiển bởi một số dòng
đã đánh dấu chú giải ở gần cuối của tệp tin và được lặp lại trong liệt kê 3. Việc ghi nhật ký dò
vết API bao gồm ba mức độ chi tiết: tóm tắt, trung bình và chi tiết, mỗi mức độ được kích hoạt
bằng cách bỏ dấu chú giải tại đầu dòng thích hợp trong tệp tin cấu hình. Bài viết này nêu các ví
dụ ở mức tóm tắt và mức trung bình cho hai hoạt động: tìm nạp tên miền mà bạn đã thấy trong
các ví dụ dò vết trên mạng (getObjectsRequest), và một cố gắng bất thành để tạo ra một thư mục
trong kho đối tượng không tồn tại (executeChangesRequest). Bài viết này không nêu ví dụ ở mức
dò vết chi tiết, bởi vì những điều bổ sung được ghi lại không thú vị lắm cho bài thảo luận này.
Điều quan trọng là nhận thấy rằng kết quả của việc ghi nhật ký dò vết nhằm mục đích chủ yếu là
giúp đỡ chẩn đoán để khắc phục nhiều loại vấn đề. Các thông điệp cụ thể và các thông tin được

Thường thì log4j tìm thấy tệp tin cấu hình của nó bằng cách tìm kiếm biến môi trường classpath
của Java. Ngoài ra còn có một thuộc tính Java có thể được thiết lập để trỏ đến một tệp tin cấu
hình cụ thể. Cả hai cơ chế này dễ dàng sử dụng nếu bạn đang ghi nhật ký dò vết API trong một
ứng dụng Java độc lập. Nếu bạn đang chạy bên trong máy chủ ứng dụng J2EE, thì bạn có thể gặp
khó khăn khi làm cho log4j tìm thấy tệp tin cấu hình của bạn (do có nhiều biến trong các cơ chế
classpath của các máy chủ ứng dụng). Nếu điều đó xảy ra, bạn hãy tạo ra một tệp tin JAR không
có gì khác ngoài thuộc tính log4j.properties ở mức cao nhất của tệp tin JAR (không phải ở trong
thư mục con). Bạn có thể đặt tên cho nó, ví dụ, là wjc.jar, nhưng tên gọi không quan trọng, miễn
là nó không trùng với một số tên JAR khác. Bạn đặt tệp tin wjc.jar cùng với các tệp tin JAR mà
ứng dụng của bạn sử dụng, thường ở tại địa chỉ WEB-INF/lib/. Nếu máy chủ ứng dụng tìm thấy
các tệp tin JAR khác, thì nó sẽ tìm thấy tệp wjc.jar. Bạn cũng có thể sử dụng cùng kỹ thuật này
với trình khách giàu (thick client), nhưng khi để thuộc tính log4j.properties ở bên trong tệp
wjc.jar thì việc hiệu chỉnh sẽ trở nên khó khăn hơn.
Ví dụ về kết quả ghi nhật ký
Tệp tin cấu hình mẫu quy định khuôn dạng cho kết quả ghi nhật ký, bao gồm dấu ấn thời gian
ngày/giờ, mức độ ghi nhật ký (luôn luôn là DEBUG trong kịch bản ví dụ này) và tên các chuỗi.
Để đơn giản, các cột này không hiển thị trong các liệt kê kết quả ghi nhật ký. Ở chỗ mà các dòng
dài bị ngắt xuống dòng một cách nhân tạo vì lý do biên tập, bạn sẽ thấy một dấu gạch chéo
ngược ở cuối dòng trên và một khoảng trắng ở đầu dòng dưới. Trường hợp dòng được bỏ qua
cho ngắn gọn, bạn sẽ thấy khoảng hẫng là dấu ba chấm.
 Tóm tắt:

Liệt kê 4. Dò vết API mức tóm tắt

Configuratio
n for:Config.AutoRefreshEnabled value:null
applied
. . .
getObjects request batch-size=1
ObjectReferences \

<value type="UnevaluatedPropertyValue"
propertyName="Permissions">
<parent ref="3"/>
</value>
</property>
<property name="FixedContentDevices">
<value type="UnevaluatedPropertyValue"
propertyName="FixedContentDevices">
<parent ref="3"/>
</value>
</property>
<property name="Id">
<value>{064735FF-3160-45D3-8258-ABA3AAE8F204}</value>
</property>
. . .
<property name="ObjectStores">
<value type="UnevaluatedPropertyValue"
propertyName="ObjectStores">
<parent ref="3"/>
</value>
</property>
</properties>
</value>
</getObjectsResponse>
<executeChangesRequest refresh="false" correlationId="0"
updateSequenceNumber="null">
<pendingAction type="Create" classId="Folder" \
objectId="{3C19B4FE-B835-44F8-AB94-AB4F40997FB1}"/>
<objectReference type="GlobalIdentity" classIdentity="ObjectStore"
\

và đáp ứng. XML trong các yêu cầu và đáp ứng khá gần với XML đã thấy trong ví dụ dò vết trên
mạng, nhưng nó không theo WSDL một cách chính xác. Một số xấp xỉ và giản lược được sử
dụng. Bởi vì việc ghi nhật ký dò vết API hiển thị XML trong một định dạng rất dễ đọc, nên bạn
có thể dễ dàng hiểu được ý nghĩa của hầu hết các dữ liệu đang được truyền đi. Đối với việc điều
chỉnh hiệu năng, trước tiên bạn quan tâm chủ yếu đến việc giảm số lượng RPC và sau đó đến
việc truyền ít nhất có thể các thuộc tính mà vẫn có thể thực hiện các nhiệm vụ cần thiết trong ứng
dụng của mình. Bạn sẽ thấy rằng rất đơn giản để tìm thấy cả hai điều đó trong liệt kê 4 và 5.
Ưu điểm và nhược điểm của việc ghi nhật ký dò vết API
Ưu điểm
 Ghi nhật ký dò vết API có thể được sử dụng với cả truyền tải WSI và EJB.
 Ghi nhật ký dò vết API không bị ảnh hưởng bởi việc sử dụng TLS/SSL hoặc VPN.
 Kết quả ghi nhật ký dò vết API nhỏ gọn hơn so với các tệp tin dò vết trên mạng. Ngoài
ra, XML được định dạng để cho con người dễ sử dụng hơn.
Nhược điểm
 Ghi nhật ký dò vết API gây ra các hao tổn về hiệu năng. Đối với dò vết API mức tóm tắt,
thì sự suy giảm về hiệu năng là tối thiểu. Đối với dò vết mức trung bình và mức chi tiết,
thì sự hao tổn về hiệu năng có thể đáng kể. Các số đo thời gian RPC có phần hơi phóng
đại quá mức đối với mức trung bình và mức chi tiết.
 Có một rắc rối nhỏ về cấu hình đối với ghi nhật ký dò vết API. Đối với một số hình thái
ứng dụng đặc biệt phức tạp, để có tệp tin cấu hình được nhận biết bên trong máy chủ ứng
dụng J2EE là rất phiền toái.
 Kết quả của ghi nhật ký dò vết API chỉ là gần đúng với những gì thực sự được gửi qua
mạng. Giá trị gần đúng này là đủ tốt cho nhiều mục đích.
 Có rất ít thông tin bao gói hoặc tiêu đề trong kết quả đầu ra của ghi nhật ký dò vết trên
API. Đó có thể là một thách thức nếu khoan sâu vào các thông tin, điều đó có nghĩa là nó
không nhất thiết là công cụ tốt nhất để xử lý mọi sự cố.
 Bởi vì về bản chất nó là một công cụ chẩn đoán, và bởi vì kết quả đầu ra là thường tương
quan với mã nguồn hoặc các tạo phẩm khác thường không có sẵn bên ngoài môi trường
hỗ trợ và phát triển, một số kết quả đầu ra của ghi nhật ký dò vết API thực sự có thể làm
tăng sự nhầm lẫn. Ví dụ, khi API cố gắng khám phá những thứ về môi trường của nó, thì