The Web Service Model

Although we are working pretty hard to package the card model independant from any web application, the model is designed to integrate with web applications.  By keeping it independant, the architect can choose how and where to integrate it, and the application will not suffer unnecessary bloat by referencing components that are not always needed.  Now we can begin to explore ways we can build systems out of webs of services and how the web service model is a great way to do that.

There is a simple idea about a class of web service abstractions, ReST for Representational State Transfer.  In this abstraction, a web address names an object and the HTTP actions, POST, GET, PUT and DELETE can be mapped directly onto lifecycle actions on the persistant object named by the URL with the data represented in the action payload.  With formatters, cards can be represented as serialized objects in one or more formats.  Then some other system can modify that representation and send an updated version back where it is parsed and applied to the stored data.  Interacting with a browser application via ajax isn't really fundamentally different than two networked applications interacting over a shared API. Either way we are transfering state of data objects using a networked representation.

Any given deck of cards can be assigned a base URI, either just a host, or a host and a path prefix, and it becomes a networked resource using the card's namespace as directly mapped onto URI paths.  There is already a large body of industry practice around abstracting a web request interface within and between systems.  In ruby and other languages there are the Rack specifications to pass web requests and responses between middleware components.  They might be different components all using the rack gem in ruby.  Rack is part of the internal routing of requests in rails, so it comes for free with rails.  The Rack protocol is very close to how you would arrange to spawn a process to service a request passing in environment variables and returning some headers and an output stream with the body of the response.  So, you could have middleware that is in-process and passing ruby objects, or middleware that is a network of service processes all using the same web-based abstraction, but maybe not over a network protocol at all.

By using a shared abstraction based on web protocols throughout the system we don't expect to have trouble at the interfaces.  Systems architects sometimes talk about impedance mismatch between the components of a system using different technologies that are not well matched.  A classic example is the difference between database tables and a group of interconnected objects of arbitrary type.  Abstractions like Object-relational Mapping (ORM) as implemented in active record implementations provide one way to deal with this mismatch.  The card abstraction is all about reducing this impedance mismatch between the storage in active record tables and web-based APIs.  Names are well matched to web name spaces and content is well matched to chunks of text and markup that make up web pages.  Formatters provide a range of external representations of the data that can be easily matched either to an external application or output channel, or to the input parsing for ReST actions to create and update cards.

SOA or Micro Services

Micro services, latest buzzword or important new methodology.  Read a little below the surface and we see that this move is connected to a deeper trend of decentralized architectures.  The earlier and clearly related idea of Service Oriented Architecture (SOA) led to a lot of designs where the service APIs were overdesigned, fragil and managed by a central authority.  The move towards decentralization acknowledges that knowledge and innovation are best when they can be created and maintained anywhere in a networked heterogenious system.  The more flexible your APIs are, the more able to evolve and to maintain connectivity with a changing network of services.

If you want to call this idea micro services, that's fine with me, but let us also declare it as a set of properties that all services should strive towards in order to be a well designed service.  We can see these principles in operation in the design of decko as a platform.  The first card based application, Wagn, is networked by virtue of being a web-app, but that's about it.  The following chapters begin to explore the vision of card based platforms generally.  As those chapters unfold, you will see how good design in the platform makes it easy, almost trivial after a little practice, to deploy services and network them according to good design practice in our increasingly distributed networks of innovation.