Catherine Tornabene CHAIMS Project README RMI Wrappers 1.0 - FAQ June 19, 1998 This FAQ is intended to questions that might arise regarding version 1.0 of the RMI Wrappers. 1. General RMI Wrapper questions =================================== 1.1. When do I use the RMI wrappers? -------------------------------------- The RMI wrappers are intended to wrap Java RMI servers that are not CHAIMS-compliant. Though there are CORBA-Java bridges, I have not tested the wrappers with anything other than an RMI server. Given the reliance on the multi-threading capabilities of Java, I would expect some problems with this approach. The RMI wrappers should be able to wrap any Java RMI server. 1.2. If I have a non-CHAIMS-compliant server, how do I wrap it? --------------------------------------------------------------- This is discussed in more detail in the document README.HowToWrap. Please see that document. 1.3. Is the wrapper considered to be a CHAIMS-compliant server? -------------------------------------------------------------- Yes. The public interface of the RMI wrapper server supports all the CHAIMS protocols. The implementation of the protocols is done in Java. CHAIMS-compliancy to the protocols is ensured because the RMI server implements the interface class called ChaimsCompliantObject.java in which all the CHAIMS protocols are prototyped. 1.4. Can other servers use the same interface? --------------------------------------------- Yes, with the caveat that I have never tried it. However, the definition of Java interfaces is that any class which adopts an interface class must promise to implement all the prototypes defined in the interface class. Therefore it should be possible for a different server to be CHAIMS-compliant by using the ChaimsCompliantObject.java interface and providing its own implementation. There is more information about CHAIMS-compliancy at http://www-db.stanford.edu/CHAIMS/Doc/Details/Protocols/chaims_compliant.html 1.5. Can the wrapper server and the non-CHAIMS-compliant server be on different hosts? ------------------------------------------------------------------- Yes, providing that the wrapper server is started *after* the non-CHAIMS-compliant server. An exception will be thrown if the wrapper server is started before the server it is wrapping. The wrapper server only interacts with the non-CHAIMS-compliant server via the public interface of the non-CHAIMS-compliant server. The wrapper is customized to know about the methods in this interface, so separating them on different hosts should be possible. This is something else I've never tried. Note that in order to wrap a non-CHAIMS-compliant server, information about the structure of the complex types is needed. For that reason, it is probably more convenient to keep the wrapper and the server on the same site. Otherwise, that information must be exported to wherever the wrapper is located. Also, if the wrapper server and the non-CHAIMS-compliant server are on different hosts, the non-CHAIMS-compliant server must send its generated stubs to the wrapper server. This is a onetime cost. If the non-CHAIMS-compliant interface is changed in any way, new stubs must be generated and shipped to the wrapper server. (Note that if the non-CHAIMS-compliant interface changes, the wrapper will probably have to be custom-changed to accomodate those modifications). 1.6 Can the same interface be used for multiple servers on the same machine? -------------------------------------------------------------------- Yes. In our case, this would happen when we have several modules wrapped that we want to interact with. Here is a small example: Assume NCCM1 and NCCM2 are two Java RMI non-CHAIMS-compliant servers that happen to reside on the same machine. We also assume that we want the wrappers on the same machine. There is a picture below that demonstrates what happens in a simplistic form. NCCM1 and NCCM2 provide interfaces which are then custom-wrapped. (Please see the README.HowToWrap document for more information). At the server side, we then have two wrapper servers whose public interface, ChaimsCompliantObject.java, is the same. Furthermore, the implementation class, ChaimsCompliantObjectImpl.java, is the same. These individual wrapper servers are given *different* names and registered at the server host via the rmiregistry. (Please see the README.HowToStart document for specific instructions on how to start up the wrappers). Because identification from the client is name-based, rather than object-based, the client program (which is generated by the compiler) only needs to have the ChaimsCompliantObjectImpl stub, so one stub will connect to any server that provides the ChaimsCompliantObject.java interface and implementation. Below is a simplistic picture of what happens. Because both NCCM1_WS and NCCM2_WS (definitions below) provide the implemented ChaimsCompliantObject interface, the skeleton will know which server to contact based on the name provided in the RMI-registry at the server site. CCO = ChaimsCompliantObject CCOI = ChaimsCompliantOjectImpl NCCM1_WS = wrapper server for NCCM1 NCCM2_WS = wrapper server for NCCM2 "1" is the connection to NCCM1_WS "2" is the connection to NCCM2_WS Client Side Server Side ------------------------ ------------------------------------ +--------+ | CHAIMS | 1 +-------+ 1 & 2 +----------+ 1 +-----------+ | client |----| CCOI |---------------| CCOI |----------| NCCM1_WS | | |----| stub | | skeleton | | | | | 2 +-------+ +----------+ +-----------+ +--------+ | | 2 | +----------+ | NCCM2_WS | | | +----------+ 1.7 The CHAIMS invoke allows a megaprogrammer to only specify some parameters rather than all parameters, and to specify those parameters in any order. Is this a problem in calling the method? ------------------------------------------------------------------ No. In the case where parameters are left off, the wrappers will invoke the non-CHAIMS-compliant method by using the default parameter values that have been established. These parameter values are established within the customized LocalMethodWrapper classes and are persistant while the wrapper is running. Should a parameter value be left unspecified, that default will be used. In the case where no order is specified, the wrapper will go through the list of arguments and match argument names. It is presumed that the megaprogrammer knows the argument names from the respository or some other source of information. If there is an argument with no matching name, an exception or print statement will let you know. 1.8 So what about that error checking? --------------------------------------- Error checking in the wrappers is haphazard. You can certainly break the wrappers if you want, probabably without trying to hard. I have tried to use exceptions and print statements, but as of this writing we have not clarified the way in which we are dealing with error handling in CHAIMS. So there is no consistent error-checking mechanism, but I have tried to at least put print statements where you might get points of failure. 1.9 What about TERMINATEALL, SETATTRIBUTES, and GETATTRIBUTES? ----------------------------------------------------------------- These are not implemented in this version of the wrapper. They are actually quite easy to implement from a programmatic point of view, but when I looked into it I realized that there were several unanswered questions regarding the behavior of these statements. For TERMINATEALL, there remains the question of consistency. It is impossible to force the multithreaded wrappers to either all successfully terminate or all fail. This is because once the method is called at the non-CHAIMS-compliant server, it is impossible to terminate it. So a TERMINATEALL call, because it must loop through the CallEntry vector in the ChaimsCallRecord class to find call entries with matching client ID's, it is possible that some invocations could be terminated and some not terminated. I am not sure if this is the desired behavior of TERMINATEALL. Implementation of TERMINATEALL should be fairly trivial. In the TERMINATEALL implementation, just loop through the ChaimsCallRecord for all call entries and look for matching clientID's. If the clientID matches, call TERMINATE on that call entry. SETATTRIBUTES and GETATTRIBUTES have more unanswered questions. These assume that the wrapped megamodule will let the wrapper set certain variable. This also assumes that the wrapped megamodule will have the ability to distinguish between one call and another call to the same method. There is no way to do this by just invoking that method unless the attribute is either a parameter of the method or is set previously by another method. The behavior of these two calls must be clarified before the programmatic implementation can take place. In particular, we must define the behavior of GETATTRIBUTES and SETATTRIBUTES at the level of the non-CHAIMS-compliant server. Implementation will depend on what these decisions are. Personally, I think it will be hard to guarantee consistency of behavior with GETATTRIBUTES and SETATTRIBUTES because the behavior of those calls depends specifically on what methods the non-CHAIMS-compliant server has made publically available, and these will not be consistent from server to server. 1.10 Any leftover development notes? ------------------------------------- Yes. Here are a few thoughts I had while I was writing the wrappers: * An invocation that doesn't probably execute at the non-Chaims server is considered "INVALID", which is the same marker used for an illegitimate callID. This could result in confusion. * You could run into big problems if the methodID of a local method is coincidentally the same as the generated clientID. Normally methodID's are low numerically, i.e., 1,2,3,4, but this is a potential problem. * You can't set default values for certain fields in complex types. i.e., you can set a default value for an entire complex type, but not for the specific fields in the types. I'm not sure if this is the right decision, but I think that it makes sense to expect whole data from other megamodules rather than partial data. To change this, one would need to change the specialized ParameterObject classes for complex types.