vendredi 22 janvier 2016

Cross-domain interaction without remoting (MarshalByRefObject, RealProxy)?

One of our company's applications features a plugin architecture which allows us to extend the capabilities of the application not with a fixed plugin contract, but in any imaginable way by extensive use of reflection, DI and in process service bus(ses?).

Basically, a plugin can look like this:

                                         |- auto handler registration via reflection
public class ArbitaryPlugin :            v
    IHandle<ImportantApplicationEvent>, IHandle<AnotherEvent>,
{
                              |- whoosh, injected if available
                              v
    public ArbitaryPlugin(IServiceOfHostSystem service) {

    }

    public void Handle(ImportantApplicationEvent message) {
        ...
    }

}

All plugins are bundled into packages with a custom manifest which allows us to resolve dependencies etc. prior to assembly loading. Neat.

However, now we'd like to open the API for the public and therefore we're required to isolate the plugins within sandboxed app domains in order to prevent them tearing down the whole application or to load/unload them on the fly (by just destroying the hosting app domain, not the whole application).

For the service bus and DI to work, we now need to be able to make unrestricted cross-domain calls, but every resource we found on this topic leads to complicated remoting, sponsors, weird lifecycle behaviors etc. Also, we would be required to make every single of our messages or dependencies deriving from MarshalByRefObject or annotated with [Serializable], which simply isn't possible since a lot of them are required to be PCLs, have already other base classes etc.

So, long story short: Is it possible to create suitable objects for cross-app domain communication without this whole remoting stuff? Or, in a more cynical manner, how to create a lightweight, extensible, but yet secure plugin architecture without turning a beautiful code/language environment into the sticks and stones of or anchestors, writing more code for the infrastructure than for the actual plugins?





Aucun commentaire:

Enregistrer un commentaire