Composite Applications and the Service Boundary

Like SOA, the term "composite application" means different things to different people. To me, a composite application is an application that composes two or more separate applications into a single integrated user experience. One such example is an enterprise portal. Another is a composite smart client application.

So what does it mean when we have a single composite application providing an integrated user experience spanning multiple services? Now we have the potential to share data between services without it being done via the public endpoints of the service. Bad composite application!

But is this really a problem? Well it depends on the design of the composite application. The purpose of our service boundaries and explicit service contracts is to provide loose coupling between services. We want to isolate change behind our service boundaries.

If we design our composite application in a modular fashion, having each module contain logic for one and only one service and we do not permit these modules to reference each other in any way, then we enforce loose coupling within the composite application and thus maintain loose coupling between our services. If one module cannot directly reference another, then a change in one module cannot by definition affect any other.

Any given module can communicate with private endpoints of the service to which it belongs, and any public endpoint of any other service. If we follow these simple guidelines we will not violate any service boundaries.