What would your extensions to JDPL look like?
I would like to add to this thought by suggesting extensibility that would allow one to map extra attributes to a Task node. This would then map to a custom TaskInstance.
what kind of extra attributes? The reason I ask this is that to much generic functionality make the core engine way to difficult.
I cannot speak for Martin's request, but could it be possible for the Jpdl Deployer to use reflection on the custom TaskInstance class to determine what the xml attributes/tags defined in a task node would mean? This would likely only be for translating Strings.
As far as other extensions (per the original question), it would be more difficult. I do believe however that one can add xml snippets within certain node types (e.g. action nodes?)
Finally, I am not familiar with the BPEL specs so these customizations might not map to that spec.
Right now, there are already several elements that can or must be provided with a custom implementation:
and, using a different method of looking up the specific implementation class,
For these elements, a mechanism is provided to supply additional configuration data. Citing an example from the user guide:
<action class="org.test.MyAction"> <city>Atlanta</city> <rounds>5</rounds> </action>
To state my question more clearly, I want to break it into two separate ones:
1. How do you tell the jpdl parser what kind of elements "city" and "rounds" are, so that the parser can check the contents according to a schema? Right now, I only get it to run by completely disabling schema validation.
2. Why not making jpdl process definitions more flexible by allowing that all jpdl elements may be extended by application specific implementations? In particular, I would like to put a user readable description into each transition. Technically, this would mean to just add a string attribute via a custom subclass of transition.
The first question is plainly about the usage of currently available features. The second question is a feature request which seems quite logical from my view. I just see it as applying object orientation to the elements of a process definition. I like jpdl the way it is - with not too many features only necessary for specific contexts. Instead, it confines to including only a reasonable subset of what should be meaningful in all applications. The only thing that is missing is a way to add those few bits that are special about a certain application context.
It looks to me these are very valid points. The xsd/validation stuff is not yet as it should be. Why not file a JIRA issue?
it's entirely natural to need to inject custom metadata into node.action definitions. writing custom java classes to implement node semantics is krazy. the modern way is to write a single class, driven by metadata.
as for instance, our architecture uses application services to implement user actions. we currently inject our metadata into the XPDL Activity model using the Activity.ExtendedAttribute element. we define how variables in context are mapped to IN/OUT/INOUT parameters to java services. this enables our mvc2 implementation. an Activity can support multiple user actions.
my point is that one of the main benefits of a 'Process Definition Language' is the ability to design a process using meta-data rather than writing java classes. a mechanism that parses custom metadata into some model (hashmaps, document, etc.) would be beneficial.