Bug 324823

Comment 1 Rob Stryker 2010-09-09 04:27:23 EDT

In order to make the BPEL project more digestable / consumable by other server types, we need to change the module factories to really really expose all the resources they need to expose. Currently they expose a seemingly random set of files and folders and it's really strange.

I suggest structuring the project around modulecore, making it a flexible project with ways to map in folders, filesets, etc. This has been tried and tested by WTP's JEE Tools team for a long time now, and I think it would greatly aid adoption. 

Changes that would need to be made are
 1) Add a wizard page in new bpel project for content root (similar to webContent etc)
 2) In the install delegate, add the component core natures and facets, and map in the content folder
 3) Create a virtual component class for bpel
 4) Completely change the module factory and module delegate to actually expose all the resources that need to be exposed
 5) Fix the apache-ODE server adapter to be able to consume this newly exposed creature

The problem with the apache-ODE server adapter is that it needlessly re-codes the tomcat adapter. It is a poor substitute for the real tomcat adapter which has much more functionality. It is a single-use server adapter which only supports the bpel project type. The list goes on.

However, right now, no other server adapters express support for the bpel module type. Generic server, tomcat, etc, all do not express support, which means that the add-remove wizard will not allow a bpel module to be added to any server. The only exception is the single-use apache-ODE adapter. 

So the roadmap should be to get the apache-ODE adapter to accept and correctly publish the module type, but quickly move to get WTP's server team to modify their plugin.xml's to express support for the "bpel.module" module type. Then, once others *do* start to consume the project properly, we can deprecate the apache-ODE adapter, which really contributes very little functionally.

Comment 2 Rob Stryker 2010-09-09 04:46:29 EDT

Created attachment 178490 [details]
First attempt, accomplishes 1-5

This patch updates the wizard, the install delegate, allows for customized content folder, and generally converts the project into a flexible project with a similar module factory as used in jeetools. 

The ODE publisher has been updated only very slightly to remove an NPE. This means the ODE publisher still behaves extremely stupidly, however at least the project is now structured properly and is easily consumed by other server adapters. 

With a tiny change to the jst's generic server jboss server adapter, the bpel project can also be deployed to the wtp generic server's jboss server adapter. Admittedly it makes some mistakes (giving the project a .war extension) but this is beyond our control currently and is a problem in the generic server adapter =] 

I believe strongly this is a good first patch.

Comment 3 Tammo van Lessen 2010-09-11 09:08:46 EDT

(In reply to comment #2)
> The ODE publisher has been updated only very slightly to remove an NPE. This
> means the ODE publisher still behaves extremely stupidly, however at least the
> project is now structured properly and is easily consumed by other server
> adapters. 

Feels a bit strange seeing others talking about the stupidity of code written by other people, I'm actually one of two how is allowed to use this term without upsetting anyone.

The right way to implement a good ODE deployer would be to use remote deployment API provided by ODE which means packaging *.bpel, *.wsdl, *.xsd, deploy.xsd into a zip and sending it via SOAP to ODE. This way it does not matter if ODE is deployed locally in a server managed by eclipse (a scenario which is only interesting for debugging/testing) or if ODE is deployed somewhere but accessible via net.

Adding this functionality would make a good patch.

Cheers,
  Tammo

Comment 4 Rob Stryker 2010-09-14 02:26:00 EDT

Comment on attachment 178490 [details]
First attempt, accomplishes 1-5

marking this as an iplog patch. Make sure you mark this is a contribution.

Comment 5 grid.qian 2010-09-14 05:49:07 EDT

apply the patch and test it

Comment 6 Max Rydahl Andersen 2010-09-15 06:12:33 EDT

(In reply to comment #3)
> (In reply to comment #2)
> > The ODE publisher has been updated only very slightly to remove an NPE. This
> > means the ODE publisher still behaves extremely stupidly, however at least the
> > project is now structured properly and is easily consumed by other server
> > adapters. 
> 
> Feels a bit strange seeing others talking about the stupidity of code written
> by other people, I'm actually one of two how is allowed to use this term
> without upsetting anyone.
> 
> The right way to implement a good ODE deployer would be to use remote
> deployment API provided by ODE which means packaging *.bpel, *.wsdl, *.xsd,
> deploy.xsd into a zip and sending it via SOAP to ODE. This way it does not
> matter if ODE is deployed locally in a server managed by eclipse (a scenario
> which is only interesting for debugging/testing) or if ODE is deployed
> somewhere but accessible via net.
> 
> Adding this functionality would make a good patch.

Not sure if you realize it but
since the bpel project is now a flexible project it is possible to add/extend remote deployment via the WTP server tools integration. Allowing you to write a ODE specific remote deployer or extend existing servers capabilities for deployment.

Comment 7 Tammo van Lessen 2010-09-20 09:49:18 EDT

(In reply to comment #6)
> Not sure if you realize it but
> since the bpel project is now a flexible project it is possible to add/extend
> remote deployment via the WTP server tools integration. Allowing you to write a
> ODE specific remote deployer or extend existing servers capabilities for
> deployment.

Yep, sorry for the rant, but as one of the original authors of the ODE deploy.xml editor and the ODE deployer (which was just a proof-of-concept yet), I just felt like complaining a bit :)

Actually we were using the Server framework already but deployed the processes by simply copying the artifacts to a local ODE instance. I'm not sure how a flexible project behaves different here, but as an ODE expert, I recommend to use remote deployment in favor of the (very basic) local deployment.

(good possible that we're talking at cross purposes ;) )

Comment 8 Max Rydahl Andersen 2010-09-22 09:28:41 EDT

(In reply to comment #7)
> (In reply to comment #6)
> > Not sure if you realize it but
> > since the bpel project is now a flexible project it is possible to add/extend
> > remote deployment via the WTP server tools integration. Allowing you to write a
> > ODE specific remote deployer or extend existing servers capabilities for
> > deployment.
> 
> Yep, sorry for the rant, but as one of the original authors of the ODE
> deploy.xml editor and the ODE deployer (which was just a proof-of-concept yet),
> I just felt like complaining a bit :)

You guys should have spoken up on the BPEL mailing/news list when we were pulling our hairs out to figure out how get it massaged into be more than just proof-of-concept :) But good to see you're back!

> Actually we were using the Server framework already but deployed the processes
> by simply copying the artifacts to a local ODE instance. I'm not sure how a
> flexible project behaves different here, but as an ODE expert, I recommend to
> use remote deployment in favor of the (very basic) local deployment.

The problem with the 'old way' was that it was non-controllable nor deterministic in its deployment. i.e. if I remember correctly it would bascially take every *.bpel file in a project tree without consideration thus it was not possible to 

A) for users to define what got included since it just took everything.

B) ensure scalability in large project trees where not everything in a project is to be included.


The deployment part were using an extended Tomcat which would be the same thing you would do here - but instead of using the above "problematic" assembly we introduce the flexible project which means you can use the existing tooling to define what goes into your "assembly".

How that actual deployment gets deployed is up the deployment implementation. That can be file based, remote api, versioned or what ever you can think of.

The important part is that you as a user can say here are the files I would like to deploy.

All of this would of course be better if there were a standard for packaging up bpel projects but I don't know of any.