The area of software design is a shifting landscape, and smart computer people are always coming up with better ways to do things. A significant shift in software design is making its way into broadcast facilities. At the core of this shift is the concept of a service. A service is a function offered on a network by a host to clients. The shift is not so much a technical change, although there are new technologies at work, but more a philosophical change.
Changing the design
In the past, functions were tightly integrated into a software package. If you purchased an automation system or a traffic system, the software was designed with various modules communicating directly with each other at a low level. This code was efficient, and for a programmer who was familiar with the system, this design made it easy to gain access to information.
But tightly coupled systems have problems. As these systems become larger, they grow in complexity. It becomes more difficult for a person to know about everything going on. Interactions between different parts of the software become complex, and changes in one area produce unexpected results elsewhere. In short, the complexity of the system grows until it becomes unmaintainable. Also, these systems embody a workflow that was happening in an organization at the point when the system was designed. Changing these systems later — when the workflow changes — is difficult, if not impossible.
Software engineers have been looking for a way to loosen the coupling of systems so that they can more readily adapt to changes in workflow. This is because many industries, including our own, have experienced rapid change. Understanding workflow is a key factor in the success of service-oriented systems.
Analyzing workflow
Workflow has been a topic of intense interest in the broadcast industry, and many of us have experienced workflow analysis firsthand. During analysis, business experts look at the entire broadcast operation, identifying areas of inefficiency and duplicated effort. Many engineers view these analyses as a waste of time. However, a focus on workflow has led to the identification of common functional elements within the broadcast facility, which in turn has allowed the development of software services that perform common functions.
For example, analyses have identified that the ingest function — the process of bringing video and audio into a system and making it available to clients — is commonly found in news, automation and post-production systems. Furthermore, as Figure 1 shows, ingest can be broken down into common workflow steps that differ little from one application to another. (Note that Figure 1 is greatly simplified.) Rather than design an ingest client into an application, programmers can create an ingest service performed by a host accessible on the network. Ingest jobs can be sent to the host, the host manually or automatically performs the ingest, and the client is then notified when the ingest job is complete.
Overall workflow
The next leap in software design comes from thinking about overall workflows and not just the functions that an individual application performs. When designing an ingest service that will live on a network, plan to make this service available not only to your own application, but to everyone on the network who needs it. Develop open, accessible interfaces to the service and publish the fact that the service exists. Overall design philosophy needs to change from building customized, specialized, highly interconnected software modules to building services that support several applications. Once you have adopted this way of thinking, it is easy to see the benefits:
- Adding capacity is easy. If more ingest hosts are needed, simply add more on the network. If an ingest host is busy, the client looks for another one.
- Upgrading is easier. When features are added to an ingest host, put a host with the new capabilities online alongside the old one. Clients that know about the new features are free to call on them.
- Unanticipated interactions are reduced. Because the ingest host is rigidly defined by the service it provides, software programmers are not as tempted to develop shortcuts around interface points to get the information they need. Interfaces remain clean and clearly defined.
- An automatic fail-over capability provides protection, so that when one service goes offline, the slack is taken up by other systems offering the same service.
- Changing the overall functionality of a program in response to workflow changes is easier because the application is not tightly coupled.
Imagine how the configuration of a system built on services would work. A new video server is brought online, pointed to a device on the network that provides the ingest service, and the server is then ready to be loaded with material. But what if the video server could discover the ingest service itself?
Discovery service
Discovery service is an exciting concept. Let's say you are installing a new video server. This server must get its content from somewhere — either from a tape machine or, in this example, over the network. Imagine that when this new server is turned on, as part of its configuration, the server goes out on the network and looks for ingest services. As Figure 2 shows, this request goes to the discovery service. Assuming that a system offering ingest services had previously registered with the discovery service, the discovery service returns a discovery response to the video server, including information about the service offerings of ingest services available on the network. The video server communicates directly with the ingest service, requesting and receiving ingest services from that host. If the ingest service goes offline, the video server looks for another ingest service.
Services are not only limited to ingest. In broadcast applications, a transcoding service would be extremely useful, as would a metadata translation service. Imagine that the video server described earlier requests that the ingest service provide a particular piece of content. The ingest service knows that the video format of this content is not compatible with the target video server, so it contacts the discovery service, looking for an available transcoder. The content is fed from the ingest service to the transcode service, and ultimately to the video server.
Beyond having common services available on the network, it is important to have a standardized way of communicating with these services. The SMPTE Broadcast Exchange Format (BXF) is establishing standards in this area, as is the Advanced Media Workflow Association and its Web Services API for MXF.
While services offer many benefits, there are some points you should consider:
- This is a relatively new area of computer science. In some cases, standards are still being developed.
- For these systems to work well, the services must be well-defined, and they must match the actual workflow of the organization.
- Because this area is new in broadcast, the industry is still sorting out how the concept of services will apply.
- As always, pay attention to security issues in designing these systems. In some ways, broadcasters are ahead of the game because most core systems run on closed networks where access to network services are closely controlled and monitored.
Brad Gilmer is executive director of the Advanced Media Workflow Association, executive director of the Video Services Forum and president of Gilmer & Associates.
Send questions and comments to: brad.gilmer@penton.com
