[Design of JBoss jBPM] - Re: various questions
by tom.baeyens＠jboss.com
"brittm" wrote : anonymous wrote : After all, users might think of a process instance as a "ticket" or a "request" or an "order", rather than as a process instance.
| That's really my point. Those business concepts are established prior to defining the process defs that serve them. By allowing the developer to specify a business entity /context for the key via jpdl, then the business entity that the process/execution is intended to represent is clear (and quickly and easily queryable).
|
| In the scenario I'm proposing, a keyable business concept is represented by one or more processes (definitions) --duh. The defs specify the concept or entity type they represent, and their executions reference the business key. The 'type' and 'key' together provide the necessary business context.
|
| To put it differently--The question is whether the business context (keyed entity representation) should be derived from the process name, some user table, or up front by configuration. If context is derived from the process name, the developer has to implement plumbing to map potentially several process names back to a business concept--and he has to do it everywhere--UI resource bundles, every imaginable report, etc. However, if business context is provided in process config the developer only has to specify it once--now the domain relationship is established.
|
| If an 'order' is only ever represented by a single parent 'order' process, then none of this is a big deal. However, if an 'order' can result in the execution of a 'New Customer Order', or a 'Change Order', or a 'Move Service Order', or a 'Cancel Service Order' process being started, then it becomes an issue, because all of these separate processes are probably still 'just an order' as far as business keys go.
|
| If my thinking is off base here, or too narrow, somebody slap me back on track :)
|
| -Britt
let me see if i get your point by proposing a solution:
ProcessInstances gets an new 'businessKey' property of type String. This property is added to the constructors. Such a business key is optional, but the combination (processDefinition, businessKey) must be unique if the businessKey is not null. (not sure if DB's support such a unique constraint)
Often the business key is a reference to some other object. So on the process definition you could specify a Converter that converts the String based business key into the referred object.
So on the ProcessInstance you would get 2 methods like this:
public String getBusinessKey();
public Object getBusinessObject();
The business key can be used in queries. I'm not sure if HQL can support the type differences between the text based reference and the typical number based PK of the referred table.
I think that even in this case, you could have multiple types of processes in 1 single process definition. Suppose that you have change orders and customer orders all being processed by the same process definition. In that case you could compose the business key like this:
"customerorder["+customerOrderId+"]" for customer orders and
"changeorder["+changeOrderId+"]" for change orders.
that makes the business key unique and still you can specify custom code to convert these business keys into the proper referred objects.
Britt, does this come close to what you were explaining ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4017487#4017487
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4017487
19 years, 1 month
[Design of EJB 3.0] - Funky config needed for extended PersistenceContext replicat
by bstansberry＠jboss.com
AFAICT, to get replication of an SFSB with an extended PersistenceContext to work, your persistence.xml needs to declare the "hibernate.session_factory_name" property, e.g.:
| <?xml version="1.0" encoding="UTF-8"?>
| <persistence>
| <persistence-unit name="tempdb">
| <jta-data-source>java:/DefaultDS</jta-data-source>
| <properties>
| <property name="hibernate.session_factory_name" value="tempdb"/>
| <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
| </properties>
| </persistence-unit>
| </persistence>
|
Without this, when the EntityManager is deserialized on the remote node, you get this:
| Caused by: java.io.InvalidObjectException: could not resolve session factory during session deserialization [uuid=8a8b8eac10c785e70110c788056b0001, name=null]
| at org.hibernate.impl.SessionFactoryImpl.deserialize(SessionFactoryImpl.java:1056)
| at org.hibernate.impl.SessionImpl.readObject(SessionImpl.java:1892)
| ... 78 more
|
To avoid the IOException, Hibernate needs a name for the factory, which is provided via the property. But having to specify that property seems funky. Could the value of the persistence-unit element's name attribute be passed to the SessionFactory as its name?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4017398#4017398
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4017398
19 years, 1 month
[Design of JBoss jBPM] - Re: various questions
by alex.guizar＠jboss.com
I see a number of similarities between the proposed business keys in jPDL, natural IDs in Hibernate and correlation sets in BPEL.
"Hibernate Reference" wrote : A natural key is a property or combination of properties that is unique and non-null. [...]Hibernate will generate the necessary unique key and nullability constraints
"BPEL4WS 1.1" wrote : Each correlation set is a named group of properties that, taken together, serve to identify an application-level conversation within a business protocol
| instance.
Notice the "combination" or "group" of "properties" references and the association to the identity of an instance. In both cases, the name and type of the properties are defined by the user.
Correlation sets exist due to the opaque nature of the instance id. Conversely, natural-ids and business keys are convenient, user-defined handles to the instance id.
Adding a "businessKey" property to the ProcessInstance class is not the way to go, because its name and type would not be defined by the user anymore. Further, composite business keys would not be possible anymore.
I see three ways:
1. Take Jeff's suggestion. Developers subclass ProcessInstance, add properties to the subclass and define natural-ids on them.
-> Subclassing ProcessInstance might not be desirable. Further, jBPM would neither be able to provide an API to get the business key(s) associated with a process instance, nor retrieve the process instance given a business key.
2. Create a BusinessKey class. Define a bidirectional association between one ProcessInstance and many BusinessKeys. Developers subclass BusinessKey, add properties to the subclass and define natural-ids on them.
->jBPM would be able to provide an API to get the business key(s) associated with a process instance, but not retrieve a process instance given a business key.
3. Create a BusinessKey class. Define a bidirectional association between one ProcessInstance and many BusinessKeys. Developers add properties to a map in BusinessKey.
->jBPM would be able to provide an API to get the business key(s) associated with a process instance *and* retrieve a process instance given a business key. However, lookups by business key cannot be fast, as Britt wants, because property values are stored in rows rather than columns.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4017377#4017377
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4017377
19 years, 1 month
[Design of JBoss jBPM] - Inheriting from ProcessDefinition
by alex.guizar＠jboss.com
The class org.jbpm.graph.def.ProcessDefinition describes jPDL processes. Some of its properties are useful for BPEL processes as well. Some of these properties are *not* useful for BPEL and merely bloat ProcessDefinition instances that describe BPEL processes. Further, BPEL processes require some additional properties not defined by ProcessDefinition.
Unlike Node, ProcessDefinition does not have subclasses in the jPDL model and does not define a discriminator. This prevents inheritance using the table per class hierarchy strategy. There are at least two ways to work around that limitation:
1. Use table-per-subclass (i.e. an additional BPEL_PROCESSDEFINITION table)
2. Override the default ProcessDefinition mapping with an alternate mapping that contains the same properties and adds a discriminator
So far (2) has been the option of choice, as a few extra fields in the JBPM_PROCESSDEFINITION table do not seem to justify the table join overhead imposed by (1). However, (2) has a big drawback: the alternate mapping can get out of sync with the default mapping.
I'm looking for a way to avoid overriding the default ProcessDefinition mapping. The options, in increasing order of complexity, are:
0. Do nothing. Keep synchronizing.
1. Switch to table-per-subclass.
2. Add the discriminator to the ProcessDefinition mapping, even if unused in jBPM jPDL.
3. "Pull up" the fields from BpelDefinition to ProcessDefinition.
->In this regard, jPDL has an edge over BPEL because it can add properties to the core graph objects even if they don't make sense for BPEL. Since the BPEL subproject resides in a separate codebase, it is not just as easy.
4. Abandon inheritance for aggregation.
->Perform complex refactoring to move the fields and methods from BpelDefinition to a new ModuleDefinition.
5. Introduce an "AbstractProcessDefinition" class.
->This implies analyzing each occurrence of ProcessDefinition in the jBPM codebase to determine whether it means "generic process" or "jpdl process".
With the PVM in sight, (4) and (5) are not worth the effort. (1) or (2) seem fair. What do you think?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4017320#4017320
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4017320
19 years, 1 month