esb_deploy - Progress Sonic ESB Deployment Guide 8.5 - Product ...
esb_deploy - Progress Sonic ESB Deployment Guide 8.5 - Product ...
esb_deploy - Progress Sonic ESB Deployment Guide 8.5 - Product ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Chapter 8: Distributed <strong>Deployment</strong> at Runtime<br />
Multiple <strong>ESB</strong> Containers in a Management Container<br />
A management container can support multiple <strong>ESB</strong> Containers. You might want to do this<br />
to have one classloader for the two <strong>ESB</strong> containers. This tactic is not typically<br />
recommended because the memory requirements for another management container’s<br />
JVM are minimal when compared to the <strong>ESB</strong> processes. An appropriate use-case for this<br />
construct is when you have a large <strong>ESB</strong> process that is running intra-container, as shown:<br />
Directory<br />
Service<br />
Management<br />
Node<br />
<strong>esb</strong>HostA1<br />
ctHostA<br />
<strong>esb</strong>HostA2<br />
<strong>esb</strong>HostA1 <strong>esb</strong>HostA2<br />
Management Container<br />
aHost-1<br />
ctHostA<br />
<strong>Sonic</strong>MQ<br />
In this illustration, HostA has one management container, hosting two <strong>ESB</strong> Containers.<br />
When intra-container steps are in separate <strong>ESB</strong> Containers, the process writes the<br />
message to the broker at strategic places in the process. Thus, a restart of the process can<br />
resume the process, and avoid having to start it from its beginning.<br />
152 <strong>Progress</strong> <strong>Sonic</strong> <strong>ESB</strong> <strong>Deployment</strong> <strong>Guide</strong> <strong>8.5</strong><br />
HostA<br />
<strong>ESB</strong> Container<br />
<strong>Sonic</strong> <strong>ESB</strong><br />
Enterprise Service Bus<br />
<strong>ESB</strong> Container<br />
<strong>Sonic</strong> <strong>ESB</strong>