## 5 A New Approach for Selection and Validation of Workflows
### Validation  
In a monolithic system where all components implemented w.r.t. to the same implementation specification, validating the interoperability of the components is not a big issue. However, we assume that existing services are offered by different third-party providers and are being reused by different systems. It is important that services can interoperate with each other, not only on the level of messages (invocations), but also on the level of behavior (interactions) according to complex protocols.  
While multimedia workflows often resemble a pipeline (e.g., of consecutive adaptation steps), the continuous nature of the data stream requires a high amount of protocol messages for stream flow control, monitoring and recovery after failures. Especially for detecting and replacing failing services the correct behavior of services prior or later in the chain is essential.  
For describing these capabilities of a service that lies beyond the observable behavior (as provided in the WSDL and OWL-S descriptions) additions to the Web service description languages are needed, e.g., WS-CDL+C [35]. In multi agent systems [31], there are a plethora of approaches to verify whether a set of agents can produce a conversation. By using conversation policies and conversation protocols, it is possible to describe the requested and actual behavior of a service.  
For multimedia workflows, a service is interoperable with other services in the workflow, if the message it is expecting to receive or sending is in line with the expected behavior of the role it supports. In the following sections a part of the monitoring protocol is used as an example to explain the interoperability check. The process of reestablishing the data connection to a replacement service, using a handshake message as a reaction to the \"Recovery\" event triggered by the Monitoring Service, is such an expected behavior for certain roles in the workflow.  
Figure 6 gives an example for one of the service interactions for recovering from a failed service, m? represents incoming messages, m! outgoing messages.  
In the first example, the protocol specifies that the receiving of message m\({}_{1}\)? (_recovery after failure_) has to be followed by sending m\({}_{2}\)! (_open connection_) to another participant. In the example, the policy of service 1 is conformant w.r.t. the requested protocol. This is different for service 2, which additionally can send a message m\({}_{3}\)! (_continue processing_) that is not supported by the protocol in this case.  
Figure 6: Recovery: protocol specification and service policies.  
For a different part of the protocol, to temporary pause a stream (see Figure 7), the interaction requires the reception of stop request m\({}_{4}\)? to be followed by sending message m\({}_{5}\)! (_disconnect_) or message m\({}_{6}\)! (_pause processing_). Service 1, which does not support the method using m\({}_{6}\)!. However, service 1 is interoperable in this case, since all the possible messages it can send are included in the protocol. Protocol specifications also include the expected interactions following an outgoing message, as shown in Figure 8.  
For this case, the protocol requires that opening the connection via message m\({}_{2}\)! is to be followed by waiting for disconnect requests m\({}_{5}\)? or recovery messages m\({}_{1}\)?. Service 2 does not support recovery (via m\({}_{1}\)?), and as such is not usable in the composition. Service 1 differs, as it additionally listens for a diagnostics message m\({}_{7}\)?, which is not required by the protocol and so does not invalidate interoperability.