-
1. Re: Roadmap for RiftSaw 3.0
+1 for 3.0 as our next major release, but I suppose we still need subsequent release for 2.0 work, which is based on ODE 1.3.3. Right? -
2. Re: Roadmap for RiftSaw 3.0
Thats what we need to decide - do we want to do a 2.1 release sometime next year on ODE1.3.x, or is it better to concentrate on delivering the next main release.
One possible reason for doing a 2.1 might be clustering or cxf support? If these could be implemented early on, and are more or less independent of whether it is ODE 1.3.x or ODE 2.0, we could possibly do an earlier release?
-
3. Re: Roadmap for RiftSaw 3.0
I think we will need 2.1 release unless ODE released 2.0 GA quick enough. As you suggested, we might need to evaluate what features might be indepedent for ODE 1.3.3 and 2.0, and then decide which features implemented first, currently the 1.3.3 seems more mature than 2.0, and frankly, I don't know when is scheduled for ODE 2.0 GA. So in terms of our release early, release often, we might have to stick to ODE 1.3.3 for a next one or two release?
-
4. Re: Roadmap for RiftSaw 3.0
I have the following questions / comments:
* Migration to ODE 2.0
* Migration to JPA+Hibernate, and provide associated db migration toolswhat is provided in 2.0?
* Mavenize ODE project
* CXF supportESB does not currently support so probably should be supported when they do?
The following are from the current roadmap page in terms of 'future' features:
* Clustering on JBoss AS
* BPMN's relationship to BPELwhat is this?
* BPEL4People- Yes, we need to support human tasks as part of a service orchestration. This help round out the offering.
* WS-HTYes - see below
* WS-* (which spec: security definitely, but others?)ReliableMessaging?
* BAM
Is this a separate project and Riftsaw would interface to to provide events?
* Java binding (orchestration Java components)No, I don't think this is needed. It is not part of BPEL or associated specs, and can be accomplished with other BPM products / specifications. Java components can be exposed as web services via ESB features. BPEL is for orchestrating Web services.
* JMS binding (orchestration of JMS components)
No. I don't think this is needed. - same as Java binding.
We also need to consider which tasks should ideally be done in collaboration with the other projects:* It would seem to make sense to work on a BPEL4People solution as part of the ODE project
* JBossWS independent JAX-WS solution that could be contributed back to ODE?
* WS-HT support - Drools or HISE or both?I think we should use the Drools implementation. It appears to be working in limited fashion (though not yet exposed as WS). Since it is JBoss project it is easier to consume, influence, etc.
-
5. Re: Roadmap for RiftSaw 3.0
* Migration to JPA+Hibernate, and provide associated db migration tools
what is provided in 2.0?
If you mean in terms of migration tools? ODE 2.0 will probably provide a migration utility between its OpenJPA schemas, from 1.3.3 to 2.0. But pure JPA, with hibernate, is something we are adding. Migration from hibernate schema in 1.3.3, to JPA+hibernate in ODE 2.0, is something specific to RiftSaw, so we will need to provide our own migration schema. Not sure if something generic could be written using the DAO objects - will have to see.
* CXF support
ESB does not currently support so probably should be supported when they do?Hopefully, but we won't know if there are any jbossws-cxf specifics that need to be handled when deploying the BPEL processes.
* BPMN's relationship to BPEL
what is this?
Can't remember to be honest - I think it was a placeholder before we started discussions on the wider BPM platform. I don't think RiftSaw needs to have any BPMN related functionality, so we could probably drop this, unless others think there are some BPMN related features required here.
* BAM
Is this a separate project and Riftsaw would interface to to provide events?
Good point - I think this would be part of the BPM console, but not sure whether we would need to specify what type of reports should be generated etc - and whether we would need to implement those within the BPM console framework?
* JMS binding (orchestration of JMS components)
No. I don't think this is needed. - same as Java binding.Its possible that this could be achieved through CXF anyway - but take your point.
I think we should use the Drools implementation. It appears to be working in limited fashion (though not yet exposed as WS). Since it is JBoss project it is easier to consume, influence, etc.
One point to factor in is how the BPEL4People may work - if done as part of the ODE project, this would need to integrate with HISE - not to say it could not also integrate with other WS-HT projects.
-
6. Re: Roadmap for RiftSaw 3.0
If I could chime in as an early adopter with a suggestion, an early minor release with WS-Security support (https://jira.jboss.org/jira/browse/RIFTSAW-75) should be top priority.
Lack of WS-Security support is a show stopper for most usage scenarios.
-
7. Re: Roadmap for RiftSaw 3.0
Hi Aleksander
WS-Security support has already been moved to 2.1.
Regards
Gary