Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [bpel-dev] Runtime issues.

Hi Phil,

 

Server definition refers to the Server Definition file “mechanism”. For runtime providers that means, either you can just reuse some existing server def file or (more likely) you just provide your own. The server def mechanism allows you to specify config parameters that will be rendered in a wizard for the user, specifies how to start/stop server, etc.

 

The publisher business refers to the genericpublisher extension point, whose current incarnation is ANTPublisher. For our purposes, we need to work on another implementation and every runtime provider may want to sub-class our implementation to cater for a particular’s engine deployment mechanism.

 

Does that answer your questions or did I miss something?

 

Cheers,

 

-- Bruno


From: Philip Dodds [mailto:philip.dodds@xxxxxxxxx]
Sent: 16 May 2006 12:38
To: B.Wassermann; BPEL Designer project developer discussions.
Subject: Re: [bpel-dev] Runtime issues.

 

Bruno,

Certainly simpler sounds better,  just a couple of things I wanted to clear up :

* When you refer to a server definition are you thinking about the JST server definition that exists or a new one?
* The publisher is a new extension point i assume not the current extension point that is part of the JST Generic Server?

Cheers

P

On 5/16/06, Bruno Wassermann <B.Wassermann@xxxxxxxxxxxx> 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

 

 


From: bpel-dev-bounces@xxxxxxxxxxx [mailto: bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Bruno Wassermann
Sent: 09 May 2006 14:10
To: 'Philip Dodds'


Cc: 'BPEL Designer project developer discussions.'

Subject: RE: [bpel-dev] Runtime issues.

 

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

 


From: Philip Dodds [mailto: philip.dodds@xxxxxxxxx]
Sent: 08 May 2006 11:47


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

 


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.

 

  1. Sort your processes in two different projects and set a deployment configuration at each project.
  2. 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

 


From: bpel-dev-bounces@xxxxxxxxxxx [mailto: bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Koen Aers
Sent: 06 May 2006 09:20


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.:


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

 


_______________________________________________
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

 


Back to the top