Warning: A non-numeric value encountered in /home/ricston2/public_html/blogarchive/wp-content/themes/Divi/functions.php on line 5766

I’m reading Thomas Erl’s “Principles of Service Design”.  So far, I’m finding it to be a good read since Mr Erl takes great care to explain what the SOA space is all about and what, exactly, a service should be.  I do have a slight objection to his use of the term Utility Services

According to Mr Erl, a utility service is a service that contains non-business logic functionality.  In other words, a service that fulfils part of a business process is a service, but a service that does nothing for a business process but handles some kind of automation should be called a utility service.  I’m not too comfortable with the thought of having several names for a service, but I can see the logic in having a separate name for items which will not handle the business processes.  His examples, though, of utility services are services which do things like “event logging, notification and exception handling.”

This, Mr Erl, is were I disagree.

Logging, and indeed all forms of auditing, should be provided by the framework around my services.  I may decide to include a service that notes when specific messages were sent and received, but that would, by definition, be part of the business process.  In Mule, I could utilise the standard logging features to figure out what Mule and my services are doing, or I could use Interceptors to keep track of, say, inbound customer orders and ensure that they handled within a given time frame. In the first case, Mule takes care of my needs. In the second case, this is part of a Service Level Agreement (SLA) and therefore part of my business process.

Notification falls under the same heading – additionally, I could also tap into Mule’s server notification mechanism and have other services react to changes in the state of my application/business process.

Exception handling should also be handled by the framework – and Mule does a lovely job of this.  My only concession to the definition in the book would be if I had a service that received all exception messages and routed them on to various endpoints based on certain criteria (If it’s a weekend to a sysadmin, if it’s a weekday and this is an exception raised by the accounting services, then this should go to the Accounts Manager, etc).  Even then, I think that this is part of the business process rather than a utility service.

Maybe it’s just the way I’m used to Mule doing these things for me or maybe Mr Erl focuses on a theoretical and abstract definition.  What do you think?