Thursday, March 6, 2008

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.

2 comments:

I Am The said...

Hi Bill,

In you previous post "Defining the Service Boundary" you state the following...

No system outside the service boundary shall communicate directly with any system behind the service boundary. Data cannot be directly shared between services. It can be shared only by way of message exchange through the explicitly defined public endpoints at the service boundary.

However in your most recent blog "Services and User Interfaces" you mentioned that user interfaces do not form a part of the service boundary but instead are considered a part of the service itself.

I believe that composite smart clients are probably a good fit for systems in which a service oriented architecture is appropriate. This would mean that the composite user interface could sit inside more than one service boundary. If this composite UI retrieves data from one service and sends it to another (using private endpoints), would this not have the potential to violate service boundaries?

Bill said...

Hi Nick,

A very good question. One for a follow up post I believe. Stay tuned!