Prefix: I was in total awe of DCE about a year ago. But after JAVA, I'm
going to throw in some controversy.
If you look at the feature set of JAVA applications distributed via Netscape
Secure Sockets Layer (SSL) gives you in relationship to what DCE promises
(below), hey, JAVA has about 80% of the DCE feature set (sometimes in a much
more narrow sense, but nevertheless, has the features).
With integrated super scalar multi-CPU machines hitting the market, what
need of getting parallel processing using DCE? Strike one.
I'm afraid that the DCE might have some problems (even as it is being
rolled out) as its feature set advantage erodes given other methods. Why?
The DCE is complex, has a high entry barrier verses the simplicity of doing
JAVA over Netscape or Active X.
Read these summaries and checklist features and decide whether JAVA served
over secure Netscape qualifies within each of these areas. But also note,
for physically separate machines, the DCE is still a winner.
I think Wirt mentioned the return of the big mainframe sprawling out JAVA
applications to the desktop as a description of this model. JAVA doesn't
address the critical multiple intra-machine communications across the
network, but JAVA does address secure, portable desktop applications (one of
the big promises of the DCE) but limited only from a central source.
===Simplistic summaries:
DCE PROBLEM #1: If you want to make all machine brands "transparent" on a
network, how would you do it? Now, I'm talking PC, Mac's, Mainframes, NT,
IBM big iron, all the Un*x flavors, etc.
You do it by 1) creating a server stack that transports your stuff in a
agreed upon "standard" way 2) creating a client stack that takes the
"standard transport" and translates it back to your particular brand x of
platform.
JAVA #1: will run on almost any platform and makes those platforms
transparent to both the client and server.
DCE PROBLEM #2: If you want to find your stuff on a network worldwide,
how would you do it? Again, use a agreed upon "standard" way. To look
within a local cell, you use Cell Directory Service(CDS). To look out and
beyond you use Global Directory Service (GDS).
JAVA #2: DNS does this job with Web index links.
DCE PROBLEM #3: If you don't want your data intercepted by network
sniffers, what would you do? Turn on data encryption within your DCE service.
JAVA #3: Run under Netscape's Secure Sockets Layer.
DCE PROBLEM #4: If you want to distribute desktop applications and
maintain one copy, how would you do it? Add DFS (Distributed File Service)
and run apps from DFS or create your own RPC.
JAVA #4: Use World Wide Web as application distributor. Single version
goes everywhere and disappear on termination.
DCE PROBLEM #5: If you want to perform OLTP across several servers
located on several different platforms and have integrity, how would you do
it? First, time is synchronized between platforms using DCE Distributed
Time Service (DTS). Then add another layer called ENCINA transaction monitor.
JAVA #5: Downfall. You wouldn't support this model (or could you)?
WWW/JAVA would be tied to a single large mainframe with super scalar CPU's
instead of many machines located at many nodes.
DCE PROBLEM #6: If you want to create a global authentication system for
services, how would you do it? Use Kerberos authentication server/clients.
JAVA #6: Use Kerberos authenticated Web/JAVA clients. The HTTP protocol
allows for Kerberos authentication, but I've never seen an instance yet of
this implemented (lack of DCE installed base at the moment). I'll assume
it's possible.
Well, five out of Six isn't bad.
----------------------------------------------------------------
Eric J. Schubert Senior Data Base Analyst
Office of Information Technologies Univ of Notre Dame, IN USA
(219) 631-7306 http://www.nd.edu/~eschuber
|
