gnue/docbook/Proposals/GComm chapters/introduct...

[Jan Ischebeck]

CVSROOT:        /cvsroot/gnue
Module name:    gnue
Changes by:     Jan Ischebeck <address@hidden>  02/05/31 22:04:04

Modified files:
        docbook/Proposals/GComm/chapters: introduction.sgml 
        docbook/Proposals/GComm: bookinfo.sgml chapters.ent gcomm.sgml 
Added files:
        docbook/Proposals/GComm/chapters: codeinsight.sgml history.sgml 

Log message:
        add RPC-abstraction to this file
        add describtion of differnt files

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/docbook/Proposals/GComm/chapters/codeinsight.sgml?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/docbook/Proposals/GComm/chapters/history.sgml?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/docbook/Proposals/GComm/chapters/introduction.sgml.diff?tr1=1.1&tr2=1.2&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/docbook/Proposals/GComm/bookinfo.sgml.diff?tr1=1.1&tr2=1.2&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/docbook/Proposals/GComm/chapters.ent.diff?tr1=1.1&tr2=1.2&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/docbook/Proposals/GComm/gcomm.sgml.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: gnue/docbook/Proposals/GComm/bookinfo.sgml
diff -c gnue/docbook/Proposals/GComm/bookinfo.sgml:1.1 
gnue/docbook/Proposals/GComm/bookinfo.sgml:1.2
*** gnue/docbook/Proposals/GComm/bookinfo.sgml:1.1      Wed Sep 26 19:05:57 2001
--- gnue/docbook/Proposals/GComm/bookinfo.sgml  Fri May 31 22:04:04 2002
***************
*** 16,21 ****
--- 16,53 ----
        </simpara>
        </authorblurb>
      </author>
+ 
+     <author>
+       <firstname>Jan</firstname>
+       <surname>Ischebeck</surname>
+       <affiliation>
+       <orgname>GNU: Enterprise Core Development Team</orgname>
+       </affiliation>
+       <authorblurb>
+       <simpara> Email: 
+         <ulink url="mailto:address@hidden";>
+           <literal>address@hidden</literal>
+         </ulink>
+       </simpara>
+       </authorblurb>
+     </author>
+ 
+     <author>
+       <firstname>Jason</firstname>
+       <surname>Carter</surname>
+       <affiliation>
+       <orgname>GNU: Enterprise Core Development Team</orgname>
+       </affiliation>
+       <authorblurb>
+       <simpara> Email: 
+         <ulink url="mailto:address@hidden";>
+           <literal>address@hidden</literal>
+         </ulink>
+       </simpara>
+       </authorblurb>
+     </author>
+ 
+ 
      
    </authorgroup>
  
Index: gnue/docbook/Proposals/GComm/chapters.ent
diff -c gnue/docbook/Proposals/GComm/chapters.ent:1.1 
gnue/docbook/Proposals/GComm/chapters.ent:1.2
*** gnue/docbook/Proposals/GComm/chapters.ent:1.1       Wed Sep 26 19:05:57 2001
--- gnue/docbook/Proposals/GComm/chapters.ent   Fri May 31 22:04:04 2002
***************
*** 1,6 ****
  <!-- -*- SGML -*-
  
!  $Id: chapters.ent,v 1.1 2001/09/26 23:05:57 baumannd Exp $
  
   Contains chapter references
  
--- 1,6 ----
  <!-- -*- SGML -*-
  
!  $Id: chapters.ent,v 1.2 2002/06/01 02:04:04 siesel Exp $
  
   Contains chapter references
  
***************
*** 8,10 ****
--- 8,13 ----
  
  <!ENTITY bookinfo             SYSTEM "bookinfo.sgml">
  <!ENTITY chapter.introduction         SYSTEM "chapters/introduction.sgml">
+ <!ENTITY chapter.design         SYSTEM "chapters/design.sgml">
+ <!ENTITY chapter.codeinsight    SYSTEM "chapters/codeinsight.sgml">
+ <!ENTITY chapter.history        SYSTEM "chapters/history.sgml">
Index: gnue/docbook/Proposals/GComm/chapters/introduction.sgml
diff -c gnue/docbook/Proposals/GComm/chapters/introduction.sgml:1.1 
gnue/docbook/Proposals/GComm/chapters/introduction.sgml:1.2
*** gnue/docbook/Proposals/GComm/chapters/introduction.sgml:1.1 Wed Sep 26 
19:05:57 2001
--- gnue/docbook/Proposals/GComm/chapters/introduction.sgml     Fri May 31 
22:04:04 2002
***************
*** 1,11 ****
! <chapter id="proposal">
!   <title>GComm Proposal</title>
    <sect1>
      <title>
!       Introduction
      </title>
      <para>
!       Just notes for now...
      </para>
      <itemizedlist mark="bullet" spacing="compact">
        <listitem>
--- 1,107 ----
! <chapter id="Introduction">
!   <title>Introduction</title>
! 
! <sect1><title>Objective</title>
! <para>
! Provide an abstract model for providing services to the world and
! for requesting services from a compatable provider.
! </para>
! </sect1>
! <sect1><title>Motivation</title>
! <para>
! Several GNUe tools require a platform- and implementation-independent means
! of communicating with other GNUe tools:
!     <itemizedlist mark="bullet" spacing="compact">
!       <listitem>
!       <para>
!    GNUe Forms (client)
!       </para>
!       </listitem>
!       <listitem>
!       <para>
!    GNUe Reports (server/client)
!       </para>
!       </listitem>
!       <listitem>
!       <para>
!    GNUe Application Server (server/client) (?)
!       </para>
!       </listitem>
!       <listitem>
!       <para>
!    GNUe Integrator (server/client)
!       </para>
!       </listitem>
!       <listitem>
!       <para>
!    GNUe Transaction Server (server/client)???
!       </para>
!       </listitem>
!       <listitem>
!       <para>
!    GNUe Security Server (server/client)???
!       </para>
!       </listitem>
!     </itemizedlist>
! 
! Each of these tools will need to communicate with the world via several
! protocols:
!     <itemizedlist mark="bullet" spacing="compact">
!       <listitem>
!       <para>
! 
!    Sockets
!       </para>
!       </listitem>
!       <listitem>
!       <para>
!    Corba
!       </para>
!       </listitem>
!       <listitem>
!       <para>
!    XML-RPC
!       </para>
!       </listitem>
!       <listitem>
!       <para>
!    SOAP
!       </para>
!       </listitem>
!       <listitem>
!       <para>
!    Local Instance (?)
!       </para>
!       </listitem>
!     </itemizedlist>
! 
! The goal of GComm is to abstract inter-tool communications so that all tools
! can share a common code base.  This also allows new mechanisms to be added
! via plug-ins that will work with all tools.  For example, as soon as an
! XML-RPC driver is implemented, all the tools using GComm can utilite XML-RPC.
! Likewise, as soon as new encryption techniques are implemented, all the
! GComm tools will support the new encryption model.
! 
! <screen>
!  Provider/Server                                              Requester/Client
!                   .-------------.                  .-------------.
!                   |             | --> XML-RPC  <-- |             |
! MyFunction1() --> |    GComm    | -->  SOAP    <-- |    GComm    |
!                   |             | --> Sockets  <-- |             | <-- Client
! MyFunction2() --> | Abstraction | -->  CORBA   <-- | Abstraction |    Requests
!                   |             | -->  Other   <-- |             |
!                   `-------------'                  `-------------'
! </screen>
! </para>
! 
! </sect1>
! 
    <sect1>
      <title>
!       Reasons against "normal" middleware
      </title>
      <para>
!       There are different good reason for NOT choosing a already established 
middleware for the GNU Enterprise project.
      </para>
      <itemizedlist mark="bullet" spacing="compact">
        <listitem>
***************
*** 41,48 ****
        <listitem>
        <para>
          developers like choices
!       </para>
        </listitem>
      </itemizedlist>
    </sect1>
! </chapter>
\ No newline at end of file
--- 137,276 ----
        <listitem>
        <para>
          developers like choices
!       </para>
        </listitem>
      </itemizedlist>
    </sect1>
! <sect1><title>
! Remote Objects vs Remote Services
! </title>
! <para>
! 
! This design is meant to exposes services. It does not try to emulate
! Object management for transports that do not support Object management
! natively. Such a design is far too complicated of a task for GNUe to
! embark upon (and would be a futile exercise as there are plenty of
! existing Object management tools.) If objects are used in a non-object
! transport, a simple reference passing mechanism will be used and all
! objects will be maintained/accessed by the server.
! </para><para> 
! However, if your design requires the use of remote objects, you might
! need to re-evaluate your design as, all-to-often, objects are overkill
! for remote services. (I'm sure we will get flamed for that statement,
! but it's true.)
! 
! </para>
! </sect1>
! 
! <sect1><title>Design Considerations</title>
! <para>
! 
! The main considerations are (in no particular order as all are critical):
! 
!       </para>
!  <itemizedlist mark="bullet" spacing="compact">
!       <listitem>
! <title>Reusability</title>
! <para>
!        GComm must meet the communication needs of all the GNUe
!        GNUe clients and servers.  Where practical, this is not
!        limited to the communication between the clients and
!        servers, but also between the clients/servers and other
!        non-GNUe sources (i.e., if a server exports a CORBA
!        interface, this interface should be usable by GNUe and
!        non-GNUe clients. Likewise, if a GNUe client needs to
!        connect to a non-GNUe service, GComm should provide the
!        basis for this connectivity.
!       </para>
!       </listitem>
!       <listitem>
!       <title>Security</title>
! <para>
!        GComm must securely pass through whatever security
!        mechanisms are in place.  If simple username/password
!        mechanisms are used, then this must be passed along.
!        Likewise, if a session-ticketing mechanism is used,
!        this "ticket" should be passed.
!       </para> <para>
!        GComm drivers should support some sort of encryption
!        if the communications medium doesn't directly support
!        such.
! 
!       </para>
!       </listitem>
!       <listitem>
!       <title>Modularity</title>
! <para>
!        GComm should support a plug-in based driver mechanism
!        so that new communication channels can easily be added
!        to the system.  This will help ensure the long-term
!        viability of our system as new communication methods
!        can be added as they become popular.
! 
!       </para>
!       </listitem>
!       <listitem>
!       <title>Portability</title>
! <para>
!        The GComm interface should be abstracted to be platform
!        and communication medium independent.
!       </para> <para>
!        Individual drivers for OS-specific communications media
!        can, of course, be OS-specific. (e.g, if someone really
!        wanted an AppleTalk client, the plug-in driver could be
!        Mac specific if necessary.)
!       </para>
!       </listitem>
!     </itemizedlist>
! 
! </sect1>
! <sect1><title>Features</title>
! <itemizedlist mark="bullet" spacing="compact">
!       <listitem>
!       <title> Exceptions</title>
! <para>
!    Python server handlers can use standard Python exceptions to
!    signal errors.  The GComm adapters will translate these to
!    whatever error mechanism that adapter provides.  Should the
!    adapter provide named exceptions, then
! </para>
!       </listitem>
!       <listitem>
!       <title>Loopback/Local Proxy Mode</title>
! <para>
!    GComm provides a "short circuit" mode so that two modules designed to
!    run as separate servers can be run under the same server instance and
!    access each others services without using an external protocol. In
!    other words, the two "servers" co-exist in the same python instance
!    and can use each others' services without the use of CORBA, XML-RPC,
!    or any other network-based protocol.
! </para><para>
!    To use this feature, use the "proxy" interface.
!       </para>
!       </listitem>
!     </itemizedlist>
! </sect1>
! 
! <sect1><title>Possible Interfaces</title>
! <screen>                                                           OpenOffice
!                       Corba     Pyro   Java RMI  XML-RPC   SOAP     UNO
!                      -------- -------- -------- -------- -------- --------
! Distributed Objects      X        X        X        -        ??       X
! 
! Exceptions               X        X        X        X        ??       X
! 
! Pass simple types        X        X        X        X        X        X
! Pass aggegrate types     X        X        X        X        ??       X
! Pass userdef types       X        X        X        ??       ??       X
! 
! Return simple types      X        X        X        ??       ??       X
! Return aggregate types   X        X        X        ??       ??       X
! Return userdef types     X        X        X        ??       ??       X
! 
! Python Native            -        X       ??        X        X        -
! Python Bindings          X        X       ??        X        X        -
! 
! </screen>
! </sect1>
! 
! </chapter>
Index: gnue/docbook/Proposals/GComm/gcomm.sgml
diff -c gnue/docbook/Proposals/GComm/gcomm.sgml:1.1 
gnue/docbook/Proposals/GComm/gcomm.sgml:1.2
*** gnue/docbook/Proposals/GComm/gcomm.sgml:1.1 Wed Sep 26 19:05:57 2001
--- gnue/docbook/Proposals/GComm/gcomm.sgml     Fri May 31 22:04:04 2002
***************
*** 1,5 ****
  <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
! <!-- $Id: gcomm.sgml,v 1.1 2001/09/26 23:05:57 baumannd Exp $ -->
  <!ENTITY % global.chapters SYSTEM "chapters.ent">
  <!ENTITY % global.shared   SYSTEM "shared/shared.ent">
  
--- 1,5 ----
  <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
! <!-- $Id: gcomm.sgml,v 1.2 2002/06/01 02:04:04 siesel Exp $ -->
  <!ENTITY % global.chapters SYSTEM "chapters.ent">
  <!ENTITY % global.shared   SYSTEM "shared/shared.ent">
  
***************
*** 18,26 ****
--- 18,29 ----
    &bookinfo;
  
    &chapter.introduction;
+ <!--  &chapter.design; -->
+   &chapter.codeinsight;
  
    <part id="appendixes">
      <title>Appendixes</title>
+     &chapter.history;
      &shared.license.gpl;
      &shared.license.fdl;
    </part>