On Apr 11, 2014, at 1:29 PM, Brad Jorsch (Anomie) <bjorsch(a)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