7.3.7 OSS-J
OSS/J（OSS Through Java）是以J2EE为基础的NGOSS解决方案。Sun Microsystems公司的Philippe Lalande指出，“Java的根本思想就是兼容性，而OSS领域最大的挑战就是面临大量应用程序接口不兼容的问题。”
OSS/J提供了一个符合框架原则的技术相关（Java）的实现方案。就在TMF（TeleManagement Forum）于2000年提出NGOSS的概念时，以SUN为首的一些厂商，如BEA、IBM、Motorola、NEC、Nokia等，酝酿成立了OSS/J工作组（OSS/J，OSS through Java™ Initiative）。自2000年成立以来，他们一直在为加速OSS/BSS解决方案的开发、简化其中系统组件的部署和集成而努力。OSS/J规范的推出是在JCP（Java Community Process, http://jcp.org）支持下完成的，以Java规约请求（Java Specification Request，简称JSR）的形式提交。JCP是SUN和许多其他主流厂商所主导的一个社团，现有500多个公司和组织参与，其中包括BEA，IBM等众多业界的领袖。OSS/J通过JCP的协议控制过程保证JSR的中立性。JCP产品中包括了OSS/J的规范、参考实现和兼容性测试工具。
OSS/J规范推出以后，得到了业界的广泛认可，许多电信运营商、服务提供商、系统集成商争相追随。来自IDC的2002年的报告显示，“由于OSS/J的努力，OSS和计费架构正在演化，竞争规律在OSS和计费领域正在发生变化，Java的使用将对行业产生深远的影响。而随着SA、TT、Qos API的发布，许多服务提供商和供应商认为，采用JAVA技术实现OSS已经到了实际可行的阶段。”Yankee Group也在研究报告中指出“通信服务提供商（CSP）面临日益增加的压力，不但要降低运营费用，还要快速推出新的业务，OSS/J对CSP的生存至关重要。OSS/J在当前通信领域可见的标准中最具有前景。”
OSS/J在目标原则的指导下，以J2EE平台为基础，运用设计模式，设计了一组API框架，它具有非常强的可集成性和可扩展性。
OSS/J的制定立足于J2EE平台，它的制定基于以下原则：
（1）OSS的功能以EJB构件定义实现。
（2）粗粒度，面向业务的接口。
（3）利用应用服务器支持集群，可扩展性和错误恢复。
（4）利用消息最小化构件间的耦合。
（5）支持工作流。
（6）依靠JCA集成遗留系统。
工作组利用JAVA技术，为OSS/BSS定义实现了一系列的开放的标准API，提供给OSS/BSS的开发者使用。OSS/J的优点在于它定义了标准的接口，应用间可以通过此接口进行交互。API的定义中考虑了其适应性和可扩展性。在设计中应用了许多设计模式，保证了新实体加入时，不会影响到API的架构。
OSS/J设计的实现依赖如下几个机制：
（1）依赖XML消息实现异步和和松耦合交互模型。
（2）强类型，基于对象的事件。
（3）XML消息机制。
（4）基于JMS的事件和消息订阅机制。
（5）利用JNDI规范，定位OSS/J架构元素（会话对象，主题，队列等）的服务。
（6）依靠外观模式实现OSS/J的会话组件接口，以JVT对象作为参数。
OSS/J核心API囊括了客户管理、订单管理、服务开通等20个，关于每个API的详细描述，可参见http://java.sun.com/products/oss/apis.html上的OSS/J API Roadmap。目前，已经完成的API有：OSS服务开通API，OSS故障单API，OSS通用API，OSS IP计费API和OSS服务质量控制API，而OSS库存API不久也将发行。除了API，OSS/J工作组还为开发者提供了《OSS/J J2EE 系统设计指导》。
（1）OSS通用API（OSS Common API）：和其他OSS/J API不同的是，它本身没有对OSS/BSS在业务逻辑提供支持，而是为开发者使用OSS/J API提供了一个基础框架，同时它也是《OSS/J J2EE 系统设计指导》一个具体实施约束框架。以下的所有OSS/J API均依赖于通用API。
（2）OSS/J J2EE系统设计指导（OSS/J J2EE Design Guideline或OSS/J J2EE DG）：定义了一系列的设计模式（Design Patterns），这些模式非常适合于采用J2EE/EJB搭建网络服务管理系统。
（3）OSS服务开通API（OSS Service Activation API或SA API）：主要提供了对订单的管理功能（例如，生成、修改、删除、查询订单等）和服务的管理功能。API中并没有给出指定的“服务信息模型（Service Information Model）”，而是将这部分工作留给开发者去实现，这样开发者可以根据自己的业务逻辑的需要定义服务信息模型。SA API中关于订单管理的定义是根据TMF 603中的“世界订单信息协定”（World Ordering Information Agreement）以及OMG WMF/WfMC的“订单状态模型（Order State Model）”的定义完成的。
（4）OSS故障单API（OSS Trouble Ticket API或TT API）：定义了生成、更新、查询、关闭故障单的一系列操作。网管系统可以通过调用TT API自动生成故障单，服务提供商也可以利用它产生和处理故障单，客户关怀系统能够调用这些API将故障单发送给服务提供商；如果故障单的管理是在一个工作流程中完成的话，那么开发人员可以使用这些API与工作流引擎进行信息传递。
（5）OSS IP计费API（OSS IP Billing API）：定义了IP计费的数据源和计费系统之间的接口。这部分API适用于针对2.5G和3G网络的OSS/BSS开发。而且API的定义重点放在（但不局限于）无线通信的领域。该规范的定义是为了实现计费系统、计费数据采集系统、计费数据源这些不同的子系统之间能够实现无缝连接，完成各种记录类型（例如，CDR、SDR、IPDR等）的交换和传输。
（6）OSS服务质量API（OSS Quality of Service API或OSS QOS API）：QOS API使得QOS系统能够从其他系统得到影响服务质量的数据，例如，网络性能、极限值以及故障数据等。QOS API主要涉及到性能和使用情况的数据监测、系统极限值的监测及故障数据的监测3个方面的内容。
（7）OSS 库存 API（OSS Inventory API）：OSS/BSS在进行操作的时候，大多需要关于网络可以提供的产品、服务和资源的规划、使用的情况，这些功能要由库存API来提供。这部分API包括了对产品和服务的目录管理，并且有跟踪用户预定和使用产品或服务的功能；同时API中对网络资源管理（例如网络上的设备和网络拓扑结构的管理）的功能对于OSS/BSS来说也是不可或缺的。
目前已经有厂商开发出基于OSS/J的解决方案，并推出了基于OSS/J的产品，如Nortel、Telcordia实现了TT API；Agilent，NEC及Cygent实现了客户关怀；Telcordia实现了SLA API；MetaSolv，Telcordia实现了SA API；IP Value，iLOG实现了Qos API。
API技术是下一代网络的一个亮点，API技术的发展首先依赖于技术的成熟程度，目前各种API协议还在发展，并且设备商也正在不断完善自己的设备；其次它需要有效的商业模型和有效的业务支持，否则API平台将不能充分利用，无法获得预期的投资回报。因此对于API技术的研究，更重要的是对于下一代网络业务提供方式的研究、业务模型以及业务管理模型的研究属于一个的新的研究方向，它包含许多待研究的课题和待开发的技术。