Composite UI for Service Oriented Systems – Mashup means bringing it together

This blogpost is part of a larger blog post series. Get the overview of the content here.

A frontend is not owned by a single “thing”. It is a mashup of multiple “things” combined together to provide a single user experience. Looking at it from the deployment perspective we can say that many “things” can be deployed to the same box, many “things” can be deployed in the same app, many “things” can cooperate in a workflow and many “things” can be mashed up in the same page. Which brings us directly to service composition.

But wait we still have a problem to solve. What about all the technical stuff like Authentication, Authorization, Hosting technologies like web servers, database and more, to which service does that stuff belong? It belongs to a special “thing” called IT/Operations. This “thing” also owns users. It provides hosting infrastructure for integration endpoints and listens to events which are crucial for provisioning and deprovisioning machines, accounts etc. Now back to composition.

We have now a decomposed system. The overall business process is driven by multiple events happening in the system which then triggers sub processes in each “thing”. Coordination of business workflows which need multiple services should happen over process managers or sagas. If possible always avoid request/reply communication and commands between “things”.

But how on earth can we bring the system together into a unified experience? We will look at two consumer patterns in the next series of blog posts.