cation committee. The certification committee will validate the report and the process used to create it. Once the certification committee acknowledges the certification of the product, the certification can then be published. The published certificates will also have a reference to the test execution report. The publication of the test report eases the procurement of certified products for faster integration. 25.5 MTOSI and OSS/J MTOSI focuses on reducing the cost of integration in a commercial environment by providing a full XML interface specification detailing the model, operations and communications enabling out of the box interoperability. The focus of OSS/J is also reduction of the integration cost in a partner/open-source environment. OSS/J pro- vides a Java interface specification that offers basic operations but does not contain the model or interaction as specific as in MTOSI. Instead, OSS/J allows sharing of reference implementations to enable interoperability. Thus it becomes evident that MTOSI and OSS/J are complementary technologies. Using a mapping/media- tion approach MTOSI and OSS/J can interoperate. For a closed partner engage- ment, OSS/J is best suited where as for an out-of-the-box commercial environment MTOSI is the best. Fundamentals of EMS, NMS and OSS/BSS OSS/J frame work MTOSI adapter MTOSI Figure 25.2 MTOSI and OSS/J can interoperate. OSS/J offers technology independent APIs. There are separate APIs for various OSS functions. MTOSI gives OSS interfaces for a multitechnology environment and is based on specific models. MTOSI models are defined in TMF 608. OSS/J, being associated to a generic set of operations, can have an adapter written when a specialized set of operations needs to be executed with MTOSI. This is shown in Figure 25.2 where the generic OSS/J framework has an MTOSI adapter for interac- tion wherever a defined set of operations are to be executed. MTOSI and OSS/J has some marked differences. While OSS/J is Java based, MTOSI is XML based with emphasis on Web services. MTOS