We had completed two model solutions but had obtained decidedly mixed results. On the one hand, the Direct HTTP Ensemble proved feasible (we had by this time verified that Explorer did, indeed, support the show document method). This was good news but for the fact that this ensemble, shown in Figure 13-4, is too complex for the simple function it performs. There also remained questions about how to manage error propagation considering the fact that distinct control and data channels are used. Another detail concerned finalization of the retrieval scenario. Specifically, data on the second Web server should be deleted immediately upon retrieval; this involves one more interaction, and still more complexity.
On the other hand the Direct IIOP solution was simple and elegant. Unfortunately, our model solution relied upon proprietary Netscape interfaces. Since the model solution did not work with both Navigator and Internet Explorer, this ensemble was, for the moment anyway, infeasible. It had failed to satisfy the evaluation criteria established for the model problem. However, we already had in mind several repair strategies and were not ready to concede defeat. We had heard rumors of a product from JavaSoft called Java Protection Domains that promised a portable alternative to Netscape's Capability Classes, and we were willing to wait on this market event while continuing to explore the ramifications of this ensemble. (Persistence is an important quality when building component-based systems. Optimism also helps.)
Figure 13-10 DeepWeb contingency.
Figure 13-10 depicts the situation in terms of contingency management. Work was proceeding on the main design option, while more work remained to prove that the applet ensemble was a viable alternative. The direct HTTP ensemble was feasible but ungainly. We were suspicious that anything that ugly could be correct. Therefore, we considered its feasibility to be unproven. The direct IIOP ensemble was the favorite, but it was infeasible without repair. Java Protection Domains, we thought, would repair the Navigator dependency, and accordingly we decided to "wait" on its release from Sun Microsystems. This did not mean, however, that further repair options were foreclosed.
Figure 13-11 shows what we discovered in a fragment of the manifests associated with the direct IIOP and direct HTTP ensembles. Roll up diagrams like this are exceedingly useful as the number of components increases and as the number of potential ensembles explodes.
Figure 13-11 Manifest after model solutions.