Architecture Thinking

So web services are an ideal way of inter-operating disparate systems in the same way that CORBA allows disparate systems to inter-operate.  The difference is that CORBA is a binary standard and struggles in the internet world of firewalls and fixed ports. 

CORBA is still widely used in defence, telcos, and satellites.  CORBA relies on defining an interface using IDL.  Each interface specifies the set of operations that can be invoked on the particular interface.  CORBA achieves interoperability through a protocol called IIOP (internet interoperability protocol) a host and process addressing mode over TCP/IP, and CDR (common data representation) a binary way of representing data from different languages on the wire.  As well as the binary representation of the data on the wire, CDR also specifies the message structures on the wire (such how to invoke an operation, how to return a value, how to throw an exception etc).

ReSTful services rely on two simple pieces of technology.  HTTP as the carrier, and JSON or XML as the mechanism for framing the data on the wire.  HTTP is also used as the mechanism for framing how messages are sent and received between systems through the HTTP commands GET, POST, PUT and DELETE.  There is no support for throwing exceptions across the wire, and data is transmitted in text character form.  Given that data framing is done using JSON and XML, you are responsible for defining your own protocols.

ReSTful Architectural Style

Because the protocol between your systems is not defined, you are going to have to design one for yourselves. 

There are three stages to apply (this technique can be applied in any distributed system) 1) your starting point should be the deciding on what different executing applications (services) that make up your system.  2) determine what services you want to expose, this is more challenging.  3) decide on whether to disaggregate the application into smaller applications each representing one service, in other words moving towards a microservice architecture.

Let's consider each stage in more detail

What are the different applications that make up your system.

This is essentially the process of componentisation.  You identify things that have a clear purpose/intent, for the moment we shouldn't worry about single responsibility.  A simple approach would be identify components based upon layers in your architecture e.g. consumer layer (web pages, desktop applications,mobile phones etc.), business service layer (banking services like debiting, crediting, or updating accounting details, media services like purchasing a movie to play etc.), the persistent layer (SQL services to provide data to the business layer or consume data from the business layer), and finally the Business To Business layer (integration services like authentication services provided by third parties, KYC service provided by other companies or parts of the organisation etc.)

What services do you want to expose

This is business driven but also future driven.  Your experience should guide you into deciding whether the business focused services are enough for possible future changes in the business.

Just because you define a component with a well defined boundary in terms of it's intent, that doesn't mean that all of it's functionality should be exposed as a service.  Clear thought should be given around what needs to be exposed.  Don't expose something if it's not going to be consumed.  If you do expose something think about using the CRUD principle at the db layer. (move to persistence layer).  

Let's consider a media service in the business layer.  Let's consider video, audio, and accounting services. 

On the video side, the available functionality are things like, watching streamed movies; some are free and others are premium rated so you have to pay a little more, having agreements with publishing companies as to when videos are available. and cataloguing and organising videos.

On the audio side, listening to streamed audio; all are free but monies need to be paid to the PRS for each track that is streamed, filtering both videos and audios based on genre, and artist for music, creating your own playlists, having a "we recommend list", on the audio side having an auto playlist streaming outward to all listeners; similar to a radio station, and cataloguing and organising audio.

On the accounting side, registering and updating payment details, and managing financial history.

So what about the persistence layer?  The most obvios approach is to think about the CRUD operations.  How will you Create, Read, Update, and Delete entries in your database?  The chances of your DB offering web services to do these is going to be very remote so you will have to write an adaptor layer to expose this functionality as web services.  An obvious approach here is to group these CRUD operations on a table by table basis but this may well be too simplistic for aggregate updates that are also transactional.  So a better approach might be to expose stored procedures and aggregate logic that is running outside of the DB server as web services.

When exposing componet functionality for any type of middleware, don't make the mistake of designing for the middleware.  Design as if the middleware does not exist, and all the component's exist within a single application.  To expose each components functionality via some type of middleware (in case ReSTful web services), place that middleware functionality in an adaptor.  If(when) the middleware technology changes, the component is completely reuasable across the middleware style timeline.  This may seem like an overkill of the design, but I have been in this industry to know that 1) software components live a longer than you think they will, and 2) middleware is a fashionable thing.