Hi
Koen,
Thank you for your
feedback.
You are right about
it not being optimal for users to click through a number of pages.
As for the
settings, there are global settings, valid across all projects, project-wide
settings (I think this is not made clear in the document) and ones that
would need to be changed for each and every deployment. It's like with JDT
where you can, in your project, override the global settings, just for that
project. If I am not completely mistaken (I never had to implement this),
you can store this information along with your project's preferences. This
is separate from the presentation as multi-page wizard or tab.
I like the
deployment tab (not only because we could reuse your code for that ;-), just
one question. As we will not just offer one engine to deploy to and should
probably not tie the user into a single engine before she models her process
and figures out what she needs for that, how would that work in the
deployment tab (do you have one tab per engine, can you implement some
dynamic UI according to some selection (then it's again two steps for the
user))?
Regards,
--
Bruno
This is a very
useful document. I nevertheless have some thoughts about the
deployment process. While developing the deployment functionality in our
jBPM plug-in, we have moved away from the 'wizard approach' in favour of an
additional tab in the editor with deployment information. There is a picture
of it in attachment. The longer term goal (that is not yet realized) is to
store this information somewhere along with the process information. The
reasoning behind it is that users don't like it that they have to click
their way through a multipage wizard if they have to do it a lot of
times. Of course you can move away a lot of this pain by choosing reasonable
preferences and reasonable defaults in the pages. Nonetheless, if users are
choosing values different from the defaults they would have to reenter
them upon each redeployment anyway.
The additional tab
in the editor could as well be a 'deployment view' in which you could
provide multiple tabs that are more or less analogous to the pages
of the described deployment wizard. Well maybe this is all a matter of
taste and as the saying goes, you can't argue about colours and tastes of
course...
Regards,
Koen
From: bpel-dev-bounces@xxxxxxxxxxx [mailto:
bpel-dev-bounces@xxxxxxxxxxx] On
Behalf Of Bruno Wassermann
Sent: vrijdag 5 mei 2006
17:59
To: 'BPEL Designer
project developer discussions.'
Subject: RE: [bpel-dev] Runtime
issues.
Hi,
Attached is a
document describing initial thoughts on how the runtime extension point
(REP) in BPEL Designer is going to work. The mechanism described is basic
and there are numerous points to "re-think" in the use cases.
I am in favour of
a basic solution, for the time being, as it will provide us with a
mechanism for deploying BPEL processes onto engines sooner rather than
later (can start to realize these use cases now).
Having said that,
now would be a good time to gather ideas on how to improve the deployment
feature in the editor whilst catering for the needs various runtimes may
have. This will allow us to gradually improve the proposed solution until
we reach the 1.0 milestone release.
As James has
mentioned, the WTP server framework may provide the solution we need for
deployment and if not that at least some inspiration. Philip has kindly
offered to share his experiences with WST as he continues to work on JBI
tooling in Eclipse.
--
Bruno
P.S.:
At the moment, I
know very little about the WST server framework.
If someone could
share the wisdom and help figure out how to make use of it for our
deployment purposes, that would be greatly appreciated.
--
Bruno
I have been wondering whether you could use the
org.eclipse.wst.server.core.moduleTypes extension point of WST to add a
jst.bpel module type, this would allow different servers to add the
ability to 'recieve' deployed BPEL projects.
I've just starting
digging around in here to add JBI as a module type to allow a WST
registered server to work with a JBI faceted project.
Right now I'm
starting to come up to speed for the JBI stuff though there might be a
good opportunity to discuss whether similar principles could be applied to
a BPEL project? Also a good opportunity to share resources on
working to build out new module types (BPEL,JBI etc).
philip
On 5/3/06, James Moody <
James_Moody@xxxxxxxxxx> wrote:
We haven't yet created such a
facet or nature, but it sounds like we might need one.
And I think, regardless of
runtime restrictions (which may differ from runtime to runtime) that we
*have* to allow the user to create more than one process per project. So I
have a couple of suggestions:
1. We should look
at the server infrastructure provided by the WTP project. This provides an
extensible mechanism for registering "servers" of various types, a view
for managing them (starting, stopping, etc) and also for deploying
projects on them (note that Project is the unit of granularity). This is a
perfect match for what we're doing here.
2.
Under the covers, in the case where the user asks to deploy a project to a
sever that only supports, say, a zip with a single process and some
wsdls/xsds, we can of course do whatever we want - i.e. create one zip for
each process in the workspace, as appropriate. This logic is up to the
glue for that particular runtime.
james
bpel-dev-bounces@xxxxxxxxxxx wrote on 05/01/2006
05:18:43 PM:
> Is there
a plan to make a BPEL facet or nature so that a project
> type can be created and
deployed? I was wondering if that might be
> a way of integrated deployment to a server?
Similar maybe to the
> EJB deployment infrastructure?
>
>
P
> On 5/1/06, Michal Chmielewski
<michal.chmielewski@xxxxxxxxxx>
wrote:
> Since we don't have right now a
BPEL project per se (as for example a
> J2EE project, a Web Dynamic Project, etc), the
BPEL process and it's
>
locally dependent resources (schemas, wsdls) sit presumably in some
type
> of a project or
directory.
>
> So currently it is ok to
put several BPEL processes in the same project.
>
>
What are we deploying and validating and compiling then? A
single
> project against a
runtime (with many BPEL processes in it) or just the
> "selected" BPEL process
in the project or both. The grouping of BPEL
> processes into projects is totally arbitrary and
we don't have such
>
groupings in the runtime.
>
> Anyhow, thought it
should be said.
>
>
--
> Michal Chmielewski,
CMST, Oracle Corp,
>
W:650-506-5952 / M:408-209-9321
>
>
"Manuals ?! What manuals ? Son, it's Unix, you just gotta
know."
>
>
_______________________________________________
> 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