Reading recent David Linthicum's post "When Considering Services...", I have caught myself on that I stumbled on many words in 3 out of 4 described issues. I tried to leave a comment but, probably, was not approved by the author. I apologise to the readers for the inconvenience because I have to quote several sentences from the David's text.
So, David intended to "Clarify these services issues at the outset of a SOA or cloud project to build better blocks" and identified four recommendation points. I fully agree with the first point - "services don't need to be Web services" - because services cannot be interfaces as well as the opposite. Web Services is one of possible service interface types that not even mentioned in the OASIS SOA standards. Nonetheless in the second point he says: "services produce behavior and data... However, while many services are very data-oriented, services are able to provide behavior as well..."
For the last 4 years, OASIS SOA RM and RAF ( recognised by OMG and The Open Group as the SOA reference architecture foundation) clearly stated that services produce neither behaviour nor data. Services produce only Real World Effects or results, i.e. the changes in the World's state. Services have behavior realised via their implementation and operate on meta-data. What data is used does not matter whilst this data fits with the meta-data definition. If one needs just to retrieve data from the remote or distributed data store, he or she uses a remote database driver, not a service. A service that is "very data-oriented" is either a Data Access Service or an oxymoron because service=function, not a data transmitting channel. You do not need services to retrieve data from the database for your UI - there are simpler and cheaper technical solutions available.
In the third point, David states "services are not applications". Well, if a service is not an application then what provides business functionality and produces Real World Effect? Actually, services are applications built on special service-oriented principles. This separates services from interfaces such as Web Services. At the same time, services are not traditional monolithic applications - I agree with David on this.
In the fourth/final point, David explains: "each service has a specific purpose, and they are not complex or naturally dependent upon other services. Thus, they are easily abstracted into composite applications, in essence, leveraging these services as if they are functions local to the composite. This is where exposed services have a tendency to fall down. Since they were not designed, but abstracted, they typically have far too many dependencies to be as useful as services that were designed correctly from scratch. That's the tradeoff. Services should exist with a high degree of autonomy. They should execute without dependencies, if at all possible. This allows you to leverage the service by itself, and design the service with this in mind no matter how course- or fine-grained the service is." To me, this sounds very confusing.
Yes, each service has its purpose but this does not prevent any service from being complex and aggregate, i.e. from being a service whose job is to orchestrate execution of other services and, possibly, add its own values (do not forget that all processes are services to their consumers). To my knowledge, the term Composite Application relates to any combination of any applications integrated together via Web Service, i.e. there may be no one service involved into such application. It is not services failing in the Composite Applications, it is wrapped applications fail "Since they were not designed, but abstracted" by Web Services. Unfortunately, posted text puts the things up-side-down in this point.
According to the standardised definition, a service may be as complex as a business task, there are no limits. The old saying says: "a bad dancer blames everything, even his own legs" - if some people cannot work with complex services, it is only their problem. My recommendation to them: do not be concerned with complex services and leave them to the professionals or go back to school and learn them.
Leave a comment