Assumption of WIS

Generally, a WIS consists of two parts: The below figure shows this structure in details. There, the client application can be further divided into two parts: a user interface part (UI) and a data access part (DA). The UI part receives input from a user while the DA part sends the input data to the backend server and receives a result page from there.


To realize navigational integration of WISs, a client application of any WIS must be wrapped and be manipulated from outside. To do so, a client application must satisfy the following constraints:
  1. The UI part and the DA part must be separately implemented.
  2. The data in the UI part must be able to be accessed and updated by a certain wrapping technique.
  3. Similarly, the DA part must be able to be invoked from outside by a wrapping technique.



Under these constraints, the WIS shown in the first figure is wrapped as shown second figure. There, the UI part and the DA part of the client application are wrapped by appropriate wrapper programs. Further, we prepare a proxy executor (PE) as a system-side server; it coordinates the behaviors of wrappers when executing a client application for the navigational integration. This figure shows also how the PE coordinates wrappers for running a wrapped client-application. That is,
  1. firstly, a user tries to access the UI part of a WIS; this access is sent to PE at first, and then is redirected to the wrapper of the UI part.
  2. By the second constraint, this wrapper can rewrite data of the UI part appropriately. A page of this UI is then displayed to the user.
  3. User gives an input or clicks a link in the page. This action is redirected to the UI through its wrapper. Then the UI passes back a service request to the DA part through PE.
  4. By the third constraint, the wrapper of the DA part can convert this request to a native form, and passes it to the DA part. The DA will then generate a result page. In this way, a wrapped WIS works in the same way as a native WIS does. The exception is that result-pages of wrapped WISs can be rewritten accordingly before being passed to users.
Experience in Wrapping

We have had tests in wrapping various client applications, i.e., ordinary Web documents, CGI-forms and java applets. Developing wrappers for Web documents or CGI-forms can be done easily by letting wrappers rewrite contents of HTML files. However, developing wrappers for Java applets is nontrivial. To satisfy the required three constraints, an original java applet must: (i) implement methods of its UI part and DA part separately, (ii) provides public methods to access and update data of the UI part, and (iii) provides public methods that can be invoked to receive a request to the DA part.

In implementation, if a developer owns all necessary Java class files of a given Java applet, a wrapper for it can be developed by using the inheritance technique from the original classes. If not, the wrapper can be developed by writing new java classes for both UI part and DA part, which (i) dynamically download original class files from remote sites, (ii) get the exported interfaces of the class files via the java reflection API, and (iii) create an instance of the original class and invoke its methods. The detail of implementation can be seen in [JavaBeans,JavaSecrets].
  • [JavaBeans] D. Brookshier. JavaBeans Developer's Reference. New Riders Publishing, Indianapolis Indiana, 1997.
  • [JavaSecrets] E. R. Harold. Java Secrets. IDG Books Worldwide, Inc, 1997.