SOX - Overview, Issues, Implementati
graham.moore at dpsl.co.uk
Tue Oct 6 10:26:46 BST 1998
I've just tried to organsie a few thoughts on the SOX issue; to clarify it
for myself and maybe others. Perhaps we can take some of these headings or
rename them, but I think we need some focus for the dicussion. This is a
very important issue. We do not want to get this wrong.
I've tried to highlight issues and alternatives, and where I feel strongly
espress my opinion.
So, here is an
1) Overview of what it is we are trying to achieve
2) Issues with Naming and Defining the association
4) Potential Use - With Examples
5) where it can go
To standardised the procedure of associating functionality with a seriliased
Traditionally, objects have had the abiliy to serialise and unserialise
themselves. The difference now is that with self describing serialised
object structures the potential exists to associate different functional
views with the same data object.
The way in which
a) the binding between the functionality ( functional object ?) and the
object data is specified.
b) this is implemented
are the problems we are trying to solve.
2.1) Naming and Defining the association
Who should name the functional assocition?
1) the receiving application could name the binding
2) the sending application could name the binding
3) the serialised instance could contain the binding information
So do we need to agree on an interface for the domBuilder to allow all of
these and other possibilities? Probably yes.
2.2) The binding information
The binding could be a java package / OLE server. tThe naming works well
XXXX.ZZZZZZ in the general case.
Does a package binding then imply a simple element to class mapping
mapping to menu.class within package myobjects
A more refined step would be to specify all the bindings in an XML file.
<FNelemmap elemName="menu" fnName="myobjects.menu">
So we could have a package binding and then optionally an instance map as
I think the main question to answer is do we have an inheritance or
delegation model. As others and myself have advocated, a delegation model is
more powerful and a superset of inheritance. If we were all working using
object lisp like systems then delegation would be the choice. However, most
people are not and delegation does not integrate seamlessly with java or
automation architectures. But it could be done.
my opinion is that the functional binding specification should be written to
allow for the definition of delegation structures with an additional
'strict' option - the dispatch order cannot be changed - to allow it to be
implemented as an inheritance structure.
4) Potential Use & Examples
1) The 'coins' use of XML and the 'run' method on the root object
demonstrates the use of XML as a transport and execution mechanism for
agents. This is a specialisation of the general pattern of serialise,
transport, rebuild and run. In this case the XML is the serialised form of
an example would be
so the binding would be from
element finder to finder.class, but finder.class would probably inherit from
the agent class.
Calling 'run' would delegate the call to the finder class that would then
execute. In the above case the agent would retreive a doc from a odbc
database and send it or an error message to the 'reportTo' port.
2) Alternatively, the functionality is combined at the destination to
provide a set of objects that are used the by the current application.
Consider a TP system
The TP system receivces this, binds the appropriate functionality and then
asks the transaction
trans.CommitToDataBase(OO DB name);
5) Where it can go..
Focus and contributions, organisation of thoughts; perhaps along some of the
lines outlined above.
A simple first step would be to define a domBuilder interface that could
support a variety of ways forward. Perhaps as these are developed it will
become clearer where to focus our efforts.
lets go do it..
gdm at dpsl.co.uk
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev