"Before I refuse to take your questions, I have an opening statement," said President Ronald Reagan.
Well, I am not going to refuse to take your questions. In fact, I am going to answer them!
I often get questions about Service Oriented Architecture (SOA) from readers of this column and others by e-mail or in person. Below are some of the more frequent questions I get about service design and some answers. Obviously, the details of an answer depend on your circumstances and with SOA there is rarely a single right answer, so take these as guidelines only.
How can I best approach service decomposition?
Service decomposition is the act of taking functions in your business or in a system and breaking them down into the modular components that will serve as services. Don't seek perfection.
Deciding exactly what makes up a service and how functions in the business should be decomposed into specific services is tough. There is almost always more than one way to "skin the cat." This means that there will almost always be at least some level of disagreement among those involved in deciding the details of the service. It is best not to focus on these details and make the best decision possible in a reasonable period of time.
Changes are almost always inevitable, and with SOA-related technologies, it is not impossible to make changes if a better approach becomes clear.
How atomic should my services be?
Services are atomic when they cannot really be broken down effectively into smaller services. Don't be too atomic in service design. It is important to think at an appropriately high level when dealing with SOA. It is natural for technical people who have been engaged in the development of tightly coupled systems to think about the details of the interaction of the systems and the people and to be tempted to build the services at this very low level.
Unfortunately, this can be a path that heads back to a tightly coupled environment. There is a tradeoff between granularity and reusability in service design. The lower the level in interface design, the less likely the service is to be reusable in other workflows.
Can naming my service help with design?
Yes! Use the "verb noun" rule in naming services. This is a simple rule to help with thinking about service levels and design. This guideline says services should typically be easily stated as a simple verb and noun combination. Anything more complicated is likely to be at an inappropriate level.
Good examples in naming services would be "Transcode Media" or "Move Media." Examples of inappropriately named services would be "Transcode Media from QuickTime to MXF" or "Move Media Using SFTP."
What other approaches can I use to help ensure my service is at the appropriate level?
One other thought is to consider the "boss voice" when thinking about service names and details. With this simple rule you think of the service as something that the "boss" would say in an organization. This helps guide the service to the appropriately high business level.
This "boss" is not really a top-level executive who would only provide strategic direction, but rather a line manager getting things done. You would expect the boss to say, "Get that media over to the news division by 5 o'clock!" You would not expect the boss to say "Get a UMID for that Media!"
How should I deal with business rules?
You should separate business rules from services. It is important to avoid as much as possible hardcoding rules or variables into either the business processes or services. This is especially important in the services.
Any business rule hardcoded into the service is at risk of needing to be changed, requiring the service to be updated. This update would have to come from IT personnel.
Storage of business rules into a rules engine or some kind of database helps to keep services stable and allows for changes to be made in applications by operations or administrative personnel.
How do I handle real-time services such as playout?
Handle those real-time aspects within the implementation of the service and not at the SOA level—SOA technologies are not designed for industries that require real-time activities in the way that we do. The best way to handle these real-time requirements is within specific services.
The service interface can allow specification, in the form of an SLA or contract, of information about when things should be done exactly or the deadline they must be completed by.
How can I upgrade my services over time?
Ensure backwards compatibility as you expand a system. It is very important not to "break" the system as it is expanded. Care should be taken to consider the details when services change.
Appropriately designed services should rarely require change, but working at the business level does not eliminate the need to upgrade services on occasion. Because most SOA technologies are associated with XML technologies, the maintenance of backwards compatibility is generally easier.
Design-time or run-time service discovery?
This is a tough one as the technologies in question are evolving. My general advice is to use design-time service discovery only. This is unfortunately true at the moment. The use of run-time discovery of services—in other words picking the specific service to use during the execution of the business process—is complicated by a lack of standards adoption.
Unfortunately, the technologies in this area have been ill adopted even in the general SOA community. For the moment, most companies would be best served by not attempting a complicated run-time registry approach and instead simply select the appropriate services during the design of the business process.
Voltaire said, "Judge a person by their questions, rather than their answers." Judging by the great questions I get, I think this audience is pretty smart. Please feel free to e-mail me questions and I will try to answer them for you. You can Count on IT!
John Footen is an independent media technology and operations consultant. He is also co-author of the book "Service-Oriented Media Enterprise." He can be reached at jfooten@footen.tv.
