#2 Redesign Service class hierarchy

[Miguel Pardal]

The current Service class hierarchy is broken. The LocalService name has historical reasons based on the first ideas about local and distributed transactions implementation. Being local is not the fundamental feature of a LocalService. The fundamental feature is participating in a work-of-unit (transaction).

See COM+ transaction types for a possible Service classification.

Define new Service class for web service client STEP applications?

Should extensible services implement a marker interface (e.g. implements Extensible)?

[Miguel Pardal]

[Miguel Pardal]

Maybe only Transactions and TransactionsManagers should be provided, letting the developer create its own service hierarchy.
This approach would also work OK with the Extensible marker interface.

[Jorge Martins]

I don't see the need for a Service hierarchy, actually...

A Service could be parameterised with the type of transaction it requires, while the actual transaction implementation could be defined on a per-execute() basis. The execute() method just needs to check that the provided TransactionManager supports the correct type of transaction. Sensible values should be chosen for each type of transactions allowed.

Based on the COM+ Transaction types, I see two types of transactions:
- DISABLED/NOT_SUPPORTED: where the service would execute without any transaction support (defaults to NullTransaction);
- REQUIRED: where a transaction will be joined if it exists or a new one will be created otherwise (defaults to FenixTransaction on 2.0);

This approach allows for Distributed Transaction support later on, as it would only be needed to implement new REQUIRED transaction implementations for both coordinator transactions and participant transactions, with the choice of what to use when left to the programmer (as was the case already, with the Service Hierarchy).