There might be other pros/cons. The list below is my point of view on the subject that I can think of:
PROS:
- Easier for scripting JS than IRD (although both are possible).
- Distributed processing among the Orchestration Server nodes (still URS is a bottleneck playing a role to send commands to the T-Server/SIP Server/IXN Server)
- Session processing recovery from the point of failure in case a node goes down (URS re-executes the strategy from the beginning if the Primary goes down)
- Possible to use a market-grade versioning platform to keep track of changes.
- Most (and probably all) DevOps tools have the ability to publish the code to production.
- New features are usually only being pushed to Composer/Orchestration Server.
CONS:
- If you want a centralized repository for the strategies, you need to set it up on your own - and you cannot be sure that it is the one that is published.
- Some functions are not implemented on ORS and are dependent on URS in order to execute.
- Documentation is not as well-detailed as it is for IRD-based strategies.
- Strategies on Composer are not as "visual friendly" as they are on IRD.
- Adds complexity on the platform and more resources are required.
- On multimedia strategies/processes, there is no simple way to send all the interactions back to the Interaction Queue (e.g., if you want them to re-execute a new version of the strategy to fix a "stuck" scenario).
- Due to ORS caching, if you update the code of a strategy on the Web Application Server, the most-current code might take a while before being executed.