Re: [bpel-dev] BPEL Project questions

[James Moody <James_Moody@xxxxxxxxxx>]

Hello Bob,

I'm the co-lead of the project from
the IBM side  - welcome!

bpel-dev-bounces@xxxxxxxxxxx wrote on 07/13/2006 04:59:56
PM:

> Hi All! 
> Sybase is interested in BPEL Designer project
and is prepared to 
> lend a hand in designing/developing the project to ensure its 
> success. I  will be the primary contact from Sybase side to keep
my 
> finger on the pulse, but I'm still getting my feet wet with BPEL so
> please forgive me if some of my questions appear naive.  I would
> like to pose following questions/issues to the BPEL Designer project
team: 
> 1. I'm sure there are still lots of BPEL engines
out there that are 
> not yet 2.0 compliant (whatever THAT means!) and probably won't be
> even after Oasis has finalized the 2.0 spec. Are there plans to 
> support BPEL 1.1 as well as 2.0? I understand that one of the 
> milestone goals is to maintain the internal DOM in parallel with the
> BPEL EMF model. It seems like a simple matter to swap out the 2.0
> model with the 1.1 model (I'm sure that code is still lying around
> somewhere, yes?) and generate/consume 1.1 instead of 2.0 BPEL. Was
> this the intent of maintaining the DOM? 

The current milestone plan calls only for working
toward a 2.0-compliant model and editor. We don't anticipate having backwards
reading capability for 1.1. There are so many syntactic changes due to
OASIS issues that this simply wouldn't be practical, especially around
the area of extensibility, etc.

The item that you mention, about maintaining the DOM
tree, works like this. Currently the model (in BPELReader) creates the
DOM tree (the easy part - just run it through the XML parser), and then
walks the DOM tree and creates BPEL EMF objects (starting with an org.eclipse.bpel.model.Process
as the root). It then throws out the DOM tree. When writing, it takes the
Process EMF model and creates a DOM tree, which it dumps to disk. The problem
with this is that any information in the DOM tree which is not reflected
in the BPEL EMF model elements (such as indenting, formatting, XML comments,
etc) is lost on the next save. We hope to take an approach like the WTP
WSDL model, where each EMF model object also holds onto its DOM element.
The DOM element is updated as set* methods are called on the EMF object.
Conversely, if the DOM element changes, the EMF features become updated
to reflect those changes. Therefore, writing is simply a matter of dumping
out the DOM tree that already exists, and you don't lose your comments,
formatting, etc. 

I don't think approach would necessarily help in being
able to support 1.1. The EMF model is based on strong typing (i.e. java
set and get methods). The namespaces of the two models are different. There
are non-trivial changes between 1.1 and 2.0 regarding extensibility, and
of course a couple hundred other changes (not all of which affect the model,
of course). Basically, this is a non-trivial problem, and we decided up
front that we weren't going to aim for this.

Our current status with respect to OASIS can be found
here:
http://apps.eclipse.org/bpel_designer/IssuesStatusPage
As you can see from that chart, many OASIS issues
have been implemented in the model (but certainly not all), and fewer have
been implemented in the UI. Our hope is that as we work towards completion
of these items from a model and tooling (and validation) point of view,
and as we get closer to the release date, the 2.0 specification will also
move to a close, and other runtimes will soon support this standard. As
we are a ways off this goal, we definitely have some lead-in time.

I hope this answers your question - if it doesn't,
please let me know.

> 2. It seems that JBoss is likely to become the reference runtime,
> yes? Is there any information regarding the debugging APIs (if any)
> that JBoss will provide? What level of debugging is planned for the
> BPEL Editor? Graphical? BPEL Source? (both would be very desirable)


That's certainly a possibility, especially given JBoss'
active involvement in this project. Really, however, "reference runtime"
means that this will be a runtime for which we provide the "glue"
to deployment and debugging - people are free to write and contribute glue
for other open source runtimes, of course. Maybe someone who is working
on the runtime framework could supply some information on the current thoughts
about debugging...

> 3. I know BPEL validation is one area that is still in the design
> phase. Has there been any progress in this area? 

There was at one point the idea of a code contribution
to kick off this area, but it looks like this will not happen at the moment.
Michal and I had a call with Thomas Schulze (an IBMer with BPEL validation
experience) in which we fleshed out some of the details of what a validator
would look like, the type of extensibility it would support, etc., so from
that point of view some initial groundwork and thinking has been done,
but there isn't any code at the moment. Michal, if you know anything further
about this, please let us know.

> 4. BPEL 2.0 provides limited access to msg headers which typically
> contain security certificates. Can the 1.1 model be extended to 
> provide similar functionality? 

I'm not familiar with this (but then again I'm not
up-to-date with respect to OASIS issues...), do you have an issue number
as a reference?

> 5. Will the BPEL project track the eclipse 3.x release train, or is
> it anticipated that platform migration is a lower priority? 

The current codebase compiles and runs on the Callisto
release train (including Eclipse platform 3.2, and currently-released levels
of emf, gef and wtp). That is our target dependency chain for a 1.0 release.

> 6. We have a need to be able to handle DND drops onto the editor 
> canvas (as invoked services). Will the BPEL Designer expose an 
> extension point to allow this? 

Absolutely. For info, we (IBM) also have such a requirement.

> Thanks for your responses. Sybase are willing
to make contributions 
> to the project in any/all of these areas, so please let me know 
> where we can help out! 

Thanks. I'm curious - in which specific areas do you
have a desire to contribute, or particular expertise that might be valuable?
Are there any OASIS issues that aren't implemented which would be valuable
to you right away (in which case help there is always welcome...)?

james