OpenESB SE and BPEL Process Persistence

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenESB SE and BPEL Process Persistence

Stefan Müller-Wilken

Dear all,

 

what is the current status of BPEL process persistence in OpenESB SE?

 

All available documents dealing with persistence were written for GFESB and seem to be tightly coupled to it. So, is process persistence still possible in OpenESB SE and is it documented somewhere? If not, what is the best strategy to deal with long running processes in high availability contexts?

 

Cheers

Stefan


Acando GmbH, Millerntorplatz 1, 20359 Hamburg, Germany | Geschäftsführer: Guido Ahle | Amtsgericht Hamburg, HRB 76048 | Ust.Ident-Nr.:DE208833022

Reply | Threaded
Open this post in threaded view
|

Re: OpenESB SE and BPEL Process Persistence

Paul Perez
Administrator
Hello Stefan,

First, thank you for your question and your interest in advanced OpenESB topics.

Regarding the BPEL persistence, you probably make a misunderstanding since the persistence is implemented by the BPEL component and not the application server. So, you can run the BPEL persistence on any Edition: Glassfish or Standalone. You can use the same documentation to setup the persistence.

Instead setting up the JNDI parameter in the application server, please use the OpenESB context. Please have a look here: http://pymma.com/images/documentation/OE%20EE%20Documentation/770-005%20OE%20JNDI%20support%20.pdf

The main drawback with the persistence is the decrease of the performance which is mainly cause by the object-Relational mapping.

Your question is good regarding the LRP is good and a smart architect must define a strategy.

The strategy, we suggest to OpenESB users, is to avoid multipart conversation, stateful and long process. To avoid these drawback, we recommend the developer to use the hydration and dehydration of the process. That pushes the process designer short and efficient BPEL. So, you can store the context in a distributed persistence such as a database, a key-value database or a distributed cache. That will provide you a strong, scalable and distributed set of processes.

I hope this port will be useful for you.

Paul
www.pymma.com The best services on OpenESB
Reply | Threaded
Open this post in threaded view
|

AW: OpenESB SE and BPEL Process Persistence

Stefan Müller-Wilken
In reply to this post by Stefan Müller-Wilken
Hi Paul,

very quick and smart answer - just as always. Thanks for that! :-)

> Regarding the BPEL persistence, you probably make a
> misunderstanding since the persistence is implemented by
> the BPEL component and not the application server. So,
> you can run the BPEL persistence on any Edition:
> Glassfish or Standalone. You can use the same
> documentation to setup the persistence.

Well, I was not sure how much the connection pooling
capability of the app server was mandatory. If it is not -
even better!

> The main drawback with the persistence is the decrease of
> the performance which is mainly cause by the
> object-Relational mapping.
...
> The strategy, we suggest to OpenESB users, is to avoid
> multipart conversation, stateful and long process.

Well, while I generally agree at 100% because this makes
OpenESB HA / load balancing via HA Proxy just a snap,
sometimes you just have to bite the bullet where you
have long lived processes and have to carry a context
with you.

> To avoid these drawback, we recommend the developer to use
> the hydration and dehydration of the process. That pushes
> the process designer short and efficient BPEL. So, you
> can store the context in a distributed persistence such
> as a database, a key-value database or a distributed
> cache. That will provide you a strong, scalable and
> distributed set of processes.

With hydration / dehydration you mean the SOA pattern of
staying stateless whereever possible and manually storing away
state and later fetching back from a database at the
end/beginning of micro-processes only in cases where
necessary, right?

Cheers
 Stefan


-----
Acando GmbH, Millerntorplatz 1, 20359 Hamburg, Germany | Geschäftsführer: Guido Ahle | Amtsgericht Hamburg, HRB 76048 | USt-IdNr.: DE208833022
Reply | Threaded
Open this post in threaded view
|

Re: AW: OpenESB SE and BPEL Process Persistence

Paul Perez
Administrator
Stefan

>very quick and smart answer - just as always. Thanks for that! :-)
It is a pleasure

> Well, I was not sure how much the connection pooling
> capability of the app server was mandatory. If it is not -
> even better!

In OpenESB SE we implemented a pool to replace the app Server one. If you have a look on the code you will find the tomcat's pool code.

> With hydration / dehydration you mean the SOA pattern of
> staying stateless whereever possible and manually storing away
> state and later fetching back from a database at the
> end/beginning of micro-processes only in cases where
> necessary, right?

That is Exactly what I meant.

regards

Paul
www.pymma.com The best services on OpenESB
Reply | Threaded
Open this post in threaded view
|

Re: OpenESB SE and BPEL Process Persistence

Jakub Grabowski
This post has NOT been accepted by the mailing list yet.
In reply to this post by Stefan Müller-Wilken
I totally agree with Paul. It's even more important if you plan process evolution. Process versioning is not supported out of the box, so you have to deal with changes by smart design and in-flight instances make it hard.
Reply | Threaded
Open this post in threaded view
|

Re: OpenESB SE and BPEL Process Persistence

Stefan Müller-Wilken
At least for new designs this is a very good point, Jakub. The question was aimed more towards legacy upgrades but nevertheless, micro-design make sense here, too.

Cheers
 Stefan
Reply | Threaded
Open this post in threaded view
|

Re: OpenESB SE and BPEL Process Persistence

Paul Perez
Administrator
Hi Guys

You can still use the same features in OpenESB SE Than OpenESB GF since we just improved the Component but did not modify any existing features.
But a large process refactory is often welcome especially because at the business level in some domain (see Amazon sell process for Example) Consistency is not required any more. SO architects have now a way to demonstrate that running a business without XA and two phase commit is possible. That is a good opportunity to break down the laaaarge BP relying on JEE transaction to small services you can name micro service as well.
(BTW casa and External Services are very useful in that case )
That's my 2 pence

regards
Paul
www.pymma.com The best services on OpenESB