[TransWarp] HowTo TreeBased Storage with RecordManagers / Specialists ??

[Phillip J. Eby]

At 12:21 PM 5/10/02 +0200, Ulrich Eck wrote:
now let me start asking again:

>I'm working on my Workflow Engine, that should store it's data in an 
>LDAP-Directory.

I'm curious why something as complex as an LDAP directory, as opposed to 
something simple, like text files.  :)


>The DataModel is taken from Wfmc.
>
>The data is arranged as followed:
><WorkflowEngine>
>  |-<DataFieldDefinition>                0-n DataFields
>  |-<ParticipantDeclaration>             0-n Participants
>  |-<ApplicationDeclaration>             0-n Applications
>  |-<ProcessDefinition>                  1-n ProcessDefinitions
>     |-<DataFieldDefinition>             0-n DataFields
>     |-<ParticipantDeclaration>  0-n Participants
>     |-<ApplicationDeclaration>  0-n Applications
>     |-<ActivityDefinition>              2-n Activities
>     |-<TransitionDefinition>            2-n Transitions
>
>Definitions in a Package are considered as global for all WorkflowProcesses.
>Definitions in a Process are consideres as local to the Process.
>Local Definitions need unique indentifiers .. but they may be reused within
>other Processes.
>
>I'ld like to store the data as shown above in the LDAP-Directory.
>here it happens, that i cannot use a fixed baseDN for a certain recordType
>because an Activity could be defined below ProcessA or another one.

Sure you can, as long as there's a unique identifier - either application 
generated, or the DN will do in a pinch.


>I have thought of arranging the objects as following:
>
><ProcessSpecialst>              supplies Process-Elements
>  <ProcessElement>
>    <ActivitySpecialist> supplies Activities (generates it's baseDN from 
> some info of 
> it's                                                               parent 
> Element)
>    <TransistionSpecialist>      supplies Transitions ...
>
>so i would place Specialists into Elements, and the behaviour of them 
>would depend on the Element's
>data. I would need to modify the Specialists code to make the keyConstants 
>dynamic .. which should not be too hard i think.
>Is there a better way to achieve Tree-like storage using TW.Database 
>(especially LDAPModel) ??

Yes, definitely, if by better you mean "preserves the abstraction of the 
storage layer".

Set up the specialists in the conventional way using unique keys (either 
generated, or the DN).  Define features that refer to collections of child 
items.  Add "domain-specific query" methods to the specialists and to the 
LDAPModel that return a list of items which are the child of some other 
item.  Have the feature call the Specialist's method to return its 
collection, and the Specialist of course will call the LDAPModel.

More specifically...  Let's say you want to get field definitions for a 
process.  Add to your RecordType a method getFieldDefsForProcess() which 
takes the DN or unique ID of the process, and searches for records in the 
LDAP directory.  It can then map each result into a Record object, using 
the same techniques as a single-record query does.  It then returns a 
collection of Record objects.

The specialist for field definitions will also have a 
getFieldDefsForProcess() method, which will call the LDAP model and wrap 
the records in Elements, using its cache to ensure that it returns existing 
Elements if available.

Finally, create a collection feature "dataFields" in the Process element 
class which retrieves its value by calling the specialist's 
getFieldDefsForProcess() method.

Admittedly, this process probably involves a bit more coding than you had 
in mind.  This is mainly because I haven't done any of these myself yet, 
and so I haven't yet added helper methods to Specialists, Features, and 
RecordTypes to do the grunt work of these things for you.