Server Side Actions?

[rsoika]

Hi,
I am looking for a Event/Obserer pattern that I can use on the GLSP Server side. My goal is to implement an extension mechanism for some of my server classes to allow to extend the behaviour later. In CDI this would be CDI-Events. I guess a similar framework exits somehow with the concept of GLSP Action Handlers. But I did not found an example how I can use action handlers for a custom internal communication between different parts of my server implementation.

For example: I have a custom GNodeBuilder impl to build a new Node. In the setProperties method I would like to send out an event which can be consumed by some other independent custom server side modules to extend the properties.

Can someone give me a short code snipped how to fire a custom action event in GLSP Sever? The event is not consumed by the client.

[planger]

Hi,

you can define custom actions, register action handlers for them (ie for their type), and dispatch those actions via the action dispatcher that you can get injected in any class that is created by the DI framework.
Whether it is client-server or server-server doesn't make too much difference, except that

1. the class that dispatches the action lives on the server
2. the action handler the action lives on the server too
3. (so you don't need to define the action on the client at all nor do you need to add it to the list of client actions in the DI module)

I think there is more details on how to do all that in code in the documentation.

Coincidentally there is also currently a PR open that adds, dispatches, and processes a server-to-server action (you can disregard that the handler is at the same time the action dispatcher): https://github.com/eclipse-glsp/glsp-server/pull/172/files

For example: I have a custom GNodeBuilder impl to build a new Node. In the setProperties method I would like to send out an event which can be consumed by some other independent custom server side modules to extend the properties.

I'm not sure though this is the best approach for the use case you describe. I feel that for others to extend e.g. the properties of a GNode, dependency injection would be the better approach rather than sending actions and letting them register action handlers.

You can for instance allow your clients to bind an implementation (or also multiple ones) against a certain interface that you then get injected as optional dependency in your GNodeBuilder. These injected implementations could then be required to implement a certain interface such as below and you invoke all registered implementations of that interface to add their properties if they want.

public interface PropertyProvider {
    void addProperties(GNode node);
}

[rsoika]

@planger Thanks for your response. Yes I read the documentation but I was was not clear how to fire a Action. But now I think I understand the concept - injecting a GLSPActionDispatcher seems to be the trick.

I will try out also your suggestion with the dependency injection of an interface.

The funny development is, that I have completely distanced myself from the GNodes and mainly work now on the source model. The GModel only implements the BPMN standard elements. What I am currently doing is, that I define only the JSONForms Schemata holding the property information of a BPMN Element. The GNode does not know which properties are possible. On the client I just open a JSONForms panel in a very dynamic way displaying properties of the BPMN Element provided by the source model.

In BPMN an Element can hold dozen of properties or only a few. The BPMN Extension mechanism just extends the properties processed by a workflow engine. The layout of a BPMN element is typically not affected from such extensions. This means, I just want to give a client the chance to describe which and how his own extensions should be handled by the property panel. This will become a super-generic approach which allows a very simple and powerful extension mechanism. Extending the GModel should not be necessary at all....

[planger]

That sounds great and like a very well separated approach!

[rsoika]

@planger - I come back to your idea of using the Guice dependency mechanism for implementing a extension concept. I do not believe that this is working in a way I am thinking about.
Using Guice dependency means (as far as I understand) that I provide some abstract impl of com.google.inject.AbstractModule which allows an extension-provider to bind his custom extensions in this module. And exactly only one extension-provider would be able to overwrite this module to register all his extensions. This is - as far as I understand - the way I extend the GLSP DiagramModule to implement my own Modeller.

But my goal is, that a client will be able to run the OpenBPMN Modeller with a custom set of extensions. The client simply add Maven dependencies to build the OpenBPMN GLSP Server. He can add dependencies of multiple independent extension-providers. Of course he could now bind all the extensions, implemented by the different extension-providers. But this means, that he needs a deep knowledge about the extensions. At least he need to know the class names for the binding.

In contrast, when I use a event/observer pattern like in JakartaEE, a extension-provider would implement a CDI observer bean in an independent Jar file. Adding the jar to some bigger implementation will ensure that the CDI observer bean is called when ever the main application fires the corresponding event type. In other words - my OpenBPMN GLSP Server module does not need to know the extension implementation.

I know only the JakartaEE framework very well and not Guice. But I think the Guice Dependency mechanism is working like JakartaEE Bean Injection. The Injected CDI bean and the client know each other. In a Even/Observer pattern the two parts are more decoupled. And for now I understand that the ActionHandler concept is similar to this - at least I hope so

[planger]

This is - as far as I understand - the way I extend the GLSP DiagramModule to implement my own Modeller.

That's correct!
I just wanted to mention that you can of course use the same approach for your client's extension capabilities. You can introduce new interfaces and allow them to bind implementations for them. I'm not sure if that's the right approach for your intended extension mechanism, but I just wanted to raise it as a potential approach.

I know only the JakartaEE framework very well and not Guice. But I think the Guice Dependency mechanism is working like JakartaEE Bean Injection. The Injected CDI bean and the client know each other. In a Even/Observer pattern the two parts are more decoupled. And for now I understand that the ActionHandler concept is similar to this - at least I hope so

I certainly don't have the full picture of what you want to do, so I can't give very clear recommendations. But I think you shouldn't restrict yourself too much with what GLSP uses. Essentially you can use whatever extension mechanism seems best to you and then only integrate that with GLSP.
So for instance, if you want to use OSGi services so that any extension could just be added and registers a service, you could then have a class in the GLSP module that collects those registered services from OSGi and provides them to other classes within the DI context.
E.g. you have a OSGi property provider service to which your clients can add implementations via OSGi service declarations.
Then you could have in your GLSP DI module an OsgiPropertyProviderService implementation that collects them on start. Other classes within your GLSP diagram implementation could get OsgiPropertyProviderService injected and query all property providers it has to ask for the properties.

This way, the extension mechanism you are using (OSGi) is completely independent of GLSP, but there is just one class that integrates your extension mechanism with GLSP so that your classes within your GLSP implementation can query them.

Long story short, I recommend to use whatever extension mechanism feels best for you and then integrate them with a dedicated class into your GLSP module, so that your GLSP implementation classes can get those injected, without even having to know via which extension mechanism they come from.
In the future you can even change your extension mechanism without impacting all classes that consume the extensions, by just binding a different implementation of the class that integrates this extension mechanism (OsgiPropertyProviderSerivce in the example above).

[rsoika]

@planger - ok after digging deeper into guice I now understand that what I expected is not possible.

Guice assumes that you bind your dependencies programmatically.
In JakartaEE we have this magic CDI Container which scans .jar files for CDI beans and binds them automatically.

This is, why I can add some maven dependencies from some external libraries to my Jakarta EE server app. This will provide new functionality without the need to register or configure this library in any way. And I expected the same magic in Guice. But Guice assumes that you know all implementations at compile time so you can programmatically bind your handlers and listeners. This is what we do in GLSP in the DiagramModule. So adding a external extension to my BPMN DiagramModule means I have to now the class at compile time (chicken and egg problem)

But also with the GLSP Action Handler I run into the same problem. It looks to me that I always have to know the ActionHandler impl so that I can register it in my DiagramModule :-(

So I came to the question: Is it possible to implement a independent module that simply listen to the GSLP server port (5007) for specific events? I guess this should be possible because the GLSP client does the same. Do you have already implemented something like this?

[CamilleLetavernier]

Guice can combine multiple modules from different sources, so you don't need to know all of them at "compile" them. You need to know all of them at "instantiation" time.

Guice itself doesn't provide a way to retrieve modules dynamically at runtime (not that I know of, at least), however you can use other mechanisms to achieve that. For example, you can define an OSGi service that provides a Guice Module. As far as I understand, OSGi services should be similar to what JakartaEE provides: you define the interface in one central bundle that all clients know about (and depend on), then clients simply implement this interface (and declare some OSGi metadata so the linking can happen at runtime). Each client bundle present in the installation will then contribute to this OSGi service (So any "jar"/"bundle" you add can contribute additional implementations of this interface).

[rsoika]

@CamilleLetavernier - just one more question about that: You say that I do not need to know all modules at compile time. But as far as I understand, I need to bind a possible extension in some way in my main module with something like:

    @Override
    protected void configureBPMNExtensionHandlers(final MultiBinding<OperationHandler> binding) {
          binding.add(com.some.company.SomeExtensionHandler.class);
          .....
    }

And for this I need the library from the extension-provider when I build my GLSP Server part - correct?

Maybe it's ok if I say: you want to include an extension? Then derive your diagram module from OpenBPMNDiagramModule and add your own bindings.

In this way the extension-provider has potentially much more possibilities extending the behaviour, like if I provide some custom osgi-service which is at the end restricting the possibilities to much....? So this all would be much work for less functionality?

[CamilleLetavernier]

And for this I need the library from the extension-provider when I build my GLSP Server part - correct?

Not exactly. With Guice, you can define multiple modules and combine then at runtime (Either by creating a new single module by aggregating several modules, or simply by instantiating the Guice Injector with an array of modules).

So in theory, your client application could define its own tiny module with its own single binding, and contribute that to the main application via an OSGi Service (providing the Module).

Then the GLSP Server application could combine the main module (the one defined by the server itself) with all client modules provided via the OSGi Service (The Injector factory takes an array of modules; although you would probably have to customize the way GLSP instantiates the Injector to use that). In that case, at compile time, the Server doesn't need to know which client modules will be provided. It just needs a way to access the modules at runtime (= via OSGi).

But I'm not sure this would be the best option. As far as I know, Guice doesn't provide a way to "combine" collections provided by different modules, so combining or overriding modules only really works with unary bindings (For Collections, I think you'd have to dig a bit deeper into Guice Bindings).

In any case, I think Philip's approach is a lot simpler (Directly using an OSGi Service to create the ActionHandlers, rather than using Modules).

[rsoika]

Yes, the OSGI approach seems a elegant solution. And I still can hold the door open for everyone who wants to extend the OpenBPMN Module directly with Guice dependencies.