From gilbertd@bio.indiana.edu Thu Dec 18 10:10:08 EST 1997 Article: 9958 of bionet.software Path: news.indiana.edu!not-for-mail From: gilbertd@bio.indiana.edu (Don Gilbert) Newsgroups: bionet.software Subject: experimental Java-CORBA applet for FlyBase searches Date: 18 Dec 1997 15:03:32 GMT Organization: Biology, Indiana University - Bloomington Lines: 105 Message-ID: <67be04$pfs$1@dismay.ucs.indiana.edu> NNTP-Posting-Host: chipmunk.bio.indiana.edu Xref: news.indiana.edu bionet.software:9958 There is an experimental Java applet for doing FlyBase queries using CORBA technology at http://chipmunk.bio.indiana.edu:7081/search/. This applet is designed for multi-databank searches in a flexible way, offering simple, quick searches at the basic level to be refined as much as desired by combining several fields in a search. There are still lots of rough points in the applet, but it works. It queries SRS services now; I hope to add some Sybase searches in future. It now requires use of Netscape verison 4, unless you have another applet viewer that includes its own ORB. It also isn't stable; the server end may die and not restart. Let me know if you try it and it works or fails for you. This applet has essentially the same user interface as its preceding Java-only query applet, searches the same data and provides the same results. The difference is that this OrbQuery applet is configured from the server, using "standard, portable" CORBA client-server methods. Potentially this same applet can be used in other databank services by desiging only the server side ORB and databank links. My reasons for designing and testing this are to compare the strengths and weaknesses of CORBA to Java-only methods, and to see if CORBA is ready for the kind of uses I see for a standard, portable client-server technology in areas of biocomputing and bioinformatics. The answer I found is mostly positive, with qualifications. In the computer world, new "standards" seem to be born ever time two programmers get together for a chat. There are now several companies and individuals producing Object Request Broker software (the ORB in CORBA). I've looked now at Orbix and Visigenic (commercial, for pay), OmniBroker (free, including source for non-comm. uses), JacORB (free, source, individual programmer's work), JavaIDL (Sun's Java-only ORB in alpha form). There are likely others, but this was plenty for tests. Visigenic and Orbix appear to be in widest use. They are not as fully interoperable in my tests as I would have liked. I had several false starts and had to back-track trying other client-ORB and server-ORB combinations. But in general they look inter-operable, following a true standard. Some concerns for general use in biocomputing and specifically for flybase: * are there free client ORBs that work? We can't afford to buy all users client orbs. Ans: Yes. * are there applet client ORBs that work w/o requiring multi-megabyte sized applets be down-loaded with each use? Ans: Yes, Netscape v.4 includes a client ORB in its java set. It is Visigenic based. My tests showed some non-interop hassles here. It was not fully compatible with the "standard" CORBA in the Omnibroker client, so I had to use Visigenic's client for development. * do client ORBs and server ORBs from different vendors inter-operate? Ans: Yes, if you use special care to avoid each vendor's "improvements" on CORBA. * does CORBA provide any advantage over Java-only client-server methods? Ans: a qualified yes. As others on both ends have pointed out, one can develop Java-only (or anything-only) designed for a specific client-server setup that works well and fairly simply. The real benefits appear to be when one wants to generalize from a specific service to many services, or many clients for one service. It looks like one can take the IDL for a client-server design, and implement the same interface for other servers fairly easily, if the IDL is flexible enough, without much concern for the client end of things. Likewise one could design multiple clients to access the same CORBA service without concern for the specifics of the server end. * does CORBA carry any disadvantages over Java-only methods? Ans: yes, but perhaps minimal and advantages can outweigh these. CORBA technology adds a layer of complexity and effort in the design, the amount of programming work and the size and time costs in usage. Adding corba methods doens't obviously offer anything more for a specific client-server operation. My first efforts aren't enough to answer these last two. Using corba at one level is straight forward object-oriented programming. The definition of the client-server relationship is in Interface Definition Language (IDL) and can model a general design well, and seems easy to write. IDL translators for all the tested ORB products work well and easily and generate about the same Java source, with product specific enhancements that I had to find my way around. With experience, I think a corba design won't add too much baggage to a client-sever setup, and carries the potential for wider uses. But also, we all know that potential may never be realized. Does anyone else care to use the IDL I designed, or do they want to design their own "general" client-server setup? Again we have a multiplicity of "standards" in the computer world. But there is a potential for CORBA based systems being more widely accessible than other systems, I think. Having said that, there are also some special benefits now to Java-only client server designs. Java has realized a long desired goal of object oriented programming to make *objects* that combine data, and software for managing that data, the central focus. These are Objects that can be moved around, updated, shared and plugged into programs in a flexible way. Data-only can now take a back seat and some worries about changing data structures can be lessened by packaging data into Java classes that have methods needed to make that data useful in programs. CORBA methods don't necessarily yet offer this same Java-specific functionality. -- -- d.gilbert--biocomputing--indiana u--bloomington--gilbertd@bio.indiana.edu