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
From:
bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Koen Aers
Sent: 06 May 2006 09:20
To: BPEL Designer project
developer discussions.
Subject: RE: [bpel-dev] Runtime
issues.
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.:
From:
bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Bruno Wassermann
Sent: 03 May 2006 16:37
To: 'BPEL Designer project
developer discussions.'
Subject: RE: [bpel-dev] Runtime
issues.
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
From:
bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Philip Dodds
Sent: 03 May 2006 15:24
To: BPEL Designer project
developer discussions.
Subject: Re: [bpel-dev] Runtime
issues.
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