08.06.2014 Views

Download PDF (1.3 MB) - IBM Redbooks

Download PDF (1.3 MB) - IBM Redbooks

Download PDF (1.3 MB) - IBM Redbooks

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Using browser tools<br />

The following observations pertain to browser tools that are available for obtaining response<br />

time measurements, counting requests, and analyzing caching.:<br />

►<br />

►<br />

►<br />

The Net tab in Firebug is useful for obtaining request timings, analyzing request/response<br />

headers, and counting the number of requests. However, it reports requests that are<br />

satisfied from the browser cache as code 200 responses. You can still determine that the<br />

request is cached from the Cache tab shown on the request, which indicates that the<br />

request was satisfied from the browser cache. If you copy and paste the results into<br />

another document (for example, into an email), the Cache tab is not copied. Thus, it is<br />

possible to be misled by the 200 responses and draw an incorrect conclusion that caching<br />

is not effective when it actually is.<br />

Fiddler is another powerful tool and has the advantage of supporting both IE and Firefox<br />

browsers. However, because Fiddler acts as a proxy between the browser and the server<br />

and cached requests are handled internally by browsers, these requests are never shown<br />

in Fiddler. This absence of result reporting prevents you from determining which requests<br />

are fulfilled from the browser cache, but Fiddler is still useful for analyzing the requests<br />

that actually are sent to the server.<br />

HttpWatch does not have the limitations of Fiddler because it is supported on both IE and<br />

Firefox browsers. Its results copy and paste easily into either a spreadsheet or a<br />

document, and it displays cached requests in a straightforward manner.<br />

3.4 WebSphere InterChange Server migration considerations<br />

The following considerations pertain to those migrating from WebSphere InterChange Server<br />

(WICS) to Business Process Manager V8.0:<br />

►<br />

►<br />

►<br />

►<br />

Migrated workloads using custom <strong>IBM</strong> WebSphere Business Integration (WBI) adapters or<br />

older WebSphere Business Integration adapters result in interaction with Business<br />

Process Manager V8.0 through JMS, which is slower than the JCA adapters. Use<br />

WebSphere adapters to replace WebSphere Business Integration adapters when<br />

possible.<br />

Some technology adapters (such as HTTP and web services) are migrated by the<br />

WebSphere InterChange Server migration wizard into native Business Process Manager<br />

V8.0 SCA binding, which performs better. For adapters that are not migrated automatically<br />

to available SCA bindings, development effort spent on migrating manually to an SCA<br />

binding removes the dependency on an older adapter and provides better performance.<br />

The WebSphere InterChange Server Migration wizard in Integration Designer offers a<br />

feature to merge the connector and collaboration module. Enable this option, if possible,<br />

because it increases performance by reducing cross-module SCA calls.<br />

WebSphere InterChange Server collaborations are migrated into Business Process<br />

Manager V8.0 BPEL processes. You can further customize the resultant BPEL processes<br />

so they become more efficient.<br />

– Migrated BPEL processes enable support for compensation by default. If the migrated<br />

workload does not use compensation, you can disable this support to gain<br />

performance. Find the relevant flag in Integration Designer by selecting the process<br />

name and then clicking Properties Details Require a compensation sphere<br />

context to be passed in.<br />

Chapter 3. Development best practices 45

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!