[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
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
|
Attachment:
deploy.jpg
Description: deploy.jpg