ervice to execute its logic, as the benefits arise from determining the next hop for a service request in parallel with the execution of the current service's logic. The number of signaling messages increases in order to communicate this information between the central node and the modules integrated with the AS. Further work is needed with this architecture to investigate how it handles faults. If a particular AS malfunctions and does not forward the request correctly or times out, the service chain is broken. The recovery mechanisms for this approach are only as complex and intelligent as each module that is integrated to the AS allows. Xia et al. [8] discuss Lucent's proprietary approach to a SCIM. The major dif- ference with this architecture is that they allow other services to interact with the SCIM through various protocols in addition to SIP. They propose allowing services to communicate with the SCIM through protocols such as HTTP. No matter which protocol is used to communicate with the SCIM externally, it would trans- late it to SIP to forward on to the internal IMS network and the relevant AS. This combined approach does not seem to be aligned with the current standardized practice of having a gateway function that only handles interoperability, such as the gateway to the Parlay X API [15]. While all the architectures discussed SO far have focused on the placement of the SCIM within the overall hierarchy of the network, Goveas et al. [11] place more emphasis on defining the internal structure of the SCIM. They discuss aspects relating to the "Policy Engine," the "Data Federator," the actual "Service Broker" as well as a "Charging Agent." It is important to mention that the Data Federator introduces new interfaces through which data can be fetched from various sources, such as the HSS or a XML Document Management Server (XDMS). This informa- tion would then be used to make intelligent decisions regarding the triggering of services and their interactions. 8.3.4.2 Functionality Regardless of the approach