| |  | |||||||||
CERC Technical Report Series
Research Note
CERC-TR-RN-95-005
INTEGRATING THE WWW AND CORBA-BASED ENVIRONMENTS
G. Almasi
V. Jagannathan
September 1995
ACKNOWLEDGEMENT: This effort was sponsored by the Advanced Research Projects Agency (ARPA) under Grant No. MDA972-91-J-1022 for the DARPA Initiative in Concurrent Engineering (DICE) and by the National Library of Medicine under Grant No. N01-LM-3-3525 for Collaboration Technology for Real-time Treatment of Patients.
Concurrent Engineering Research Center
West Virginia University
P. O. Box 6506, Morgantown WV 26506
2
Integrating the WWW and CORBA-based Environments
G. Almasi and V. Jagannathan*
Concurrent Engineering Research Center
West Virginia University, P.O.Box 6506, Morgantown, WV 26506-6506
* Also with the Department of Statistics and Computer Science, West Virginia University
Abstract
The current proliferation of the World-Wide Web (WWW) has fueled a need for web browsers to provide access to the variety of information sources and services now available on the Internet. In parallel to this revolution, computer vendors have been cooperating to develop an interoperable standard for communication which is based on the Common Object Request Broker Architecture (CORBA). In this paper, we present the tools we have developed at the Concurrent Engineering Research Center (CERC) at West Virginia University that provide powerful mechanisms for accessing any service based upon the interoperable CORBA standards from the popular WWW browsers. These tools are available in the public domain and have been downloaded and used around the world for building practical, fieldable systems.
1: The World-Wide Web
The World-Wide Web is accessible through commercial on-line services and through popular Web browsers, such as Mosaic (available in the public domain) and Netscape. The Web browsers provide a point-and-click metaphor for accessing a hyperlinked collection of documents written using the Hypertext Markup Language (HTML). HTML is one of the family of languages that conform to the Standard Generalized Markup Language (SGML) ? an international standard for specifying neutral-format documents. HTML documents are served by servers that adhere to the Hypertext Transfer Protocol (HTTP), which was designed to efficiently support multiple independent requests for documents. These servers do not maintain any state information; each request for a document is an independent transaction. To support the dynamic creation of HTML documents, the HTTP servers support a Common Gateway Interface (CGI). Typically, the HTTP servers invoke CGI programs ? frequently called CGI scripts ? when requested to serve specific documents. CGI scripts can be written to provide access to, and present information coming from, a variety of sources.
2: CORBA standards
The CORBA standard was developed out of the need for interoperable solutions that work across multiple hardware and software platforms. This standard is promoted by the Object Management Group (OMG), whose membership includes over 500 hardware and software vendors. The CORBA architecture, and particularly the Version 2.0 standard, promotes interoperability to a hitherto unprecedented level: it promotes independence in hardware architecture, language, and location. For instance, by complying to CORBA, software services can be written in any language (C, C++, Scheme, or even Fortran), run on any machine (Sparc, Silicon Graphics, PC), use any
3
operating system (Windows NT, Unix), and be accessed by client software, which could be in turn be written in any language. Of course, the success of this standard ? and it already has achieved a fair measure of success ? depends upon the availability of support for developing Object Request Broker (ORB) services in the respective languages and operating environments. This support is currently commercially available for all of the major hardware platforms.
The CORBA standard defines services that are based on object-orientation principles and requires the definition of services using the Interface Definition Language (IDL). The following sections describe tools CERC has developed that allow the WWW server developer to provide access to services that are defined using CORBA.
3: Scripting Languages
Scripting languages have long been used for routine chores that do not need the full power of a programming language such as C or C++. Some examples of scripting languages include shell scripts in Unix, the Practical Extraction and Report Language (Perl), and the Tool Command Language (Tcl). One characteristic that most scripting languages have in common is that they are usually interpreted. Because of this fact, interpreted programming languages such as Basic, Common Lisp, or Scheme can also be used as scripting languages. Deciding which language to use for a given application is largely a matter of determining what functionality is needed to solve the problem and who is writing the application. For our initial development of tools to support WWW access to information, we chose the Tcl scripting language. Tcl is simple to learn, supports declaration and use of variables, has reasonable control structures (for looping and checking), is interpreted, and is available in the public domain. Our next generation of tools use Scheme, which has more powerful programming support and is also available in the public domain.
4: Web*
Developed by CERC, Web* ? pronounced WebStar ? provides a user-friendly environment for information providers on the WWW, enabling information to be published in a flexible and consistent fashion.
Web* can be added as a CGI script to an already-installed WWW server. The "*" in the name of "Web*" stands for ?anything? (similar to a wildcard). The implied meaning is that Web* enables any information-providing engine to be interfaced with the WWW.
4.1: Why Web*?
Regular HTML pages contain lots of formatting information, but the contents are static; with CGI scripts, however, contents are dynamic, but formatting information is harder to generate.
Imagine a scenario in which you write regular HTML pages, but wherever you need data from other applications you can insert a Tcl script; Tcl variables declared and used in one page will be preserved and transmitted to the next page; moreover, when you write forms, you can access the client's input in the next page as Tcl variables!
This is precisely what you get with Web*.
Web* is a generic CGI script that accesses a set of ?layout pages,? one at a time. Each of the layout pages is essentially an HTML document, except that Tcl scripts can be embedded anywhere
4
within it. Tcl scripts are recognized within the HTML code because they are escaped (the escape character is the TCL scope delimiter, ?[?). Web* operates as follows: everything that is HTML is written to the output with no change (and thus will be sent by the HTTP server to the Mosaic client); all Tcl scripts are interpreted, and the results are sent to the client using the same system.
Web* was developed to support Cerc?s Advanced Research Testbed for Medical Informatics (ARTEMIS). The ARTEMIS project demanded that we call services implemented in the CORBA standard. Using Orbix TM software (an implementation of the CORBA standard), we developed an interface from the Web* scripting language to Orbix.
4.2: Web* Features
? ability to be inserted seamlessly into an existing WWW server
? writing of scripts that are available for immediate execution and that have the same degree of flexibility as with HTML alone but with more expressive power
? TCL scripting language for providing dynamic information support of HTML forms via TCL, and conversion of form information into a set of TCL variables that can be processed in a script
? support for tables ? not a feature of HTML, although new versions of Web browsers such as Netscape provide it
? TclDii support of interactions based on the CORBA standard, using the Orbix TM software
? session support in which the client state is maintained and remembered in each WWW interaction, giving the impression that the client is in a session with the information provider
5: Web* Architecture
The Web* architecture is shown in Figure 1 below. In the following sections we present the specific problems Web* solves to make it possible to link any information source to the Web.
5.1Generating HTML on the fly
TclDii TCL
HTTP
Server
regular (HTML) files
CGI scripts
CGI
Web*
layout pages
(Web* scripts)
DII
Orbix
Services
ORB
Figure 1: Web* architecture
5
As far as the HTTP server is concerned, Web* is just another script. However, Web*?s engine processes templates called ?layout pages.?
HTML as a text-formatting language is still evolving. The early versions of HTML were engineered to support simple, easy-to-use features which combined text, images, and other multi-media entities. HTML has not evolved to a point at which its functionality rivals the power of commercial word processing packages. The most common initial complaint about HTML is the lack of support for tables, e.g., multiple columns and many other things that regular text editors provide. Current Web browsers now provide this by extending HTML. Web* has some Tcl extensions that allow the generation of tables.
The other problem with HTML is that it does not contain any procedural knowledge. It is a ?hard coded? language; i.e., once a page is written, no parameters can be changed inside. Regular text editors use variables, such as current page numbers, current dates, and paragraph count. These features are not present in HTML, and this complicates the work of information providers. This problem can be overcome by using Web*, since it uses Tcl variables.
5.2 Managing the transmission of state across multiple access points
The HTTP protocol also provided us with a challenge. HTTP can be traced back to the Gopher and Z39.50 protocols, which are both stateless. Consequently, HTTP is also stateless, thereby guar-
<H1> This is the title </H1>
<H3>This is today?s date: [exec date]. <P>
2 + 3 make [expr 2+3]
Figure 2: Sample layout page written using HTML with Tcl expressions
Figure 3: Layout page using Tcl expressions displayed using Mosaic
6
anteeing the simplicity of concept and implementation that surely contributed to its wide distribution.
Unfortunately, what is good conceptually may not be practical for the user. With HTTP, transactions cannot consist of multiple client interactions; each HTTP request takes place with no relation to other requests.
Our biggest challenge with Web* was to superimpose a ?stateful? scripting environment on the stateless HTTP protocol. We used a trick that we call ?state freezing? to achieve this (Figure 3)..
Web* uses the second approach. The state information is captured as a collection of Tcl variables, which are transmitted to the clients as embedded hyperlinks.
Example: Suppose you have two pages, and in the second page you want to display the time at which the previous page was interpreted:
In the first layout page, you would write:
[set myvar [exec date]]
<A HREF=?[URL thedate $myvar pageid nextpage.html]?>
click here </A>
The next layout page, called "nextpage.html,"would then look like this:
[puts $thedate]
The first page, when interpreted, sets the variable myvar to the current date (using the ?exec? command in Tcl that executes UNIX commands). Then the value of myvar is
Approach 1:The server maintains state memory and restores
Client Server
state
memory
Client ServerState
Approach 2: The freeze-dried state is transmitted to the client for holding
and is included in the next service request
it when client reconnects.
Figure 4: Two approaches to handling the stateless nature of the HTTP protocol
7
transmitted through the hyperlink under the name thedate.
When the second page is interpreted, the value of thedate will be displayed.
6: The Scripting Language Challenge and TclDii
In the previous section we discussed how to dynamically create HTML-formatted information using Tcl. At CERC, we are in the process of deploying an Advanced Research Testbed on Medical Informatics (ARTEMIS), and we needed to access information from a variety of services and from databases, such as OracleTM.
To address this need, we decided to take the most general approach and build tools that will enable us to call any services presented in an object-oriented fashion. Figure 4 highlights the specific tool we built to facilitate this, which can be used in conjunction with Web* to access CORBA- based services. The tool, TclDii, provides Tcl support for the Dynamic Invocation Interface, which
is supported by CORBA-based services. The Object Request Broker (ORB) services are represented by their Interface Definition Language (IDL). Clients to such services map languages, such as C++, to the neutral representation of IDL. TclDii extends the functionality of Tcl by enabling Tcl scripts to send requests to CORBA services. TclDii is built on top of the Orbix? client library, which in turn implements a C++ mapping of CORBA?s IDL. TclDii is intended as a generic application, but is also shipped as part of the Web* (Version 1.1) package. TclDii can also be linked in with tk/Tcl, allowing users to write, with little effort, graphical user interfaces that are also Orbix? clients.
But before we show an example, we must explain how type conversions are handled. Tcl understands exactly one type code: strings. ORB services and most programs deal with more types than that! A Tcl value does not automatically correspond to any IDL type; if one wants to specify the type of a value, one needs to associate a type description with that value. The type description we adopted in TclDii is a typecode string ? a string representation of CORBA typecodes. A CORBA typecode, as described in the ORB architecture description, describes types of invocation
ORB Core
Orbix?
Dynamic
Invocation
Interface
IDL
Stubs
ORB
Interface
...
TCL
Library
TclDii
TclDii scripts
Figure 5: TclDII: a Tcl interface to CORBA?s Dynamic Invocation Interface
8
arguments and results. CORBA typecodes have a lot of expressive power, almost like IDL itself. CORBA typecodes in Orbix? are sometimes represented by strings. We use these string representations in TclDii to associate types with Tcl objects and call them typecode strings. The TCL command that implements the ORB service call is as follows:
orb_call[nw]<target>;<method>;<resulttype>{<paramtype>; <parameter> } *
orb_call is the name of the command. In fact, if invoked without arguments, it will print out the line above to help users. Its variant, orb_callnw, performs essentially the same operation of sending a request to a CORBA service, but it will not wait for an answer or confirmation by the target object. The following table shows how each one of the CORBA-type codes is represented in TCL as strings.
In the following example, a service called grid has two methods, set and get. This service is invocable from a TclDii-based client to that service.
TclDii: A Simple Example
set hostname stonecoal.cerc.wvu.edu
# ------------ bind to server object ---------------------
set gridobj ?:\$hostname:grid:::IR:grid?
if (![orb_ping $gridobj]) {
puts ?Bind to object failed?
exit 1
}
# ------------- get height and weight of grid ----------
set height [orb_call $gridobj _get_height s]
set width [orb_call $gridobj _get_width s]
# ------------ set/get value in cell 2,4 ---------------
orb_call $gridobj set v s 2 s 4 s 123 ; set
set v [orb_call $gridobj get s s 2 s 4] ; get
7: Conclusion
In effect, Web* makes it easier for the information provider to organize and publish information. It uses a better, more powerful paradigm ? session-oriented transaction ? extending the range of information that can be published. Further, by virtue of the fact that they can embed calls
Table 1: Type code representation
short ?s?
long ?l?
string ?0?
sequence of 25 strings ?S{0},25?
structure containing a string and a long ?R~struct~a{0},b{l}?
9
to any CORBA-based services, users can literally provide access to any services needed to exploit the Internet as well as object-oriented and object-based services.
In Web*, flexibility is innate. Added to the flexibility of HTML is the powerful, yet easy-touse, scripting language Tcl. Web* clients currently can use most popular Web browsers; however, deviations from the standard implementation of the HTTP protocol may render some WWW clients unable to communicate with Web*.
More information about Web* is available at the Web* Homepage at the URL
http://webstar.cerc.wvu.edu
Web* is used in the ARTEMIS project (sponsored by the National Library of Medicine) to implement a medical patient record that can be browsed using Mosaic. Work on Web* is progressing; Version 1.1 was released in July, as was TclDii Version 1.0. A new software module, ScmDii, which supports Scheme-to-IDL mapping, will be released in the fall of 1995.
8: Glossary of Terms & Standards
ARTEMIS Advanced Research Testbed for Medical Informatics
CGI Common Gateway Interface, a low-level information provider's interface and part of the WWW system
CORBA Common Object Request Broker Architecture, a standard developed and maintained by the Object Management Group to facilitate interoperability between heterogeneous architectures and programming languages
Gopher an information retrieval protocol (as well as the name of the client program based on the protocol) developed at the University of Minnesota that had a solid popularity base before the WWW protocol emerged. It is supported in WWW
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol, the main information-providing protocol of the WWW system.
Orbix TM an implementation of the CORBA protocol by Iona Technologies, Inc.
Tcl Tool Command Language, a powerful scripting language developed by John Ousterhout at the University of California at Berkeley
WWW the World-Wide Web, developed at CERN (Conseil European pour la Recherche Nucleaire, the European Laboratory for Particle Physics, in Geneva, Switzerland); a widely popular information retrieval system that gained notoriety with the spread of the Mosaic browser
Z39.50 an information query and retrieval protocol that is the basis of the Wide Area Information Server (WAIS) information retrieval system; the WWW continues to support the protocol.
9: The Web* Team
The original idea for this effort was provided by Tad Davis as part of our healthcare informatics project. Two years ago, when we presented a Mosaic mockup of a patient chart to participating
10
healthcare providers, they were excited. We decided then that we would adopt the World-Wide Web as our interface.
Since then, George Almasi has spearheaded the effort. Numerous other people have contributed to the Web* effort, including Anca Suvaila, Calin Cascaval, Ion Muslea, and Cristian Goina. Tad Davis has been the relentless customer of this effort, encoding innumerable layout pages (80 at last count), in which each page represents one form of a patient chart.
10: References
[1] Berners-Lee, Tim (WWW Project): WWW Naming Schemes. Accessible at ftp://xcf.berkeley.edu//pub/ht/ projects/WWW/WWWBook/WWW/Addressing/Addressing.html.
[2] NCSA Mosaic Home Page. Consult the Mosaic Home Page, http://www.ncsa.uiuc.edu/.
[3] TCL FAQ. Accessible at http://www.cis.ohio-state.edu/hypertext/faq/usenet/tcl-faq/top.html.
[4] Common Object Request Broker: Architecture and Specification. Object Management Group. Available at ftp.omg.org/pub/CORBA.
[5] HyperText Mark-up Language. Available at ftp://xcf.berkeley.edu//pub/ht/projects/WWW/WWWBook/ WWW/MarkUp/MarkUp.html.
[6] Stallman, Richard: Why You Should Not Use TCL, Article No. [email protected] on comp.lang.tcl.
[7] K. Srinivas, K. Gopinath, V. Jagannathan, R. Karinthi, Matthew Fuchs, Y.V. Reddy, George Almasi, Tad Davis: Applications of Mosaic in Health Care Delivery, Proceedings of the Second International WWW Conference ?94: Mosaic and the Web, October 1994, Chicago, IL. Accessible at http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/MedTrack/srinivas/artemis.html.
11: Acknowledgements
This research was partially funded by ARPA grant number MDA 972-91-J-1022 and the National Library of Medicine grant number N01-LM-3-3525 awarded to the Concurrent Engineering Research Center.
12: Biographical Sketches
G. Almasi is a Research Associate at the Concurrent Engineering Research Center (CERC), West Virginia University (WVU). He received his MS in computer Science from WVU in 1993 and MS in Electrical Engineering from Technical University of Cluj, Romania, 1991. He was the principal designer and developer of the Web* and TclDII software described in this paper.
Dr. V. "Juggy" Jagannathan is the Associate Director of Research at the Concurrent Engineering Research Center (CERC) and Associate Professor of Computer Science in West Virgina University. His research focus is on interoperability and integration environments. He is the Co-PI of a $4.1 Million National Library of Medicine sponsored project on "Collaboration Technology for Real-time treatment of patients." He directed the development of Web* software - now in the public domain - that link CORBA-based environments to the World Wide Web. He initiated the IEEE, AAAI and ACM sponsored "Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE)". Dr. Jagannathan has over 50 publications in workshops, conferences, books and journals.