近五年来，IP多媒体子系统(IMS)可以说是移动服务稳定和进步的救世主，也可以说是围墙花园主义的最后堡垒。讨论的感情用事掩盖了一个非常重要的问题。IMS的正确答案足以推动未来朝着任何方向发展吗?我们需要IMS吗，更多还是更少?
五年来，IP多媒体子系统(IMS)可以说是移动服务稳定和进步的救世主，也可以说是围墙花园主义的最后堡垒。讨论的感情用事掩盖了一个非常重要的问题。IMS的正确答案足以推动未来朝着任何方向发展吗?我们需要IMS吗，更多还是更少?
IMS作为一个标准涵盖了如何实现SIP基于服务是客户、移动运营商和其他漫游提供商之间的协调。该标准包括网络设备(例如会话边界控制器)和中央呼叫和会话管理功能之间的接口的定义。它还展示了应用程序如何适应这个过程。IMS是许多供应商的服务交付平台(SDP)标准中的一个关键元素。问题在于，在应用程序级别，IMS并没有真正指定很多东西。事实上，它缺少两件关键的东西。
第一件事是对服务逻辑执行环境(Service Logic Execution Environment，简称SLEE)的完整而严格的定义。网络特性或服务应用程序是一个程序，像所有程序一样，它需要一组应用程序接口(api)，将它链接到操作系统、网络服务集和它所运行的硬件平台。一个可移植到不同sdp的SLEE标准将允许开发人员编写服务和特性，并在任何支持SLEE的地方运行它们，就像Linux应用程序在移植了Linux的地方运行。在IMS中没有这样的东西。
第二个缺少的IMS成分是服务管理执行环境，我想我们可以称之为sme。如今，理解一项新服务或功能是如何与运营和业务支持系统(OSS/BSS)集成的，与理解该服务或功能如何与用户一起工作同样重要。IMS也不提供这种服务。
如果没有SLEE和SMEE的特定定义，IMS应用程序就不能在sdp之间移植，这意味着实际上没有任何一般意义上的“IMS应用程序”之类的东西。也没有“IMS开发人员”，只有为某人特定平台编写的IMS兼容应用程序的开发人员。
还有一些其他的标准活动已经解决或正在解决其中的一些问题。Parlay X倡议提供用于呼叫控制和OSS/BSS连接的api，但它专注于呼叫，而不是一般的多媒体网络服务。同样的道理也适用于Java先进智能网络(JAIN)工作。远程管理论坛的服务交付框架团队正在研究托管服务和特性的管理框架，但它不包括服务逻辑定义或标准。因此，没有人真正考虑如何以灵活和可移植的方式编写服务特性和服务创建应用程序这个高层次的问题。
有理由认为，SLEE和SMEE规范的“好”标准方法是使用Java, Java已经成为一种几乎通用的编程语言，也被服务提供者市场所接受。SLEE和SMEE的工作也可以借鉴Parlay和TMF的工作。关键的问题可能是找到一个适合服务和像这样的功能标准的地方。整个领域似乎都落在当前标准流程的裂缝中，考虑到运营商将重点放在创建托管服务特性的问题上，这一点令人惊讶。有人可能会说IMS是由它可以提供特性托管这一概念推动的，尽管IMS并没有真正做到这一点。
具有讽刺意味的事实是，真正的SLEE/SMEE规范可以用作IMS的替代方案，以及在IMS中提供应用程序和特性编程支持的一种方法。IMS的反对者掩盖了这一点;他们反对IMS，但除了“使用Web 2.0”这样含糊其词的评论外，没有其他选择。由于几乎每个主要门户都有自己独特且不兼容的Web 2.0 API工具包，因此没有提供创建开放、可移植的服务特性和逻辑的现实途径。
标准化的SLEE/SMEE体系结构仍然会留下一些悬而未决的问题谷歌谷歌(google inc .)在移动领域推出的开放移动Android计划。例如，消费者希望能够防止骚扰和猥亵电话，他们也希望他们的手机不会被黑客入侵，或者他们不会漫游到收取高昂漫游费的流氓蜂窝区。这种事情不能被开放的手持设备体系结构所阻止，也不能被标准的SLEE/SMEE框架所阻止。要防止这种虐待至少需要一个有围墙的花园，一个为其所支持的社区的行为负责的提供者。
最近的开放移动趋势，包括Android，似乎表明我们既需要一个更完整的服务功能和操作标准来指导托管应用，也需要一种创建可信的开放服务的方法。面临的挑战可能是如何同时实现这两种标准，以及如何使这些新标准与更传统的标准(包括IMS)的工作相协调。