I included Rob in the loop because he is working on the
new server adapter at the moment.
If you can shed a light on this issue
Rob...
Thanks,
Koen
Marshall,
BPEL is a standard
XML language for composing web services into new web services. jBPM provides
an implementation of the standard. The JBPM team, including me, is
collaborating with the Eclipse BPEL designer community on a framework for
deploying BPEL processes to compliant
implementations.
Deploying a BPEL
process to a runtime for enactment is in many ways similar to deploying an
enterprise component to an application server. Therefore, we are evaluating
whether the WTP server framework covers our requirements to avoid reinventing
the wheel.
Would you share your
expertise with us on the points described below? That’d really help speed
things up.
Thanks,
-Alejandro
From:
bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Bruno Wassermann Sent: Monday, May 08, 2006 10:22
AM To: 'BPEL Designer project developer
discussions.' Subject: RE: [bpel-dev] Runtime
issues.
Hi,
I have been looking
at some of the WTP server framework stuff. It really looks like this good be a
great fit for our needs, but I still need to figure out the details.
Given that JBOSS has
been integrated into WTP and made use of the server framework, would it be
possible for someone from that corner to share his/her experiences in the form
of relevant extension points, their function, how to consume them,
functional overview of how the integration of an app server works, etc.
This would help speed things up and allow us to finish evaluating whether we
can realize our requirements within the server framework. Apart from these
details about what is needed to use the framework I am wondering about
available wizards and whether we might reuse them, how the publishing is
organized and whether this would allow us to do some pre-deployment
validation.
I will, of course, in
the meantime continue my excursion in the framework, but some
information/sharing of experiences in this way, if possible, would be very
helpful (and might be an interesting piece of documentation for WTP?).
Many
thanks,
--
Bruno
From:
bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Bruno Wassermann Sent: 07 May 2006 16:22 To: 'BPEL
Designer project developer discussions.' Subject: RE: [bpel-dev] Runtime
issues.
Hi
Alejandro,
Large-scale
deployment (deployment of many smaller processes or deployment of a few very
resource-intensive workflows) probably necessitates further support for
reasoning about memory, thread usage, potential for deadlocks… otherwise you
are restricted to a back-of-the-envelope and/or frustrating and time-consuming
trial and error approaches.
We have done some
work with some colleagues recently that provides for model-based analysis and
automated validation, which might be an interesting feature to provide our
users with. I will find out whether they think it might be worth thinking
about contributing this to BPEL Designer.
--
Bruno
From:
bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Alejandro Guizar Sent: 06 May 2006 22:29 To: BPEL
Designer project developer discussions. Subject: RE: [bpel-dev] Runtime
issues.
I was thinking about
a statement James made in an earlier post to this
thread:
I've seen real-world scenarios
where people have upwards of one hundred business processes deployed on their
server. Forcing them to have a project for each one is a serious scalability
problem in that case.
Earlier this year one
customer was trying to deploy a network of ~120 processes. Only a few external
services were involved; most partner relationships had a process at both
ends. Many WSDL definitions were shared among two or more processes. At
design time, it makes sense to group them in a single project. However, at
deployment time you might still want/require to manipulate the individual
processes separately.
One such requirement
is scalability. In the customer’s case, you simply couldn’t deploy all
processes to the same server. They’d quickly run out of working space and
performance degraded substantially. A second server was required to handle the
load. In this scenario, I can think of two
options.
- Sort your processes in two
different projects and set a deployment configuration at each
project.
- Keep your processes in a single
project and set a deployment configuration at each
process.
Option (1) is easier
to manage than (2). However, (2) is more flexible: imagine a third server
becomes available. (1) forces you to create a third project and move processes
there. With (2) you just set a different
configuration.
I can see value in
either and think we should eventually support both. In order for (2) to be
useful we need some sort of catalog where you define a number of deployment
configurations. Later on, those configurations can be referenced at the
process, project and workspace level.
-Alejandro
From:
bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Philip Dodds Sent: Saturday, May 06, 2006 9:53
AM To: B.Wassermann;
BPEL Designer project developer
discussions. Subject: Re: [bpel-dev] Runtime
issues.
If there is going to be a number of BPEL
process definitions in a project then holding this information at the project
properties level might be the way to go. Also collecting the information
that the runtime needs could be handed off to a class that can implement the
form, from the use-case it looks that storing information pertaining to
the 'runtime' that the user has selected to deploy to is the responsiblity of
the runtime extension. Therefore it would make sense that rendering the
form for managing this runtime is probably also its responsiblity.
>From the use-case the deployment of individual processes is
allowed through a right click? I can understand the need in a project
for multiple BPEL's however I'm not sure about the deployment of each one
independently, this might lead down the route of different runtimes for
different processes within a project? I'm not saying we should implement
this just wanted to get some perspective from people implementing large scale
BPEL deployments.
P
On 5/6/06, Bruno Wassermann <B.Wassermann@xxxxxxxxxxxx>
wrote:
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
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.:
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
_______________________________________________ bpel-dev
mailing list bpel-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/bpel-dev
|