sessions and services

[tom.baeyens]

during pierre's visit an inconsistency came up with the naming of session and service. i have renamed the code according to the following guidelines:

All resources (optionally transactional) that should be used inside of an environment block are called Sessions. This is because they are at the same level of e.g. a hibernate session.

PersistenceService was renamed to PvmSession
TimerService was renamed to TimerSession
MessageService was renamed to MessageSession
LogService was renamed to LogSession

the package org.jbpm.svc was renamed to org.jbpm.env.session

All session facade interfaces that are based on the command executor pattern will be called services. E.g.

CommandExecutor was renamed to CommandService.

Let me know if you find any other inconsistencies or local variable names that i might have forgotten to update.

[porcherg]

Here are some comments about the sessions and services refactoring:

- In the org.jbpm.env.session package, we find Timer, Job, Message classes. These classes are not related to sessions maybe they can be moved to the org.jbpm.jobexecutor package.

- org.jbpm.jobexecutor.JobService is a session, and this is an implementation that depends on hibernate. Maybe we can create a interface org.jbpm.env.session.JobSession for this session. The JobService class can be renamed to HibernateJobSession and moved to the org.jbpm.env.session.hibernate package.

- in org.jbpm.jobexecutor, the implementation of TimerSession and MessageSession have not been renamed (StandardTimerService and StandardMessageService)

- the findTimers method is in the TimerSession and in the PvmSession interfaces, we can remove it from the PvmSession.

- why was the PersistenceService interface renamed to PvmSession ? (the NAME field has not been updated). Some methods in this interface (save, lock, get, delete) are related to the persistence. Was this class renamed to PvmSession because the queries (findProcess) return pvm objects ?

regards,
Guillaume

[tom.baeyens]

"porcherg" wrote:
- In the org.jbpm.env.session package, we find Timer, Job, Message classes. These classes are not related to sessions maybe they can be moved to the org.jbpm.jobexecutor package.

From an API perspective, they are defined by the MessageSession and the TimerSession and therefor part of that API. That's why i have put them there.

"porcherg" wrote:

- org.jbpm.jobexecutor.JobService is a session, and this is an implementation that depends on hibernate. Maybe we can create a interface org.jbpm.env.session.JobSession for this session. The JobService class can be renamed to HibernateJobSession and moved to the org.jbpm.env.session.hibernate package.

yes. i created http://jira.jboss.com/jira/browse/PVM-15

"porcherg" wrote:

- in org.jbpm.jobexecutor, the implementation of TimerSession and MessageSession have not been renamed (StandardTimerService and StandardMessageService)

Correct, i've added that to http://jira.jboss.com/jira/browse/PVM-15

"porcherg" wrote:

- the findTimers method is in the TimerSession and in the PvmSession interfaces, we can remove it from the PvmSession.

probably that can be removed. but do consider the consoles. the consoles need to be able to show all timers and messages in a way that is the same for the jobexecutor (messages and timers) as well as the enterprise variants (ejb timers and jms messages).

you have a point, but i don't know yet what would be the best interface for the consoles. if you have a good solution for that, you can just implement it is you want.

"porcherg" wrote:

- why was the PersistenceService interface renamed to PvmSession ? (the NAME field has not been updated). Some methods in this interface (save, lock, get, delete) are related to the persistence. Was this class renamed to PvmSession because the queries (findProcess) return pvm objects ?

that rename was done to have a name that would be analogue as to all the other sessions. it's about pvm objects. maybe more correct would be PvmDbSession since it's targetted at relational DBs, not persistence in general.

you have shown that you understand the naming strategy as it is intended. do you have a proposal for a name that is better in sync with the rest of the naming ?