[ https://jira.jboss.org/jira/browse/JBPM-1242?page=com.atlassian.jira.plug... ] Tom Baeyens reassigned JBPM-1242: --------------------------------- Assignee: Tom Baeyens -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1242?page=com.atlassian.jira.plug... ] Tom Baeyens commented on JBPM-1242: ----------------------------------- Miguel, There is one more service to consider (TODO), which is the task service. So we'll have ProcessService for access to the process definition repository. ExecutionService for managing the runtime process executions. ManagementService for management operations such as looking at the job queues and perhaps statistics on avg time per environment block. TaskService for managing task lists. In all of the process languages XPDL, BPEL and jPDL, we need to start new process executions and we need to provide external triggers. The only argument I can detect in your explanation is that for vertical solutions, you might want to introduce a subset of that in one single interface. I don't think that 4 separate interfaces with very clear responsibilities is creating inconvenience. I want to cover all the jPDL and XPDL needs in those 4 interfaces. That should not be a problem. In fact, similar to how TaskService extends the base services for task management, BPEL could define a MessageService that handles incoming BPEL messages. If you add that idea into the mix, then we have a full API for those three languages already, covering 90% of all workflow/BPM usecases. Note that if you're exposing an API, you're always doing this to java developers. In that respect, the PVM APIs are not different from product API's. I can't see a functional difference in what the API's address. If you also take the TaskService into account, I think it should cover the future needs of XPDL, BPEL and jPDL. I'm sure that we can pull this off! If we can make sure that our products are based on one set of API's, we have a *very* good case for taking this to standardization body. However, if you hide the PVM API's behind your own product API's, then that whole case falls apart. Let's take this discussion a couple of iterations further. It is too important to let it fade away. Ah... and I don't think its necessary to prohibit backwards compatibility in your products. I think it is OK if you ship a backwards compatible API that sits in front. But only if it is clear to new users that the PVM APIs are the way forward. Then we can still make the case to standardization bodies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1242?page=com.atlassian.jira.plug... ] Tom Baeyens updated JBPM-1242: ------------------------------ Summary: publish api and docs (was: publish pvm api and examples online) Component/s: API (was: PVM) Description: docs should be split into userguide and developerguide the userguide contains the limited api that is supported and tested. the developerguide contains info on all kinds of customization possibilities that are not officially supported. was:to get more community feedback -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira