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
|