Integration Interfaces. Licensee must develop, use and maintain all Integration Interfaces in compliance with applicable specifications and compatible with the most current version of the Xxxxxx Xxx application. Licensee shall not transfer data via an Integration Interface if the Integration Interface is out of compliance for more than 120 days. Licensee must make available to Xxxxxx Mae qualified personnel to promptly respond to technical questions pertaining to its Integration Interfaces.
Integration Interfaces. Different modules of the On-Time Architecture will communicate using standard inter- faces. For sake of clarity, we will represent these interfaces as standard UML interfac- es definitions but, in most of the cases, they have to be interpreted as web Services interfaces of distributed systems. Since the rise of Web 2.0 technologies, the difference between static and distributed interfaces are becoming more and more subtle, some languages doesn’t make any dif- xxxxxxx between the two, since communication frameworks and high-level program- ming languages can abstract the communication layer from the functional specifica- tions. Since the architecture is conceived to be modular and flexible, remote interfaces can become native and vice-versa, the architecture definition poses no limit on how the modules can be coupled. Functionally, the On-Time architecture adhere to a minimalist design pattern. Even though there are several guidelines that the modules must comply to, they are very simple building blocks that can be used in different ways to achieve the desired re- sults. In addition, the technology used allows for cross-language, cross-OS and cross- technologies integration without too much effort. The architecture will distinguish modules. Modules have been conveniently named against the WP name of the project. A single WP can have multiple modules and dif- ferent implementations (for example different WP4 Modules can exists, with different kind of optimization and planning algorithm). It is responsibility of the architecture to keep communications between the modules and forward data and messages to the correct endpoints. Basically, a module must carry on these functions: Be able to subscribe for events. Be able to publish events. Be able to access the Static and Operational Data Provider of the architecture. These three functional characteristics are the basics at which a module must adhere to be able to carry out its functions. To be able to receive events, a module need to implement the EventConsumer Inter- face. The EventConsumer Interface it is the basic requirement to process messages and it is shared both by modules than by the architecture (since also the architecture must be able to receive messages from modules). To access Operational and Static Data a module must know the location of a Data Pro- vider Service. This service is an abstraction between different systems that stores and manages data for railway systems, called Train Control Sys...
