May 09, 2016 09:16 PM|hugo|LINK
I'm seeking ideas for some form of extensible architecture, here's a short background.
We're implementing what are termed "LTI Tools" these are - in essence - represented fine as MVC action handlers, they simply return a view. The processing consists of verifying the LTI request (which begins life as a POST from some external system) then
doing stuff then returning a view.
LTI Tools are consumed by external learning platforms, they are often fairly simple single-page apps, that do things like show a list of books that a student can use, show some form of calculator related to their course, present them with assessments (question/answer),
and so on, these tools are often provided by a variety of unrelated vendors (named Tool Providers).
Now we are going to be creating a number of in-house LTI Tools and we already have three or four working.
Right now this is a single MVC app, we have a dedicated controller (ToolController) that includes several action handlers (one per tool).
The architectural problem here is that one must update the web app solution, add handlers to the controller, rebuild and retest, all of these tools are tightly coupled to the server app.
I'm seeking ideas for a more "pluggable" pattern, where someone can develop "just the LTI tool" code and then deploying it, the server simply "seeing" the new tool and leveraging it when a suitable request comes in.
Ordinarily deploying an assembly that contains the functionality would be one way, using reflection etc or dynamically loading the assembly etc. The problem here though is that there's more than code here, there's JS, .cshtml files etc etc and packaging
all this into some single entity is a problem that arises.
One way is to make EVERY LTI Tool its own asp.net web app, so that URL's ultimately map one-to-one to servers.
This is the general problem statement, any ideas much appreciated.