You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Matthieu Riou (JIRA)" <ji...@apache.org> on 2006/11/01 01:40:17 UTC

[jira] Resolved: (ODE-75) Separate configuration and runtime process representations

     [ http://issues.apache.org/jira/browse/ODE-75?page=all ]

Matthieu Riou resolved ODE-75.
------------------------------

    Resolution: Fixed

Done.

> Separate configuration and runtime process representations
> ----------------------------------------------------------
>
>                 Key: ODE-75
>                 URL: http://issues.apache.org/jira/browse/ODE-75
>             Project: Apache Ode
>          Issue Type: Improvement
>          Components: BPEL Runtime, Deployment
>    Affects Versions: Incubator
>            Reporter: Matthieu Riou
>         Assigned To: Matthieu Riou
>             Fix For: Incubator
>
>
> Right now the ProcessDAO is a mix of both configuration information (deploy date, custom properties, active/retired, serialized compiled process) and runtime information (instances, correlators) which isn't so nice. It's also the source of many deployment problems as we have some duplicate information between the filesystem (the deployed process bundles) and the database.
> To clean that up I'm going to introduce some sort of process configuration store (still haven't found a really impressive name for it). It would handle process deployment, maintaining these deployments over time (which involves redeployment or undeployment but could also be versioning in the future) and configuration changes. The runtime would use it to get information about processes currently deployed to activate them.
> That would both introduce a cleaner separation between runtime and static process definitions and would be much more in line with the deployment specifications. It would also make clustering easier as configuration could be easily propagated. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira