Can SOA Give You A Good Service?

Featured
13510 Views
2 Comments
4 Likes

Like any other religion, sorry architecture, SOA has its own language and meanings for the terms it uses. Unfortunately, some of these words can be very confusing, none more than the term "service". So here is a bluffer's guide to understanding and conversing in SOA-speak.

Lexicon of confusing SOA terms:

Service:
The trickiest of the lot. Here is my preferred SOA usage:
"A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data; consolidate drilling reports). It is self-contained, may be composed of other services, and is a "black box" to its consumers."

Two more definitions in increasing order of opaqueness:
"...;a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description." OASIS

"...;a discretely defined set of contiguous and autonomous business or technical functionality" Wikipedia(!)

However, in IT the term service can also apply to a very low level data or logic routine, and in business discussions, service is a description what your business provides to its customers, and in operations, service describes the quality of delivery (i.e. Service Level, Service Management). The newer definitions above are peculiar to SOA, but those with the misfortune to have been exposed to Object Oriented (OO) methods in the nineties will recognised the constructs (and obscure language).

Sub-categories of Service:

Composite Service/Atomic Service:
"A composite service is a service whose implementation calls other services. This is as opposed to an atomic service, whose implementation is self-contained and does not invoke any other services. A composite service acts as both a service provider of the (composite) service and as a service consumer of its child services. The composite can be considered to be aggregating together the child services into a bigger service."

This building block approach, where you can create larger re-usable service blocks from the smallest services is a fundamental characteristic of SOA and provides significant potential maintenance benefits.

Service Consumer:
"A consumer of a service is an agent (user, process, composite service) which seeks to satisfy a particular need through the use of capabilities offered by means of a service. A service can have one or more consumers."

There are many consumer/provider models in IT, including Pub/Sub (Publish/Subscribe), that de-couple the systems required to support the overall business process. The ultimate consumer is the customer for the business process, but they can be several layers of service consumer each of which is loosely connected to the layer below.

Service Provider:
"A provider of a service is an agent that takes responsibility for it being carried out. Every service has a provider."

The key point about a service provider in the SOA context is that the service provider is not the service itself, but is effectively a management layer than ensures that all the non-functional characteristics for the service (accessibility, availability, quality, security, etc.) are agreed with and delivered to the Service Consumer.

Service Registry:
"To make a service available for use by consumers, the service providers register their service in a public registry. A registry is nothing but a collection of services, their description and their addresses. The registry is used by consumers to find services that match their requirements. If the registry has a service with matching criteria, it provides the consumer with the address for that service. The consumer accesses the service, binds to the service by calling its visible interfaces and invokes the methods provided by the service."

A more recent addition to the SOA terminology and tools list is the concept of making information about existing services easier to discover, so that effort is not duplicated in developing new services when existing services have been developed for another project that can be re-used to meet the requirements of the current project. More sophisticated Registries and Repositories for services are emerging that support real-time service choice and usage at run-time as well as during development. A key advantage for BAs here is that you have much better visibility of the building blocks you could use to build the solution required.

Web Service:
"A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards"

In effect, a web service is a specific software implementation of service architecture that have specific physical definitions and characteristics - enabling real code to be cut and executed to deliver some service functionality. Fortunately, or unfortunately depending on your view, web services have come to dominate the whole service discussion. It is certainly the most popular implementation of the SOA service concept, and has a large set of agreed policies ensuring that interoperability is easy to achieve (all called WS-something). The downside is that it allows programmers to jump straight into coding with little architectural context for the overall business service they are delivering. So if you ask your IT department about SOA, and all they come up with is web services, don't expect to get a process-driven, service-oriented solution to meet your business requirements.

So these are most of the definitions of Service terms you will need to know to be able to make sense of SOA. In the next article I will cover some of the other arcane and, at times, baffling SOA terms you may come across.


Author: John Moe is Head of Business Consulting at Alphacourt, and writes and presents widely on SOA and BPM. With over 25 years experience delivering application development and business transformation programmes, John has made most of the mistakes you will ever make and is keen to pass on this knowledge to help you avoid them yourself. In return he just expects undying gratitude and free drinks wherever he goes.

Like this article:
  4 members liked this article
Featured
13510 Views
2 Comments
4 Likes

COMMENTS

Chris Bird posted on Wednesday, May 6, 2009 6:23 AM
This is a very helpful article indeed because it helps keep Service and SOA on the straight and narrow. Nice call out of the Web Service vs Service.

Interesting observation that "A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data; consolidate drilling reports). It is self-contained, may be composed of other services, and is a "black box" to its consumers."

Nowhere in this definition is there any requirement to get an answer back, except maybe a status of "yup, I've done that" or "No couldn't do it, sorry". For sure a result could come back. For sure some system state may be changed (perhaps because of a side effect), but the key is that it is a black box.

Where we do see some confusion is in granularity. I occasionally here the word operation being applied to Services. So in your example "Check Customer Credit" above, is that really a Service invocation or is an invocation on another Service (perhaps a Customer Management service). Just dealing with the granularity would help me in understanding the kinds of numbers that are bandied about at conferences. "We have over 3000 services" vs "We have 40 services (and 3000 operations). Is that simply a packaging issue?

Coming back to the whole WS-something discussion, you make a telling point that "A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards". First up this says machine-to-machine. And while the computer at which a user is sitting, operating the browser is most definitely a machine, I am not convinced that WS-something is the most appropriate way of managing that interaction. It may be, but the point is not proven. Secondly, it is not completely clear to me when services actually need to be exposed (assuming that we have defined service correctly). So how much WSDL wrapping do I do? And why? In some ways - especially for internal code, WSDL wrapped service invocation is just really expensive function or subroutine calling.

So even though we can define what a service is, it is harder to define what a service isn't, and harder still to choose the right architectural approach to allow for machine/machine interoperability, human/system interoperability.

I have posted this commentary and a link to the original article at http://businessanditarchitecture.blogspot.com
seabird
johnarmoe posted on Monday, May 11, 2009 3:53 AM
Chris,
Thanks for the comments. I think you have illustrated the difficulty in agreeing a set of common definitions and interoperability at the English level, let alone at a more technical level. Yor points are unfortunately true, and I am always on the lookout for clearer and more concise, but complete, definitions.

I find that I have to re-calibrate meanings at each site I go to - and this calibration is to help the organisation clarify the taxonony themselves.

My take is that you should assume that there is no standard understanding of service until proven.

Regards

John
johnarmoe
Only registered users may post comments.

 



 




Copyright 2006-2024 by Modern Analyst Media LLC