gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnue-dev] [patch] [documentation] docbook/GNUeObjectServer/chapters/arc


From: Jens Müller
Subject: [Gnue-dev] [patch] [documentation] docbook/GNUeObjectServer/chapters/architecture.sgml
Date: Thu, 02 May 2002 15:40:23 +0200
User-agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i386-debian-linux)

address@hidden:~/devel/gnu/gnue/docbook/GNUeObjectServer/chapters$ cvs diff 
architecture.sgml
Index: architecture.sgml
===================================================================
RCS file: 
/cvsroot/gnue/gnue/docbook/GNUeObjectServer/chapters/architecture.sgml,v
retrieving revision 1.2
diff -r1.2 architecture.sgml
83a84,114
>     Probably there will be the need for explicit information in the data
>     definition (e.g., definition of business objects) on how data can
>     be replicated and distributed, to ensure data integrity.
>   </para>
>   <para>
>     Some business objects will have to explicitly specify behavior for
>     disconnected locations. Also, there need to be possibilities to
>     connect object servers with locations, i.e., manage object servers
>     as business objects as well.
>   </para>
>   <para>
>     Example: If there is one server per branch, this server's
>     connection to this branch has to be explicitly stated, so that
>     business objects and triggers from supply chain can manage the
>     supply chain only for this branch. Otherwise, different systems
>     might try to manage the supply chain for the whole enterprise,
>     wondering that consumption of goods is so low. This won't produce
>     any usable results.
 >   </para>
>   <para>
>     Syncronization schemes should also be definable as business
>     objects, as syncronization is an issue relevant for the business,
>     e.g. reporting and tax purposes.
>   </para>
>   <para>
>     The process of syncronization itself should be definable in the
>     business objects to be syncronized, as it may depend on the way
>     such objects are used and created (especially the methods used to
>     resolve conflicts (multiple updates)).
>   </para>
>   <para>
-- 
Please don't CC me on replies!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]