Skeletons are abstract classes that connect your servant implementation of the interface methods to the ORB. That is, the IDL compiler or equivalent produces an abstract class definition that includes every method that you specified in the original module. You will typically derive a class of your own from this class, and your derived class will contain the server-side implementations of the methods. Your implementation can also include methods not defined in the IDL (which will not be available through CORBA calls).
Stubs are client-side proxies (stand-ins) for the corresponding server component. Your client-side code calls a proxy method, which packages its arguments and sends them off to the server-side skeleton. The server-side skeleton unpacks the arguments and calls the appropriate methods of the skeleton derived class that you created. Return values work in the same way, but in the other direction.
Marshaling is the process of converting typed parameters of a component operation to platform-independent (PI) form (usually a binary stream) for transmission over the network. The stub method is said to “marshal” its arguments when it puts them into a binary form for transmission to the skeleton. When you make a CORBA call, you may have in, out, or inout parameters. That is, each argument can be labeled with one of these IDL keywords to specify which direction the parameter is moving. This notation is of interest primarily with references and will tell the IDL compiler whether the referenced object is simply used, or if it’s modified. In the former case, the skeleton won’t contain any code to send the (unmodified) object back to the client-side stub.
Your client may be on a Windows platform and your server components may be on one or more Unix platforms. The code on the two sides of the connection can be written in any language (i.e., a Java server could talk to a C++ client). The operating systems may differ in hardware or memory specifications. Hence the data should reach its destination and return if necessary. The ORB takes care of all this translating by marshaling into a well-defined binary representation (the most common of which is IIOP, “The Internet Inter-Orb Protocol). On the receiving end, the process of converting the PI data back to the platform-specific form is termed as unmarshaling.