Bruno,
+1 on the simple case as the first thing to do.
I am in favor of getting something build and putting it to the test and
worry about changes later. In this case, the simple case you outline
does not preclude us from considering the more complex case later.
Having said that, how does that relate to validation ? We have talked
in the past of "marrying" the process to the runtime and allowing
various validation decisions to be made based on that association and
perhaps allowing that knowledge to seep into the palette to disallow
activities which do not make sense for the married runtime.
Best,
-m
Bruno Wassermann wrote:
Hi guys,
I have finished working my way
through the server
framework and determined that this will change the runtime extension
business
considerably (for the better).
There are basically two options
for achieving what we
want. One is a nice and simple solution, the other one more complex.
*** Simple option - Generic
Server Tools
- .bpel file is the module type
to be deployed, which
means that the user does not need to be concerned with the various
formats of deployment
archives. User can simply deploy a BPEL process.
- Our extension point offers
something like a
GenericBPELPublisher that provides common functionality (allow storing
local
copy of deployment archive, update problems view, etc.).
- Extensions just need to
provide sub-class of
GenericBPELPublisher and a server definition file to allow
for user config via wizard and allow start/stop of server. Sub-class
takes care
of generating deployment archive and publishing it. That's really all
you want
a runtime provider to have to do.
- Advantages are: Nice and easy
integration for
runtime providers, user only worries about deploying a BPEL process.
Even
though less flexible than complex option, does not preclude use of
facets and moduleTypes.
That is, REP can still define BPEL moduleType and wizard for creating
new
instances, etc.
*** Complex option - Server
Tools
- This means a lot more work for
runtime providers. May
need to implement runtimeTypes, serverTypes, wizardFragments,
moduleTypes, etc.
Need to provide several classes in order to initialise, start, stop
server, publish
modules, implement wizard pages to get user input, etc. Too much work
just to integrate
a runtime.
- Runtime providers may be able
to reuse some existing
implementations (Tomcat?), but providing a server def file is still
simpler option
in any case.
As I currently don't see how the
Generic Server Tools
Framework would fail to cater for our needs, I am in favour of
exploring the
simple solution.
In any case, it is better to
require less work from
everyone now and then discover that we need more features and have to
use the
complex option than spend a lot of effort on the complex option now
just to find
out that a day's worth of coding with the generic tools might have done
the
job.
Not sure that I will finish this
before leaving the office
for a while, but should have something useful at some point in June.
Regards,
-- Bruno
That’s
great! Thanks for doing that.
-- Bruno
From: Philip Dodds
[mailto:philip.dodds@xxxxxxxxx]
Sent: 09 May 2006 12:36
To: B.Wassermann
Cc: BPEL Designer
project
developer discussions.
Subject: Re:
[bpel-dev] Runtime
issues.
I have
put together some
notes on the WTP functionality we are looking at that might help
explain a bit
of the WTP functionality out there : http://www.goopen.org/confluence/display/SM/Extending+Eclipse+WTP+to+support+JBI
P
On
5/8/06, Bruno
Wassermann <
B.Wassermann@xxxxxxxxxxxx> wrote:
Hi Phil,
There was
this idea about in-process monitoring (as in
re-using the visual process representation in the editor)…
How will
this work? What do we need to get this working? How
will this work for different BPEL engines? Would it be
necessary/useful/possible to instrument processes to provide more
informative
monitoring? Don't know yet.
Something
else that's not covered, but which might be a
mighty fine feature: automatically generating some servlet (or
whatever) that
can be used to kick-off a process that has been deployed.
-- Bruno
To:
B.Wassermann;
BPEL Designer project developer discussions.
Subject:
Re:
[bpel-dev] Runtime issues.
In these original use-cases for the
deployment from
Eclipse it doesn't seem to cover the return of a handle to the running
process. I remember seeing that debugging, monitoring was on the
requirements for the Eclipse BPEL project. It might be the wrong time
to
ask but I was wondering if we intend to use the same deployment
infrastructure
then we might want to think about how that interaction might be
modelled?
P
On
5/7/06, Bruno Wassermann
<B.Wassermann@xxxxxxxxxxxx>
wrote:
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
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
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
_______________________________________________
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
--
Michal Chmielewski, CMST, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
|