Those of you using my SOA methodology already know that one of the things I ask for is that you look for candidate services. Candidate services, simple put, are services that have the potential to become core services, but that requires a bit more analysis before they do.

The fact is most services employed within SOAs exist already. Thus, part of the process of building a successful SOA is figuring out what should be a service, and what should not. A common amateur mistake is to service enable everything. That typically proves unproductive, and could be a "SOA killer" at the end of the day.

While there are no hard and fast guidelines on what makes up a well-defined and developed service, I do know a few things:

• Services are not complete applications or systems. They are small parts of an application, and should be tested as such. Services are not subsystems; they are small parts of subsystems as well. Indeed, services are more analogous to traditional application functions in terms of design, and how they are leveraged to form solutions, fine or course grained. Knowing that, we have a better basis of understanding when approaching the service testing problem.
• 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.
• 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.

Posted by Dave Linthicum on July 30, 2007 05:25 AM