TOSI 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. MTOSI however has guide- lines on using JMS, though its usage is not mandatory for implementing MTOSI compliant APIs. OSS/J also supports XML, but the XML API is wrapped with Java API. The MTOSI back end implementation is not based on a specific technology as compared to OSS/J where the back end implementation is in Java. As MTOSI evolved from MTNM most of the issues in interface APIs were fixed and the defini- tions were to offer a service oriented interface on a heterogeneous platform environ- ment. So when multitechnology, multinetwork support is required MTOSI would be a good choice, while in open source based environment OSS/J would be the popular choice. Support to both these interface standards can be implemented in the same OSS solution. 25.6 Conclusion An application programming interface (API) is an interface that defines the ways by which an application program may request services from another application. APIs provide the format and calling conventions the application developer should Standard Interfaces use to work on the services. It may include specifications for routines, data struc- tures, object classes, and protocols used to communicate between the applications. The APIs are mostly abstract interface specifications and controls the behavior of the objects specified in that interface. The application that provides t