Distributed Computing Environment

1. OSs are going to be more and more Object Oriented (in a very general sense).
2. OSs are going to be more and more Distributed.

1. nfs: Part of some OSs (Unix), additional application to others (MS). Brings distribution.
2. afs: Additional application. Brings distribution.
3. dfs: Application of dce; can be seen as part of OS where dce is such. Brings distribution.
4. dce: Part of many OSs (Unix), additional application to others (MS). Brings distribution and limited object orientation.
5. Corba: Additional application. Brings distribution and object orientation.
6. OODB: Additional application. Brings limited distribution and limited object orientation.
7. Java: Additional application, OSs based on Java as native language may appear soon. Brings distribution and object orientation.
8. WWW: Additional applications, there are tries to make it part of OS (MS). Brings distribution, together with other applications (Java) also object orientation.
9. NIS: Originally external application, now part of many OSs (Unix). Brings distribution.

DCE resources are principals. Almost anything, what exists in a computer, can be a principal: user, printer, process, machine, file,... There is ACL attached to each principal. Security is very strong point of DCE, which is natural thing coming from the fact that DCE is Internet-Wide OS. DFS is just one application using DCE (although probably the most important one nowadays).

As it is part of the OS (at least in the Unix world), it can be OO only to limited extend like the OS which carries it. It, however, satisfies several requirements usually laid on OO systems: It is fundamentally Client-Server environment and as such it allows encapsulation and polymorphism. In the version 1.2.2, DCE allows also passing of object reference and interface inheritance.

The support for C++ in the core DCE is very limited. In the version 1.2.2, C++ header files can be created from DCE idl files. There are applications allowing to use C++ in broader way: for example Objtran (from CityBank), DCE++ (from HAL Computer Systems) or OODCE (from HP) which may in future become part of the core distribution. Some applications allow creating DCE idl files from C++ header files.

DCE is part of all  important OS and is derived from the common source code, which is provided by the OSF and is free for non-for-profit organizations since version 1.2.2. The common source allows in principle to write easily portable code.

• Programming in DCE is simpler.
• DCE is not fully OO.
• DCE is based on common source code, while Corba has only standard API defined.
• DCE has reference implementation for all platforms, Corba only has common abstract specification.
• DCE standard is very strict, while Corba standard is very broad (this comes from the fact that DCE standard has been defined before implementation while there have been several Corba implementation before standard).
• All DCEs are well interoperable, this is by far not true for Corba as Corbas from different vendors cannot talk one to another (although common protocol exists here too).
• There are Corbas using DCE as its transport protocol (ORB+, HB DCE CCIOP,...).

• MS has taken only specification for DCE RPC (officially because of cost) and will "redo and extend".
• MS uses several components of DCE:
• OLE uses DCE RPS and Kerberos5.
• MS Exchange uses DCE RPC.
• DCE may be in core MS security in 98.
• DCE DTS (time service) may be in MS in 98.
• There is internal "Strategy Paper" about DCE in MS.
• Proper DCE implementations exist from other vendors (Gradient, DEC).

• They can live together.
• They will probably live together in HPSS, which uses DCE as its underlying protocol.
• Both are similar in many items (caching, replicas,...).
• DCE moves computing, OODB moves data.
• They may both become well integrated in the OS.

• DCE has much better performance.
• DCE is much more stable.
• Solid DCE applications exist already now, Java applications may exist soon.
• DCE is part of OS already now, this may be true for Java in future.
• Java is very well OO, DCE is not (at least yet).
• Java is 100% platform independent, DCE is reasonably platform independent (same source code).
• There are Java frontends allowing access to DCE from non-DCE world (DE-Light).

1. Application uses Client Object.
2. Client Object decides to use remote Server Object.
3. Client Object asks CDS (part of DCE) where is available suitable Server Objects. Server Object had to register itself via its Server before.
4. Knowing the address of  Server Object, Client Object uses the chain Client Proxy Object - Stub - Runtime - Runtime - Stub - Server Proxy Object, which can then directly call Server Object itself. All chain components are either part of DCE environment or are created automatically when Client Object or Server Object is compiled.

1. User should define the interface of the Server she wants to use: idl file. It contains UUID unique identifier which identifies the running Server.
2. idl compiler creates several header files *.h and libraries lib*.a.
3. User should implement her client.c (nobody else can do it). She is using generated header files here.
4. User (or another user) should also implement the Server part of application: the function.c, which does the required job and server.c, which organizes the Server process. Some example of "server.c" can be used as function itself is rather complicated (but only minor changes are needed to "server.c" to get server.c.
5. Both client and server part of the application can now be compiled using generated libraries.

• idl, which defines the interface:

/* arithmetic.idl */
[uuid(C985A380-255B-11C9-A50B-08002B0ECEF1)]
interface arithmetic
{
   const unsigned short ARRAY_SIZE = 10;
   typedef long long_array[ARRAY_SIZE];

   void sum_arrays ([in] long_array a,
                                [in] long_array b,
                                [out] long_array c
   );
}

• client (only pink line is additional to local application):

/* client.c */
#include <stdio.h>
#include "arithmetic.h?
long_array a ={100,200,345,23,67,65,0,0,0,0};
long_array b ={4,0,2,3,1,7,5,9,6,8};
main ()
{
   long_array    result;
   int i;

   sum_arrays(a, b, result);
   puts("sums:");
   for(i = 0; i < ARRAY_SIZE; i++)
      printf("%ld\n", result[i]);
}

• routine, which performs the computing (only pink line is additional to local application):

/* sum_arrays.c */
#include <stdio.h>
#include "arithmetic.h"  

void sum_arrays(a, b, c)
   long_array a;
   long_array b;
   long_array c;
   {
      int i;

      for(i = 0; i < ARRAY_SIZE; i++)
         c[i] = a[i] + b[i];    /* array elements are each added together */
   }

• server steering, which organizes the server:

/* server.c */
#include <stdio.h>
#include "arithmetic.h"
#include "check_status.h"

main ()
{
   unsigned32           status;
   rpc_binding_vector_t *binding_vector;
/*...*/

   rpc_server_register_if (arithmetic_v0_0_s_ifspec, NULL, NULL, &status);
   CHECK_STATUS(status, "Can't register interface\n", ABORT);
/*... 257 lines together */
 
 
 
 

1. User runs only the front end (GUI, Event Display, Histogram Visualization,...) of the application on her computer.
2. She may (or may not) use some Institute resources for more computing demanding tasks. Also necessary data may reside somewhere around.
3. If any other results (objects) are needed, which are not available locally, they are localized somewhere on the network (possibly on some Regional Center). The place which is able to provide the results is asked to do so. It will do all necessary computing locally (remotely from the user point of view) and will send only necessary objects to the local Institute (and user).

• DCE is not yet OO. Also creating distributed applications is very easy using DCE (see example above), the need of using remote objects immediately brings problems. It is difficult, for example, to create an object in the server and pass it to the client in case client doesn't know  the full description of the object in advance (in idl). The same is true even for simple pointers and references. In general,  memory allocated on the server cannot be accessed easily from the client.
• DCE is very complex and the support for user friendly environment is very limited. Once any application more complicated than trivial is being created, user immediately should go quite deep into the DCE internal structure (RPC, Threads, Kerberos,...) and there are only a very limited (free or cheap) tools for that. There are several probably high quality tools for developing applications in DCE (Encina++,...), but their price are too high for us. DCE is more-or-less ignored by the GNU community (which may however change after Linux port of DCE is ready).