On Apr 11, 2014, at 1:29 PM, Brad Jorsch (Anomie) <bjor...@wikimedia.org> wrote:
> I think a more salient difference between the current situation and a more > SOA setup would be that the different services could in theory be used > outside of the rest of MediaWiki This may be a very noticeable, but I'm not sure it's the most important aspect. The drive for this isn't to separate out the current services of mediawiki into an outside-MediaWiki or 3rd party use, but rather to untangle the current tight coupling[1] in the architecture itself. While the access interface between parts of MediaWiki are well-unterstood, the interfaces are broad enough to allow (in some cases require) content coupling. I think the most drive and importance of SOA is just to narrow the interfaces to the point where they are a collection of well-defined, highly-cohesive[2] systems. In your example, the interfaces two the database and the caching system are narrow and service-oriented, but that doesn't necessarily imply a good architecture. As an example: an object is a DataObject abstracted from a database, but an independent part of the system were to modify the row in database directly an independently of the DataObject in order to take advantage of a side-effect (you can modify the data without modifying the object in the current request); furthermore if this pattern is not discouraged, but actually encouraged—this is poor architecture, even when the design of the interface (SQL) is narrow. (Where it is very noticeable is that 3rd party use or independent use of a service causes the service to have a loosly-coupled, highly-cohesive architecture, since the service itself doesn't distinguish between an internal call and an external 3rd party use. It also makes it easier to test and mock.) [1] http://en.wikipedia.org/wiki/Coupling_(computer_programming) [2] http://en.wikipedia.org/wiki/Cohesion_(computer_science) > This has both benefits and drawbacks. For > example, Parsoid (theoretically[1]) allows for parsing wikitext without > having to set up all of MediaWiki to be able to do so, which is good. > [1]: I say "theoretically" because I believe it currently calls back into > MediaWiki's web API to do various things. But it's not impossible that > Parsoid or some other program could be a standalone wikitext parser. This is correct. But for wikitext processing, I feel it likely that the change would simply be that Parsoid would call a non-web-based, lower-overhead service for the pieces of the API it needs. > That sounds correct. As I see it, the general idea of REST is that it's a > generic model for clients to access resources from a server ("server" being > "a thing that provides a service"). So every service doesn't have to invent > it's own format for specifying which resource to act on, how to specify the > actions, and so on. And so every client doesn't have to implement code to > connect to the server over the network, send the action and > resource-identifier and such, wait for a response, and so on. Again, I feel a more important aspect of REST is that the interface is extremely narrow: basically a representation of a resource (URL) and a set of 4 CRUD commands (create read update delete = post get put delete). The fact that each resource is independent and each action is stateless, allows it to be highly scalable. But you are correct, that REST has the advantage over non-RESTful APIs in that the access language is defined naturally in the protocol, rather than convention. Take care, terry _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
