OSGi Service Task?

[ancoron]

I already saw the discussions about EJB tasks and I also see that Activiti shall be nicely integrate into OSGi environments (I'm about to put this to the test with GlassFish 3.1/Felix).

So I wondered why also not support OSGi Services? It shouldn't be that hard but we must presume that we are already running inside an OSGi environment. Also I imagine the following:

• Declarative/POJO Services: invoked like stateless beans


• Managed Services: invoked with optional (even runtime determined) configuration attributes (by requiring a ManagedServiceFactory of course)

Also within OSGi we must also face the issue of services being unavailable for some time (updates, something broke but the admin can fix online, …) and so processes by default pause in such a situation until the service is available (service listeners are a great thing here to avoid polling) or - if the process has been specified with some timeout - pause with a failure mark waiting to get resumed or failed manually.

What do you think on that?

[ancoron]

I've just written my own ELResolver and added it to the list of resolvers of Activiti-Engine (attached as a Fragment Bundle and the ELResolver lookup is made non-intrusive, so it won't break non-OSGi setups) and it works like a charm.

As the base I've used the BeanELResolver class. However, I have to provide the variable-mapping for each process execution but as far as I have seen the spring integration basically does the same but I wanted to prevent that overhead here.

The implementation just accesses OSGi Services by getting an instance for a service interface. Additional service query filter support is on the todo list.

[mproch]

Hello, sorry for late reply,
Is your code available somewhere on the web? It sounds interesting.

I managed to invoke OSGi services, using bluepring configuration, the code is here: https://github.com/mproch/activitiCamelKarafSample/tree/master/bundle,
it's not really sophisticated - but it works.

[ancoron]

Hi maciek,

I don't have cleaned up the code yet but will do this as soon as possible and upload it to my github repo too.

What I have done basically here is that I am using the blueprint approach for Activiti itself to get it started, although I also extended the available JTA Engine Configuration to be able to reference a datasource provided by the container using its JNDI name.

I also do not use the Aries version from servicemix in favor the official one, directly inside our GlassFish 3.1 (b36 currently) and I use the OSGi/JTA integration to reference the transaction manager.

The OSGi Service ELResolver I have written basically works with ServiceTracker to get a service instance. Also it is packaged in a separate Fragment bundle (attaching to activiti-engine) to be able to specify custom OSGi imports that will be required when integrating that into an application while preserving the OSGi setup of all other Activiti bundles.

Cheers,

     Ancoron

P.S.: I see that you're from TouK, are you considering Activiti as a "replacement" for ODE? I've worked quite hard on a nice and advanced OSGi setup of ODE into JavaEE servers (GlassFish 3.1 preliminary).

[mproch]

Hi,

I see we came up to quite similar approach independently

I don't have cleaned up the code yet but will do this as soon as possible and upload it to my github repo too.

Great, please send info when it's ready

What I have done basically here is that I am using the blueprint approach for Activiti itself to get it started, although I also extended the available JTA Engine Configuration to be able to reference a datasource provided by the container using its JNDI name.

Yes, this is basically what I'm also doing - using gnodet work on OSGi-fying Activiti - however I would prefer using OSGi services to expose datasource.

I also do not use the Aries version from servicemix in favor the official one, directly inside our GlassFish 3.1 (b36 currently) and I use the OSGi/JTA integration to reference the transaction manager.

Do you mean reference implementation by 'official one'? Aries implementation is quite complete - http://aries.apache.org/downloads/ct/current-release/org.osgi.test.cases.blueprint.html, the only extension I used
is ability to load properties easily - but guess blueprint implementation doesn't really matter that much…

The OSGi Service ELResolver I have written basically works with ServiceTracker to get a service instance. Also it is packaged in a separate Fragment bundle (attaching to activiti-engine) to be able to specify custom OSGi imports that will be required when integrating that into an application while preserving the OSGi setup of all other Activiti bundles.

Did you consider using BlueprintContainer? It's part of standard, and I find it easier to use than service tracking - or do you need some other functionality?
I ended up using DynamicPackage-Import - as I probably want to use pretty random packages as serviceTask implementations

P.S.: I see that you're from TouK, are you considering Activiti as a "replacement" for ODE? I've worked quite hard on a nice and advanced OSGi setup of ODE into JavaEE servers (GlassFish 3.1 preliminary).

Well… we found using BPEL extensively quite a pain One of the main reasons we did that is because it's standard… So now when we have BPMN 2.0 we hope to use Activiti in new projects I remeber that somebody contributed more advanced ODE OSGi setup than I did initially - was that you?

cheers,
maciek

[ancoron]

Hi,

I see we came up to quite similar approach independently

I don't have cleaned up the code yet but will do this as soon as possible and upload it to my github repo too.

Great, please send info when it's ready

What I have done basically here is that I am using the blueprint approach for Activiti itself to get it started, although I also extended the available JTA Engine Configuration to be able to reference a datasource provided by the container using its JNDI name.

Yes, this is basically what I'm also doing - using gnodet work on OSGi-fying Activiti - however I would prefer using OSGi services to expose datasource.

Yes, I was looking forward for that too, but GlassFish 3.1 apparently doesn't come with the OSGi/JDBC service integration yet, so the JNDI thing was the fastest for me without having to look around a lot and trying things that wouldn't go well.

I also do not use the Aries version from servicemix in favor the official one, directly inside our GlassFish 3.1 (b36 currently) and I use the OSGi/JTA integration to reference the transaction manager.

Do you mean reference implementation by 'official one'? Aries implementation is quite complete - http://aries.apache.org/downloads/ct/current-release/org.osgi.test.cases.blueprint.html, the only extension I used
is ability to load properties easily - but guess blueprint implementation doesn't really matter that much…

Well, to be honest I don't know the blueprint stuff very well, as I always try to keep things at a low level to be more compliant with different implementations. In addition I don't like Spring, and OSGi Blueprints actually does look like Spring. With "official one" I mean directly from the project Aries build, not the repackaged one from ServiceMix as they slightly differ in their imports. I always try to pull in new OSGi bundles in a sensible manner and I always try to keep it as close as possible to upstream sources.

The OSGi Service ELResolver I have written basically works with ServiceTracker to get a service instance. Also it is packaged in a separate Fragment bundle (attaching to activiti-engine) to be able to specify custom OSGi imports that will be required when integrating that into an application while preserving the OSGi setup of all other Activiti bundles.

Did you consider using BlueprintContainer? It's part of standard, and I find it easier to use than service tracking - or do you need some other functionality?
I ended up using DynamicPackage-Import - as I probably want to use pretty random packages as serviceTask implementations

I use ServiceTrackers because I want to be in charge if a required service goes down (that's one of the things I'm not sure how the blueprint containers handle that or provide "interceptors" or "mechanisms").

I also try to avoid the DynamicImport-Package stuff as it may lead to inconsistent classpaths at runtime (there are numerous ways to get the OSGi environments out-of-sync with this stuff when you're going to hot-update service hierarchies) and may also open up a security hole. In addition I always want that the developer has full control over that at development time, as we also know at development time which services we are going to use.

That's also why I chose the Fragment bundle way, because it non-intrusively adds imports and exports to the Activiti runtime in a very controlled manner. If something is wrong, than the Fragment just doesn't attach and you're not going to break your runtime.

P.S.: I see that you're from TouK, are you considering Activiti as a "replacement" for ODE? I've worked quite hard on a nice and advanced OSGi setup of ODE into JavaEE servers (GlassFish 3.1 preliminary).

Well… we found using BPEL extensively quite a pain One of the main reasons we did that is because it's standard… So now when we have BPMN 2.0 we hope to use Activiti in new projects I remeber that somebody contributed more advanced ODE OSGi setup than I did initially - was that you?

cheers,
maciek

Yes, I guess that was me  , and I'm still working on the cleanup, to make a decent contribution, as I've also implemented all database access using JPA 2.0 (yes, even the Scheduler) as well as providing a ManagedService for the ODE runtime that in turn configures the Axis2 ConfigurationContext using the ConfigAdmin mechanisms.

[tombaeyens]

Great to see this thread. 

@Ancoron Can you tell us a bit about your usage of Activiti?   And separately, if you want to share your code with Activiti, you'll have to sign a contributor agreement.  There's more info about it in the wiki.

@Maciej Bare in mind that we need contributor agreement for all code that enters the codebase.  So it's not possible for us to accept code from Ancoron if he didn't sign a contributor agreement.

[ancoron]

Well, we're looking forward to use Activiti to implement workflows and high level use cases in a new cloud management software. We saw that BPMN 2.0 is a lot easier to write/read than WS-BPEL and so we currently give it a try run and see how it works out. The use cases start from simple things like user registration up to more complex stuff like virtual machine provisioning using several application modules that calculate things, calling external tools, sending the actions down to the physical machines where they are executed, collecting responses and so on. We also want to implement recovery/self-healing features using processes (that's where we really need a clever error handling - and using drools we might be able to do that with the out-of-the-box Activiti).

We used ODE previously, but had a lot of stability problems lately and integration in a full JavaEE stack is not very well - it's not designed to be integrated as a pure tool into JavaEE. It has an "integrator" API, but it's rather complex and in a JavaEE 6 + OSGi world you seriously just want to plug and play. That's what Activiti made a difference from the beginning, as it already comes as OSGi bundles. It feel more like a tool in the Java world should feel.

OK, back to the code contribution: I'm just about signing that agreement, although I might implement other Activiti specific things outside of the scope of the Activiti contribution using another repository (just like Maciej does with his github repo).

[rodolfobarbeiro]

Hi mproch!

I'm trying to use the solution created for you to install activiti in karaf as the osgi bundle. I want to use OSGi Service Task.

When I build the POM.xml (https://github.com/mproch/activitiCamelKarafSample/tree/master/bundle) not find the version 5.2-SNAPSHOT in the repository http://maven.alfresco.com/nexus/content/repositories/activiti/.


There are other maven repository?


Thanks!

Rodolfo Barbeiro

[rodolfobarbeiro]

Hi everyone!


It is possible to use the Spring DM directly? In communication with OSGi bundles…