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.