On the plane or in the plane?

…I’m getting IN the plane! IN the plane! Let Evil Knievel get ON the plane! I’ll be in here with you folks in uniform! There seems to be less WIND in here!
(George Carlin commenting on airport announcements)

Words have meaning, but we sometimes use them in a casual manner. George Carlin made a career pointing out absurdities from casual usage. Likewise, lawyers have good days or bad days depending on the precision or lack of precision in the use of language. A recent article on TechRepublic caught my eye for that same reason: if “Poll: How much of your logic is in services?” is taken literally, there’s a huge problem.

Having your business logic “in” services as opposed to “behind” services means you’ve either limited your flexibility or you will violate the “Don’t Repeat Yourself” (DRY) principle. The principle of interoperability that underlies service orientation is potentially impaired if the application logic is tightly bound to the communication method that exposes it. Last month, Davy Brion complained about the use of WCF services as an intermediary between a web front end and the back-end of the application. He identified the performance impacts as well as the increased complexity of both development and deployment. However, if your non-UI logic is inseparable from the service itself, you cannot avoid this without redundant code. The only way to expose functionality via multiple methods (e.g. REST and SOAP services, direct connection, message queues, etc.) when working in this manner is to duplicate the functionality for each method – not an ideal situation.

A more flexible architecture can be achieved using a message-oriented business layer that can be wrapped by one or more services or consumed directly. Internal clients that are deployed concurrently with the back-end can use the “native” message format, either by directly referencing the business layer (for a web application) or through a service facade (for Smart Clients, SharePoint web parts, etc) as may be appropriate. External clients can be handled via strictly versioned services that translate to and from the canonical format. This strategy allows not only controlled versioning, but also the ability to provide multiple endpoints for a unified code base. Having only one version of business logic should yield a far more robust system than one where the same business task is implemented multiple times.