[Design of OSGi Integration] - Re: Current roadmap
by david.lloyd＠jboss.com
OK, I'm resigned to the fact that I'm not going to have time to do this. So my parting thoughts are:
1. OSGi metadata should not extend manifest metadata. Manifest metadata should be a separate thing altogether - there are probably more than one deployment type that might make use of it, and by having OSGi metadata extend manifest metadata, you implcitly disallow more than one deployer to make use of the manifest. Instead the manifest metadata should be transformed into OSGi metadata, which is not implementation-dependent on the manifest (which makes it easier to programmatically generate).
2. Once the above is done, I think this might be easier to accomplish using regex - a simple static method to identify and transform manifest into OSGi metadata.
3. This also leads to the conclusion that there is (again) no point to having an OSGi metadata implementation which is not just a plain bean-style POJO.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210492#4210492
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210492
17 years, 1 month
[Design of JBoss jBPM] - Re: task assignee vs owner
by kukeltje
I agree with Kris and Bernd regarding the WS-HT usage and plugability
Although I'm also partly with Tom that if you can write almost 1MB of specs about 'task management' it is complex. Secondly (and there may be 'workarounds') I dislike the WS-* nature of it. Makes it way to complex imo. I want xsd's not wsdl's
Bernd wrote :
| Kris wrote :
| | you are confronted with logic that could best be represented using a business process and other logic where you would like to use rules. So in that sense it makes sense to integrate them.
| |
|
| I agree on that. This is why integrating jbpm and drools is a very good idea! But I would keep seperation of concers, so state chart in jbpm and rules in Drools.
|
|
Yes, integrate them in the SOA platform, not in one project. But politics.....I've never had a problem integrating jBPM and Drools in one application. I did not use either of their deployment methods and just bundled them in versions of applications. Works great (multiple versioned webapps related to processes/rules is a much more complex problem)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210481#4210481
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210481
17 years, 1 month
[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1
by bstansberry＠jboss.com
"bstansberry(a)jboss.com" wrote : "emuckenhuber" wrote : Hmm is the DeploymentManager enough for you then?
|
| Not sure about the overall scope of this question, so I'll reply separately. ;)
|
OK, now a bit more on the DeploymentManager in general and how it relates to the clustered deployment repository I'm working to get into 5.1. Basically my goal for 5.1 was to restore an equivalent to the old "Farm" feature where a local-filesystem based repository is aware of changes in content and replicates the changed content around the cluster. Primary target is people updating the repository content by copying a new version of a deployment into a directory.
The DeploymentRepository.addDeploymentContent() method will also trigger replication around the cluster. So, if a DeploymentManager client loaded the "farm" subprofile and then called distribute(name, phase, url, true) the net result would be the content would be replicated to all nodes in the cluster. But, that wouldn't result in it getting deployed in all nodes, since that's a separate step. Getting it deployed in all nodes would require a clustered DeploymentManager impl, which isn't in the cards for 5.1. So, kind of half-way there.
Bottom line, I think a tool written against the 5.1 code base would be better off independently working with each of the nodes in the cluster; i.e. let the tool coordinate getting the content distributed to and deployed on all nodes. Let the clustered deployment repository be the replacement that people have requested for the non-tooling based Farm service.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210480#4210480
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210480
17 years, 1 month
[Design of JBoss jBPM] - Re: task assignee vs owner
by camunda
Heiko wrote :
| Either you go for WS-HT or you don't. But it doesn't make sense to rip it apart and customize bits and pieces. You'd loose the benefit of the specification in the first place.
|
I do not agree.
Kris wrote :
| I don't think that you should either go for WS-HT or not at all
|
My opinion too! To support WS-HT is a good thing if you need a task component which supports WS-HT or if you want to use that as central HT component in your SOA.
But a lot of use cases face different requirements and there you need to adapt task lifecycle for your needs (but break WS-HT).
Kris wrote :
| you are confronted with logic that could best be represented using a business process and other logic where you would like to use rules. So in that sense it makes sense to integrate them.
|
I agree on that. This is why integrating jbpm and drools is a very good idea! But I would keep seperation of concers, so state chart in jbpm and rules in Drools.
Ehm, and sorry Tom for somehow hijacking this thread ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210477#4210477
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210477
17 years, 1 month
[Design of JBoss jBPM] - Re: task assignee vs owner
by KrisVerlaenen
anonymous wrote : anonymous wrote : +1 for the shared task component supporting WS-HT (but not being tied to it, means having a pluggable life cycle). Kris, is there an easy example using your task component and how to change life cycle?
| |
|
| Either you go for WS-HT or you don't. But it doesn't make sense to rip it apart and customize bits and pieces. You'd loose the benefit of the specification in the first place.
Bernd, while we have tried to take into account that the life cycle might need to be pluggable in our design, we didn't really put a lot of focus on it, hence we don't have examples or documentation on how to change it. But I guess you could take a look at the implementation of our TaskServiceSession. Generic documenation on our human task service (work in progress) can be found here:
https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/t....
I don't think that you should either go for WS-HT or not at all, as the implementation is fully pluggable (meaning that the process engine should be able to work with different implementations). It just means that by default you could follow the WS-HT spec, but in cases where people want to change it, you could provide the hooks that enable them to do that. But then they are responsible.
Kris
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210445#4210445
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210445
17 years, 1 month