[Cobold-developer] towards a whitepaper

[joern t. <joe...@we...>]

Hi *,

i'd like to initiate the next step in the discussion about the cobold 
platform. since a lot of issues, thoughts and wishes have been gathered 
its about time to transform these into a more structured document which 
may become the first whitepaper/documentation of the system.

although we all have some very concrete ideas in our heads that's still 
the problem - there still in our heads and not written down somewhere 
for reference. therefore it seems valuable to gather the fragments we 
have and form them into a new more elaborated structure for further 
development. we may e.g. share the document via sourceforge simply as an 
openoffice document.

i've another thought in mind when proposing this document: since we have 
a lot of ideas these still have to be structured to become one whole 
thing. i've recently read an article about how software is build in the 
aviation industry where highest reliability and robustness is needed; 
they first implement all testcases of the system *and* the complete 
documentation! then coding is started  with clear, well documented 
requirements. of course, this is an extreme, but a bit of it may be 
helpfull for us now. - in documenting the details of how our system 
should behave and be used in future we fix the requirements by the way. 
this is quite the same viewpoint like that of a test but from a higher 
perspective - you look from outside and define how the system should 
look and behave.

i think we already discussed a document structure and should restart 
this. anybody?

now some content:
in the meantime i've learned that the common wording for what we've 
named 'usecase realisation' maps quite good to the term 'process 
definition' which seems to be common in business process modelling.

free citation:
process modelling is the activity which analyses a business and 
translates these into a set of activities and transitions (a process model).

so a process definition seems to be the missing part which we need to 
formalize our autmated process. - and of course we'd like to express it 
in XML.

the process model is expressed in terms of UML activity diagrams cause 
these already provide all needed constructs like
- activity
- transition
- conditional
- forks and joins in transitions
- loops

the neat advantage of this is quite clear. you can use any UML tool to 
define the business process and as long as it supports XMI it should be 
easy to transform the diagram into a process-definition.

i won't go into detail about the possible structure but i have a good 
proposal for that on my desk if you like the overall idea.

if this model will be adopted we'll need a process-engine which works on 
the process-model and manages the flow. here we come back to 
XForms/Chiba and i guess that its would be possible to express/transform 
the process-model into one (or a set of related ones) XForms.

in this case there will be a layer (lets call it ProcessEngine in 
contrast to XFormsProcessor) which is responsible to start business 
processes by loading some specified xforms and maybe routing data 
between several different forms in more complex scenarios.

'below' this layer there will be the xforms processor which executes the 
details of a activity as described by the processmodel. for this to be 
possible, the xforms processor must be able to make use of services 
(like fetching some data from a db). these should perfectly be possible 
with the current implementation via connectors.

much more could be said but this should be enough for today.

comments?

cheers,

Joern