To: java@cs.caltech.edu
Subject: Microsoft Professional Developers Conference Summary
Content-Length: 24932
This note is from Steve Tuecke of Argonne Nat'l Labs. It contains
some good information on Microsoft's Java strategy (Jakarta etc).
-John
------- Forwarded Message
Subject: Microsoft Professional Developers Conference Summary
Date: Sun, 17 Mar 1996 20:50:16 -0600
From: Steve Tuecke <tuecke@mcs.anl.gov>
content-length: 24565
Microsoft Professional Developers Conference Summary
3/11/96 - 3/14/96
Steve Tuecke
Remy Evard and I just spent the last week at the Microsoft
Professional Developers Conference in San Francisco's Moscone Center.
This was a large (>5000 attendees) conference that Microsoft sponsored
to introduce new technologies, educate developers, display Microsoft
and 3rd party wares, and to allow ISV developers to interact with the
MS developers. The focus of this event was internet technologies.
This is a fairly complete (i.e. long) summary the interesting tidbits
I picked up. I will address specific Nexus and Zipper related issues
in separate email to those groups.
COM/OLE
=======
* The theme of the week could be summarized as: "Everything should
be developed with COM." Microsoft made it painfully clear that
everything they are developing will be based on COM, and that all
ISV's should do everything in terms of COM.
* COM (Common Object Model) is basically Microsoft's alternative to
CORBA. We came away from the full-day COM talk with the feeling that
it is a codified collection of hacks to work around flawed
implementation languages (C++ and Visual Basic). A more positive (and
Microsoft friendly) way to state this is that COM is an object model
designed to allow the incorporation of all existing and emerging
languages, and that this necessarily adds some complexity.
But dispite some grossness, at actually does work. COM objects
are (demonstratably) interoperable between C, C++, Visual Basic,
VBScript, Java, JavaScript, Delphi, etc.
* COM is a "binary component standard". It describes the actual
byte layout of objects (such as a C++-like vtable layout for method
indirection). It also defines a small standard set of methods that
all COM objects must implement. One speaker expressed it by saying,
"COM is code packaging technology."
What they are trying to accomplish with COM is the ability to
distribute COM objects in binary only form, while solving such
problems as the fragile superclass problem, versioning problems, etc.
For example, normal C++ objects are poorly suited for this purpose,
because for one thing if you change an object by adding an instance
variable or method to it, that can change the sizeof() the object, as
well as the layout of the vtable. This requires you to recompile any
code that uses these modified objects. COM avoids these sorts of
problems.
In addition, COM defines a way to do dynamic method lookup on
objects, which allows COM objects to be called from scripting
languages with no apriori knowledge of the object.
After hearing the arguments for a week, and having a little time
to digest and think about them, I think I believe that these really
are important, non-trivial problems, and that COM really does provide
a workable solution to the problems that is reasonably efficient.
While CORBA is perhaps more elegant (and "standard") it is not yet
clear to me if CORBA really addresses some of the important issues
that COM does.
* OLE, as far as I can determine, is two things:
1) A set of COM classes and interfaces, primarily for the
purpose of embedding documents and controls into other documents and
controls. It is just one of many families of COM objects for various
purposes.
2) The old marketing name for COM. But apparently the use of
COM is back in favor, relegating OLE more to meaning #1. "Network
OLE" is the same as Distributed COM (DCOM). As one of the DCOM
developers put it, "We've always used the name DCOM, while they wanted
to call it OLE. Our name has finally won out."
* ActiveX: One big area MS was stressing this week was another
family of COM classes and interfaces called ActiveX. This is a family
of COM objects for putting active content on the web. It includes
standard interfaces to scripting environments, and *TODO*
* While MS is trying to put everything into COM, there are some
things are more appropriately cast in terms of a low level functional
API. Winsock falls into this class, as does CryptoAPI (basic
encryption services). These APIs are meant to allow an efficient,
though not necessarily easy, access to basic services. But then MS
layers higher level COM objects on top of these lower APIs.
* GUID (Globally Unique ID): This is a 16 byte integer that is
guaranteed to be unique across eternity. Apparently the algorithm was
developed years ago at Apollo.
Microsoft uses GUIDs everywhere. Probably the biggest use is that
all COM classes and interfaces are identified with GUIDs. When a
developer creates a new class or interface to a class, he assigns a
new, unique GUID to that thing. Now that version of the
class/interface has that GUID for all time. If the developer modifies
the class/interface (particularly if they modify the semantics or
interface), they assign a new GUID to it.
* COM has an interesting model and implementation of "interfaces".
In conventional OOP, an object can interit from multiple interfaces
(or pure virtual base classes). Inheriting from an interface implies
that the object implements a particular set of methods.
COM has added a small twist to interfaces. In usual OOP
implementations, an object has a single method indirection table
(vtable) which contains all of the methods from all of its interfaces,
in addition to any methods that object implements that are not part of
any particular interface. When you get a pointer to the object, you
are able to call any method on that object.
With COM, an object makes method indirection tables (vtables)
available on a per-interface basis. So when you get an object
pointer, you are only presented with the methods for the interface you
requested.
This is accomplished through the QueryInterface() method, which is
one of the standard methods that all COM objects must implement. The
COM object instantiation model uses this QueryInterface() method to
allow the object to present multiple views of itself.
This approach has several benifits:
1) Suppose a developer wishes to change its methods in an
incompatible way, for example by changing the semantics or the
argument interface. The developer would assign a new GUID to this
interface, so that it is distinct from the old interface's GUID. Now
it can be intelligent about versioning. If some other piece of code
requests the old interface (using the old GUID), the new version of
the object can either return an intelligent error. Or better yet, the
developer can maintain both interfaces to the object, and return the
correct interface from QueryInterface() depending on which GUID is
used. In other words, some sticky versioning problems can be address
through interfaces.
2) Multiple inheritance in normal OOP languages has a real
sticky problem with method name clashes. Suppose an class inherits
from two classes, each of which has a the method "int foo()". If a
user calls the foo() method, which one does it get? With COM
interfaces, this isn't a problem, since an object can present whatever
interface it wants, based on which interface (GUID) is requested by
the user.
3) A COM object can actually be implemented using more than
one C++ (or Java) object. So, for example, to solve the incompatible
interface problem described in #1, it could actually just use a
separate conversion object. When the new interface is requested, it
can return a vtable that points directly to the new object's methods.
But if the old interface is request, it can return a vtable to the
conversion object's methods, which will internally convert to the new
object.
4) This approach allows for vendor customization of standard
interfaces. For example, if an ISV wants to provide a custom
implementation of some standard MS supplied object, but with some
additional functionality, this is straight-forward. It can present
the standard interface when requested. But it can also present a
nonstandard interface, as well as the ability to clients to query for
this interface and optionally fall back to the standard one if it is
not found.
* COM persistence: MS has set of standard COM classes to do object
persistence.
The basic model of the system is that you have Storage containers,
and Stream containers. A Storage container can hold any number of
other Storage containers, in addition to any number of Streams. A
Stream is just a dynamically sized byte stream. The COM persistance
objects take all of this and store it out to some backing store.
Different backing stores can be easily plugged in.
This storage system can be used directly by an application, or it
can be used in tight conjunction with COM object instantiation to
implement object persistance.
The implementation allows you to easily plug in new backing
storage I/O objects at the bottom of this subsystem and leave the
higher layers alone. They currently have implementations that flatten
these storage structures into linear files and into memory. However,
the next version of NT (Cairo, shipping in 1997) will have a new
object filesystem (NTOFS). Though this was never stated, it is a
small leap to believe that this COM storage model will map directly
onto NTOFS.
They demonstrated an interesting example of the use of COM
persistence. MSWord documents are stored using these classes. An
MSWord document is just a Storage container. This Storage container
hold several Stream containers, such as one to contain header
information, one to contain versioning and access control
inteformation. The actual documents is stored as a sub-Storage
container, which has (at least) one Stream for the words, and
subcontains for images, embedded spreadsheets, etc. After saving out
such a document, they browsed the components of the MSWord document
using a generic Storage and Stream browser.
* reference counting: All COM objects must be explicitly reference
counted by the user. (See Java below for the exception to this.) In
addition to QueryInterface(), all COM objects must support AddRef()
and ReleaseRef(), which should implement reference counting. There
are codified rules for where and when AddRef() and ReleaseRef() should
be called. For example, if a function instantiates an object and then
returns a pointer to that object in a return argument, it is the
functions reponsibility to call AddRef(), but the caller's
responsibility to call ReleaseRef() when it is done with the object.
* WinInet: They introduced a familry of COM objects at this
conference to talking various internet protocols (http, ftp, etc.).
For example, it is really easy for an application to extend its "Save"
and "Open" functions to go directly to an ftp server. In the open
panel, instead of opening foo.doc locally, you can just type in
ftp://ftp.mcs.anl.gov/foo.doc to open a file from an ftp server.
DCOM (Distributed COM)
======================
* DCOM is MS's distributed version of COM, allowing you to do remote
method invocation on COM objects. Any COM object is automatically
usable as a DCOM object with no changes.
DCOM is available with NT4.0beta (shipping already), and was
demonstrated repeatedly this week. It will be available in beta for
Win95 in 2Q96, and shipping in 3Q96.
* threading: DCOM integrates both into the NT threading model.
Actually, there are two threading models that DCOM supports:
1) free threading: Each method is invoked in its own thread,
as the method invocation requests arrive. So there may be multiple
methods in process simultaneously. It is up to the user to do proper
synchronization.
2) apartment threading: Remote method invocation is integrated
with the Win32 event loop, so that all methods on an object are
invoked from the same thread as the object was created in, and are
serialized both with respect to other method invocation, and with
respect to win32 events that reach the object. This is convenient for
integrating DCOM into non-thread-safe objects, such as the various
display objects.
* security: DCOM integrates into the NT security model. Normal NT
ACLs (Access Control Lists) can be applied to object instantiation.
So user access to objects in an NT domain is automaticly determined
when a user logs into an NT domain.
Once instantiated, various levels of security can be applied to
messages sent around by DCOM when doing remote method invocation.
These levels include no security, authentication only, authentication
& signed messages (cannot change contents of message), and
authentication & signing & encryption.
It wasn't clear to me if this message security is currently at the
object level, or the process level. However, they clearly stated that
they will be gradually moving to ever finer grained control, allowing
security to be changed per-object or even per-method.
* Bootstrapping DCOM over HTTP: MS has a standard way (i.e. COM
classes) of bootstrapping a DCOM remote object reference via an http
link, or any other out-of-band method. In the http case, they have a
class called URLMoniker to do this. Basically, the client connects to
an http server. The ISAPI (MS server side COM classes) code on the
server creates a COM object. It then uses CoMarshallInterface() to
flatten the object (interface) reference into a linear byte stream
that can be embedded into the reply http message. On receipt of the
http message, the client uses CoUnmarshallInterface() to reconstitute
the byte stream as a remote object reference. The client can then
communicate with the remote object directly.
* Custom argument marshalling: CoMarshallInterface() and
CoUnmarshallInterface() automatically generate a proxy and stub for
the remote object. However, this limits the type of objects that can
be passed as arguments to remote methods to just the basic data types.
To get richer argument marshalling, you can use two approaches:
1) MIDL: This is an IDL (Interface Definition Language)
compiler which can generate more complex proxies and stubs. For those
of you who are Win32 hacking, MIDL is apparently a merging of ODL and
MakeTypeLib.
2) You can implement the IMarshall interface on the object
that you want to invoke remotely. CoMarshallInterface() uses
QueryInterface() to see if an object supports IMarshall. If it does
not, then it just uses the default behavior described above. But if
an object does support IMarshall, Co{Un}MarshallInterface() then uses
methods on that interface to allow custom argument marshalling.
* DCOM will also have support for tunnelling over HTTP, with the
stated purpose of making it easier to breach firewalls (beta in 2Q96).
* Asynchronous features: DCOM currently does not have much in the
way of asynchronous features. For example, you cannot yet mark a
method for asynchronous invocation. They do have something called
"RPC pipes", which I'm guessing allows you to easily setup an
out-of-band communication stream.
In talking with the DCOM developers, they will be adding asynch
features in the future. In addition to asych method invocation, they
are considering split invocation (check for completion later), and
even some form of futures on individual arguments.
* DCOM runtime is layered on top of DCE/RPC, though they have
enhanced it to run over other protocols, etc. (Well, really Winsock2
has been enhanced to support multiple protocols, and their DCE/RPC
uses Winsock2.) However, if COM objects are in the same process, they
invoke methods directly using a vtable, so you do not pay a penalty
for in-process calls.
* DCOM performance: In one session, the speaker ran a simple remote
method invocation with DCOM, to an empty method with no arguments.
(After the session, I verified with the speaker that it was doing what
I thought it was doing.) So this is a round trip message, using
NT4.0beta, running over an unloaded ethernet.
The round trip time was about 1.4-1.5ms. This implies that
Winsock can get end-to-end, user space, one way latencies in the
<600us vacinity.
Compare this to probably about 1.5-2.0ms for one way latency
between two Suns.
* Like COM, all of the languages can use DCOM. This has some
interesting implications. For example, HTML v3 allows you to directly
embed scripts into HTML documents. So you can use this capability to
embed a VBScript of JavaScript into an HTML document that can directly
instantiate and call methods on remote DCOM objects. This obviously
has significant security implications, but I'm not sure what they are
doing about this.
* porting:
- Software AG is porting DCOM to many (supposedly 18)
varieties of Unix, including Linux. They are also porting to MVS.
- DEC is porting to several Unixes and VMS. This port will
use a DCE infrastructure, including integration into DCE security.
Java
====
* Microsoft and Sun finally resolved and signed the Java licensing
agreement the week before the conference.
* MS is doing the right thing with Java (and they demonstrated most
of it at the conference). It will be a first class citizen in the
suite of MS language tools. And it will be a first class citizen with
respect to COM and DCOM.
* The project name for the Java IDE (Integrated Development
Environment) is "Jakarta" (a city on the island of Java). It
includes:
- A byte code compiler (.java -> .class), but where the
compiler is implemented as native code. It is _very_ fast. Compiling
Java classes is nearly instantaneous on a Pentium. And they claimed
they can byte compile the entire AWT class library in 2-3 seconds.
- Full Visual development environment, including VC++ like
debugger, class browser, version control, smart code editor, etc. One
cool feature is the class browser. They have a background thread that
parses your .java source files as you write them, and updates the
class browser on the fly.
- In addition to the standard java class libraries, there will
be a library of microsoft libraries.
- Optimized virtual machine for Win32. They demonstrated
their Java VM running in Internet Explorer 3.0, running Java programs
2x faster than under Netscape.
- Just In Time (JIT) compiler: A standard feature of their
Java VM is a JIT compiler (.class -> object code). They demonstrated
this from IE3.0 also, and it totally blew away the interpreted VM.
They said they are seeing a 40x improvement over their VM.
- Native code compiler (.java -> .o or .java -> .dll). All
Java classes will automatically compile to COM classes.
* Java is fully integrated with COM:
- From Java, COM objects are first class objects. You can
instantiate and call COM objects just like native Java objects. You
just need to import an appropriate class library for the COM object
you wish to use.
- Java type casting implicitly performs a COM
QueryInterface().
- You do not have to explicitly implement or perform the COM
AddRef() or ReleaseRef() methods. They have transparently integrated
this functionality into the garbage collector.
- DCOM just works with Java.
* Java VM _is_ and ActiveX control. In other words, the Java VM,
including the JIT compiler, is a COM object in all of its glory. So
any Win32 application, no matter what language it is written in, can
embed Java easily. In addition, MS is extending the Java Applet
framework to transparently interoperate with Win32 events and
display.
* Availability: Beta of whole development environment in 2Q96,
shipping in 3Q96. Java VM with JIT will also be in Internet Explorer
3.0. They were demonstrating alpha versions of everything at the
conference.
Winsock2
========
* Winsock2 is a major upgrade to the Winsock1.1 interface. It was
designed by a large consortium of companies, including MS. Some of
the new features supported by Winsock 2 are:
- Multiple protocols: MS will support at least TCP/IP and
IPX/SPX in their version of Winsock2. All of these protocols lie
under a common, stream oriented (read() and write()) interface.
- Multiple namespaces: This is an attempt to unify DNS, NDS
(Network), NT nameservice, and whatever others under a single unified
interface.
- Socket sharing: You can pass socket access from one process
to another. This is apparently to allow Unix daemon style
programming, where a parent process opens a socket, forks a child, and
then lets the child handle the socket.
- Multicast
- Quality of Service
- A scatter-gather interface
- Asynchronous notificatioin integrated into the Win32 event loop.
- Layered service providers: You can plug in filters between
the API and the protocol providers, so do such things as encryption,
compression, message boundary marking.
* Winsock2 is available now as part of NT version 4 beta
* MS Bloodhound: This is an IP packet sniffing tool, similar in
spirit to etherfind.
* Blocking select() in Win95/NT is apparently _very_ inefficient.
Instead, you should use the event tie-ins to get more efficient
blocking select behavior. This was mentioned several times. It
sounds like this should be avoided like the plague.
In NT, you should apparently use "completion ports" for doing
asynch notification of data availability.
Security
========
* PCT is Microsoft's and other's answer to SSL. There are beginning
to be efforts within the IETF to merge PCT and SSL into a single
standard. Also PCT can fallback to the SSL2.0 protocol. Apparently
PCT1.0 and SSL3.0 are very similar.
* MS has a PCT reference implementation (PCTRef), which runs on NT
and Linux. PCTRef uses RSARef. Netmanage (www.netmanage.com) is now
shipping a WinPCT implementation, free of charge, as of this week,
which uses PCTRef.
* WinPCT hooks into Winsock1.1. The user "does not have to do
anything". For example, since it hooks into Winsock directly, the
users does not have to use special calls. (SSLRef requires you to use
SSL_read() instead of read(), etc.) Apparently you configure WinPCT
to kick in security for particular ports, or particular combinations
of IP addresses and ports, etc.
* CryptoAPI: This is a low-level, function based API which supplies
encryption services. It is implemented as part of the NT kernel.
There is a higher-level APLI called SSPI, which is "basically a Win32
implementation of GSS-API." Custom crypto services can be plug into
this architecture, while keeping the CryptoAPI the same.
* SET (Secure Electronic Transactions) is a standard for doing
electronic bankcard payment, developed by Visa, Mastercard, Amex,
Microsoft, Netscape, et al. It uses very strong encryption (long
keys), but is very limited (cannot encrypt a payload) so as to allow
for export clearance. MS has a COM interface to SET which layers over
CryptoAPI, and allows easy integration of SET into applications.
* PPTP (Point to Point Tunnelling Protocol): NT now supports PPTP,
to all construction of virtual private networks with "very strong"
encryption (in the US).
* MS and some 30 other companies announced this week a digital
signature initiative. The purpose of this is to allow the "network
equivalent of shrinkwrap software". The idea is to sign network
loadable software in a standard way. Not only will complete
applications be signable, but so will COM objects, Java classes, etc.
Internet Explorer 3.0 will support this.
Miscellaneous
=============
* Internet Explorer 3.0: This is a complete integration of Internet
Explorer with the Win95 File Explorer. They showed alpha versions of
this, with expected beta in the Summer and shipping in Fall.
The idea is to remove distinctions between browsing your
filesystems and browsing the web. So you can embed rich text context,
COM/OLE controls (interactive display objects), etc into your
filesystem.
I'm guessing that you'll be able to do something like drop an
index.html file into any directory. This file will control the
display of that directory's content when you click on that directory
in the explorer. In addition, that index.html may have URLs out to
the web, COM/OLE controls, etc.
This unified explorer makes all the normal controls available from
both the current file explorer and internet explorer, such as property
sheets, various views, forward and backward buttons, etc.
The next stage in this process will be to integrate this explorer
directly into the desktop. (It wasn't clear to me if this was part of
IE3.0, or if this comes after that. I think its in IE3.0.) So
instead of having passive background, the background becomes an
explorer display surface.
IE3.0 will fully support VBScript, JavaScript, Java, and DCOM.
------- End of Forwarded Message