ed in the current IMS's S-CSCF (the S-CSCF sits on the path of all signaling messages, and can inspect every message). Under this new arrangement, the SIP-based micro- service orchestration module is the first module to be contacted by the I-CSCF after it is contacted by the user terminal. I-CSCF will also provide the rele- vant user-related information. It decides both the order and to which applica- tion server(s) (both IMS-based and WS-based) messages will be forwarded in order to provide the relevant services. It accomplished this by sending the messages via the S-CSCF module. 9.4.2 Basic Operations The basic operations of the proposed SDP are listed as follows: Invocation of services: As with Web services, there are two key roles in SOA: service requestor and service provider. The requestor application invokes ser- vices offered by one or more provider applications by sending request mes- sages and processing response messages. Some service providers can also be service requestors: they aggregate capabilities from other service providers to construct composite, higher-level services. Today's SOA implementations commonly use HTTP, resulting in synchronous communications-the requestor waits for a response before proceeding. Synchronous exchange is used to invoke services which are expected to complete in a relatively short period of time-seconds or minutes. It is also possible to have asynchronous service interactions, in which the service requestor does not wait for a response but expects it to be delivered later. For example, invoking a business process Design and Implementation of an IMS-Based Testbed to request a quote for a custom passenger aircraft, involving many partners or human interaction in the process. Brokering between services: A service broker is an intermediary between a ser- vice provider and a service requestor-for service location, brokered trust arrangements, and SO on. A service broker facilitates communications between a service requestor and a service provider by allowing the requestor 