I've tried to highlight issues and alternatives, and where I feel strongly=20
espress my opinion=2E
So, here is an
1) Overview of what it is we are trying to achieve
2) Issues with Naming and Defining the association
3) Implementation
4) Potential Use - With Examples
5) where it can go
1) Overview
To standardised the procedure of associating functionality with a seriliase=
d=20
object structure=2E
Traditionally, objects have had the abiliy to serialise and unserialise=20
themselves=2E The difference now is that with self describing serialised=20
object structures the potential exists to associate different functional=20
views with the same data object=2E
The way in which
a) the binding between the functionality ( functional object ?) and the=20
object data is specified=2E
b) this is implemented
are the problems we are trying to solve=2E
2) Issues
2=2E1) 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=20
these and other possibilities? Probably yes=2E
2=2E2) The binding information
The binding could be a java package / OLE server=2E tThe naming works wel=
l=20
with both
oleServerName=2EautomationObjectName
javaPackageName=2EClassName
XXXX=2EZZZZZZ in the general case=2E
Does a package binding then imply a simple element to class mapping
e=2Eg=2E
<menu>
=2E=2E=2E=2E=2E=2E
</menu>
mapping to menu=2Eclass within package myobjects
A more refined step would be to specify all the bindings in an XML file=2E
<FNelemmap elemName=3D"menu" fnName=3D"myobjects=2Emenu">
So we could have a package binding and then optionally an instance map as=
=20
well=2E
3) Implementation
I think the main question to answer is do we have an inheritance or=20
delegation model=2E As others and myself have advocated, a delegation model=
is=20
more powerful and a superset of inheritance=2E If we were all working using=
=20
object lisp like systems then delegation would be the choice=2E However, mo=
st=20
people are not and delegation does not integrate seamlessly with java or=20
automation architectures=2E But it could be done=2E
my opinion is that the functional binding specification should be written t=
o=20
allow for the definition of delegation structures with an additional=20
'strict' option - the dispatch order cannot be changed - to allow it to be=20
implemented as an inheritance structure=2E
4) Potential Use & Examples
1) The 'coins' use of XML and the 'run' method on the root object=20
demonstrates the use of XML as a transport and execution mechanism for=20
agents=2E This is a specialisation of the general pattern of serialise,=20
transport, rebuild and run=2E In this case the XML is the serialised form o=
f=20
the application=2E
an example would be
<finder id=3D"1">
<odbcConnection>dynamciHTMLServer</odbcConnection>
<reportTo><ip>x=2Ex=2Ex=2Ex</ip><port>5656</port>
<cond>where name=3D'index=2Ehtml'</cond>
</finder>
so the binding would be from
element finder to finder=2Eclass, but finder=2Eclass would probably inherit=
from=20
the agent class=2E
Calling 'run' would delegate the call to the finder class that would then=20
execute=2E In the above case the agent would retreive a doc from a odbc=20
database and send it or an error message to the 'reportTo' port=2E
2) Alternatively, the functionality is combined at the destination to=20
provide a set of objects that are used the by the current application=2E=20
Consider a TP system
<trans>
<basket>
<item>=2E=2E=2E</item>
<item>=2E=2E=2E</item>
<item>=2E=2E=2E</item>
<item>=2E=2E=2E</item>
<item>=2E=2E=2E</item>
</basket>
</trans>
The TP system receivces this, binds the appropriate functionality and then=20
asks the transaction
trans=2EcalculateTotal();
trans=2EcalculateOfferReduction();
trans=2ECommitToDataBase(ODBCConnection);
trans=2ECommitToDataBase(OO DB name);
etc
etc=2E
5) Where it can go=2E=2E
Focus and contributions, organisation of thoughts; perhaps along some of th=
e=20
lines outlined above=2E
A simple first step would be to define a domBuilder interface that could=20
support a variety of ways forward=2E Perhaps as these are developed it will=
=20
become clearer where to focus our efforts=2E
lets go do it=2E=2E
graham=2E
gdm@dpsl=2Eco=2Euk