Hi Mark,
I am working on a few use cases that will illustrate how deployment is going
to work in BPEL Designer.
One quick question in order to make sure the use cases cater for jBPM's
requirements:
Assuming the editor will offer a preference page allowing users to configure
transfer mechanism (FTP, SFTP) and location (some URL), what kind of
information would you need in order to automate deployment/have
click-of-a-button deployment?
Also, would it make sense to get one of your jBPM guys involved on the list
so that we can discuss things as they come up over the next couple of weeks?
Many thanks,
-- Bruno
-----Original Message-----
From: Mark Little [mailto:mark.little@xxxxxxxxx]
Sent: 29 April 2006 08:14
To: B.Wassermann; BPEL Designer project developer discussions.
Subject: Re: [bpel-dev] Offer of donation of WS-BPEL implementation to
assist project development
Hi Bruno. I checked with the guys developing jBPM and here are some
answers for you.
"
- How is deployment going to work (hot-deployment? files &
data required by deployment archive)?
"
we support hot deployment. a zip file is uploaded to a servlet. the
zip file contains the bpel and wsdl files.
"
- Are there published interfaces to run jBPM's deployment
validation or part thereof programmatically?
"
afaik, not at this point. but that should not be hard to do.
"
It is worth to think carefully about jBPM's requirements on deployment
within the BPEL Designer so that the corresponding runtime extension
point will cater for its needs. We should probably also work on a set of
somewhat detailed use cases describing deployment in BPEL Designer to
allow more detailed discussion and let everyone know what to expect.
"
we have found that uploading a zip file through a servlet is the most
flexible deployment mechanism.
"
We (at University College London SSE http://sse.ucl.ac.uk/omii-bpel)
currently offer the ActiveBPEL engine to computational scientists and it
would be great to be able to have jBPM-BPEL as a potential alternative
as this would demonstrate that, when you need to rely on open-source
enactment environments (in academia), it doesn't all stand or fall
because of a single suitable engine.
"
we are defenitely worth the consideration. our implementation,
commitment to standards and developer friendly focus make all our engine
very suitable. also our license terms are a lot more flexible then
ActiveBPEL's.
"
We (UCL SSE folks) can offer to stress test jBPM to its limits and
beyond with some seriously large-scale workflows to determine and
hopefully help to improve its scalability characteristics.
"
That would be awsome.
Mark.
Bruno Wassermann wrote:
Hi,
Another open-source BPEL engine integrated within BPEL Designer sounds
fantastic!
There are a few pieces of info about jBPM's characteristics that would
help facilitate its integration into BPEL Designer:
- How is deployment going to work (hot-deployment? files & data
required by deployment archive)?
- Are there published interfaces to run jBPM's deployment validation
or part thereof programmatically?
- (That's all I can think of right now).
It is worth to think carefully about jBPM's requirements on deployment
within the BPEL Designer so that the corresponding runtime extension
point will cater for its needs. We should probably also work on a set
of somewhat detailed use cases describing deployment in BPEL Designer
to allow more detailed discussion and let everyone know what to expect.
We (at University College London SSE http://sse.ucl.ac.uk/omii-bpel)
currently offer the ActiveBPEL engine to computational scientists and
it would be great to be able to have jBPM-BPEL as a potential
alternative as this would demonstrate that, when you need to rely on
open-source enactment environments (in academia), it doesn't all stand
or fall because of a single suitable engine.
We (UCL SSE folks) can offer to stress test jBPM to its limits and
beyond with some seriously large-scale workflows to determine and
hopefully help to improve its scalability characteristics.
Regards,
-- Bruno
------------------------------------------------------------------------
*From:* bpel-dev-bounces@xxxxxxxxxxx
[mailto:bpel-dev-bounces@xxxxxxxxxxx] *On Behalf Of *James Moody
*Sent:* 28 April 2006 18:14
*To:* BPEL Designer project developer discussions.
*Subject:* Re: [bpel-dev] Offer of donation of WS-BPEL implementation
to assist project development
Hello Mark,
This looks very interesting! From the jBPM-BPEL roadmap that you
outline below, it looks like your dates will line up nicely with those
of this project (allowing of course for whatever changes are necessary
when WS-BPEL 2.0 is completed). I believe this move will certainly
benefit the community.
I'm not a lawyer so I won't comment on the license-related issues,
except to say that we should get the Eclipse IP person/people to take
a look and confim that it makes them happy.
Bruno: as you've taken a look at the issue of a runtime framework, I'd
appreciate it if you could add any comments here.
Let's continue the discussion here of how to proceed on the design of
this framework and how to carve up the work among those involved.
Thanks,
james
bpel-dev-bounces@xxxxxxxxxxx wrote on 04/27/2006 05:05:23 AM:
We know that the Eclipse-BPEL project is looking for a WS-BPEL 2.0
engine with which to test. After some discussion within JBoss, it seems
to us that in the interests of the community as a whole, it might make
sense for JBoss to donate our jBPM-BPEL runtime for use within the
project: essentially for this implementation to become the reference for
Eclipse in the event that other projects have a similar need. jBPM-BPEL
is licensed under terms that closely approach LGPL except for certain
amendments required to comply with the IPR statements known to the OASIS
WS-BPEL TC. Therefore, it should not pose any problems with inclusion or
use by Eclipse. Because we think this is so important for the community,
we've spent the last few days looking at the group requirements and
trying to match them (or vice versa) with the current jBPM development
goals. As you can see outlined below, we think that this represents a
good opportunity to catapult the Eclipse-BPEL work forward by several
months and allow the group as a whole to concentrate on higher-level
aspects of BPEL design and use, which will benefit all of our users.
It appears that these are the current Eclipse BPEL milestones:
M0: December 15
M1: View Only. January 31
M2: View and Author simple, exercise extension points. March 7
M3: View and Author complex, and Validate. May 15
M4: Deploy and Debug a process to the reference runtime. July 1
M5: Verify deployment and debug to proprietary runtimes. August 15
M6 (1.0): Exercise Activity extension. October 1
The jBPM-BPEL product roadmap has monthly beta releases and a GA release
at the end of Q2 covering the public review draft of the BPEL
specification due for release in May.
jBPM BPEL 1.0 beta 1 31/Mar/06
jBPM BPEL 1.0 beta 2 28/Apr/06
jBPM BPEL 1.0 beta 3 26/May/06
jBPM BPEL 1.0 23/Jun/06
Once 1.0 GA is out, we will track the specification review process to
incorporate changes while building new features. Such features include
communication with the BPEL designer and support for non-normative Web
Services standards.
After the OASIS TC finalizes WS-BPEL 2.0 somewhere in Q4, we intend to
release another GA version with full support as quickly as we can.
Obviously our current release plans are based purely on this being done
within JBoss, i.e. resourced entirely by JBoss staff and community
members. However, if the Eclipse group accepts the contribution of
jBPM-BPEL we would able to increase the community involvement in order
to escalate some of these delivery dates, if necessary.
If accepted, we think that as a group, this Eclipse BPEL project could
make the following milestones:
1. Release Eclipse/jBPM BPEL 1.0 GA covering the BPEL 2 public review
draft, June 23
2. Deliver the framework and the RI for deploying a process, July 1
3. Deliver the framework and the RI for debugging a process, August 15
4. Release jBPM BPEL 2.0 GA covering the final BPEL 2 spec, November 17
As mentioned earlier, these dates are probably quite conservative. If
the entire Eclipse-BPEL community can get behind the development of the
donated jBPM-BPEL then we may be able to shorten the development
lifecycle significantly.
Mark.
----
Mark Little (mark.little@xxxxxxxxx)
Director of Standards
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
------------------------------------------------------------------------
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
