BPEL deployment framework

[objectiser]

With the current "conversational ESB actions" generation mechanism, the user is presented with a 'Generate' menu item which shows a dialog enabling them to optionally select one or more participants from the choreography, along with an associated Eclipse project name that will be created for that participant.

The user can also select a build system, that can be used to package up the generated artefacts, currently using either Ant or Maven.

We need to decide whether the same mechanism is appropriate for the BPEL generation? Do we want each BPEL process (one per participant type in the choreography) being in a separate Eclipse project - and if so, do we envisage Ant and Maven being used to deploy to the specific target platforms? In which case we may need the user to select the target platform at the generation stage.

Alternatively, we should have a simple generation mechanism, to just generate the platform independent artefacts (possibly still in separate projects), but not generate any build configurations. Then a separate approach would need to take those artefacts and enhance them (and package them) on a platform specific basis.

Once we have a better idea of what each platform requires, we may be able to better answer this. Initially I just plan to duplicate the same generation approach used for the ESB actions - which can be updated in the future based on whatever decision is made.

[jeff.yuchang]

IMHO, I think we'd have a way to generate the platform independent artefacts, and then we can have some add-on features that can support specific bpel runtime configuration files.

But as you said, lets do it first by using what we familiar, and then refactor after we get more familiar with those deployment.

Thanks
Jeff

[jeff.yuchang]

As Looked into the Active BPEL and Apache ODE, I would say that it should be better we provide option to generate the vendor independent artifacts, thats bpel, wsdl files. And provide other options to generate the vendor specific deployment files.

Also, I'd think in our M2 release, we are focusing on the Active BPEL as our bpel engine.

[jeff.yuchang]

Playing with the Intalio's BPMS Designer and ActiveEndpoint's ActiveVOS, it leads me to think about the deployment framework, and how do we expect users to use.

As for me, I would expect users (business analyst) do it like following:

1. Use pi4soa tool to create a CDL file.
2. Use overlord cdl feature to generate a CDL -> BPEL file.
3. Use BPEL visual editor to see the BPEL file.
4. Using the BPEL visual editor to complete other necessary elements. (optional?)
5. Using tool to deploy the Bpel to engine, see if it works as expected.

For its simplicity, I really like to have pi4soa, bpel visual editor in one editor, so does not need to switch tool during this process, just change the editor (perspective).

Back to those two tools, they are all pretty good at visualizing BPEL. (and other features, like BPMN), while they are targeted different bpel engine. Intalio one is for Apache ODE, and the ActiveVOS is for ActiveBPEL. They both have deploy option for generating its runtime specific descriptor files etc.

Below are my comments and thoughts:

The ActiveVOS is not open source, I play it with its evaluation license, while we can get Intalio one's community version free. At least, thats what I learn from its website. There is also a BPEL designer plugin in the Eclipse webiste, it seems to me that can't be compared to above two tools.

An interesting thing is that all these three tools are based on Eclipse 3.3 series. If I remember correctly, the pi4soa plugin also can be run based on Eclipse 3.3, so it should not be a problem, it leads me to think whether we need to test our cdl-bpel module against Eclipse 3.3?

I don't know which tool in our mind to recommend, or at least that we need to use in day to day? I don't think we will ask users to switch tools after they generate bpel files from our tool.

As to the deployment framework, I am thinking that we do NOT need to have it in our tool. our tool is just responsible for generating the common bpel artifacts, like bpel, wsdl, xsd files that defined in the CDL file. If users want to use & deploy BPEL, in most cases, they will have BPEL editor at hand. I don't think users will just want to deploy the BPEL without see the bpel file in a visual bpel editor.

Thoughts?

Thanks
Jeff

[jeff.yuchang]

Oh, forgot to say that Intalio is the people who is building the Apache ODE. so their tool can be kept up-to-date against its runtime easily. If we build our deployment framework, it means we need to check from time to time to see if runtime changes or not. since there are no spec on this area. Also, I didn't see much in common in their deployment descriptor files.

Thanks
Jeff

[marklittle]

Links to the ActiveEndpoints software that we use in the ESB can be found on the ESB forum. Try those since they are the only ones we officially support at the moment.

[objectiser]

From what you have described, it sounds like it will be best to rely on the deployment capabilities within the specific BPEL platform (whether part of the editor or not).

We need to sort out the Eclipse version though - did you try the ActiveVOS or Intalio editors in Eclipse 3.4?

[jeff.yuchang]

"objectiser" wrote:
From what you have described, it sounds like it will be best to rely on the deployment capabilities within the specific BPEL platform (whether part of the editor or not).

Yes, IMHO, we just need to care about generating the common artifacts.

"objectiser" wrote:

We need to sort out the Eclipse version though - did you try the ActiveVOS or Intalio editors in Eclipse 3.4?

No, they are distributed as one big bundle, not as eclipse plugin. ;-(