svn commit: lorikeet r236 - in trunk/white-papers/dcom: .
jelmer at samba.org
jelmer at samba.org
Mon Feb 28 22:11:15 GMT 2005
Author: jelmer
Date: 2005-02-28 22:11:15 +0000 (Mon, 28 Feb 2005)
New Revision: 236
WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=lorikeet&rev=236
Log:
Add diagram explaining the relation between DCE/RPC, NDR, COM, DCOM, ORPC and
.NET Remoting
Add diagram with pidls internal structure and logic
Added:
trunk/white-papers/dcom/pidl_structure.dia
trunk/white-papers/dcom/relations.dia
Modified:
trunk/white-papers/dcom/Makefile
trunk/white-papers/dcom/dcom.tex
Changeset:
Modified: trunk/white-papers/dcom/Makefile
===================================================================
--- trunk/white-papers/dcom/Makefile 2005-02-28 14:28:41 UTC (rev 235)
+++ trunk/white-papers/dcom/Makefile 2005-02-28 22:11:15 UTC (rev 236)
@@ -3,7 +3,7 @@
BIBTEX = bibtex
DIA = dia
-IMAGES = interface-implementation.mps object-exporter.mps call-local.mps call-remote.mps
+IMAGES = $(patsubst %.dia,%.mps,$(wildcard *.dia))
all: dcom.pdf
Modified: trunk/white-papers/dcom/dcom.tex
===================================================================
--- trunk/white-papers/dcom/dcom.tex 2005-02-28 14:28:41 UTC (rev 235)
+++ trunk/white-papers/dcom/dcom.tex 2005-02-28 22:11:15 UTC (rev 236)
@@ -67,7 +67,7 @@
\begin{figure}
\includegraphics[scale=.40]{interface-implementation}
-\caption{An example of DCOM's distinction between interface and implementation}
+\caption{An example of COM's distinction between interface and implementation}
\end{figure}
\subsection{Interfaces}
@@ -148,7 +148,7 @@
\begin{itemize}
\item Binding directly to the ``Class Object''. This can be used to do either a ``static'' call or to call $CreateInstance$ (if the class object supports the $IClassFactory$ interface) to return a new class instance
\item Create an instance based on the CLSID. Windows looks up the CLSID in the registry, finds the associated DLL or EXE and loads it. ($CoGetInstanceFromFile() $)
-\item From Persistent State Object %FIXME
+\item From Persistent State Object. This creates an instance from a $IStorage$ pointer
\end{itemize}
Objects returned by other calls all use one of the three ways described above in
@@ -180,9 +180,16 @@
Distributed COM is nothing more then a 'hack' to make standard COM work
remotely. It was added later as a way to allow the distribution of COM objects
-over multiple computers. It is basically the glue between DCE/RPC \cite{opengroupdce} and
-COM.
+over multiple computers. It is basically the glue between DCE/RPC \cite{opengroupdce} and COM, as drawn in \ref{relations}
+\begin{figure}
+\caption{The relations between COM, DCOM and DCE/RPC}
+{\center
+\includegraphics[scale=.50]{relations}
+}
+\label{relations}
+\end{figure}
+
DCOM is not as closed as one might think; there are several documents available
from Microsoft explaining the wire format \cite{UnderstandDCOM,DCOMarch}. There has even
been an Internet draft on DCOM \cite{DCOMSpec}.
@@ -211,10 +218,8 @@
Every object lives in a certain context, known to Windows programmers as
an {\em apartment}. Calls crossing apartment boundaries need marshalling.
Usually the term apartment maps to a thread. Apartments are identified
-remotely by Object Exporter IDs (OXIDs)\footnote{I think these are just thread IDs, which are
-unique to the system on Windows.}.
-% For samba, let's use getpid() for OXIDs or some function for thread id's
-% from pthreads
+remotely by Object Exporter IDs (OXIDs)
+unique to the system on Windows.
\begin{figure}
\includegraphics[scale=.50]{object-exporter}
@@ -369,6 +374,16 @@
extension do not require large amounts of changes in
the pidl code nor do they increase the complexity of the pidl code.
+\newpage
+\oddsidemargin=0em
+\begin{figure}
+\caption{The data flow inside pidl}
+\includegraphics[scale=.40]{pidl_structure}
+\end{figure}
+\newpage
+
+
+
The additional pidl module, $com_header.pm$, generates C header files that contain
structs with function pointers for each object interface. They also generate wrapper macros for
easier use of the interfaces.
@@ -400,7 +415,7 @@
struct IUnknown {
struct com_context *ctx;
struct IUnknown_vtable *vtable;
- void *object_data;
+ void *object_data;x1x
};
#define IUnknown_QueryInterface(i,m,p1,p2) (i->vtable->QueryInterface(i->object_data, m, p1, p2))
@@ -460,6 +475,10 @@
It should be relatively easy to add support for DCOM, perhaps somewhat
similar to Remoting.Corba\footnote{http://remoting-corba.sourceforge.net/}.
+It is likely, however, that Samba's DCOM implementation is not necessary for
+this, only it's DCE/RPC implementation and ORPC extensions (see again
+\ref{relations}).
+
\subsection{Wine}
(Ideas)
\begin{itemize}
Added: trunk/white-papers/dcom/pidl_structure.dia
===================================================================
(Binary files differ)
Property changes on: trunk/white-papers/dcom/pidl_structure.dia
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: trunk/white-papers/dcom/relations.dia
===================================================================
(Binary files differ)
Property changes on: trunk/white-papers/dcom/relations.dia
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
More information about the samba-cvs
mailing list