RE: [bpel-dev] Runtime issues.

[James Moody <James_Moody@xxxxxxxxxx>]

Good question. 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. That was most of my motivation for my
statement. It would also create an artificial constraint for servers which
do not have that restriction. Additionally, if we have "magic"
that handles the single-eclipse-project-to-multiple-deployed-zips translation,
then the user never needs to be aware of it. It also goes against the Eclipse
design points for projects, in my opinion.

I agree about the importing of documents
from other projects - that's especially important when you have company-wide
XSDs, for example, that you need to access from all of your processes.

james

bpel-dev-bounces@xxxxxxxxxxx wrote on 05/05/2006 12:46:01
PM:

> James,
>  
> It is not clear to me why do we *have* to allow
multiple processes 
> per project. Some build frameworks, notably Maven 2, seem to favor
> the idea of a single product per project. In our case, the product
> is an archive containing a BPEL document and the related WSDL/XSD
documents.
>  
> The immediate use case I can think of for multiple
processes per 
> project is that they are related and share some WSDL/XSD 
> definitions. However, we can always import documents from other projects.

>  
> Do you have other use cases in mind?
>  
> -Alejandro
>  
> 
> From: bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx]
> On Behalf Of James Moody
> Sent: Wednesday, May 03, 2006 8:39 AM
> To: BPEL Designer project developer discussions.
> Subject: Re: [bpel-dev] Runtime issues.
>  
> 
> 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