interesting communication
Valdes Faura Miguel wrote:
>
> Hi Tom,
>
> I was discussing with Guillaume this afternoon on the points covered
> during you last meeting in Turnhout. I so realized that you did a good
> progress together !
>
> I'm trying now to set up a development plan for the M2. This version is
> scheduled for mid december (just after JavaPolis) and will mainly add
> support for persistence.
>
> I understood that you have mainly finished the PVM refactoring (even
> main variables changes regarding Variables Scopes), so I think this is
> the right moment for us to speed up with our persistence prototype and
> to apply changes to both XPDL and BPEL extensions, right ? In this case
> I would like to know whether you have some plans to work on the PVM
> basics until JavaPolis ?? In this case we should created a branch,
> otherwise we can just work with the PVM snapshot !
for now, the only work i planned is dynamic resolution of variables and asynchronous execution. these are items on which guillaume is waiting.
if i want to do any other refactorings after that, i'll synchronize with you so that we can consider branching at that point.
> There is only one thing that I would like to check with you on the
> latest refactoring interfaces vs implementations of basic PVM entities.
>
> We think its a good idea to make this differentiation in terms
> of standardization. However, we see languages extensions to work with
> interfaces rather than with a particular implementation. Otherwise
> languages extensions are tight to a particular implementation.
you should ping for each case where the interfaces are not sufficient. and we will see how we will resolve it
but keep in mind that portability of workflow engine impl is not the goal of the interfaces. the interfaces are to avoid distraction for users. they should only see the methods that they are able to use. so it's more for the user's convenience then for portability.
portability for engines is not yet feasible, i think. the interfaces could become a basis for that if we happen to get to a JSR. but thinking that we can assume that the current interfaces will be standardized is too optimistic
> This not seems to be the intent right now. We are not allowed so to only
> work with interfaces in extensions because only getters methods are
> available.
all process definition data is read only in the interfaces. runtime data is read + update methods. that is the general idea
> What are the reasons for that ?? can we have a phone call tomorrow
> afternoon to discuss about that ?
>
> I will also take the chance in this email to start a discussion around
> other items:
>
> - In memory version of the PVM: we think would be great, for particular
> uses cases (i.e: job management language) to be able to run the PVM and
> services without persistence. Do you consider this use case important on
> your side ?
it's just a matter of implementing the persistence service, messaging service and the timer service in terms of maps, blocking queues and timertasks respectively. not much work. i think there is a start somewhere in the code for this.
> - Transaction and resources in the PVM are still not clear to me. I see
> a requirement to support multiple transaction types, i.e database, jms
> notifications... but I thought that even in an standard version we can
> leverage a Java Transaction monitor for that. What is the purpose of the
> current implementation in the PVM ?
there is no transaction monitor in standard java. i explained it to guillaume. please talk to him first.
> - We have been also discussing about the asynchronous services. Those
> ones will rely on jobs and in DB persistence of those jobs. So the
> asynchronous service can pick up a job from the database when getting
> the notification. I guess you decided to store jobs in the dabase to
> easily monitor and administrate them from external applications right ?
yes. so for the standard java as well as the enterprise java service implementations, the jobs will be stored in the db (persistence service). so the console can just look in the db (persistence service) to show the timers and messages.
the only difference will be the threading model. in standard java, we'll have our own job executor (guillaume had some good ideas for that). and in enterprise java, the threading model is delegated to JMS/MDB and ejb timers.
> - We have taken a look to the newest variables implementation and
> particularly Varibles Scope. We see pretty well how to leverage it in
> both XPDL (for local variables in nodes, even with propagation of
> variables) and in BPEL (inside BPEL scopes). Now time to start working
> on it...
the only thing i'm doing now is implementing the dynamic type resolution. that should be decoupled from the API. it's an implementation detail of the VariableMap. for now, you'll be only working with UnpersistableVariable's. Once my current work is done, process variables will be stored in many Variable subtypes and then guillaume can make them persistable
> - Guillaume told me about your plans to start ASAP working on the jpdl
> extension. He also pointed out that you could consider to refactor the
> PVM persistence if needed during the development of this extension. I
> think we will have similar requirements for both XPDL and JPDL so the
> best would be that you start ASAP on that to avoid DB schema changes
> when we are close to the v4 (planed end March 2008 on our side). What
> are your plans for JBPM 4 ??
i should be able to get jPDL done before february. first goal indeed should be to come to a stable database schema. but please, take into account some flexibility. just in case. it's hard to predict how much time i can find to actually work in it. e.g. today i didn't even get to opening eclipse :-(
> - I've also have a question related to Events, Guillaume told me about
> event propagation but I can't see the use case there instead on nested
> nodes...
i can easily put that in jPDL. or i can put it in PVM in a way that you can turn it off easily in XPDL.
