Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [bpel-dev] Offer of donation of WS-BPEL implementation to assistproject development

Hi Koen,

 

Attached is the original email that was mentioned about high-level requirements. You should be able to find the corresponding discussion in the mailing list archives.

 

Enjoy,

 

-- Bruno

 


From: bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Koen Aers
Sent: 29 April 2006 10:10
To: BPEL Designer project developer discussions.
Subject: RE: [bpel-dev] Offer of donation of WS-BPEL implementation to assistproject development

 

Hi All,

 

I understand that there has already been some discussion about high level requirements concerning the integration of a runtime engine. Where can I find this discussion? Is it in the newsgroup somewhere or should I have a look in the mailing list archives?

 

Regards,

Koen

 


From: bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Philip Dodds
Sent: zaterdag 29 april 2006 3:01
To: B. Wassermann; BPEL Designer project developer discussions.
Subject: Re: [bpel-dev] Offer of donation of WS-BPEL implementation to assistproject development

Sounds like an interesting opportunity to try and make an extracted interface for BPEL engines as I'm just starting to look at integrating Apache ODE through the ServiceMix engine, so it would be great if we could look at doing leveraging the jBPM integration.

Just to throw some stuff out there so far we have been looking at using a JBI Service Engine hot deployment to ServiceMix,  trying to look to extending of the JST/WST components to provide a JBI project,  note sure if that will be the same in jBPM but it would be sweet to be able to plug-in the engine of your choice?

Cheers

P

On 4/28/06, Bruno Wassermann <B.Wassermann@xxxxxxxxxxxx> 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

 

--- Begin Message ---
Title: [bpel-dev] Rutime Extension Point Requirements

Hi All,

I have put together a (very high-level) list of requirements on an extension
point for third-party runtime support. This stuff is rather basic and maybe
obvious, but hopefully can help with developing such an extension point.
Please let me know what you think, questions, etc.

- Deployment wizard
        + First page has a list of current engines process can be deployed
to      in current plug-in configuration. Installed and enabled runtime
plug-   ins (extensions) should be added to this list/be able to add
themselves.
        + Second page of wizard has a configuration page that extensions can
provide to allow manipulation of such items as host address,    deployment
directory, transfer mechanism, etc.
        + Progress view to indicate deployment progress (but this may just
be      a requirement on an extension itself rather than the extension
point).

- Preference Pages
        + Extensions can add their own engine configuration page to the
editor's preference pages to store the same type of information as
indicated above across projects/permanently.

- Access to Process Represenation
        + Extensions can get hold of a copy of the .bpel file for the
process         which is to be deployed.       
        + Extensions can obtain access to an instance of the editor's EMF
model representing the process.
        + Extensions can get hold of all WSDL files involved in defining the
process.

- Validation
        + The editor should not allow user to deploy (i.e. display warning
message instead of deployment wizard), if there are any outstanding
validation errors.
        + The editor should save the process and validate it in case user
requested deployment whilst editor state dirty. Or could just prompt
        user to do so.
        + Extensions have access to problems view to communicate any engine-
specific validation problems to user.

That's the first set of requirements I can think of. It would also be nice
to figure out how runtime extensions could enable a form of real-time
in-process map monitoring, but maybe that's something to think about at a
later stage.

Regards,

-- Bruno




______________________________________________
Bruno Wassermann
          
Research Fellow               
                              
University College London      Tel: +44 (0)20 7679 0369 (Direct Dial)
Dept. of Computer Science      Fax: +44 (0)20 7387 1397
Gower Street                  
London WC1E 6BT                http://www.cs.ucl.ac.uk/staff/B.Wassermann
United Kingdom
______________________________________________
 

_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev


--- End Message ---

Back to the top