A new business object framework runtime is provided in version WebSphere Version 7, which is built on a new high speed XML infrastructure that enables optimized XML processing and enhanced XML fidelity.
The following should be taken into account when choosing the parsing mode:
- A module can be configured to run in one parsing mode.
- Modules that were created in a version of IID prior to version 7 will run in the eager parsing mode without any changes required.
- By default, modules and libraries that are created in IID version 7 and later versions will be given the most suitable parsing mode depending on the parsing mode of
- existing projects in the workspace
- dependent projects in the workspace
- other projects in the same solution
- For better performance, avoid using mixed mode (eager, lazy) for application modules that frequently interact with each other.
- The interaction between modules with diff erent parsing modes takes place through serialization and deserialization, which can negatively affect performance.
- If using a mixed mode is unavoidable, starting an application from an eager parsing module to a lazy parsing module is more efficient than the other way around.
The WebSphere runtime uses the RMI/IIOP for the synchronous invocations.
Assuming we have the following scenario:
where the SCA messages are passed by value across different servers using RMI/IIOP. The SCA messages are transferred from one SCA at runtime to the SCA runtime on the second server by using the RMI/IIOP protocol.
In this case there is a slowdown in speed due to the serialization and deserialization of the data between the two servers. A slowdown is introduced also if the parsing modes of the two modules are different, as show below:
An attractive alternative solution for these kind of invocations (intermodule between two different clusters) could be the following:
where the SCA cross JVM invocation has been replaced by a Web Service binding invocation.
(Note that the module M1A acts as a static single access point for multiple consumers that want access to the services provided by the Cluster B modules.)
By bench marking the above solutions (40 parallel requests every 2 seconds) with the same sample XML (~3KB) we show that the average response time for the second scenario (Web Services) was 171 msec, whereas for the first scenario (SCA) the average response time was 260 msec.
The following should be taken into account when choosing the parsing mode:
- A module can be configured to run in one parsing mode.
- Modules that were created in a version of IID prior to version 7 will run in the eager parsing mode without any changes required.
- By default, modules and libraries that are created in IID version 7 and later versions will be given the most suitable parsing mode depending on the parsing mode of
- existing projects in the workspace
- dependent projects in the workspace
- other projects in the same solution
- For better performance, avoid using mixed mode (eager, lazy) for application modules that frequently interact with each other.
- The interaction between modules with diff erent parsing modes takes place through serialization and deserialization, which can negatively affect performance.
- If using a mixed mode is unavoidable, starting an application from an eager parsing module to a lazy parsing module is more efficient than the other way around.
The WebSphere runtime uses the RMI/IIOP for the synchronous invocations.
Assuming we have the following scenario:
SCA synchronous intermodule communication (two servers) |
where the SCA messages are passed by value across different servers using RMI/IIOP. The SCA messages are transferred from one SCA at runtime to the SCA runtime on the second server by using the RMI/IIOP protocol.
In this case there is a slowdown in speed due to the serialization and deserialization of the data between the two servers. A slowdown is introduced also if the parsing modes of the two modules are different, as show below:
An attractive alternative solution for these kind of invocations (intermodule between two different clusters) could be the following:
where the SCA cross JVM invocation has been replaced by a Web Service binding invocation.
(Note that the module M1A acts as a static single access point for multiple consumers that want access to the services provided by the Cluster B modules.)
By bench marking the above solutions (40 parallel requests every 2 seconds) with the same sample XML (~3KB) we show that the average response time for the second scenario (Web Services) was 171 msec, whereas for the first scenario (SCA) the average response time was 260 msec.
References
[1] IBM Information Center- “Consideration when choosing the business object parsing mode" Date of access: October 2014. http://www-01.ibm.com/support/knowledgecenter/#!/SSFPJS_7.5.1/com.ibm.wbpm.main.doc/bo/topics/rboparse.html
No comments:
Post a Comment