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.

Services and User Interfaces

One of the common misconceptions regarding the definition of service boundaries is that user interfaces fall outside the service boundary. User interfaces form part of an application, they are never a separate application in their own right.

Consider a Web application that exposes some service endpoints. Some of these endpoints may be public (they sit on the service boundary) and some may be private (intended for use within the service boundary).

Regardless, any endpoint should be exposed only for the purpose of accessing functionality from a remote system (either inside or outside the service boundary). Endpoints should never be utilised by a component sitting on the same physical tier. Why go to the effort of creating a message to send to a local component? Why not just invoke the local component directly?

If the application is designed appropriately, there should be proper separation of concerns between the logic that receives the message, and that which performs the business logic. That is, you should have a message handler object that receives each message, and separate business logic components invoked by the message handler in order to achieve the desired business action.

This way, we can have the user interface invoke these local business logic components directly, without going to the effort of constructing message objects that are not actually going to be sent over a boundary of any kind.

Now, where we do need messages to be constructed and passed by the user interface to the application is where we have the user interface on a separate tier. One example of this is an AJAX application where the browser invokes Web services on the application tier. Another is a smart client application.

Note that the Web service endpoints powering the UI are private. They are not intended for use outside the service. Their existance is merely an implementation detail of the service. In fact in the case of the smart client application, we could change our approach to use .NET remoting, or DCOM if we so desired. In this case, there are no Web service endpoints exposed, but the application functionality remains identical.

So with any application, the user interface (and the people that use it) sit inside the service boundary.