What are NGOSS and OSS/J?
NGOSS (New Generation Operations Systems and Software) and OSS/J (Operations systems and Software through Java) are telecommunications industry standards with the ultimate goal of promoting the delivery of reusable OSS solutions to service providers. The NGOSS program has focused on the business and systems aspects of OSS-solution delivery (the problem and solution statement) whereas OSS/J program has focused on the implementation and deployment aspects (the solution realization and deployment using Java technology).
The OSS/J initiative has delivered freely-available, testable API specifications, reference implementations, and test kits. Commercial products implementing the specifications are now available. Classic OSS/J interfaces are implemented on the following standards:
However, OSS/J is migrating towards the WS-I web services standards. The OSS/J Initiative recommends that a WS-I compliant WSDL specification be prepared for every existing OSS/J API. This will expose the same functionality that existed in the classic Java EE RMI-IIOP model into the platform independent XML based web services model.
Testing an OSS/J implementation with LISA
LISA is uniquely positioned to provide complete end to end testing of OSS/J implementations. To LISA, an OSS/J implementation appears like just another SOA "alphabet soup" of technologies. Not only can LISA test existing RMI-IIOP and JMS based services, but as individual services are migrated to WS-I compliant web services, LISA can continue to test them. The migration of an application to SOA usually doesn't happen overnight, it's a gradual process service by service. LISA is the only tool needed to test your OSS/J implementation through the entire migration process.
As an additional benefit, LISA supports the concept of test case data abstraction from test case procedure. With LISA, it is possible to create two test case procedures, one to test a classic Java EE based service, and a second parallel procedure to test the web service. But only one data set identifying the inputs and expected outputs would be necessary. That data set can be used to drive both test case procedures, and validate that the responses from both interfaces match. This verifies that when a client application begins calling the new web service interface, the integrity of the responses from the Java EE interface will be preserved.
Finally, OSS/J specifies use of JTA (Java Transaction API) and JCA (Java Connector Architecture) for use when interacting with backend data sources or legacy systems. However, the actual implementation of those backend data sources is intentionally left open ended to accommodate the system implementer's specific choice of database or legacy system. LISA can interface directly out of the box with any relational database that has a JDBC driver available for it. This allows test cases to validate the integrity of data in the storage tier against the middle tier services, all from one tool, all GUI driven with no code to write. For those who need to validate against proprietary legacy systems, the LISA Extension Kit provides an interface to create a connector to them as well.