Author: jelmer Date: 2006-05-25 19:07:28 +0000 (Thu, 25 May 2006) New Revision: 549
WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=lorikeet&rev=549 Log: Update DCOM paper to reflect some new insights - DCOM should be based on Mono and its' COM support and utilize Samba's DCE/RPC + ORPC code instead of having our own COM implementation in Samba, which is too much work to implement and harder to code (C). Modified: trunk/white-papers/dcom/dcom.tex Changeset: Modified: trunk/white-papers/dcom/dcom.tex =================================================================== --- trunk/white-papers/dcom/dcom.tex 2006-05-10 20:05:58 UTC (rev 548) +++ trunk/white-papers/dcom/dcom.tex 2006-05-25 19:07:28 UTC (rev 549) @@ -308,8 +308,10 @@ DCOM and COM together, ignoring the concept of proxy classes. This attempt failed because it made matters very complicated. -The final attempt seperates the COM and DCOM implementations (somewhat similar to Windows), making the code simpler. +\subsection{First try} +The second attempt seperated the COM and DCOM implementations (somewhat similar to Windows), making the code simpler. + \begin{itemize} \item $lib/com$ contains a very simple (but sufficient) COM implementation. \item $lib/com/interfaces$ contains pidl generated structure files for the COM interfaces @@ -317,7 +319,7 @@ \item $lib/dcom/proxies$ contains the pidl-generated proxy files \end{itemize} -\subsection{COM implementation} +\subsubsection{COM implementation} Since Samba is written in C, which is not object-oriented, COM calls in Samba are made using function pointers in structs. This works @@ -457,62 +459,34 @@ TODO: Split out NDR-related and other stuff in ndr\_*.h \end{verbatim} - -\section{Future integration} -\subsection{OpenPegasus: WMI} +\subsection{Integration in Mono} -WMI (Windows Management Instrumentation) is Microsofts implementation of -the Web-Based Enterprise Management (WBEM) standard from the -Distributed Management Task Force (DMTF). +COM contains a lot of classes, making it very time-intensive (if not +impossible) to implement. Since it is object-oriented by nature, it is +also much easier to implement in an object oriented language, rather than +C. -One of the parts of WBEM is the Common Information Model (CIM) \cite{CIM}, -which is a data model for various types of management information. - -WMI is built on top of (D)COM\cite{COMWMI}; it looks like implementing WMI -will be possible by implementing a thin layer of (D)COM classes. For the -client-side, this should be sufficient. For the server side, -using the OpenPegasus \cite{OpenPegasus} backend might be an option, -though this would probably require a lot of integration work. - -An interesting option would be to create Python bindings for DCOM -on Linux so it can be used with WMI, with an API similar to that -of the Python-WMI\cite{PythonWMI} project. - -\subsection{Mono} - DCOM is currently mostly a legacy technology, with Microsoft focussing on the .NET framework. The .NET framework in -the Windows world has compatibility for COM built in. Rather then +the Windows world has compatibility for COM built in. Rather than a hard-coded standard for remoting, the .NET framework supports various backends, DCOM being one of them.\cite{DotNETRemotingIntro} Mono\footnote{http://www.mono-project.com/} is an open source project -that aims to implement Microsoft's .NET framework. +that aims to implement Microsoft's .NET framework. Work is currently in +progress to implement COM support for Mono. -It should be relatively easy to add support for DCOM, perhaps somewhat -similar to Remoting.Corba\footnote{http://remoting-corba.sourceforge.net/}. +It should be relatively easy to add support for DCOM +once the COM support is done, perhaps somewhat +similar to Remoting.Corba\footnote{http://remoting-corba.sourceforge.net/}, +based on Samba's DCE/RPC code. -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} -\item ability to disable either rpcss or Samba's epmapper support -\item use epmapper and rot pipe internally as well as externally -\item support for ncacn\_unix\_ds: in wine or ncalrpc: in the same fashion - as Samba? -\item Proposal: Keep all the object management stuff in Samba, but allow - Wine (thru the ROT interface) to add new objects. This allows the Wine folks - to use the Samba infrastructure for now, while giving them the opportunity - to move to a Wine-specific implementation of this stuff later on, if necessary. -\end{itemize} - -\subsection{Mozilla (ActiveX)} -There is a plugin for Windows only at the moment, available in Mozilla CVS \footnote{http://www.iol.ie/~locka/mozilla/plugin.htm}. Maybe extend to support *nix ? - +This makes the scope of the problem a lot smaller --- it means no longer +being required to reimplement COM in Samba. The only thing necessary for +this, is the DCE/RPC implementation and ORPC extensions from Samba and +some way to generate Proxy/Stub objects in Mono (see \ref{relations}). + \bibliography{dcom} \end{document}