slivka

Yes, there are pieces of code that can be reused across multiple if not all other workers. I suppose we can either add component classes that can be used by the workers that need them or we can create an abstract base class for all workers with implementations of common methods. The purpose of operation class is to provide metadata and create a worker, so the operation should stay as it is, but the worker needs to be tidied up. I absolutely agree that currently it is too bloated and should be split into smaller pieces but for now I wanted something that just works.
Regarding tuning, the whole point is that now the service is made of operations instead of extending one, so we can create new operations or add extra parameters to the existing operation classes that would alter worker behaviour without touching other parts of the code.

after taking a look at the rest I can see that the next step is to split this class up further. There's plenty of code that will be used by many different operations - e.g. job state management - is that the plan ?

not really the recommended way - see e.g. https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/beans/PropertyChangeSupport.html

• do you need to expose the generic binders ? what kind of events need to be monitored ?

is utils really the right name ? suggest the classes are used in several different places

this is going to get much more complex. there are plenty of additional attributes - e.g. input type (dna, protein, rna) - none of them are currently being configured on the operation.

this class seems to contain a bunch of hard coded stuff taken from the original web services configuration code rather than provide a way for a web services provider to configure an instance of AlignmentOperation tuned to the alignment service that the provider is offering.