Composite UI for Service Oriented Systems – Composition Patterns

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

 

The Composite Front End pattern glues “things” together as a cohesive whole still keeping them autonomous. The Composite Front End patterns takes the ideas of web portals and applies them to SOA. It is composed of two main components: the portlet and the host.

The portlets are the building blocks (composites) which contain at least two parts: the UI logic (views and controllers/view models) and a “thing” agent. The “thing” agent is the client side representation of a “thing”. The agent itself is part of the “thing” it belongs to but deployed into the host. The host ties together the different portlets into a cohesive whole. It provides several roles:

• Provides the canvas or surface on which the portlets are displayed
• Controls the lifecycle of the portlets
• Provides capabilities like interportlet communications and single sign-on

This technique can be applied to rich clients as well as web clients. The composite Front End patterns is the preferred way of integrating different “things” into a cohesive whole. Especially if you are starting from scratch (aka green field). When you have an existing UI that you want to expose to “things” and that UI is not SOA-aware you need another pattern.

Sometimes it is not possible to change the UI in a reasonable time frame. The Client/Server/Service pattern provides a way to integrate new functionality, begin the SOA transition and get a reasonable time to market by introducing a Server/API between the client and the service.

The patterns suggests to integrate new services on the server-side or the back-end of the UI. On the server side you have a “thing” agent (similar as in the Composite Front End pattern) which is used to communicate to the “thing”. The existing logic on the server must be changed to integrate with the new “thing”. A smooth transition is possible by write to both the old and the new implementation and gradually move the readers to read from the new implementation and finally retire the old way. That’s sounds awfully complex? The benefit of this approach is that it is usually easier to do server-to-server integration (behind the firewall in the datacenter) in regards to security and integration technologies than from the client to the server. Another difficulty to tackle is that when you have to keep existing APIs intact that these concepts leak into your message design. For example old APIs are often in favor of request/response style communication which can be poisonous in regards to proper message design. But hey: It’s all about trade-offs! Consider adding NGINX or a similar load balancer in front of it. This allows you to reroute APIs pretty dynamically to the changes in the backend without affecting the client.

In the next series I’m going to cover the challenges you’ll face when doing these composition techniques.