Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [smila-dev] The Eclipse BPEL Designer Project - what's the deal here?

Great news Bob!
Please keep up the good work. We really look forward having usable BPEL editor for our SMILA workflows.

Cheers
Igor


-----Ursprüngliche Nachricht-----
Von: Bob Brodt [mailto:bbrodt@xxxxxxxxxx] 
Gesendet: Dienstag, 31. August 2010 17:23
An: smila-dev@xxxxxxxxxxx; bpel-dev@xxxxxxxxxxx
Cc: Novakovic, Igor, M-E-D; Schumacher, Jürgen, M-ED
Betreff: The Eclipse BPEL Designer Project - what's the deal here?

Good idea Igor :) I have posted this email trail to the dev mailing lists.

I have fixed the crash in the BPEL designer caused by unimplemented extensionActivities and will be checking it in to the BPEL CVS repo at eclipse.org soon. Ideally, the default implementation of the Details Tab in the Property Sheet for unimplemented extensionActivities should be something like the WTP XML editor - I'll probably add that later when time permits. Currently, you have to use the Source view in the BPEL Designer to edit your extension elements.

_______________________________________
Robert ("Bob") Brodt
Senior Software Engineer, JBoss Riftsaw
JBoss by Red Hat

----- "igor novakovic" <igor.novakovic@xxxxxxxxxxxxx> wrote:

Hi Bob,

Writing an extension plugin for the BPEL editor (or for each extension
activity a separate extension plugin) was something that we intend to
do, but as you already said the editor should definitely not crash
when it encounters anything that it is (currently) not able to
configure. It would be great if you (JBoss) could fix this by merging
your fork to the trunk.

> Can you (or Igor) tell me a bit more about these invokePipelet and
> invokeService extension activities? what do they do on the runtime?

invokePipelet calls a SMILA-pipelet which is a simple POJO that
implements some piece of "light-weight" business logic that does not
consume lots of hardware resources. The lifecycle of this pipelet is
tied to the one of the BPEL workflow/pipeline.
On the other hand, invokeService calls a SMILA-service which is a OSGi
declarative service and thereby has its own lifecycle independent of
the BPEL pipeline where the invocation took place. SMILA-services
usually take long to initialize and consume more hardware resources
than pipelets and therefore used/executed in several different
pipelines/workflows.
There are some more details and nice examples on this topic at
http://wiki.eclipse.org/SMILA/Documentation/BPEL_Workflow_Processor 

BTW: It would be nice if we could continue our conversation on our
mailing list so that the community can profit from this insights.

Cheers
Igor


> -----Ursprüngliche Nachricht-----
> Von: Bob Brodt [mailto:bbrodt@xxxxxxxxxx] 
> Gesendet: Donnerstag, 26. August 2010 14:23
> An: Schumacher, Jürgen, M-ED
> Cc: Novakovic, Igor, M-E-D
> Betreff: Re: AW: [Beepul, beppul or beepell? It's all geek to me!]
> Comment: "The Eclipse BPEL Designer Project - what's the deal here?"
> 
> Ah ha! That explains it then :)
> 
> You have to write an extension plugin for the BPEL editor that
> implements a couple of extension points defined by the editor. This is
> described here:
> 
> www.eclipse.org/bpel/users/pdf/CreateAnExtensionActivity.pdf
> 
> The document is pretty straight-forward, but let me know if you need
> help with this.
> 
> Regardless, the editor should NOT just crash and burn when it loads a
> bpel file that contains an undefined extension activity. I have
> created a bug report on the JBoss community bug tracking system here:
> 
> https://jira.jboss.org/browse/JBIDE-6917
> 
> Some history about this: we (JBoss) were forced to create a fork of
> the editor because we needed to make some enhancements to allow us to
> deploy to the Riftsaw runtime, and there were no active committers
> left at eclipse.org/bpel to help push those enhancements back
> upstream. Now that we have some control over that project again, we
> are planning to merge our bug fixes and enhancements into the eclipse
> project, and eventually abandon our fork and consume the eclipse BPEL
> editor directly. We hope to have this done in about a month or so. At
> that point, we'll start doing nightly builds at eclipse and make the
> binaries available to the community.
> 
> Can you (or Igor) tell me a bit more about these invokePipelet and
> invokeService extension activities? what do they do on the runtime?
> _______________________________________
> Robert ("Bob") Brodt
> Senior Software Engineer, JBoss Riftsaw
> JBoss by Red Hat
> 
> ----- "Jürgen Schumacher" <juergen.schumacher@xxxxxxxxxxxxx> wrote:
> 
> > HI Bob,
> > 
> > Am 25.08.2010, 20:10 Uhr, schrieb Bob Brodt <bbrodt@xxxxxxxxxx>:
> > > Thanks for those Jürgen. By any chance, did you create BPEL
> > extension  
> > > activities for "invokeService" and "invokePipelet" and if so, can
> > you  
> > > send along the classes for those? If not, then I think I know the
> > reason  
> > > why the editor is crashing ;)
> > 
> > I'm not completely sure which classes you mean, so let's see:
> > 
> > We did not create any special code for the BPEL editor (I even did
> > not
> > do the experiments with the editor myself, so I do not know the
> > details).
> > 
> > The code that executes the "invokePipelet/Service" actions is here:
> > 
> >   
> >
> https://dev.eclipse.org/svnroot/rt/org.eclipse.smila/trunk/org.eclipse.smila.processing.bpel/code/src/org/eclipse/smila/processing/bpel
> > 
> > starting with SMILAExtensionBundle.java, which does the actual
> > integration  
> > into the ODE engine.
> > 
> > Classes which can be invoked using the "invokePipelet" activity
> exist
> > in  
> > the SMILA repository, e.g. at
> > 
> >   
> >
> https://dev.eclipse.org/svnroot/rt/org.eclipse.smila/trunk/org.eclipse.smila.processing.pipelets/code/src/org/eclipse/smila/processing/pipelets
> > 
> > All this code was probably not in the classpath of the BPEL editor.
> > 
> > Hope this helps (-:
> > 
> > Thanks,
> > Juergen.
> > 
> > PS: I'll be out of office tomorrow and on Monday, so I'll not be
> able
> > to  
> > answer further questions before
> > Tuesday. But Igor or someone else from the team should still be
> able
> > to  
> > answer.

Back to the top